incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: several messages
Date Fri, 09 Jul 2004 21:30:34 GMT
On Fri, 9 Jul 2004, Andreas Hartmann wrote:
> Brian Behlendorf wrote:
>> In walking through the incubation documents (helping a couple of groups 
>> who have asked me about how to do this) it struck me that there was no 
>> requirement that the proposal provide a link to download and evaluate the 
>> code around which a project is being proposed - in fact it appears the 
>> code itself could be kept secret until project acceptance into the 
>> incubator.
> I'd like to express a concern about this. I think the decision about
> incubation should not depend on the code. When a the idea / goals /
> concepts of a project can attract developers, they would certainly
> be interested in improving the code base. Couldn't it even be
> possible to re-build the code base from scratch?
> Is it really useful to require a certain quality standard already
> in the beginning of the incubation process?

Good points.  One could propose a project without pre-existing code, along 
the lines of "I think this needs to be done, and I'm want to start writing 
code here for it".  But, so far all the Incubator projects to date have 
pointed to pre-existing code the project would bootstrap from.  And that 
seems to match the pattern of how many open source projects start - as a 
branch or continuation from a prior one.

Bad code can definitely be the basis for later good code; Linus once said 
the best way he found to spur developers to write device drivers for Linux 
was to check in a clearly broken driver for the device.  A missing driver 
wasn't enough to incent someone with that device to take a look; a broken 
or incomplete driver was instead a defect that needed to be fixed.

Much corporate software, though, is software we don't want to see. 
Without casting aspersions, let's say that pressures from deadlines, 
legacy customers, fixes optimized for "don't break the build tonight!" 
rather than "what's the right way to solve this?" don't always result in 
long-term quality.  I won't use that to characterize any of the 
contributions we've had to date from corporations, let me be clear; most 
likely, knowing the contributors, we've been seeing the creme of the crop. 
:)  It's still a concern one should have when starting a project. 
OpenOffice, for example, has still not gotten past much of its legacy, 4 
years after launching, and still has a huge learning curve for new 

> What if a company considers to introduce an open source strategy,
> but the decision depends on whether the code is accepted as an
> Apache project or not? I think they will avoid showing the code
> before the project is accepted or rejected.

Indeed, that is one subtext to my proposal.  I hold this idealistic image 
of Apache as a place where developers, who have work to get done and just 
want to be able to work with others on achieving the same goals (and be 
protected legally while doing it) can leave their corporate affiliations 
on the back of their chair and approach discussions and decision-making 
based on what's best for the community and the codebase.  At the same 
time, the majority of contributors here (by my reckoning, a real survey 
could be fun) are at least in part paid for their involvement by their 
employers, and that's because the employer benefits from the resulting 
work in some way.

That kind of influence isn't all bad - for example, it can help focus 
efforts on specific hard technial challenges that require full-time work, 
or to wrap up a development branch and make a release rather than the 
perpetual beta.

On the other hand, I don't want corporations to view Apache as a "channel" 
for broader adoption of a new standard they've invented, a way to get a PR 
bang to help the stock price, etc.  I am /not/ opposed to doing things 
like joint press releases or having us talk to execs about how we work or 
setting up, as we may in the future, some sort of corporate sponsorship 
plan to help with fundraising.  But when it comes to projects and their 
technical direction, I'd like to see us adopt policies that defuse the 
political tension that often arises.

One way to do that, I feel, is asking that proposals to the incubator for 
new projects for incubation be able to point to pre-existing code. 
Perhaps it's nothing more than a tarball sitting on a corporate server 
somewhere.  Perhaps it's already a SourceForge project, or codehaus, or 
Alphaworks, or, or whatever.  By requiring that, we would be 
asking companies to make the plunge into releasing something publicly 
under an Open Source license (doesn't have to be Apache's license first, 
though it would be once incubated) before bringing it to us.  That 
reduces the pressue on us to accept - instead of saying "accept this 
proposal, or this code isn't released at all", it's "accept this proposal, 
because Apache can help build a real community around the code."

On the flip side, I know that our brand is powerful enough in the business 
world, that hearing from an internal open-source advocate, "Apache is 
willing to host this project for us" could be compelling compared to 
"we'll run this project ourselves" - it might even be enough to encourage 
the company to make the release rather than keep it themselves.  Yet, I 
don't know if playing an Open Source Robin Hood is what we want to be; my 
hunch is that the most successful technologies tend to originate in the 
public sphere anyways, with companies pulling it in or building internal 
clones for a more mass-market product.

If it's a good idea for a company to Open Source a technology, it should 
be a good idea whether or not Apache is involved.  If we're involved, then 
in theory, we can make it even more successful, by removing the influence 
and power of a single vendor/developer, and constructing a 
consensus-driven "do-ocracy"[1].

Phew, OK, sorry about the long-winded piece.  But yeah, that's one 
meta-question I had hoped to ferret out by making my original proposal.
And then when I realized there were more practical advantages (such as 
being able to evaluate the quality of the code) I felt asking the simple 
question first would be a good approach.

On Fri, 9 Jul 2004, Cliff Schmidt wrote:
> +1
> If someone wants to propose a project, I think it is quite reasonable
> for them to show the code that would be the basis of the project.
> However, I think the interesting stuff is in the details here.  For
> instance:
> Q: must the source be licensed under the Apache License before
> project acceptance?
> IMO: no


> Q: must the source be licensed under an OSI-approved open source
> license?
> IMO: I could see arguments either way.  If the purpose is to assess
> the merit of the code itself, any legal mechanism that provides for
> anyone in the community to conveniently read the source should be
> acceptable, even if the license restricts distribution, for instance.
> However, if the purpose of this new rule is also to require commitment
> to open source that isn't dependent on the Apache brand, then we would
> specify the code must be available under an OSI-approved license prior
> to proposing.

It should at least be under a license that doesn't cause the person who 
views the code to be contaminated should they decide to work on a similar 
project elsewhere.  That means, no NDA's.  Given my broader thoughts 
above, my ideal would be that it would be Open Source licensed already.

> Q: what would this mean for project proposals that do not include an
> initial code base?
> IMO: While some might say that no project should start in Apache
> without an initial code base, I would personally like to allow for
> this possibility, depending on the make-up of the initial committers
> and related communities.  Therefore, I would suggest that any proposal
> that suggests the new project would be built on some particular initial
> code base would need to have that code base available for review.  Any
> proposal that does not suggest this (including those that might want to
> base a new project on some other piece of software without actually
> using the old source as a base) would not need to open any source.

Right.  Presumably if slightly later on there's a body of code that looks 
interesting, it can be evaluated by the PPMC for the same reasons.

> Q: if the bar to bring projects into the incubator is meant to be
> relatively low as long as the legal and community issues are reasonable,
> should we even be evaluating the code base at all?
> IMO: we could probably have long discussions about whether the best
> long term future for the ASF requires some degree of technical
> evaluation of projects or not; however, without diving into this issue
> for the moment, I would suggest that perusal of any significant code
> base could be done just for any glaring problems (potential legal
> entanglements with dependencies, inappropriate technical dependencies,
> etc).  Problems that are found may not necessarily have to be fixed
> before project approval, but I think it would be nice to allow major
> issues to be discovered and responded to during the evaluation of the
> proposal.


> Q: how close must the evaluated code base be to the one eventually
> contributed after project acceptance?  In other words, could a proposal
> show most of the planned contribution without having 100% of it ready?
> Could the contributor make changes to the source between the time of
> proposal and the initial grant (e.g. what about changing the license
> header?  what about doing a little more than that?)
> IMO: we shouldn't put strict limits on this -- any abuse of the
> intention behind this requirement (such as a significant bait-and-switch
> with code bases) would probably be obvious and could be dealt with on a
> case-by-case basis.


Anyone want to throw this up on the Wiki and see what sticks?


[1] I've heard a couple people use the term here, but Google appears to 
point to as the 
origin of the term...

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message