Outside view on incubator policy to initial committer list

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Outside view on incubator policy to initial committer list

Martijn Dashorst
All,

Just to pose an outsider view, being new to the ASF and not to hijack
the discussion on the CFX/CeltiXFire, I would like to share my views
on the policy of the incubator.

From the documents I have read on the policy for entering, being
inside and graduating from the incubator there is a lot of talk on
process, but not a lot of explanation on *why* the process is in
place, nor on how things are done.

The first 'gripe' is the uncertainty for existing open source projects
that want to join the ASF that their current contributors will be
allowed to work on the project at Apache. The documents clearly state
that such karma needs to be earned based on merit. It never states
that merit earned in the past for the project can and *WILL* be used.
This can only be found in heated discussions on this list.

You will find in such discussions a variety of views, but the most
restrictive, and in my opinion negative for existing projects is the
one that wants only the mentors being on the initial PPMC/committers
list, and have the incubating community earn their merit on apache
ground using patches, mailinglist activity and whatnot, without giving
the originating developers the karma to commit directly in Apache
incubator SVN for the project. This is very damaging for a project
that is already active outside the ASF and will grind it to a halt.

If the prevailing opinion is that previously gained merit outside the
ASF is taken into account, the policy should note that explicitly.

The second gripe is the fact that only the Incubator PMC members of
the PPMC have binding votes. I think I understand the reasoning for
this, but it is not clear how the PMC members will excercise their
binding votes. Will they affect the average day-to-day affairs within
a community where the mentors have no direct affiliation with? Or is
this only a guiding vote, for things such as:
 - withholding a release when the podling is not considered ready
 - not granting karma (with good backing reasoning)
 - not taking in external code bases without the correct grant
 - etc.
The policy should make it clear that the PPMC chairs with the binding
votes, only have that executive power to vote on such things regarding
process.

The third gripe is that graduation has two components: a measurable
component (active community, diverse, all legal matters resolved, no
violating code, etc) and a non-measurable component (mature enough to
be an 'apache' project). Given the sometimes extreme views expressed
here (a nice read though :-), it is for an existing project really
hard to trust such a process when you already have a healthy community
which is basically put on hold whilst incubating, if you follow the
incubator policy (and some egos) to the letter.

Note that I understand the opposite views presented in the CFX case
and I sympathize with all of them. I just wanted to express a view of
someone coming from the outside, and looking at the process as it
takes place.

For existing projects it is a very hard decision to enter the
incubator and the uncertain process until graduation. As the ASF you
(we I should say) really have to put yourself into the shoes and
clothes of the small community that is about to join a rollercoaster
with unknown process, procedures, laws and above all, unwritten rules
of conduct. It is quite something when a team has worked for 2 years
two or three jobs worth of free time  on a project and it 'hands it
over to the incubator'. Scary poo indeed.

Martijn

--
<a href="http://www.thebeststuffintheworld.com/vote_for/wicket">Vote</a>
for <a href="http://www.thebeststuffintheworld.com/stuff/wicket">Wicket</a>
at the <a href="http://www.thebeststuffintheworld.com/">Best Stuff in
the World!</a>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Outside view on incubator policy to initial committer list

Garrett Rooney
On 10/3/06, Martijn Dashorst <[hidden email]> wrote:

> All,
>
> Just to pose an outsider view, being new to the ASF and not to hijack
> the discussion on the CFX/CeltiXFire, I would like to share my views
> on the policy of the incubator.
>
> From the documents I have read on the policy for entering, being
> inside and graduating from the incubator there is a lot of talk on
> process, but not a lot of explanation on *why* the process is in
> place, nor on how things are done.

I can understand all the gripes you bring up, and I'll try to address
each of them in turn...

> The first 'gripe' is the uncertainty for existing open source projects
> that want to join the ASF that their current contributors will be
> allowed to work on the project at Apache. The documents clearly state
> that such karma needs to be earned based on merit. It never states
> that merit earned in the past for the project can and *WILL* be used.
> This can only be found in heated discussions on this list.

Ok, so for the record, I don't think anyone involved in the incubator
thinks that ANY committer on an existing open source project that
moves to the ASF should lose that status in the process.  Unless
there's some sort of legal situation where the person can't sign the
CLA there should be NO reason that sort of thing should ever happen.

The reason there have been recent discussions about who gets commit
and who doesn't is rooted in a totally different situation (people who
were not formerly developers on the codebase in question being granted
commit as part of bringing the project to the ASF, without having done
anything to earn it).

> You will find in such discussions a variety of views, but the most
> restrictive, and in my opinion negative for existing projects is the
> one that wants only the mentors being on the initial PPMC/committers
> list, and have the incubating community earn their merit on apache
> ground using patches, mailinglist activity and whatnot, without giving
> the originating developers the karma to commit directly in Apache
> incubator SVN for the project. This is very damaging for a project
> that is already active outside the ASF and will grind it to a halt.

I don't think that anyone feels that this sort of precedure should be
followed for an existing open source project.  I certainly don't.

> If the prevailing opinion is that previously gained merit outside the
> ASF is taken into account, the policy should note that explicitly.

I believe that is the case, and I believe that it should be noted
explicitly in the policy.  There really should be two sets of
guidelines, one for existing open source projects, and one for
projects that are just becoming open source, IMO.

> The second gripe is the fact that only the Incubator PMC members of
> the PPMC have binding votes. I think I understand the reasoning for
> this, but it is not clear how the PMC members will excercise their
> binding votes. Will they affect the average day-to-day affairs within
> a community where the mentors have no direct affiliation with? Or is
> this only a guiding vote, for things such as:
>  - withholding a release when the podling is not considered ready
>  - not granting karma (with good backing reasoning)
>  - not taking in external code bases without the correct grant
>  - etc.
> The policy should make it clear that the PPMC chairs with the binding
> votes, only have that executive power to vote on such things regarding
> process.

I believe the problem here is a misunderstanding about how "binding
votes" are actually used in ASF projects.  In a normal ASF project,
who has a binding vote and who does not is almost never spoken of.
It's just not an issue.  When talking about applying a new patch or
ways to best fix a bug, an informal "+1" from a new contributor or
committer who is not on the PMC is just as welcome as one from a
seasoned PMC member.  It's NEVER been the case in my experience that
people would be held off from committing a change until enough
"binding" votes were gathered, that would be insane, and projects
would grind to a halt in that situation.

The only time that people need to care about making sure there are
enough binding votes are for things like releases, granting commit
access, adding people to the PMC, importing new codebases, stuff like
that.

> The third gripe is that graduation has two components: a measurable
> component (active community, diverse, all legal matters resolved, no
> violating code, etc) and a non-measurable component (mature enough to
> be an 'apache' project). Given the sometimes extreme views expressed
> here (a nice read though :-), it is for an existing project really
> hard to trust such a process when you already have a healthy community
> which is basically put on hold whilst incubating, if you follow the
> incubator policy (and some egos) to the letter.

Yes, it is definately unfortunate that some components in graduation
are difficult to quantify, but there really isn't much of a way around
that.

> Note that I understand the opposite views presented in the CFX case
> and I sympathize with all of them. I just wanted to express a view of
> someone coming from the outside, and looking at the process as it
> takes place.
>
> For existing projects it is a very hard decision to enter the
> incubator and the uncertain process until graduation. As the ASF you
> (we I should say) really have to put yourself into the shoes and
> clothes of the small community that is about to join a rollercoaster
> with unknown process, procedures, laws and above all, unwritten rules
> of conduct. It is quite something when a team has worked for 2 years
> two or three jobs worth of free time  on a project and it 'hands it
> over to the incubator'. Scary poo indeed.

I understand that it's definately scary, but keep in mind, you're not
really "handing it over", there's no "Us and Them" here, just Us.
Yes, you have to accept that for a period of time you'll need to run
some things by Incubator PMC members, who will make sure that big
ticket items (like releases) are following the guidelines that are
expected for ASF projects, but well, you'll be expected to follow
those same rules post-incubation at the ASF anyway, so assuming you're
actually doing things "right", getting 3 people to say "yep, looks
good" shouldn't be that huge of a problem.

Could it be easier?  Sure.  We could certainly have better
documentation (although what's there now is light years better than
what used to be).  We could have more Incubator PMC members voting on
releases.  But in the end I don't think the reality of being an
incubator project is as bad as it may look at first glance.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Outside view on incubator policy to initial committer list

Leo Simons
In reply to this post by Martijn Dashorst
Hey Martijn,

do keep sending these e-mails. Less replies doesn't mean that its  
less valuable.

On Oct 3, 2006, at 9:38 PM, Martijn Dashorst wrote:
> Just to pose an outsider view, being new to the ASF and not to hijack
> the discussion on the CFX/CeltiXFire, I would like to share my views
> on the policy of the incubator.

I'm gonna respond in the generic rather than specific points.

Rest assured, the whole CXF thread doesn't apply to projects like  
Wicket. Where wicket was a solid open source community already, CXF  
was an attempt to start something by merging something corporate with  
something open source, pour in some unknowns, and then hope for the  
best.

Where wicket's technology space is essentially well-understood by  
most incubator PMC members (and asf peeps world wide, most likely),  
the stuff CXF focusses on is still buzzword-ridden and thus well-
avoided by many.

Do you really think a wicket contributor would've waited two months  
for his account if the people around him would've been happily  
committing code? Do you think you would've? I would guess board@  
would've known about it by then, if not slashdot...

...It is simply a world of difference. Which makes writing a single,  
sane, understandable, clear, permanent, policy for both (well, n,  
there's a new world every time there's a new project) quite hard  
(I've never understood why we try, but that's another subject). For  
example, where I'll happily go and weigh what wicket contributors  
contributed to wicket before it came to apache (especially if those  
contributors rub my nose in it), I'm not gonna care a rat's ass what  
Joe Corporate Developer Who Is Unknown To Google Or Koders.com  
contributed to a corporate codebase before his company came to apache.

Bluntly, a project like Wicket starts at 90% "community clearance  
done" (just some IRC things to convince people of ;) ), that other  
project starts at -20%-100% depending on which company it came from.

In the end, this means you don't put your trust into the process. You  
put your trust into the people that make that process work, and into  
processes where what those people say and do (and vote) matters above  
and beyond most (some of it is legal shtuff, can vote all you like  
there, ain't gonna help) process description.

Which, getting back to CXF, is now getting me really worried, since  
its champion and most active mentor resigned from his position.

LSD



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Outside view on incubator policy to initial committer list

Steve Vinoski
Sorry, Leo, but I don't see the point of your message below making  
statements about CXF that are wholly untrue.

First, CXF is corporate? That's incorrect, given that it's purely the  
combination of two separate open source projects, Celtix and XFire.  
Celtix was developed completely under the ObjectWeb community, and  
XFire was developed under Codehaus.

Second, CXF is nothing but a bunch of buzzwords? I've personally been  
working for over 15 years now with numerous people in various  
middleware communities on the technologies and techniques that have  
led to what's going into CXF. Over the years those communities have  
delivered a variety of commercial and open source systems based on  
those techniques that run every single day, often for years at a  
time, in production. I can assure you that these approaches are quite  
far from being just buzzwords. You very likely use such systems every  
single day, in fact, perhaps without knowing it -- whenever you make  
a phone call or carry out a financial transaction, for example.  
(Coincidentally, Mark Little, one of the people directly affected by  
this whole issue, has done tons of work in this area over the years  
as well.)

Lastly, CXF has strong champions like Dan D. and Dan K. working on  
it, along with some strong committers. I have no doubt they'll  
continue to work with their mentors to make CXF a success.

--steve

On Oct 6, 2006, at 12:43 PM, Leo Simons wrote:

> Hey Martijn,
>
> do keep sending these e-mails. Less replies doesn't mean that its  
> less valuable.
>
> On Oct 3, 2006, at 9:38 PM, Martijn Dashorst wrote:
>> Just to pose an outsider view, being new to the ASF and not to hijack
>> the discussion on the CFX/CeltiXFire, I would like to share my views
>> on the policy of the incubator.
>
> I'm gonna respond in the generic rather than specific points.
>
> Rest assured, the whole CXF thread doesn't apply to projects like  
> Wicket. Where wicket was a solid open source community already, CXF  
> was an attempt to start something by merging something corporate  
> with something open source, pour in some unknowns, and then hope  
> for the best.
>
> Where wicket's technology space is essentially well-understood by  
> most incubator PMC members (and asf peeps world wide, most likely),  
> the stuff CXF focusses on is still buzzword-ridden and thus well-
> avoided by many.
>
> Do you really think a wicket contributor would've waited two months  
> for his account if the people around him would've been happily  
> committing code? Do you think you would've? I would guess board@  
> would've known about it by then, if not slashdot...
>
> ...It is simply a world of difference. Which makes writing a  
> single, sane, understandable, clear, permanent, policy for both  
> (well, n, there's a new world every time there's a new project)  
> quite hard (I've never understood why we try, but that's another  
> subject). For example, where I'll happily go and weigh what wicket  
> contributors contributed to wicket before it came to apache  
> (especially if those contributors rub my nose in it), I'm not gonna  
> care a rat's ass what Joe Corporate Developer Who Is Unknown To  
> Google Or Koders.com contributed to a corporate codebase before his  
> company came to apache.
>
> Bluntly, a project like Wicket starts at 90% "community clearance  
> done" (just some IRC things to convince people of ;) ), that other  
> project starts at -20%-100% depending on which company it came from.
>
> In the end, this means you don't put your trust into the process.  
> You put your trust into the people that make that process work, and  
> into processes where what those people say and do (and vote)  
> matters above and beyond most (some of it is legal shtuff, can vote  
> all you like there, ain't gonna help) process description.
>
> Which, getting back to CXF, is now getting me really worried, since  
> its champion and most active mentor resigned from his position.
>
> LSD
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Outside view on incubator policy to initial committer list

Leo Simons
On Oct 6, 2006, at 11:36 PM, Steve Vinoski wrote:
> Sorry, Leo, but I don't see the point of your message below making  
> statements about CXF that are wholly untrue.

The point was to provide some insight into the differences between  
different projects under incubation and how that leads to a different  
kind of incubation taking place. Also note that, to begin with, "the  
whole CXF thread" referred to a "whole" bunch of things that weren't  
really all about CXF at all, and just as much about the "general  
case". In this light, CXF is an unhappy example for a wider  
discussion, for which I'm sorry, but it tends to be somewhat  
difficult to avoid.

The fact that you consider what I said about CXF to be wholly untrue  
is probably since you (a) misinterpreted my statements, (b) you  
fundamentally disagree with my view on the SOA space and the  
assertions I made about it, and (c) you're missing some incubation  
terminology. I'm sorry, but it's probably not because I know nothing  
about middleware or SOA or CXF or incubation.

> First, CXF is corporate?

*sigh*. I said, "CXF was an attempt to start something by merging  
something corporate with something open source".

> That's incorrect, given that it's purely the combination of two  
> separate open source projects, Celtix and XFire. Celtix was  
> developed completely under the ObjectWeb community, and XFire was  
> developed under Codehaus.

When you look at the people (not the code), it is a combination of  
people from two open source projects, and some additional people. The  
project has quite a few committers who are paid to work on it. At  
least one company whose representatives I spoke with (IONA) has told  
me they plan to donate various other in-house things.

When you look at the project its stated goals, it is a combination of  
the goals from two open source projects, and some additional goals  
(the most obvious two being (a) becoming an Apache project and (b)  
merging two big existing open source codebases).

Various corporations have business strategies that involve CXF. Some  
of them but out corporate-oriented press releases or datasheets [1]  
which are, ehm, "itchy" from an apache-style open source perspective  
that say things like "Users who are interested in getting started can  
download Celtix 1.0 today at ObjectWeb, and developers who want to  
get involved in its next generation can contribute to the CeltiXfire  
project in the Apache Incubator" which is *just* enough off-key to be  
slighly annoying.

So, I do consider CXF a merge between something corporate and  
something open source. That isn't a bad thing in and of itself. It is  
just a difference (with wicket), and one that should be taken into  
account (when considering the incubation policies and processes).

For example, one project I've helped mentor, Harmony, did much the  
same thing -- it started with some donations from existing open  
source projects, some corporate ones, and it has various people paid  
by a few companies to work on it. Harmony still has a little bit of a  
corporate feel to it at times, but we've worked hard to shed as much  
of it as possible, hopefully to the point that the average CompSci  
student can start contributing and feel happy about it. The point is  
that this takes effort, effort which a project like wicket doesn't  
have to expend.

And even *if* you disagree that there's "corporate elements" to take  
into account here, I still suggest not calling CXF "purely the  
combination of two [projects]".

> Second, CXF is nothing but a bunch of buzzwords?

I didn't say CXF is nothing but a bunch of buzzwords. But contrast  
"SCA integration" with "built-in support for HTTP sessions" and  
you'll get the point.

I said "the stuff that CXF focusses on is still buzzword-ridden".  
There's so many of them that they get their own acronyms. SOA (has  
got to be my favorite), WS, ESB, etc. It's not CXF's fault (though  
I'd love an ASF project that would just do away with them all and be  
simple to understand to the rest of the world) this part of the  
technology space is not so good at explaining itself as it could be.

> I've personally been working for over 15 years now with numerous  
> people in various middleware communities on the technologies and  
> techniques that have led to what's going into CXF. Over the years  
> those communities have delivered a variety of commercial and open  
> source systems based on those techniques that run every single day,  
> often for years at a time, in production. I can assure you that  
> these approaches are quite far from being just buzzwords. You very  
> likely use such systems every single day, in fact, perhaps without  
> knowing it -- whenever you make a phone call or carry out a  
> financial transaction, for example. (Coincidentally, Mark Little,  
> one of the people directly affected by this whole issue, has done  
> tons of work in this area over the years as well.)

(which whole issue?). In any case, good for you guys. I didn't say  
that all the middleware work you guys (or anyone) have done through  
the ages is "just buzzwords", or that some of it doesn't "run every  
single day, often for years at a time, in production".

But I'll happily stick to my assertion that there's too many of them  
buzzy words (TLAs too, lots of TLAs), and that this is quite a  
reasonable indicator some people use to not touch these things even  
with a very long pole. It's not a beef with CXF, it's a beef with a  
whole technology space, and it is something that causes various  
problems for open source communities. For example, try explaining to  
your favorite ASF board member the difference and similarities  
between CX, XF, CXF, Axis1, Axis2, Synapse, Tuscany, and the-new-SOA-
related-project-proposed-for-incubation-two-months from now, in 2  
minutes.

> Lastly, CXF has strong champions like Dan D. and Dan K. working on  
> it, along with some strong committers. I have no doubt they'll  
> continue to work with their mentors to make CXF a success.

Sorry, champion in incubator context is a specific term referring to  
a specific role taken on by a specific person - the original "old  
fart" at the ASF that helps a fledgling project with the first few  
phases of the project@apache. That project then alienating that very  
person a few months down the road is what causes the worry, since in  
a healthy situation that would be the last person you'd possibly  
alienate.

It is not the best word (read mail archives for why we stuck with it  
anyway), and it definitely isn't meant to imply other people are not  
to be considered "champions" in their own right. When you read  
"champion" on these mailing lists, think "specific incubator handyman  
person that takes care of some specific things".

cheers,

Leo

PS: the top posting doesn't make untwining these threads any easier...

[1] - http://www.iona.com/info/aboutus/collateral/CeltiXfire- 
datasheet.pdf

> On Oct 6, 2006, at 12:43 PM, Leo Simons wrote:
>> Hey Martijn,
>>
>> do keep sending these e-mails. Less replies doesn't mean that its  
>> less valuable.
>>
>> On Oct 3, 2006, at 9:38 PM, Martijn Dashorst wrote:
>>> Just to pose an outsider view, being new to the ASF and not to  
>>> hijack
>>> the discussion on the CFX/CeltiXFire, I would like to share my views
>>> on the policy of the incubator.
>>
>> I'm gonna respond in the generic rather than specific points.
>>
>> Rest assured, the whole CXF thread doesn't apply to projects like  
>> Wicket. Where wicket was a solid open source community already,  
>> CXF was an attempt to start something by merging something  
>> corporate with something open source, pour in some unknowns, and  
>> then hope for the best.
>>
>> Where wicket's technology space is essentially well-understood by  
>> most incubator PMC members (and asf peeps world wide, most  
>> likely), the stuff CXF focusses on is still buzzword-ridden and  
>> thus well-avoided by many.
>>
>> Do you really think a wicket contributor would've waited two  
>> months for his account if the people around him would've been  
>> happily committing code? Do you think you would've? I would guess  
>> board@ would've known about it by then, if not slashdot...
>>
>> ...It is simply a world of difference. Which makes writing a  
>> single, sane, understandable, clear, permanent, policy for both  
>> (well, n, there's a new world every time there's a new project)  
>> quite hard (I've never understood why we try, but that's another  
>> subject). For example, where I'll happily go and weigh what wicket  
>> contributors contributed to wicket before it came to apache  
>> (especially if those contributors rub my nose in it), I'm not  
>> gonna care a rat's ass what Joe Corporate Developer Who Is Unknown  
>> To Google Or Koders.com contributed to a corporate codebase before  
>> his company came to apache.
>>
>> Bluntly, a project like Wicket starts at 90% "community clearance  
>> done" (just some IRC things to convince people of ;) ), that other  
>> project starts at -20%-100% depending on which company it came from.
>>
>> In the end, this means you don't put your trust into the process.  
>> You put your trust into the people that make that process work,  
>> and into processes where what those people say and do (and vote)  
>> matters above and beyond most (some of it is legal shtuff, can  
>> vote all you like there, ain't gonna help) process description.
>>
>> Which, getting back to CXF, is now getting me really worried,  
>> since its champion and most active mentor resigned from his position.
>>
>> LSD


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Outside view on incubator policy to initial committer list

robert burrell donkin-2
In reply to this post by Martijn Dashorst
On 10/3/06, Martijn Dashorst <[hidden email]> wrote:

> From the documents I have read on the policy for entering, being
> inside and graduating from the incubator there is a lot of talk on
> process, but not a lot of explanation on *why* the process is in
> place, nor on how things are done.

one of my aims in the documentation revision is to clearly separate
policy and process from explanation and discussion. there's a lot of
work still needed on the discursive documentation.

the short answer is that the process has been created and policy
defined by a series of votes.

> The first 'gripe' is the uncertainty for existing open source projects
> that want to join the ASF that their current contributors will be
> allowed to work on the project at Apache. The documents clearly state
> that such karma needs to be earned based on merit. It never states
> that merit earned in the past for the project can and *WILL* be used.
> This can only be found in heated discussions on this list.

it's important to realise that the democractic nature of the process
means that gaurantees are not possible. there is neither a judge nor a
jury objectively testing an application against criteria. whilst the
incubator retains it's democractic process, policy should not mandate
how electors shall vote.

but i hope and expect (given the electorate) that their votes would
acknowledge existing karma.

> The second gripe is the fact that only the Incubator PMC members of
> the PPMC have binding votes. I think I understand the reasoning for
> this, but it is not clear how the PMC members will excercise their
> binding votes. Will they affect the average day-to-day affairs within
> a community where the mentors have no direct affiliation with? Or is
> this only a guiding vote, for things such as:
>  - withholding a release when the podling is not considered ready
>  - not granting karma (with good backing reasoning)
>  - not taking in external code bases without the correct grant
>  - etc.
> The policy should make it clear that the PPMC chairs with the binding
> votes, only have that executive power to vote on such things regarding
> process.

apache has PMCs not from a love of bureaucracy but because official
committees can take official decisions. apache believes that projects
should have autonomy and in delegating decision making to
self-organizing communities.

if PPMCs are official committees (which IMO isn't too clear ATM) then
all PPMCers can cast binding votes. if not then they can't.

the stuff listed as process is pretty much the same as a list of stuff
that should require an official vote. official decisions by the
(P)PPMC should only be taken for matters that require an official
decision. for most other things, discussion, lazy consensus or
unofficial votes are better approaches. IMHO any project that counts
binding official votes for day-to-day matters is most likely
unhealthy. the (P)PMC isn't intended to be a oligarchy. i would expect
incubator PMCers to start taking an active interest in any podling
whose PPMC started acting as such. this probably isn't captured very
well in the incubator documentation and need to be.

> The third gripe is that graduation has two components: a measurable
> component (active community, diverse, all legal matters resolved, no
> violating code, etc) and a non-measurable component (mature enough to
> be an 'apache' project). Given the sometimes extreme views expressed
> here (a nice read though :-), it is for an existing project really
> hard to trust such a process when you already have a healthy community
> which is basically put on hold whilst incubating, if you follow the
> incubator policy (and some egos) to the letter.

any process can be subverted. apache trusts communities not process.
decisions are taken in public before the court of public opinion. so,
look at the people, not the process.

the incubator PMC is almost entirely composed of apache members. the
members elect the board and are the ultimate authority at apache. if a
community does not trust the apache membership then it cannot trust
apache and needs to create it's own organisation.

members are elected by the existing membership and typically have many
years of open source experience. i estimate that the incubator PMC
collectively has well over 200 years of collective open source
experience.

if the process is getting in the way and results in a community having
to put itself on hold, then it needs to be improved. if anyone has any
specific ideas, pull together a proposal to change the process.

<snip>

> For existing projects it is a very hard decision to enter the
> incubator and the uncertain process until graduation. As the ASF you
> (we I should say) really have to put yourself into the shoes and
> clothes of the small community that is about to join a rollercoaster
> with unknown process, procedures, laws and above all, unwritten rules
> of conduct. It is quite something when a team has worked for 2 years
> two or three jobs worth of free time  on a project and it 'hands it
> over to the incubator'. Scary poo indeed.

apache is a rollercoaster. delegation is scary. democracy is scary.

if the incubator were to mandate rules of conduct and laws for
podlings then it would be acting against it's own principles. when a
project graduates it needs to be capable of both self-governance and
acting in accordance with the principles of open development. in the
vast majority of cases, this means change and growth.

IMO the major problem is not lack of policy and rules but lack of
documented guidelines.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Outside view on incubator policy to initial committer list

Noel J. Bergman
In reply to this post by Leo Simons
Leo Simons wrote:

> Rest assured, the whole CXF thread doesn't apply to projects like
> Wicket. Where wicket was a solid open source community already

+1

I normally would post a "me, too" e-mail like this, but I do want to
reassure the Wicket folks!

        --- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Outside view on incubator policy to initial committer list

Noel J. Bergman
In reply to this post by robert burrell donkin-2
Robert Burrell Donkin wrote:
> Martijn Dashorst wrote:
> > From the documents I have read on the policy for entering, being
> > inside and graduating from the incubator there is a lot of talk on
> > process, but not a lot of explanation on *why* the process is in
> > place, nor on how things are done.

It is fairly common to separate process from policy and justification.  You
can see this in the Bible (the Written Law of the Torah and the Oral Law
explaining how to apply the Written Law), the US Constitution and the papers
written by the Framers, etc.

I personally favor a small set of processes that allow trusted people to
make decisions based upon their understanding of ASF philosophy over a more
elaborate and complex set of rules that govern people.

> > The first 'gripe' is the uncertainty for existing open source projects
> > that want to join the ASF that their current contributors will be
> > allowed to work on the project at Apache.

That should not be the case, and anyone who says otherwise is
misunderstanding policy.

> > The second gripe is the fact that only the Incubator PMC members of
> > the PPMC have binding votes. I think I understand the reasoning for
> > this, but it is not clear how the PMC members will excercise their
> > binding votes.

I expect them to exercise their oversight for the benefit of the community.
And I would also like to emphasize that vote counting is the absolute worst
form of decision making.  Decisions should be a consensus.  If there are
disagreements, work out a synthesis that makes everyone happy.  If you
cannot, in the end, then the community can make the best available choice,
but whenever you cannot reach a true consensus, the community loses.


> the incubator PMC is almost entirely composed of apache members.

And the Apache Software Foundation Members are the owners (shareholders),
which means that they have the ultimate decision making authority in the
end.

> if a community does not trust the apache membership then it cannot trust
> apache and needs to create it's own organisation.

+1

> i estimate that the incubator PMC collectively has well over 200 years
> of collective open source experience.

I suspect that you're off by a significant upside multiplier.

> if the process is getting in the way and results in a community having
> to put itself on hold, then it needs to be improved. if anyone has any
> specific ideas, pull together a proposal to change the process.

Absolutely!

        --- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]