5.4 Governance

Although the FLOSS community is very individualised it is not enough to explain FLOSS by individual motivations. Individual motivations is the cornerstone of the community, but efforts needs to be coordinated. Unlike many genre of art you need to work closely with other practitioners of the coding “art”. It is simply to much work to do for one individual alone. For small projects with just a few developers, which is the majority of FLOSS projects, the question of governance and management is not very important. It is only for projects of some size that the previously mentioned N² effect (Brook’s Law) becomes relevant.

Maybe the most important aspect that help to frame the FLOSS community is the license. This is mentioned in section 5.5. But other factors are important in how FLOSS is governed. A basic value of the community is that your work speaks for you. It is at its core a meritocracy. According to the survey previously mentioned 48.4% of the respondents mentioned among the three most important things a leader should do, that the leader should “Create initial code base”. 34.4% answered “Contribute code” (Lakhain et al. 2002). This shows that the ability of a leader to create code is what legitimise him most as a leader.

Linux is an example of such. Linus Torvalds started the development of Linux as a post graduate student. He initially released a small, but working kernel. Many others later joined the project, but Torvalds still have the final saying in what is going to be incorporated in the official releases of the Linux kernel. Torvalds gained his initial leadership role because he made the first release. He kept his leadership role and avoided forking because of a combination of responsiveness and charismatic leadership. Because he responded to patches and suggestions contributors felt that their work were appreciated. After the Linux kernel and the Linux community grew Torvalds had problems responding to the community, because it was to much for one man to do. This is often called the “Linus don’t scale” problem. This was solved by giving the responsibility for different sub systems of the kernel to lieutenants, who could approve patches. This made the Linux project into a hierarchical ordered organisation.

This story about Linux points to tree important organising factors common is FLOSS. That is the right to submit code into an official release, charismatic leadership and meritocracy. Because it is difficult to build a community of developers around a forked version of code, the ability to decide what is to be included in an official release gives power. The charismatic leadership of Torvalds is important for Linux, but other forms of organisation exists. In the Apache Foundation a board is elected by the foundation’s members. In that kind of an organisation charismatic leadership is less important. In all cases the time, effort and skill you put into making working code is what most give you the power to influence an FLOSS project.

Even if the management in FLOSS is not strong and coercive and most often do not have the power to punish and reward, it is still important with management. As we have seen punishment and reward is a poor motivator for creative work, so the more informal structures in FLOSS is an asset. Successful management is FLOSS is more in the spirit of this saying of Jesus (Matt 20:25-26):

Management in FLOSS must be with a serving attitude. If a developer do not like the way he is treated he can just leave, and there is also the possibility of forking the code. This to not imply toothless leadership, you must be able to give direction and convince others about your decisions.

Weber tries to capture what FLOSS participants do and how project are managed in the following eight point. This points are most relevant for the projects which are based on the bazaar model, or as I prefer to call it a community model. This is because community gives more sense of identity and structure than the word bazaar.

1. Make it interesting and make sure it happens.

FLOSS developers choose to participate and chooses which tasks they want to contribute to. Many of the tasks that needs to be done to make good software is uninteresting. What is thought of as interesting or uninteresting will vary among contributors. With a community of some size associated with the project, a project leader can hope that someone will find a particular task interesting or valuable as a learning experience. To make sure an uninteresting piece of work get done, the project leader engage the community and encourages someone to step up to the task. Doing such tasks increases a contributor’s standing in the community.

The contributors want their work to be appreciated by seeing their work getting into actual use. Projects that looks like it will generate significant products will attract more contributors. If the project can offer interesting programming challenges it is even better. The contributors don’t want to waste their effort on dead-end projects.

2. Scratch an itch.

The itch a FLOSS developer can scratch is the problems he faces in his immediate environment. Most software code is written for in-house use, estimated to about 75%, and are not written for sale. It is much more cost efficient for a business to contribute to an existing project to make it useful for a specific in-house use, than it is to build the same from scratch. Besides, this releases the business from maintaining a lot of in-house built code. For hobby programmers there are other itches. Linus Torvalds wanted to have an operating system similar to the one they had at the university, at home. People contributed to Emacs because they wanted the editor to do more useful tings.

3. Minimise how many times you have to reinvent the wheel.

To write good quality code is hard and time consuming work, so FLOSS developers tries to avoid writing code for problems that are already solved, whenever this is possible. Volunteer FLOSS programmers have an extra strong incentive to avoid this, since they are not compensated for their time. Within proprietary settings there is constantly a need to reinvent the wheel, since the code is not available to the competitors.

4. Solve problems through parallel work process whenever possible.

In the conventional engineering archetype there is one or a few architects that are responsible for deciding what need do be done, and to delegate sub-tasks to the hierarchy beneath the architects. The architects defines the problems that needs to be solved. On a FLOSS project the project leader can set the effective definition of a problem that need to be solved, in other cases the definition can be given by a desired feature request, suggestions or by the discovery of bugs. There can potentially be many ways to solve a problem. By attracting a number of developers to work on this problem different routes to a solution can be explored. No central authority decides which routes should be explored or who should explore them.

There can also be problems that are not tied to a specific project. One example is the problem of making and displaying dynamically created web content. This have given rise to many different web development frameworks. Different solutions to this problem have given rise to different projects.

5. Leverage the law of large numbers.

Even a moderately complex program has a functionally infinite number of paths through the code. To discover bugs in the code as many as possible of this paths should be tested. The developers of this program have preconceived ideas of how this program are to be used. The consequence of this is that only a tiny portion of the possible uses of the software will get tested by a few developers. By submitting the code to massive peer review, and by letting many people use the software, more bugs will get uncovered, and the fix will be obvious to someone. “Given enough eyeballs, all bugs are shallow” (Raymond 2001) is a phrase used to describe this. By having different people doing different things with the software more bugs will get uncovered. The bug can then be communicated to an audience of possible fixers. For one of these the fix will be obvious. Lastly the fix have to be incorporated into the main code base.

6. Document what you do.

Documentation is important in both proprietary and FLOSS settings. It is difficult and time consuming to deduce how a program, or piece of code, function by simply reading the code. In proprietary settings developer documentation can often be substituted by face-to-face communication because of the proximity of the developers. Proprietary software can be developed in a distributed manned within a large enterprise, and FLOSS can be developed by a tightly knit group without contribution from the outside. Distributed development is more common in the FLOSS setting, and is facilitated by the openness of the code and the liberal licences for distribution. For distributed development good documentation is important for the different contributors to get up to speed on what can and should be done. To attract volunteer user-programmers into contributing to a project good developer documentation is a way to lower the entry barrier. Developer documentation transfers the knowledge of the software author across time and space. Good user documentation is equally important for FLOSS and proprietary software, if they want their software to be used.

7. Release early and release often.

FLOSS project built on the community model can harvest more contribution by early and frequent releases. In this way contributors can see the result of their contribution quickly and bugs can be discovered more quickly. If the number of new features contributed to a project gets too high it can overload the selection mechanism, selecting which features to include in the official release. Each new feature included can contain new bugs, so the number of new features have to be balanced against the desired stability of the code. This is why many project have a development and a stable release.

8. Talk a lot.

Interaction is the mean by which social systems are changed and replicated over time and space, to recapitulate a central concept from structuration theory. In community based FLOSS projects the activity on e-mail lists, discussion forums and other mediums for communication is fundamental in creating communal identity around a project. A common misconception about the community based FLOSS process is that it involves like-minded geeks who cooperate and agree with each other based on technical grounds. The tone of conversation if often far from calm and polite, and disagreements, frustrations and criticism are openly vented. Discussions about technical problems is generally grounded in a belief that there exist a technical solution. However, the solution is not always obvious and there can be many contending solution.