Open-source software development
Open-source software development (OSSD) is the process by which open-source software, or similar software whose source code is publicly available, is developed by an open-source software project. These are software products available with its source code under an open-source license to study, change, and improve its design. Examples of some popular open-source software products are Mozilla Firefox, Google Chromium, Android, LibreOffice and the VLC media player.
History[edit]
In 1997, Eric S. Raymond wrote The Cathedral and the Bazaar.[1] In this book, Raymond makes the distinction between two kinds of software development. The first is the conventional closed-source development. This kind of development method is, 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 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.
Differences between the two styles of development, according to Bar and Fogel, are in general the handling (and creation) of bug reports and feature requests, and the constraints under which the programmers are working.[2] 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 creating and prioritizing 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.
Methods[edit]
It is hard to run an open-source project following a more traditional software development method like the waterfall model, because in these traditional methods it is not allowed to go back to a previous phase. In open-source software development, requirements are rarely gathered before the start of the project; instead they are based on early releases of the software product, as Robbins describes.[4] Besides requirements, often volunteer staff is attracted to help develop the software product based on the early releases of the software. This networking effect is essential according to Abrahamsson et al.: “if the introduced prototype gathers enough attention, it will gradually start to attract more and more developers”. However, Abrahamsson et al. also point out that the community is very harsh, much like the business world of closed-source software: “if you find the customers you survive, but without customers you die”.[5]
Fuggetta[6] argues that “rapid prototyping, incremental and evolutionary development, spiral lifecycle, rapid application development, and, recently, extreme programming and the agile software process can be equally applied to proprietary and open source software”. He also pinpoints Extreme Programming as an extremely useful method for open source software development. More generally, all Agile programming methods are applicable to open-source software development, because of their iterative and incremental character. Other Agile methods are equally useful for both open and closed source software development: Internet-Speed Development, for example is suitable for open-source software development because of the distributed development principle it adopts. Internet-Speed Development uses geographically distributed teams to ‘work around the clock’. This method, mostly adopted by large closed-source firms, (because they're the only ones which afford development centers in different time zones), works equally well in open source projects because a software developed by a large group of volunteers shall naturally tend to have developers spread across all time zones.