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 switching

For *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'.