Aaron Bannert wrote:
> >I don't know if the 'revolution' rule is specific to jakarta > >or is implied by the 'majority takes the name' - but by definition > >a revolution can go over a veto ( otherwise it won't be a majority, > >but one person that can make this kind of decisions ). > > > What is this 'revolution' rule I hear of so often? Is there a document > out there or something that I can read?
Yes, there is one but I'm currently offline so I can't point you to it (but I'm sure others will). Just allow me to give my perspective on the concept which I believe it's *very* important.
The 'rules for revolutionaries' was proposed by James Duncan Davidson as a way to potentially dissipate the negative energy created by forking friction.
We are all aware that 'forking' is the worst thing that can happen to an open development effort. The reason is that the energy behind a development effort is the community and a successful fork will split the community, and ego forces will keep them separate.
The idea of Duncan was to try to reduce those 'ego forces' by allowing *any* committer to propose an 'internal fork' where he could show off his/her ideas to the development community.
Of course, all possible efforts should be placed to avoid internal forks and keep the development process *evolutionary*, but he thought (and many others agreed) that keeping at least the community together in the same place, would be a great way to avoid community fragmentation.
To guide this process, the 'rules for revolutionaries' where created. They are:
1) every committer can ask to start an internal fork at any time 2) this fork will be hosted in a folder named /proposal inside the CVS module 3) every *proposal* (internal forks are named Proposals) must have a unique name which is *not* related to the name of the project. 4) no other mail lists or CVS modules or separate distributions can be done for that proposal, everything must be done *underneath* the original project [this is sort of internal incubation, so to speak] 5) the lifecycle of the proposal can be:
a) the proposal is taken apart and merged with the main trunk. The
proposal ends and it gets frozen
b) the proposal is proposed on the community for switchingFor *switching* I mean: the old trunk becomes obsolete by the new proposal which becomes a new version.
For this *switching*, the entire develoment community (the committers) must place a vote. If the majority of them accepts, the switching is performed.
This means:
1) the proposal becomes the main trunk, it gets the name of the project and development continues from there.
2) the old trunk can be dismissed or, if others want to continue on it, they have to move it on proposal, thus, in short, create another internal fork (but at that point, they can't no longer redistribute it nor use the name of the project).
NOTE: the rules for revolutionaries are designed to be the *last line of defense* against forking. Their aim is to protect the community from fragmenting.
- o -
So far for the theory, let's now consider the practice.
The rules for revolutionaries have been applied several times over at jakarta/xml. The interesting thing is that nobody agrees on whether they were successful.
One thing is for sure: the ASF has never experienced an external fork.
I personally consider this a *major* sign of overall health of our development model. Whether or not this is also due to the rules of revolutionaries, this is debatable.
So much, in fact, that Duncam himself doesn't believe anymore on them. But we'll come to that later.
- o -
Here are the projects that have internal proposals (there might be others, but I was not involved into them)
- ant - tomcat - cocoon - xerces - xalan
all of these but ant acted the revolution and moved the internal fork as the main trunk. This happened for the transition between Cocoon 1.x and Cocoon 2.x, Xerces 1.x -> Xerces 2.x, Xalan 1.x -> Xalan 2.x.
They were all 'revolutions' in technological terms, but, in fact, they can't be considered revolutions from a community perspective because, in all these three cases, the architecture leadership on both the old generation and the new proposal was the same.
For xerces, Andy Clark lead the re-design phase for Xerces 1.x and he was already recognized as community leader. For xalan, Scott Boag did. For Cocoon, I did.
So, in fact, the revolution happened only at technical level. This caused some friction in the user community, but it was solved easily since the entire development community participated in the design of the next generation of the products and all agreed it was a good thing to do.
- o -
Ant and Tomcat present a different story.
Tomcat ------
When the ASF created the jakarta project with code donations from Sun, both sides agreed that it was a great thing to do. But there were a bunch of technical details to solve and tomcat didn't seem a great codebase to start from.
The pressure for forking was increasing day after day and the Jakarta PMC at that time was very afraid of this. So Duncan proposed the 'rules for revolutionaries', so that others could 'show off' their architectural ideas, work inside the community and cohexist peacefully.
The forking friction resolved. Parallel development continued for a while between Tomcat 3.x and Catalina (that's the name of Craig's proposal), until Catalina was proposed to become Tomcat 4.0
And the shit hit the fan.
In short: the community decided that Catalina was going to become Tomcat 4.0. The problem is that some developers didn't stop working on Tomcat 3.x.
Now, since Tomcat 3.x was used in production in several environments it makes perfect sense that both versions were continuously maintained. The problem is that development *evolution* happened on both trunks.
For a while (and this until not long ago!), the ASF was, in fact, distributing *TWO* totally different codebases, both doing the same exact thing, both called Tomcat, both with their own development community and without any intention to collaborate or to solve the issue.
Some consider this a sign that rules for revolutionaries don't work.
Ant ---
Ant was developped in a continously evolutionary way, yet there are several proposals in the making for what it will potentially be called Ant 2.0
Duncan is the original author of both Tomcat 3.x and Ant. He became more and more involved into open source evangelization activity in Sun (where he worked at that time) and detached from the Ant development community.
At some point, he came back, he didn't like some of the technical/design choices that were done and proposed his own. Since these changes were revolutionary, he wanted to use the rules for revolutionaries and start working on its own internal fork codenamed 'amber'.
Dry story: he was told he had to re-earn committership in order to do that. He tried to fought that, but got pissed after slamming on some rubber walls and left, leaving a bad taste in many people's mouths. His own first.
- o -
My personal considerations --------------------------
The people that have been burned by the friction heat created by internal forks say that the rules for revolutionaries don't work.
I think they *do* work, but their job is not to protect the inviduals or the codebase, but to protect the community integrity.
So far, no forking friction was big enough for communities to be split apart.
Admittedly, the rules of revolutionaries have one bug: at the end of the process one person leaves the community. This happened on JServ, on Tomcat, on Ant and I see this happening in the future as well.
We should ask ourselves? is it really something that some rule can fix?
I mean, if we get to the point of an internal revolution, there are already ego problems in a community. This means that two people can't live in the same community. This happens, it's sad but it's in the human nature.
IMHO, the rules for revolutionaries work. The only byproduct is a lot of negative energy and one (or more) person leaving with anger. But I really can't see how we can possibly fix that if not showing history and suggesting actions *not* to use a revolutionary path.
But, instead of making it harder for committers to startup proposals, I think it should be as easy as possible but provide some constraints and rules for revolutionaries do exactly that.
I think, in fact, they are one of the most brilliant (and efficient, despite the individual who gets burned out) examples of community engineering practices I've ever seen and I would love to see this encoded more formally in 'the apache way'.
Thanks and hope this helps.
-- Stefano Mazzocchi <[EMAIL PROTECTED]> --------------------------------------------------------------------
