Efficient and fun software development the open source way

One of my constant sources of inspiration in how to work with software development, is the way successful Open Source (OS) projects structured. One obvious reason for using OS projects as inspiration, is of course the visibility of how the development works here. But other fundamental forces are at work here which makes OS projects very interesting, when considering how to build an efficient and robust platform for software development.

A interesting aspect of OS projects, it that they have to succeed under conditions which we would normally consider crippling in commercial software development. Some of these conditions are:

• Allocated resources: One of the cornerstone in every project management model is the ability to plan (and somewhat control) which resources are available when. In OS project people do work, when they have the time and interest.
• Control by management: In normal commercial projects you have the luxury of having roles,, which are dedicated to controlling the project. These are people like project managers, architects, QA, etc, and are backed by the company or organization. In OS projects there are no formal mechanisms for forcing people to do the 'right' thing.
  
• Localized team: Most commercial teams are placed in one location, and distributed teams are usually shunned, because these teams are notorious prone to inefficiency. OS projects are usually distributed, both geographically and in working hours.
  
• Sales organization: In commercial organizations, the usage of the products developed are helped on the way by a sales organization persuading customers to the virtues of the products. In OS software the sales organization is usually lacking.
  

Because of the absence of the listed factors in OS project a number of more fundamental qualities are more clearly visible and have to be addressed.

• Fun: Because of the voluntary nature of participating in OS projects, an OS project needs to be 'fun' to work in, or else it will died a silent dead because nobody contributes. Many of the following qualities are derived from this.
  
• Usage driven documentation: Where, the documentation in commercial projects are usually produced based on what non-users think is a good idea, OS documentation is much more driven by Just-In-Time need for documentation (here non-users are people like QA, project leaders, architects, process definers etc, which don't directly use the developed product or source). The result is, that OS documentation is usually much more relevant and updated than commercial documentation. The OS documentation production is also part of the daily work, so the infamous 'task' of documentation is much less pronounced in OS (eg. boring work isn't done i OS projects).
  
• Usage by product and web quality: Where a major part of commercial products success depends on the sales organization, OS projects have to depend more on the merits on the products themselves and the quality of the (typically web based) public interfaces to the consumers of the products. The result is that the usability and visibility of the project is essential, eg. documentation, bug/feature tracking, design/source need to be of high quality.
  
• Managerless: OS teams very seldom include non-software producing members, and are very efficient role vice, eg. everybody is producing actual software.
• High level of automation: Because boring tasks aren't performed in OS projects, these are either automated if they are necessary, or left out if the need of the task is difficult to see. Mature, high quality OS projects therefore have automated many of the repetitive, boring tasks done manually in many commercial projects.
• Self-organizing: Because projects teams in OS projects aren't defined by outside forces the OS teams usually have a much more organic approach to who-does-what. Everybody is in principle project manager, architect, developer, tester etc.
  
• Distributed team: OS projects are in nature spread all over the globe, and project members typically work at different times. To handle this OS projects needs to function efficiently without the people ever meetings of talking together.
  

For a OS project to be a success these factors have to handled efficiently.

Conclusion: Because of the more 'fundamental' nature of OS software development, a good OS development 'model' can be used as a solid foundation for a commercial development process, where higher order methods for improving software development like SCRUM, Unified Process, CMMI, internal processes, etc. can be added. If, on the other hand, the concerns exposed in OS projects aren't handled in projects focused on higher order development models, like SCRUM, UP, etc. it will be very difficult to make the project a success. And even worse, the forces ruining the project won't be understod, making improvement impossible (my blog SCRUM vs. JIRA and following discussion elaborates a bit on this).

Disclaimer: The differences described between commercial and OS projects are of course exaggerated, many commercial project are adopting more agile approached to software development, which have many similarities to OS development. OS projects are on the other hand seeing greater influence from commercial based team setups, where the advantages of more dedicated contributers becomes available.