cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject rules for revolutionaries
Date Fri, 22 Aug 2014 09:21:56 GMT
Hey folks!

Open source means chaos.
Chaos is ok.
Community over code.
Consensus can and should be reached lazily.
Decisions should and will be made by the people who do the work.
Vetoes are a last resort.
Neither lack of consensus nor prevalence of vetoes can block progress.
Revolution is allowed, evolution is preferred.


If you were the release manager for cloudstack 4.5, and you decided to build the release by
exporting some branches to bitkeeper, doing lots of merge management in there, and then exporting
the result back out to subversion, building a release from that, and calling a vote, no amount
of process or rules could stop you.

If you would get enough (3) binding votes, and more +1s than -1s, then that beast you built
would become cloudstack 4.5.

Even if you weren't the nominated release manager, you could still do that. Even if someone
else _was_ nominated as release manager. Even if there’s a policy on confluence clearly
stating you should’ve done it.

Note that it doesn’t even matter if you're not a committer. You just need the votes.

This is, by-the-way, why active committers should want to become PMC members, to get the binding
votes aligned to who is doing the work. The ratio PMC member / committer in this project scares


Some of the biggest releases at apache, like the 2.0 (or the 2.2) of the apache web server,
or the 4.0 (or 5.0, or 6.0) of apache tomcat, or the 2.0 of apache maven, were rather contentiuous
and rather revolutionary releases. In the linux ecosystem, ubuntu was a rather revolutionary
fork of debian. Funnily, centos is revolutionary because it _isn’t_ a fork of RHEL. Chrome
is in part a revolutionary fork of safari. HTML5 is a revolutionary fork of HTML4, competing
with XHTML. Git was a revolution against bitkeeper, which was a revolution against centralized
version control.

Empirically, darwinistically, it has to be this way. We’re just not good enough at software
development yet to avoid revolution.

At various points in the past, apache tried to have rules for revolutionaries, i.e.
to at the same time both sanction and limit the scope of revolutions. This can’t work since,
of course, revolutionaries don’t follow the rules.

These kinds of revolutions hurt communities a lot though when they happen. So, social pressure
(not rule, not policy, just expectation from your peers) is that you do whatever you possibly
can to avoid them. I.e. you’re expected to build consensus. Are you doing everything you
can to build consensus? Good.

What will always fail in the end is trying to block chaos, or block change, or block the people
who are doing the work from making the relevant decisions. It’s wasted energy.


If you’re an evolutionary, and you spot a potential revolution you don’t want, the best
strategy is to assimilate, to embrace and extend. Step up to do the work that gives you the
actual influence in how things get done. Interestingly, along the way, you’ll usually pick
up the most important bits that the revolution was about, anyway, surprising amounts of real
progress get made, and it’s a surprising amount of fun :-)

Happy hacking!

- Leo

View raw message