What's on Mike's mind?

Read what's on Mike's mind!

Cialis online

Open Source Project Management Insights

Posted by Mike on November 22nd, 2004

I just read an article on Groklaw about Andrew Morton’s Speaker Notes from SDForum. You can go to Groklaw to read all of it.

Here are some excerpts that I think are related to successful projects. (If you like them, read the whole article, as these are taken out of context.)

a huge project is really an agglomeration of thousands of small projects

With the success of the Linux Kernel, you can hardly argue with this approach. The better you break down the huge projects into manageable projects, the better your chances are for success.

I dislike private design discussions because it cuts people out of the loop, reduces the opportunity for others to correct mistakes and you just end up repeating yourself when the end product of the discussion comes out.

It seems like so much work to involve everyone in design discussions, but it is critical to the process of having a quality product. The more eyes you have, the better your chances that mistakes will be caught early. Also, with better participation in design, the more your team will understand the what and why of the work.

Contributors send their code submissions as source code patches to the relevant mailing lists for review and testing by other developers. The review process is very important.

This open source project places a high value on code reviews. The Linux Kernel is a very large project, but I think you would benefit from code reviews even in small projects. It is too easy to be blind to your own mistakes.

The preferred form of bug reports from testers is an email to the relevant mailing list. We go through a diagnosis and resolution process on the public list, hopefully resulting in a fix.

We do have a formal web-based kernel bug reporting system, using bugzilla. But the bugzilla process is one-to-one rather than many-to-many and ends up being much less effective because of this.

Once again, we see a public process. Here it is concerned with bug fixes. Project communication needs to be team communication. If you leave team members out of the loop, you just might miss out on the best solution. Also, how will your team grow, develop and understand, without seeing the issues and contributing to solutions?

The above quotes from Andrew Morton contain very practical advice for project managers. I can sum it up in a short statement. Communicate openly on the team, in a public manner.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>