Brian Behlendorf wrote:
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.
[snippage]
i don't think i'm getting this. are you saying that, if they want to avoid revealing the code until the concept has been accepted, we should automatically ignore the proposal? 'show us the code or take a walk' ?
It's a statement that "Apache accepts it as a project" shouldn't be the trigger for a company to release its code under an Open Source license. It's my opinion, but I was looking to see who might share it. Showing the code is a litmus test of sorts of the proposers' intents, and I still think it's useful on technical and legal grounds in deciding whether to even allow a project in the front door.
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 do not think that is going to happen.
It's happened already, Ken. It's not been much of a problem in practice, and I think we've kind of looked at this as a grand experiment of sorts... but it's interesting to note that those incubator projects that consist of code from larger companies and associated with a big-bang PR tend to not see as much participation in the incubator as the more grass-roots proposals like Geronimo or the more modest launches like XMLBeans. So I'm trying to explore why, and how can we improve.
not only because we've been publicly thorny about this issue in the past, but because the people directly tasked with the interface -- the incubator -- take their jobs seriously and are especially vigilant.
I don't intend my "it's happened" as a slight on incubator people, nor should this be seen as a bad thing - it goes back to my own involvement in starting Jakarta and XML, and I think it's been a useful thing. But I know it's the impression that people in the public have when I get calls out of the blue from companies who (paraphrased, exaggerated slightly) "want to open-source this prototype legacy code we wrote (that we couldn't build a business around) through Apache so we can get a PR boost for our upcoming [IPO/product release/funding announcement/etc]." Such people are of course ill-informed about why we exist, what we can do for them, and what we expect from groups who approach us to become projects; but I thought it would be useful to see if there are things we can do at the inception of an incubator project to address this mis-perception in a way copacetic to our own principles of fairness, transparency, and community. That's when a requirement that the code be already published on a public web site under an open source license (or otherwise available for inspection in an unencumbered way) seemed an interesting litmus test.
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.
i don't see that a 'show us the code' requirement is a technical direction at all. i see it as a political/philosophical stance.
You might not have understood me above. I agree, it is a statement of philosophy, as much as our vaunted "three +1s, no vetos" is a statement of philosophy. When the code is available at the time the incubator is considering whether to accept a project into the incubator, the discussion can be quite technical - is the code base suitable for the direction the proposed project would want to head in, does this project overlap too much with another existing project, etc. On the other hand, with only the description of what the code does, you have to trust the individuals or company behind the proposal to be accurately describing what the code does, its quality/suitability, and perhaps that proposer's history in prior situations. The latter feels more politically tense" than the former - thus my statement quoted above.
i have no problem with the incubator making a case-by-case evaluation of what's needed to process/accept a proposal. i *do* have a problem with setting down a policy that ties its hands, whether that policy is 'show us the code' or 'you don't need to show us the code.'
Every requirement is a "ties its hands" kind of thing - none are, prima facie, good or bad. It's what we decide for ourselves. It's kind of like the no-more-than-50%-from-a-single-employer requirement... er, guideline... er, suggestion... for projects to graduate out of the incubator. Flexibility is good, but so is predictability.
That reduces the pressue on us to accept - instead of saying "accept this proposal, or this code isn't released at all"
i think everyone involved is strong-willed enough to bristle and take umbrage at such a thing, rather than being cowed by it.
Obviously it's not said directly as I said it above; the communication is more subtle. And you did quote me out of the context that makes that sentence make sense.
'show us the code' could be construed as 'we don't want to even look at your code unless you let everyone else see it at the same time.' i'm not sure how i feel about that construction.
Doesn't everyone get a look at it eventually anyways? Isn't subscription to [EMAIL PROTECTED] open anyways?
In fact I thought we had agreement that allowing only select people to look at the code under NDA was not the best idea... I certainly wasn't arguing for it.
Anyways, I'll desist on this if it doesn't seem like there's convergence towards something. Like many conversations in the ASF these days the responses strike me more as "here's where you're wrong" rather than a constructive discussion, to which I feel compelled to respond point-by-point (trying to find middle grounds), and I don't have the energy to campaign for something that just seemed like a simple oversight. Carry on.
Brian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
