Versioning
In Linus We Trust
Zenpundit links back to The Tactical Loop in Following up on Learning Organizations. I found this section interesting:
I will quibble with Adam [Elkus] in that “crowdsourcing” phenomena or open systems that acquire a “community” aspect with recognizably distinct cultural norms are usually dominated by a “natural aristocracy” among the membership – a cadre of “influencers” who make qualitative contributions frequently and disproportionately and have individual and collective ”auctoritas” to police the larger mass than contribute occasionally. There’s a “feedback loop” where certain members of “the crowd” add complex thinking for collective evaluation, modification and ratification. Linux is the original example as is Wikipedia, where senior and elusive ”Wikipedians” carry great weight compared to say, me, logging on and editing away.
The “natural aristocracy” Zen refers to is enforced in Linux, other open source software projects, and Wikipedia by a version control system (VCS). The simplest VCS is the undo/redo functionality found in most application software. Undo/redo is linear: you either go x steps back or x steps forward. A slightly more complex VCSes like the one used by Wikipedia adds an additional wrinkle: while undo/redo is usually confined to a single user using a single application, Wikipedia gives multiple users the ability to undo and redo. This creates complications because just anybody can come along and make a change, sometimes improving but other times defacing or inserting personal idiocy. The Wikipedia community must assume the wiki’s burden and preserve the integrity of the wiki from faction, malice, trolls, spammers, and anonymous cowards. This involves ’senior and elusive ”Wikipedians” standing vigilant over the wiki, fending off attacks in often vicious edit wars.
BDFL. Refreshing.
In open source software projects, a VCS usually is under even tighter control. While Wikipedia is a libertarian paradise where any yahoo can make a contribution, open source software projects feature access control that restricts who can commit or revert changes to the VCS. Many projects are divided into a “natural aristocracy” of committers and users. Committers themselves can be subdivided into tiers of commit rights, with some developers only having rights to commit to some portions of the code and some developers having the right to revert other developer’s changes.
Some projects have a dictator who exercises final control over what code does or does not make it into the main software release (often called a trunk because other versions of the code branch off of it). This is probably true for most projects since most open source software projects only have one or two developers. Others have a dictator surrounded by key lieutenants who are delegated certain parts of the codebase. This is the case with Linus Torvalds and Python’s Benevolent Dictator For Life Guido van Rossum and their merry men. Others have an meritocratic oligarchy like the Apache Web Server core developers.
When a major disagreement breaks out between developers that comes to (virtual) blows, often the result will be a fork. Programmers, generally being anal-retentive types, love to quibble over arcane and obscure minutia. In this regard they are a lot like early Christians and prone to schism. A schism in an open source software project, called a fork, occurs when one faction of developers takes the source code from a particular project and begins developing it independently of the original project. They vote themselves off the island in order to maintain their vision for the software.
The saga of one core group is indicative of how this system can play out in practice. BSD was originally a fork of the One True AT&T UNIX that was developed and maintained by the University of California-Berkeley. AT&T, prevented from making money off of UNIX initially because of an antitrust agreement with the Justice Department, distributed the source code for UNIX to interested parties for the nominal cost of the media to ship it on. Berkeley was one such party and made their own variant of core UNIX. After Ma Bell was broken up, AT&T was allowed to enter the computer market so they decided to monetize UNIX. They sued Berkeley and forced them to stop developing BSD UNIX, the basis for Sun’s original versions of UNIX. This produced an effort to make a version of BSD that was no longer tainted by AT&T’s copyrighted code. Berkeley released a final version of BSD in 1995 and stopped developing the operating system.
Beware Lucifer, Son of the Morning Star
An earlier version of BSD developed into what eventually became the NetBSD project. The original developers of NetBSD were unsatisfied with the couple developing 386BSD and forked their code. NetBSD was devoted to making BSD run on every object in the universe, especially your toaster. However, the original developers had an argument and Lucifer was expelled from heaven. The sign of his fall was the revoking of his commit rights to the NetBSD source. Lucifer, his evil designs thwarted, plotted his vengence. He picked over the NetBSD source code until he had his own Canadian version: OpenBSD. Lucifer’s vision was to allow every object in the universe to be a firewall with military grade security. The reasons for his madness are hidden. Pray they are never revealed. (A friend of mine had a brush with Lucifer when he tried to help an innocent OpenBSD newbie configure the operating system (OS). Lucifer howled with rage, cursed my friend, and expelled him from Hell.) In the meantime, FreeBSD was also born, dedicated to running BSD on your PC instead of your toaster.
This saga, much of it caused by rigidity some development oligarchies maintained over there VCS repositories, led to BSD falling by the wayside as the open source OS of the future. Instead Linux, with its more efficient benevolent despotism, became the open source operating system (unless you count MacOS X as a BSD, in which case BSD has 9% of the OS market while Linux has ~1%) while BSD forked and schismed.
Linus, however, is a tyrant that sits easily upon his throne. He popularized the adoption of the Distributed Version Control System (DVCS), a system which replaces the one central repository under the control of a dictator or oligarchy model favored by traditional VCSes like CVS and its successor Subversion with many distributed repositories under the control of many developers. Instead of changes being submitted to a few committers and then, if blessed, being added to the main trunk of the software, developers using the DVCS approach push and pull changes from their own local repositories to and from other developer’s repositories in a peer-to-peer relationship. Linus’s own repository of Linux is technically equal with every other Linux developer’s repository. He, as with every other Linux developer, can push and pull changes from other repositories as he wants. However, Linus, being Linus, is more equal than others developers. He still possess the sole right to “sprinkle holy penguin pee” on a Linux software release and declare it the official Linux release.
He uses his power wisely and intends to liberate the world from the domination of monolithic VCSes. The video that made me believe is a talk Linus gave at Google where he walks in, tells them that their VCS (Perforce) is lousy and that they should follow the DVCS model. Linus compellingly argues that the DVCS scales an open source software project better than a VCS. It allows more developers to contribute, reduces the more prominent developers tasks to picking the best code possible from multiple repositories instead of guarding their precious, precious core repository, and minimizes the chance that an outright fork has to occur in order to push minority changes into the codebase. His performance is a tour de force.
Letting a hundred flowers blossom and a hundred schools of thought contend.
