Open source software development is the process by which open source software (or similar software whose source code is publicly available) is developed. These are software products “available with its source code and under an open source license to study, change, and improve its design”. Examples of popular open source software products are Mozilla Firefox, Google Chrome, Android and the OpenOffice.org Suite. In the past, the open source software development method has been very unstructured, because no clear development tools, phases, etc., had been defined like with development methods such as Dynamic Systems Development Method. Instead, every project had its own phases. However, more recently there has been much better progress, coordination, and communication within the open source community.
In 1997, Eric S. Raymond wrote The Cathedral and the Bazaar. In this fasting book, Raymond makes the distinction between two kinds of software development. The first is the conventional closed source development. These kind of development methods are, according to Raymond, like the building of a cathedral; central planning, tight organization and one process from start to finish. The second is the progressive open source development, which is more like a “a great babbling bazaar of differing agendas and approaches out of which a coherent and stable system could seemingly emerge only by a succession of miracles.” The latter analogy points to the discussion involved in an open source development process. In some projects, anyone can submit suggestions and discuss them. The ‘coherent and stable systems’ Raymond mentions often do emerge from open source software development projects. Differences between the two styles of development, according to Bar & Fogel, are in general the handling (and creation) of bug reports and feature requests, and the constraints under which the programmers are working. In closed source software development, the programmers are often spending a lot of time dealing with and creating bug reports, as well as handling feature requests. This time is spent on prioritizing and creation of further development plans. This leads to (part of) the development team spending a lot of time on these issues, and not on the actual development. Also, in closed source projects, the development teams must often work under management-related constraints (such as deadlines, budgets, etc.) that interfere with technical issues of the software. In open source software development, these issues are solved by integrating the users of the software in the development process, or even letting these users build the system themselves.
Open source software development can be divided into several phases. The phases specified here are derived from Sharma et al.. A diagram displaying the process-data structure of open source software development is shown on the right. In this picture, the phases of open source software development are displayed, along with the corresponding data elements. This diagram is made using the meta-modeling and meta-process modeling techniques.
The process starts with a choice between the adopting of an existing project, or the starting of a new project. If a new project is started, the process goes to the Initiation phase. If an existing project is adopted, the process goes directly to the Execution phase.
One can distinguish several different types of open source projects. First, there is the garden variety of software programs and libraries. They are standalone pieces of code. Some might even be dependent on other open source projects. These projects serve a specified purpose and fill a definite need. Examples of this type of project include the Linux kernel, the Firefox web browser and the OpenOffice.org office suite of tools.
Distributions are another type of open source project. Distributions are collections of software that are published from the same source with a common purpose. The most prominent example of a “distribution” is an operating system. There are a large number of Linux distributions (such as Debian, Fedora Core, Mandriva, Slackware, Ubuntu etc.) which ship the Linux kernel along with many user-land components. There are also other distributions, like ActivePerl, the Perl programming language for various operating system, and even the OpenCD and cygwin distributions of open-source programs for Microsoft Windows.
Other open source projects, like the BSD derivatives, maintain the source code of an entire operating system, the kernel and all of its core components, in one revision control system; developing the entire system together as a single team. These operating system development projects closely integrate their tools, more so than in the other distribution-based systems.
Finally, there is the book or standalone document project. These items usually do not ship as part of an open source software package. The Linux Documentation Project hosts many such projects that document various aspects of the GNU/Linux operating system. There are many other examples of this type of open source project.
There are several ways in which work on an open source project can start:
1. An individual who senses the need for a project announces the intent to develop the project in public. The individual may receive offers of help from others. The group may then proceed to work on the code.
2. A developer working on a limited but working codebase, releases it to the public as the first version of an open-source program. The developer continues to work on improving it, and possibly is joined by other developers.
3. The source code of a mature project is released to the public, after being developed as proprietary software or in-house software.
4. A well-established open-source project can be forked by an interested outside party. Several developers can then start a new project, whose source code then diverges from the original.
Eric Raymond observed in his famous essay “The Cathedral and the Bazaar” that announcing the intent for a project is usually inferior to releasing a working project to the public.
It’s a common mistake to start a project when contributing to an existing similar project would be more effective (NIH syndrome). To start a successful project it is very important to investigate what’s already there.