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.
http://incubator.apache.org/learn/rules-for-revolutionaries.html
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
