Google defends open source from 'poisonous people'
The Case of the Self-Centered Date Parser
Customer Success Testimonial: Recovery is Everything
Google I/O Once upon a time, there was an open source project called Subversion, and it needed a new date parser.
One day, a coder came along and wrote one. But he insisted on tagging the source code with his John Hancock. And that was against the rules. Subversion's founders said that name tags would undermine collaboration.
When the founders asked the coder to remove his name, he refused, threatening to leave the project and take his date parser with him. It was a good date parser - just want the project needed - but the founders stood their ground.
So, the coder left with his parser and never submitted another patch. But six weeks later, a second coder came along. "Hey," he said, "I can write a date parser."
Two of Subversion's founding developers - Brian Fitzpatrick and Ben Collins-Sussman - believe in open source projects that maintain a large "bus factor." That would be the number of people who could get run over by a bus before the project collapses. A simple means of maintaining a large bus factor, they say, is banning names from source code.
"You have to discourage people from feeling like 'This is my module. I wrote this. Every change has to be approved by me,'" Collins-Sussman argues. "That's very dangerous for the project as a whole."
This may mean the loss of some valuable contributors - and some valuable code. But in the end, the project comes out ahead. There will always be more contributors. And more code. "You can't sacrifice the long-term health of a project for short-term gain."
That's just one lesson from Fitzpatrick and Collins-Sussman, two long-time open source gurus now plying their trade at Google. The pair turned up yesterday at the Google I/O developer conference in San Francisco, delivering a talk they like to call "How Open Source Projects Survive Poisonous People."
A poisonous person would be anyone who puts a drag on collaborative coding, from cruel souls who enjoy tossing a wrench into the works to social misfits who screw things up simply by being themselves. "You have to guard against anyone who distracts you, who drains you," Collins-Sussman said. "Sometimes, these are trolls. But sometimes they're valued community members, the nicest people in the world who also happen to be perfectionists or obsessive compulsives - people who bog you down with endless discussion."
The success of an open source project depends on "attention and focus", the two Googlers explained, and those assets must be protected at all costs. "If you had a group of people who are all contributing to a pile of money and someone came along and started taking money from the pile, you'd be annoyed. You might even call the police," Fitzpatrick said. "Attention and focus are the currency of an open source project."
That may sound like commonsense. But Brian "Call me Fitz" Fitzpatrick and Ben "Call me Collins-Sussman" Collins-Sussman laid down more than a few practical tips for making sure those poisonous people aren't so poisonous.
Rule Number One: When you launch a project, carefully define your mission - and post that mission to a conspicuous web page. "If it's on a website, it's official," Collins-Sussman said. This drew a hearty laugh from dozens of the developers on hand for the talk. But Fitz was quick point out that this was a joke with more than a little truth to it: "If you say something over email, people will debate it for weeks. If you take the time to put it on a web page, suddenly people take it seriously."
Subversion's mission statement: "To create a compelling replacement for CVS," a common version control system for open source projects. Thanks to this single sentence, Collins-Sussman argued, the project generally attracted the sort of contributors it wanted to attract.
The pair also advocates keeping discussion to a healthy minimum. This involves maintaining a complete email archive and extensive documentation of a project's history, including all designs decisions, code changes, big fixes, and mistakes. If you do that, they said, you prevent people from rehashing old debates. "If you don't document your project's history, you will be condemned to repeat it, over and over and over..."
But even when you're discussing things that haven't been discussed before, the pair went on, you have to know when to shut things up. "We once had a guy who wouldn't stop talking about a particular feature. He went on and on and on, and we couldn't decide what to do," Fitz recalled. "So, finally, we just told him 'Let's move on and write code.' That did the trick. He said 'OK.'"
The culture of open source projects, they said, should be self-selecting. In other words, stick to your guns. If people don't like it, they'll leave.
Or, at least, most of them will leave. There will always be those who hang around just to cause trouble. When this happens, the Googlers said, you mustn't be afraid to "flip the bozo bit" - i.e. boot them from the project. That goes for project founders. And geniuses.
Subversion once booted a well-known "genius" after his constant criticism threatened to bring the project down. Collins-Sussman called it the project's "key decision". Genius isn't as important as community collaboration, he said, and nowadays, code geniuses are a dime a dozen.
Bootnote
Last year, Fitz and Collins-Sussman gave a similar talk at Google's Mountain View headquarters. You'll find a video here and slides here. ®
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
COMMENTS
Didn't Stallman
already pass a copy of the communist manifesto around?
Rhyming slang?
"But he insisted on tagging the source code with his John Hancock."
@ownership of code
Not a coder so may be completely off track, but:
Surely if someone is going to get all prissy about "their" code they will do so whether it has their name on it or not? Surely a coder can recognise something that they have written and see any changes that have been made from their submission.
Also, does this whole premise not diminish the appeal of FOSS with respect to proprietary software? The 2 main appeals of FOSS are the fact you can see the source code and the fact that the community is involved in the creation process.
If you take the community out and revert to a "my way or the highway" approach then you are very likely to alienate a lot of the best thinkers and coders; and even if good thinkers stay if you don't listen to them then what is the point? It is like proprietary software without the benefits of being proprietary.
IMHO, obviously

IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring