Good and bad practices from the Linux Kernel open source project
James Bottomly (one of Linus Torvalds lieutenants)
Part of the motivation for Linux: even BSD code was hard to get outside the US
Founding: freedom to redistribute and contribute
Linus dislikes the 'cult of personality' associated with some open source projects
Not tracking the origin of contributions from the beginning is a lesson learned
Kernel developers try really hard to do development in the open
All patches should always first should go over a mailing list (a few have not)
“Even the best open source companies would, one in a while, like to keep code hidden until the product releases – classic example is Google with Android”
“There are sound reasons business reasons for doing this”
A transparent open dev policy creates a client of equality, trust, and franchise
Single committer model – “the Linus doesn't scale problem” … enter Bitkeeper
DVCS proved to be the solution
People who merged entire trees became Lieutenants
Solidification of the Maintainer Model
April 2005 – The Bitkeeper Blowout – Git was born
All of the Lieutenants at this time starting to working on Git (and Mercurial even)
They replicated the functionality of Bitkeeper in 3 months
Mercurial principles are similar to Bitkeeper; Git is much different
June 2005 – Git became stable enough to host Linux Kernel development
Mistake in Kernel development: Odd is Unstable version numbering scheme
Should have (and now does) a release early, release often model
The Linux Culture … a meritocracy
A negative: “Code costs effort to produce but Criticism is free”
People follow be example: some lieutenants flame a lot
Surviving the Critical Culture – learn who to listen to and who not to listen to (just watch the list)
People who only criticize and never contribute are not trusted by the community
LKL list (only 2 of 30 lieutenants still even read it – look for the smaller lists)
Advise on identifying mentors: look at contribution record, sometimes can be abrasive (nerd social ineptness)
Conclusions:
- Full openness brings problems (but they are outweighed by community it creates)
- Ownership create franchise (conversely copyright assignment creates inequity)
- Mailing lists can be rough places, particularly with a critical meritocratic cultures
– To survive them, learn who the trust
