On Tue, Mar 22, 2011 at 09:07:40PM -0700, Henri Yandell wrote:
> > ... except that the ASF would never actually use this document. Legal
> > affairs
> > expertise is a limited resource, and if we don't have skin in the game, I'm
> > hesitant to suggest that it live there.
>
> I'll challenge that one. The ASF employ individuals to develop, and
> they contribute back as a part of their job.
Ah, good point!
> So potential goal there - your liberal policy would have to stretch to
> the extremes of the ASF and other foundation employers.
+1. Let's at least draft it in such a way that the ASF might conceivably
adopt it. ASF adoption might prove infeasible for any number of unforseen
reasons, but if it happens, it will send a signal that we think the document
is at least legally sound.
You're right that setting that goal will constrain the policy's content. I
imagine Joe Schaefer would chafe if he had to get management approval to
whitelist each project he wanted to contribute to. :)
> > I've looked around the community.apache.org website, and while there is not
> > an
> > obvious home for it there, it's an interesting question whether a place
> > could
> > be carved out for it. Trawling through email archives, past board reports,
> > and blog entries, I see that coordinating Google Summer of Code has been a
> > major focus, and that questions have been asked like "How might we attract
> > more technical writers to the ASF?". This seems like a similar outreach
> > activity, intended to bring more people to the ASF and make it easier for
> > them
> > to contribute.
>
> The primary value would be in decreasing the time it takes for a company to
> go from user to contributor to committer-employer, incubator-source and/or
> sponsor.
Well stated. That would be this document's value to the Apache Software
Foundation directly, and provides justification for expending ASF resources to
vet it and adopt it.
Facilitating increased corporate contributions to the ASF also provides value
to those of us who labor on ASF projects as developers, by increasing the
demand for our services. I'm lucky -- I have a great job at a growing company
where about 75% of my hours are spent on an ASF project. I would like more
people to have jobs like mine, and if my fortunes were to change unexpectedly,
I would like to be able to find another one like it.
Extrapolating outwards for the sake of argument, increasing contributions to
the ASF and to open source in general aids the software industry at large. To
the extent that our industry competes with others within the broader economy,
we are better off when we can pool resources. And it is to our advantage when
software companies consumed by the creative destruction of capitalism leave
something of value behind -- both in terms of raw code and developer track
records.
Nevertheless, the narrow interests of the company/organization must remain
paramount as we draft this document. Companies should adopt this policy
because it's a good deal for them:
* It decreases costs. (They get to spend minimal time modifying a
boilerplate document instead of drafting a custom document themselves.)
* It lowers risk. (The policy was drafted by knowledgeable open source
developers with the express goal of blessing common practice. As adoption
spreads, developers will become increasingly familiar with how to comply
with it effectively and its strengths and weaknesses will be probed at
other companies.)
* It lets employees and job candidates know where everyone stands,
potentially yielding a recruiting advantage.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional commands, e-mail: community-h...@apache.org
