Seven-and-a-Half Rules of Open Organisations[]

What is the seed of progress? And how do we cultivate its growth?

For Linux, that seed was a rudimentary operating system provided by an obscure college student from Europe. No commercial company would have dared put out something as unrefined as the first version of Linux. But for potential contributors that was an attraction. It meant there was enough to work on, but still a lot of gaps to be filled in. They could add something. Think about how difficult it is to modify a refined product.

To get an open source community going requires identifying an opportunity and putting up a first, promising stab at addressing it: a seed, a site, a way of working--- anything that will attract other contributions. Communities form around simple ideas but rarely create them. Attractive seeds usually come from odd, unusual and entrepreneurial people who have little to lose by pursuing crazy ambitions. How can an open organization coalesce around a simple idea and cultivate it?

1. Motivate and attract contributors…

We need a reason to join a community and to keep coming back. Goals and values certainly matter-- the more idealistic and inspiring, the better. Linux is a community underpinned by an ethic of shared exploration. Its contributors are peers rather than as expendable employees or contractors. They main contribute in hopes of status or creative expression; but Linux also depends on being deeply pragmatic and problem-solving: it allows software programmers to get together to do what they love, speaking a language only they understand. It delivers the goods. That is why people keep coming back to it. They get something tangible out of it: better software. A community high on ideals but which fails to deliver practical benefits will soon collapse.

2. Low barriers to entry, easy to use tools…

It has to be easy to get involved. Nupedia failed because contributions were difficult to make; Wikipedia took off because it is so simple to contribute. Linux and Wikipedia do not check people out before they are allowed to contribute. There is no lengthy recruitment and interview process. It's easy to grab the tools to start creating content. In open source, this self-help approach is as much a matter of necessity as principle.

The first versions of the Unix operating system, on which Linux is based, were created by Pro-Am programmers, Ken Thompson, Bill Joy and others in the 1960s. They could not afford to provide tech support, so they sent the programme to people, including a set of tools so users could sort out problems themselves. It is like a baker selling a cake but including the recipe and some basic ingredients with the package.

The more that easy to use tools are distributed to a community of knowledgeable users, the easier it is for them to start creating their own content. Giving people tools carries a risk that would worry many companies. What participants choose to work on and how they decide to use the tools cannot be mandated from above. This highly distributed approach to innovation – giving people tools, inviting them to decide what they work on – would still not add up unless the many contributions people make are brought together. How does that happen?

3. Crowds need meeting places...

...and they need a place they can make their own. If collaborators operate in a fixed, generic realm like a bureaucratic office building, they can't make their own niches to operate, their own groups to connect with. This is not simply a public park. We have seen such parks covered with graffiti and and trash. The Tragedy of the Commons exists where law-abiding citizens don't have an incentive or a responsibility to take action and make an individual contribution.

Develop the tools for making and modifying meeting places. Don't play-proof the playground by making it impossible to get hurt. Instead, allow for spontaneity and opportunity for games and get-togethers. And, keep in mind, the more eyes, the better. Wikipedia would fail without the constant vigilance of its supporters because it's so easy to be a dick and throw in some trash. Fuck.

4. Self Distribution of labour...

Let them do it themselves. Let them create problems; let them create solutions. Torvalds assumed that as people started to use the programme, they would try it out in different settings, find different ways in which it did not work and so discover how it could be improved. The more people tested it, in different situations, the more bugs would be found and if the users had the skills and tools to improve the programme themselves, then innovation could take place on the spot, where the problem had arisen, instead of being sent back to head office for repairs.

Many thousands of Linux contributors have made a long tail of smaller contributions, highlighting bugs. These provide the starting point for more ambitious innovations that are mainly the work of about 400 lead programmers who have earned a reputation for writing good software. The only way to get status in the Linux community is to make contributions that other people find useful. A traditional software company might employ these lead programmers to work full time. But it would find it much more difficult to mobilise the long-tail of mini-contributions that eventually add up to something far more substantial.

This ability to allow many thousands of people to make mini contributions is a vital organisational innovation. How do you mine all those small nuggets of knowledge?

5. Encourage people to build on your ideas…

It's like improv comedy. The impromptu actors build upon one another's jokes rather than killing the scene with a random one-liner.

Open source products are designed to evolve from the combination of many thousands of small contributions and a few large ones. Open source is not about creating beautifully designed, perfectly honed products. A good piece of code in an open source project is one that can be built upon by other people. The aim is constant improvement and refinement. That only takes place with dialogue and debate.

It's a conversation, not a speech. In many larger organisations the ethos is the corporate parade ground: speak only if you are spoken to, name rank and serial number. So too many people are afraid to speak up in such an authoritarian environment. Democracy works: a pragmatic, fix-as-you-go, approach to innovation – release early, test, learn, adapt, improve, release again – is made all the easier when there is lots of rapid feedback, because testing it fast and cheap.

6. Think Lego…

But then all the bits must fit together. How do they all add up, creating a whole that is greater than the sum of its parts? As Linux has become more complex, so it has been broken down into a series of interconnecting modules, like Lego bricks that click together. That means a team of programmers can work on just one module without necessarily knowing what anyone else is doing. As long as all the modules click together the programme as a whole should work. The way in which the modules click together, however, the interfaces between the bits, depends on some clear, simple, central design rules. Those rules usually do not come from the community but from a small core team, in this case Torvalds and some of his lieutenants. They design rules and protocols which allow mass innovation to add up. Linux is far from the first product to use modular design principles.

Modularity has been a feature of computer development since at least the 1960s when IBM was developing its system 360 computer. Fred Brooks the person responsible wanted everyone involved in the project to be kept abreast of what everyone else was doing. Daily notes of changes were shared with everyone. Pretty soon people were starting work by sifting through a two-inch wad of notes on design changes. By the time that wad was 5 feet thick Brooks decided he needed a different approach. The costs of communication and coordination had spiralled out of control. Miscommunication and misunderstandings grew. Adding people to the project did not solve the problem: more work got done, but more misunderstandings and so more bugs were created. Brooks decided to break the S360 into discrete modules – Lego bricks – which could be worked on separately. A core team set visible, central design rules, which specified what modules were needed, how they should to click together and what they should do. That meant that module makers could concentrate on innovation in their small world, while the core team could look after the architecture of the system as a whole. New and better modules could be fitted in without the entire system being redesigned.

Modularity takes off, however, when it is combined with open ways of working. Then it enables a mass of parallel experiments, with different teams working on the same modules, each proposing new solutions. That is how Linux gets the Holy Grail: a mass of decentralised innovation combined with overall coherence. Everything is done independently but it all fits together.

7. Conversational leaders…

We need leaders. We also need followers. To be effective, everybody has to be both. Nobody likes dictators; and the mindless bureaucrats will someday be replaced by algorithms and robots.

The greatest leaders are those who spark conversations. It's not about control-- in fact, the quest for control can destroy your cause (because nobody likes dictators). Leaders spark and facilitate conversations, whether about small things like a line of code or enormous things like the future viability of an open-source project.

Torvalds embodies the norms which encourage people to contribute and share. The open source ownership of the project, the fact that Torvalds gave his creation away, set the tone for the way the community behaves. It is all based on reciprocity. Even self-organising communities need leadership, but of a very distinctive kind. Torvalds is the acknowledged leader of the Linux community, just as Wales is the monarch of Wikipedia. But they are not leaders in the manner of corporate chief executives. They tend to be quiet, self-effacing, modest and self-confident. They lead by establishing values and norms. They do not need to hog the limelight, claim all the credit or have a big office. They lead by setting the context for many thousands of other people, at all levels of the community, to take decisions for themselves. Their particular style of top-down leadership allows for a mass of highly distributed bottom-up initiative. Proposed improvements have to gain a following, especially among respected peers. In some open source communities, such as the one that creates Apache, the software which runs most web servers, improvements are voted on by a committee, which has a revolving membership. These communities work because they have ways to raise and resolve conflicts, usually quite transparently, which promote good solutions, establish a common sense of direction, hold people together and in extremis, punish bad behaviour.

7.5 (It's not magic pixie dust)

Open source is not always the answer, believe it or not. And it's definitely not as easy as it sounds.

Apple, Inc. has a fantastic marketing strategy which revolves around surprising people. Their secrecy also keeps competitors from taking over their ideas before they are implemented. Open-source those nuke designs? How about giving away that secret recipe that made your business rise above the rest?

Be careful what you open-source. You won't control its destiny. You can create favorable conditions for success by following the rules above, but no promises.

Return to the Main Page
Proceed to Chapter 4 part 3