Open Source Project Management Handy Rules ;-)

Let's face it. Most open source projects fail. This is the way the marketplace should work. Ideas and companies fail all the time. While they fail for myriad reasons, one preventable reason for failing is poor project management. Let's face facts. Project management is hard. The job is often thankless and requires a type of mentality not often found in top flight engineers. For certain projects where those engineers have both top flight project management skills and engineeering skills (Brian Behlendorf of the Apache project comes to mind. Brian doesn't claim to have project management skills but he's far too modest).

Project management for open source projects isn't much different than project management for closed source software projects. First off - project management is about organization of information. If your project manager's desk looks like a tornado hit it, he/she shouldn't be your project manager. Very often engineers tend to see project management as a component that can be solved with just the right piece of software or by religously using a tool like sourceforge or MS Project. While these tools can be helpful, very often the tool gets in the way of project management. MS Project's primary purpose appears to be production of pretty graphs and charts which can be handed to upper management. While this may pass for project management at a large Fortune 500 company, it's not. It's the form of project management without actually being project management. If you want your project to succeed, you should learn at least the bare minimum required to actually make your project succeed.

1. Write a functional specification. Specification writing is yet another process with far too much written about it. Once again it is often written in an overly obtuse jargon much preferred by people who are attempting to sound smarter than they actually are. Very often the person that gets stuck writing your functional specification are pretty pissed about and they need feel the need to impress upper management. Fortunately for you this is an open source project and you are management! This also means it needs to be written so you can attract new developers and so your current team can underestand what you are trying to achieve. If you are coming from the traditional corporate world, throw pretty much everything you know out. I would suggest start with Joel Spolsky's four part post on why you need a spec. His advice is right on for any software project. His sections are why you need a spec, what a spec has in it, who should write a specification and tips on writing a painless specification. I would write more about writing a functional specification but quite frankly Joel does such a good job of it and I would simply be re-hashing in a much less interesting way. I suggest you read his posts.

2. Your project needs a core set of high set of developers to start. Without this core of developers consistently contributing. When you first start out, very often your other developers will be in the same room with you. This is pretty helpful initially, you can scribble on white boards, discuss coding approachs, coding standards, you name it. As you work in close proximity your developers begin to develop a mental model about each developers strengths and weaknesses. Hopefully team cohesion will improve as a result. This happens because when human being communicate, they are recieving a whole lot of data on the subconscious level. It might not and if it doesn't you need find which developer is the fly in the ointment and gently suggest another project they might be really interested in. Let's assume however that your team has gelled and your project has begun to get some traction in the marketplace. You are about to add some outside developers who have become interested in your project. These guys have developed a module or two and hopefully will contribute to the core product. So they begin contributing via CVS and discussing things on your mail list (you do have a source repository, bug tracker and commit mailing list right? No - well you should.) However you soon find a flamefest happening on the mailing list and people instead forming a smoothly running team are begining to get upset.

What happened? Well anyone that has spent time on Usenet can tell you. Human communication devoid of any physical proximity fails to capture the nuances of communication and soon these things begin to pile up. Misunderstanding piles on top of misunderstanding. As a project manager when workign with distributed teams, you must find a way to restore the balance and help those bonds form. You could get together on a yearly basis (the BSD project did this and found it helped quite a bit). If the developers are too distributed, web cams (which have much improved in the last few years) can help. Just email, mailing lists or forums don't provide enough context for developers - add another communication medium that will help personalize the other developers.


This post has gotten pretty large so I will continue it with a part two.

Technorati Tags
open source
open source project management

Holiday Ran Late

Sorry for not posting sooner, my holiday, ran a little late. I have a more complete post up in an hour or so. Happy New Year and congrats to the Longhorns.