cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <>
Subject Re: rules for revolutionaries
Date Fri, 22 Aug 2014 19:01:55 GMT

On Aug 22, 2014, at 5:21 AM, Leo Simons <> wrote:

> 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 me.
> (…)
> 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.

good read for us all

> 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