On Aug 22, 2014, at 5:21 AM, Leo Simons <lsim...@schubergphilis.com> 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. > http://incubator.apache.org/learn/rules-for-revolutionaries.html 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 >
