Open Source and The Mythical Man Month!

This is a re-post of my original article, modified to reflect clarifications that I received from the author,  which were very much appreciated.  In fact the author spent some time developing a response which he kindly sent to me rather than posting as a comment.  However having read the comments,  I still thought that a slightly modified article had something useful to say so I made these updates and reposted.

———————————————————–

Nic just blogged on an interesting article published by IBM titled “Opening minds: Cultural change with the introduction of open-source collaboration methods”. 

It’s message centred around the concept that there are two cultural models, the Traditional Approach and the Open-Source Approach.  I mistakenly thought that the traditional approach was described by the classic book “The Mythical man Month”, the Open Source approach by Linus.  However the author has pointed out to me that only certain elements of the approach described in the Mythical Man Month are actualy being referred to in the article.  The following table from the article describes the key differences:

When I read the “Mythical Man Month” a few years ago these are some of the key messages that I remember that are relevant. 

• It is very difficult to maintain “conceptual integrity” and so this is best achieved by placing responsibility for conceptual integrity with a small number of people, often 1 or 2 people
• Establishing common ground across the whole team is key, so senior people should keep journals daily so that everyone knows what is going on, and there is no “knowledge is power” issues, also everyone should have access to design documents and specifications.
• As the team scales communication and co-ordination get ever more difficult so the programme needs to be broken up into smaller pieces with well defined and stable interfaces between them, so that everyone can work in parallel and innovation can go on within the interfaces without sacrificing compatibility or conceptual integrity
• Nothing can be perfect so we should gain agreement on the concept before defining the logical, before defining the physical.  As each layer is defined they are tested against the concept and then the logical definition and these are iterated as required to reflect the fact that the project is learning as it goes.

When I look at this list I actually think it has a lot in common with almost all really successful Open Source projects.  lets compare:

• It is very difficult to maintain “conceptual integrity” and so this is best achieved by placing responsibility for conceptual integrity with a small number of people, often 1 or 2 people  – well every Open Source project I can think of has a leader who takes responsibility for the conceptual integrity.  In fact as the project grows this becomes probably the only thing they do!  Sometimes they delagate leadership but only to a handful of people, but even then they keep overall control.
• Establishing common ground across the whole team is key, so senior people should keep journals daily so that everyone knows what is going on, and there is no “knowledge is power” issues – Blogs and email lists serve the same purpose for Open Source, I actually think this is one of the great features of A Mythical Man Month, that it strongly promotes communication to level the playing field around knowledge.  It’s true that there is no true democratic decision making process going on,  but nor is there in most Open Source projects.
• As the team scales communication and co-ordination get ever more difficult so the programme needs to be broken up into smaller pieces with well defined and stable interfaces between them, so that everyone can work in parallel and innovation can go on within the interfaces without sacrificing compatibility or conceptual integrity.  This is exactly the approach taken in Open Source,  develop modular software with well defined interfaces, and delegate out responsibility for the implementation of those modules.
• Nothing can be perfect so we should gain agreement on the concept before defining the logical, before defining the physical.  As each layer is defined they are tested against the concept and then the logical definition and these are iterated as required to reflect the fact that the project is learning as it goes.  This is conceptually simillar to the start simple ship often idea, but with a different implementation.  Conceptual definitions of a system are simpler than logical, which are simpler than physical.  I know that modern ideas like extreme and agile programming go beyond this, but they are not so far apart.  Both stress flexibility and iterative improvement.

I had previously agued that the model in the article was fundamentally flawed, however because this post discusses what the Mythical Man Month approach had in common with the Open Source development approach where as the article focussed its comparison in a different area,  its more difficult to draw the comparison.  However the following are areas of the article that I do relate to:

New technologies asynchronous collaboration technologies definately allow for more discussion and debate than the “meeting and memo” tools available to Brooks.

The level of commitment felt by members of the Open-Source community is definately stronger,  but probably not just because they feel more involved, but because of the sense of ownership they feel in the end product. 

Techniques like extreme programming and agile programming, using the system you are creating (dog fooding) and regular or daily builds are definately innovations that were just not viable in Brooks’ time, and are certainly not confined to Open Source, or in fact invented by Open Source. They have been just as popular in the closed source world, and in fact are often easier to achieve in the closed source world.

Whereas I previously thought that the article was “massively misleading”,  it’s now clear that my misunderstanding of the premis of the article made it difficult to really make a valid comparison.  However I do still feel that it stresses differences where actually both camps have more in common than you might think, it attributes chartacteristics to Open Source development and technologies that are not linked to Open Source at all.

I think that I responded to this article negatively because of its use of histrorical comparison.  I would rather stress the things we should do to make collaboration work, and not get bogged down with historical comparisons and specific cultures, what are some of these things:

• Establish the maximum level of common ground between all team members, for example keep people informed, help people get to know each other, develop trust, make sure everyone has access to everything.
• Create a work breakdown structure that minimises tightly coupled interactions between virtual team members, unless it is to stimulate creative friction to achieve innovation
• Make sure people feel involved in decision making and can comment on decisions and make suggestions of their own.  Blogs and discussion areas are perflect for this.
• Make sure the business is ready to collaborate, for example make sure that people are motivated and measured in ways that encourage collaboration
• Make sure that the technology supports collaboration in a seamless and easy way, ie it is easy to use, reliable, predictable, does not add additional steps to the process and helps people be more productive rather than turns them into administrators.