incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: several messages
Date Wed, 14 Jul 2004 09:32:26 GMT
On Tue, 13 Jul 2004, Rodent of Unusual Size wrote:
> 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 general@incubator 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.


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

View raw message