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 N2 effect (Brook’s Law)
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
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
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
You know that the rules of the Gentiles lord it over them, and
their high officials exercise authority over them. Not so with
you. Instead, whoever wants to become great among you must
be your servant, and whoever wants to be first must be your
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
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
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
3. Minimise how many times you have to reinvent the wheel.
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
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.