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 developers.
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 java.net, 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
Agreed.
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.
+1.
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.
+1.
Anyone want to throw this up on the Wiki and see what sticks?
Brian
[1] I've heard a couple people use the term here, but Google appears to point to http://www.libertyforall.net/2002/archive/do-ocracy.html as the origin of the term...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
