== Rules for Revolutionaries ==

In a closed source project where you’ve got a set team, you make decisions about where the entire team goes and somebody takes the lead of deciding what gets done when. In the discussions about Craig’s long term plan, this metric was applied by several of us in thoughts about where to go next.

After pondering this for a while, it’s (re)become obvious to me that there’s no way that anybody can expect an open source organization to work the same way that a team in a corporate setting can. Ok, so this is pretty freaking obvious, but I’ve been watching people that are not from Sun and who have been doing open source for a while talking and proposing things that come from this line of thought as well. Its not just people from Sun or people from any particular

entity.

So – in any software development project there is a natural tension between revolution and evolution. In a closed source environment, you make the call at any particular time on whether you are in revolutionary mode or evolutionary mode. For example, JSDK was in evolutionary mode for years. Then in Nov 98, We made a decision to go revolutionary. Of course, at the time the project team

was composed of 1 person – me, so it was an easy decision. After that revolution was over in Jan 99, Tomcat was in evolutionary mode getting JSP bolted in and working with J2EE. We (Sun folks) could do that because that was what suited the goals best at the time.

However, Open source is chaotic. With its special magic comes a different reality. This is:

1) People work on their own time (even people paid by a company can be considered to be working on their own time in this situation as each company is going to have different cycles and things they want)

2) People work on what they want to. If you are working on your own time, you are going to do what you want or you do something else.

3) Some people are evolutionaries, other are revolutionaries, and some are both at different times.

4) Both approaches are important and need to be cultured.

5) You really can’t afford to alienate any part of your developer community. Innovation can come from anywhere.

To allow this to happen, to allow revolutionaries to co-exist with evolutionaries, I’m proposing the following as official Jakarta policy:

1) Any committer has the right to go start a revolution. They can establish a branch or seperate whiteboard directory in which to go experiment with new code seperate from the main trunk. The only responsibility a committer has when they do this is to inform the developer group what their intent is, to keep the group updated on their progress, and allowing others who want to help out to do

so. The committer, and the group of people who he/she has a attracted are free to take any approaches they want to free of interference.

2) When a revolution is ready for prime time, the committer proposes a merge to the -dev list. At that time, the overall community evaluates whether or not the code is ready to become part of, or to potentially replace the, trunk.

Suggestions may be made, changes may be required. Once all issues have been taken care of and the merge is approved, the new code becomes the trunk.

3) A revolution branch is unversioned. It doesn’t have any official version standing. This allows several parallel tracks of development to occur with the final authority of what eventually ends up on the trunk laying with the entire community of committers.

4) The trunk is the official versioned line of the project. All evolutionary minded people are welcome to work on it to improve it. Evolutionary work is important and should not stop as it is always unclear when any particular revolution will be ready for prime time or whether it will be officially accepted.

— http://incubator.apache.org/learn/rules-for-revolutionaries.html