teh bigbro blog(tm)
Bigbro's foray into the scary world of blogging

Wed, 28 Jun 2006

ApacheCon '06 : The Code is Not Enough

A subjective talk by Brian W. Fitzpatrick, from Google. The 'W' is to distinguish him from the band of the same name, he assures us :-)

To determine whether a project is successful as an OSS project, first you have to define success. Some companies seem to think that making their software Open Source will provide a huge amount of publicity. This may not be the case, unless they do it right. Trying to use OSS to make other people write the code for you, or maintain it, is almost always doomed to failure.

A successful project:

  1. Has a healthy developer community.
  2. Makes decisions by consensus.
  3. Can survive being hit by a bus (or some developers being hit by busses.)
  4. Can survive poisonous people.
  5. Doesn't let the perfect be the enemy of the good.
  6. Has a mission statement.
  7. Documents both software and process.

The code doesn't matter - building a team of great developers is the hard part. Having a good community is vital to the longevity of any OSS project. Community requires that people relinquish control of what might be their pet project, but has the advantages that the importance of a corporate umbilical is lessened and the chances that the project will be governed by consensus are greatly improved.

How do you build up a community?
  1. Start with a mission statement.
  2. Document your code.
  3. Document your processes.
  4. Remember that the perfect is the enemy of the good. Make your project good enough.
  5. You reap what you sow.
  6. Once you trust a developer, hang on to them.

Governing a project by consensus gives enfranchisement, ownership, responsibility ( there are still some questions re whether a Project Management Committee or Committers - or both - works better.) The best developers usually aren't followers and want to help to drive the project.

Of course, there are things that shouldn't really be done. Dumping code is likely to not work. Unless the code is useful, relevant and not superceded is likely to be ignored, and a community is unlikely to form around it. Pushing code over the wall periodically, while continuing development internally is also not hugely useful.

While this was one of the less technical presentations, it's certainly added to the whole. Open source projects is what it's all about, and while communities are strong once they're built, they can be very fragile things during the growth stages. Brian did an excellent job of describing some of the activities that have hurt or hindered various open source projects, using Apache and Subversion as examples of two different but both successful projects (and communities.)
posted at: 15:24 | path: /technical | permanent link to this entry


copyright © 2005-2008, Gareth Eason