Friday, 29 April 2011

Thoughts on open-source development methods (and congratulations to Ubuntu)

First of all I want to say congratulations and thank you to all of the people at Canonical and in the Ubuntu community for all of their hard work in getting out the latest release of the Ubuntu Linux distribution.  Despite all of the criticism the distribution comes under from time-to-time these people strive hard to put out a new version every 6 months.

When you think about their achievement you soon come to realise it's no small feat that they have pulled off, bringing together the best-of-breed free and open-source applications into an easy to install and use distribution readily available to the entire world for free.  It becomes even more amazing when you consider that the people working on the projects are spread all over the world, even the teams working on a single feature might be spread across multiple countries perhaps only meeting in person a few times a year.  The same is true of many free and open-source projects where there may be hundreds, if not thousands, of contributors to a single project spread around the globe.  And yet the projects comes together and produce incredible results, such as the Linux kernel itself which powers so many of the devices and much of the infrastructure we use each day without realising, the chances are that you have at least one gadget in your house powered by the Linux kernel.

The main reason I find all of this amazing and why I felt compelled to blog about it is because, following the very recent release of Ubuntu 11.04 (Natty Narwhal), is because of this geographic spread of developers, document writers, testers, packagers etc... and my own experiences of working in teams within a corporate environment.  I have worked in a number of places now where people have found it difficult (if not impossible) to work with people who are not sat immediately within the same vicinity as them.  Where projects have been delayed and delivered late because people have had difficulties in working across time zones, and in a few instances where people have been in different offices in the same building.  So I suppose I'm curious as to why people working with free software all over the globe can meet these 6 monthly deadlines with amazing frequency and yet companies with money to throw at the same or similar problem have so much trouble!

I have seen a few problems in corporate environments which are often quickly overcome by open-source companies and communities, but I'm sure that these are not the only problems.

The first is often something as simple as choice of version control system.  Whereas the recent adoption of distributed systems such as Git and Bazaar in the open-source world has allowed people to work within a project more efficiently companies I have worked in seem to stick to and prefer the older check-out, check-in systems such as SourceSafe.  This type of system, although easier to understand by inexperienced developers, is often slower and imposes bottle necks on development process, whereas using a distributed system allows users to work remotely without requiring constant access to a centralised server meaning that the developer only requires access to main branch when retrieving a revision and finally merging changes.

A second problem I've often seen is one of communication.  Often in corporate environments communications in teams is limited to office chat, email or meetings, the problem here is that chat often excludes a large number of the team, email is limited to the people on the To and CC list and meetings are more often restricted to a single geographical location.  These factors typically lead to large numbers of team members becoming excluded from conversations and vital information, some companies try to limit this by creating procedures for disseminating information but these are not always followed (lets be honest, most of us despise more procedure!).  In open-source conversations take place in the open, normally using social systems such as blogs, microblogging, mailing lists, wikis and internet chat, other systems such as mumble are also being adopted for having open meetings over the internet where anyone can join in.  Typically a project will let contributors know which are the preferred methods for keeping up to date with project information and developments and which channels are preferred for informal chats.

Whilst I do not think that open-source development methods are perfect, I do believe that there is a lot companies can learn from them if they are willing to break away from traditional models.  Perhaps if they do then maybe they to can hit deadlines repeatedly and successfully in the same way many open source projects do.