In his book The Cathedral and the Bazaar (Raymond 2001), Eric S. Raymond divides between two different paradigms of software development; the Cathedral and the Bazaar. The cathedral represents the hierarchical and ordered organization of the big software companies. The bazaar on the other hand represents the many independent actors in the open source community. This comparison gives a good picture of the differences between companies and the open source community, but is not all together true. All companies is not necessarily strongly hierarchically organized, and the Open Source community have many organizations that gives structure to the development. I will in this section look closer at the Bazaar model, with which I mean the distributed innovation done in open source projects.
To build usable software is a extraordinary complex process. It is hard to predict the time and money required to build an application. The computer software history is full of examples where project have blown the budged and gone severely over schedule, and sometimes never finished. This complexity exist for both proprietary developed software and software developed by an open source project. This complexity however is handled in different ways. In a business setting complexity is often handled through distribution of labor. The scheduling of tasks is most often handled in a top-down fashion by management. Because different part of an application often have complex dependencies, it is exceedingly difficult to make good decisions about how labor should be distributed. There is no question about the need to distribute software development, the task of making large computer software is too big for anybody to do alone. Unlike when an architect is drawing a building it is not possible for a software architect, or a group of software architects, to make a drawing, or plan, of the software and hand it down to the workers and expect that the software will become as he imagined. The field of software development is simply a to complex and lucid a thing, to accurately pin down in general terms. The bazaar and the cathedral are illustrations on how labor are distributed.
In an FLOSS setting division of labor is done in a quite different manner. Production in a FLOSS project is based on voluntary labor. A company hands out reward in form of payment and can threaten to fire an employee if he does not fulfill the requirements laid on him. Because of this the company can make the employee perform a task that he finds boring. This is not the case with voluntary labor. In an FLOSS setting you have the chance to choose what you want to contribute. There exist a multitude of project that you can choose to contribute to, and if you find a need in an area you are interested in you can start your own project to fulfill that need.
This motive to participate in or start a project in a area you are interested in is labeled with the phrase “to scratch a personal itch”. In this scenario the developer is both the user of the software and the developer. Close communication between users and developers is critical to the successful development of software with non-trivial and/or uncertain requirements. When the user and developer is merged into one, this communication is as perfect as it can get. Participants in a FLOSS setting are user-programmers, with varying degree of emphasis on user or programmer. There are a varying degree of sophistication and involvement by the user-programmer. The different degrees can be exemplified by the following phrase: “All can make suggestions, many can send bug reports, some can make patches and a few can make major contribution.”
FLOSS developers being motivated by interest might lead you to think that a lot of boring task will not be done. Among programmers the tasks of user documentation and visual design is often not found interesting, but participation in FLOSS is not limited to programmers. As an example I can mention freecol http://www.freecol.org/. Freecol is an FLOSS implementation of a computer game called Colonization. In this project a music composer, two graphics designer and a writer is mentioned on the Credits page. FLOSS gives people with different interest a chance to do what they like, and at the same time give them a chance to share it with the world. It seems that the way of organizing complex task through individuals choosing tasks is a viable alternative. It is true, however, that proprietary software usually are more pleasing to the eye. After all like many other commercial products, proprietary software are in large part dependent on the wrapping to sell.
There is a danger that the code you develop will not be accepted into the project. When this happen one choice FLOSS provides you is the possibility to fork the original project, that is to take the source code and distribute your own version. This is a danger taken seriously by the FLOSS community. This do not happen frequently because among other reasons you have to build a community around your distribution and because you can not take the trade mark. If the time you spent on making code that are not accepted was measured in money, as it would be in a corporate setting, it would be considered a great waste.
Because FLOSS project often depend on contributions from many developers and because FLOSS do not suffer from the tight schedules that are common in corporate settings, you both have the incentive and time to give proper structure and documentation to the code being developed. For new people to be able participate it is important that the entry level to understand the code is not prohibitively high.
When Netscape Communication decided to release the code for their browser they had to restructure the code. Their browser was developed in a corporate setting with a tight schedule, but when they wanted to build a community of voluntary developer around the browser Netscape understood that it had to represent the code in a more communicative way. Still after restructuring the code it was found to difficult to build upon. The Mozilla project which the FLOSS project that spun off from the Netscape source release was named, decided to build the browser based on the FLOSS Gecko layout engine. This allowed for a much more modular design of the code, which made code contribution much easier.