How Open Source Projects Survive Poisonous People (And You Can Too)

54 min - Jan 25, 2007 Open Source project: Subversion

This video is by Ben and Brian from Subversion community currently working on Google Code from Chicago. This video has not a single second of technical content but focused fully on human side of an open source development process and their worst enemy - poisonous people. This is one of those few open discussions on social side of project development. I am sure it happens in corporate world too but we can't identify or talk about them. Although they acknowledge at the end but most of the talk is relevant to any community or project group in corporate. So it will not hurt your time if you are not in OSS project. [I have also not contributed to any project till now! :(]

Their discussion made me realize that how much each project has history, emotions and vision behind it. Today when you see thousands of projects in successful open source communities, we seem to take things for granted. Talk is distillation of their experience over 6++ yrs project(s),  hence information presentation is concise and precise.

Complete presentation is broken down into following for major sections:

• Comprehend - preserve attention and focus
• Fortify - build a healthy community
• Identify - look for tell-take signs
• Disinfect - maintain calm and stand your ground.

Other discussed areas are:

Documentation:

One important thing pointed out by Ben and Brian was the value of documentation. Although they have stressed and pointed out its relevance in terms of OSS world, but I see how much we can learn from it. Incremental documentation can turn into a good book, or precise instructions are useful in providing URL to newcomer etc. What I want to learn is how open source developer is able to maintain and write documentation along with software. Since I see that even in corporate world it fluctuates between two extremes -- too much or none at all!

 Key things to track as part of project history are:

• design decisions
• bug fixes
• Mistakes
• change log / code change 

On Bus factor:

Bus factor defines how many people it takes to be hit by bus (job change, health issues, marriage etc. etc.) to take project off rail. This is very critical for open source project, hence always focus on increasing your bus-factor. I can say that this is also very critical for commercial software teams.

 Some other tidbits of advice:

• Send commit emails, encourages email review.
• Do not submit big changes
• Don't out author name at the top as it marks the territory. Let it give  the feel of community.