Be lazy, be fast

At its best Open Source software is about accelerating the pace of innovation by enabling unconnected groups to collaborate across organisational borders. It is a software development process that allows people to freely share ideas and...

Share

At its best Open Source software is about accelerating the pace of innovation by enabling unconnected groups to collaborate across organisational borders. It is a software development process that allows people to freely share ideas and implementations among a community of peers while still focusing on their own local needs and business drivers

To gain the maximum benefit from this development process it is necessary f or participants to relax their grip on the software they produce. There can be no single individual or organisation that owns the code since ownership implies control and unnecessary control limits innovation in a community led project

For many however, the concept of community owned software presents a problem. Community management and collaboration is usually seen as a slow process. For many collaboration is a luxury that is only appropriate when time is available. Unfortunately this misunderstanding prevents a full engagement with open source. In some cases open source is avoided entirely. In others the code is forked and any local customisations are kept local, which result s in higher maintenance costs in the long term

The reality is, however, that a well-run open source project is not slow, in fact some of the more popular projects move so quickly it can be difficult to keep up. But what defines a well-run open source project? There are a number of important attributes to look for. In this article I want to focus on the key processes that allows a community led project to progress at speed

The first thing to understand is that efficient community development does not imply democracy. An open source community does not manifest itself as "one voice, one vote". Instead the community should recognise those who understand the strategic goals of the community and actively work towards achieving those goals. The phrase "actions speak louder than words" translates to "code speaks louder than words" in an open source project

It's not that words are unimportant, talking through major strategic decisions or significant architectural changes makes sense, but the most productive software development activities are about writing code. Open source development models seek to allow community members to get on with writing the code that needs to be written while also ensuring that progress continues to wards the agreed upon strategic and architectural goals

A key tool in supporting developers is version control. This provides many of the advantages of a time machine (unfortunately not all though). U sing our time machine coding mistakes made today can be easily rectified tomorrow. Open source takes advantage of this fact* Community participants need not be scared of mistakes. As long as there is a review process designed to catch and rectify mistakes quickly we can turn back time and all will be well again

By adopting a solid review process for all changes, a healthy open source software project does not require most changes to be actively pre-approved - that would be cripplingly slow. Instead, projects adopt a process that assumes an absence of objection is the same as approval. This is a safe assumption to make since changes are reversible and thus "after the event" consensus is acceptable. In the Apache Software Foundation we call this "Lazy Consensus" but you will find the same process in many other open source projects and foundations

For lazy consensus to work it is necessary to ensure that the process of co de contribution is open, transparent and incremental. This allows community members to actively review changes that affect them and to passively accept changes that do not affect them. Community members are able to raise an objection during review. However, if objections were cheap this could become another pain point in the process. It is therefore no accident that it is harder to object to a change than it is to accept it. Actions speak louder than words

By making the objection process harder than the approval process community members will only object if they feel the community will support the object ion. In an Apache project objections must be supported by a full justification and, where appropriate, an alternative set of actions. For example, an objection to a new feature that introduces a security issue, or one that demonstrates a change is in conflict with the projects defined strategy, is usually valid and thus will be backed by the community. In these cases the change is reverted and the contributor who needs the feature is forced to co me up with a more secure or appropriate implementation

Whilst some objections are likely to be supported by the community others are of a more personal or trivial nature, such as the choice of colour for a new widget. Such objections might not be seen as valid by the community. Therefore it is best to support the objection with an alternative implementation that satisfies the both your own needs and those of the original contributor. For example, an implementation that makes the widgets colour fully configurable

In this latter case, thanks to lazy consensus, the objection would probably never be raised. There is an easier way. The alternative implementation would simply be committed under lazy consensus. In this case, not only has the project got a new widget, but the original implementation has been improved as well. All this without the need for time consuming debates and votes

Whilst lazy consensus is suitable for the majority of changes there are situations in which lazy consensus is not appropriate. A significant change that is known to directly affect other community members is one such example.* In these situations it is best to make a proposal first. This allows people to comment on and improve your proposal before you start work. However, even here there is no need to seek full approval from all members of the community. It is still possible to assume that a proposal without objection is a proposal that will be accepted. It is up to the person doing the work to decide what level of explicit approval is needed before investing time and money in the work

Lazy consensus enables rapid innovation in collaborative projects. It ensures that those willing to do the work are empowered to get it done, while al so providing mechanisms to maintain a reasonable level of control on the project. It recognises that actions speak louder than words and it rewards those willing to back their words with actions. It can be a tricky concept to come to terms with, but it is truly worth the effort. Once you've mastered it you will probably start bringing into all aspects of your work, not just in open source software development

Posted by Ross Gardler

Ross is a committer and PMC member on a number of Apache projects, a champion and mentor on incubating projects including OpenOffice.org, and Vice President of the Community Development project. He is a founder of OpenDirective, a company specialising in making the connections between the academic research sector and the commercial product and service delivery sector. Until recently Ross was manager of OSS Watch, the open source advisory service to the UK higher and further education sector. He is chair of the TransferSummit/UK conference, which seeks to link the academic research sector and the commercial sector.