Open source software development method
From Wikipedia, the free encyclopedia
| Software Development Process |
|---|
| This article is part of the Software Development Process series |
| Activities and Steps |
| Requirements | Architecture | Implementation | Testing | Deployment |
| Models |
| Agile | Cleanroom | Iterative | RAD | RUP | Spiral | Waterfall | XP |
| Supporting Disciplines |
| Configuration Management | Documentation | Project Management | User Experience Design |
Open source software development is the development of Open source software products. 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 product are Mozilla Firefox and the OpenOffice.org Suite. The Open source software development method is very unstructured, because no clear development tools, phases, etc. have been defined like with development methods such as DSDM. Instead, every project has its own phases. There are, however, generalities between Open source development projects. In this entry these generalities will be described.
Contents |
[edit] History
In 1997, Eric S. Raymond wrote The Cathedral and the Bazaar. In this 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 is points to the discussion involved in an Open source development process. In some projects, anyone can submit suggestions and discuss them. Fact is, that the ‘coherent and stable systems’ Raymond mentions 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.
More general historic information can be found in the article about Open source software.
[edit] Open source software development tools
Several kinds of tools are being used to assist in Open source software development. These tools include the ones described in this section.
[edit] Source code revision control
These tools are also referred to as version control tools, or configuration management tools.
According to Bar & Fogel, the participants in Open source software development projects are mostly volunteers and distributed amongst different geographic regions. Also, a lot of different additions to the code have to be integrated into one consistent whole. This can not be done by one author, because in informal project such as Open source projects, the work is not divided in advance and is not centrally directed. Moreover, in Open source projects the (majority of the) participants are not trained to work together, simply because this investment would be lost if a volunteer leaves, and is replaced by an untrained volunteer.
Bar & Fogel mention that in Open source software development, “the source code is made accessible to the entire world”. Releasing the code has advantages for the project, for instance bugs can be fixed by volunteers. This principle arises some issues: the source code should be released often, because bug tracking demands this: by releasing the code often, participants can check if a particular bug is already fixed or being fixed. The participants of Open source projects continuously need access to the latest versions of the continuously changing source code. To accommodate this, individual contributors have to be able to enter changes to the code.
These issues make the use of a Version control system necessary. This is a category of systems that facilitate in the continuous changing of code, keeping track of changes, etcetera.
Concurrent Versions System (CVS) is a major example of a source code collaboration tool being used in OSS projects. CVS supports (and integrates) two different needs in Open source software development: keeping track of changes and collaboration. In short, CVS works as follows:
- A individual participant downloads a ‘working copy’ of the project. This is a composition of the files making up the project, arranged in a directory tree.
- The participant starts working in the downloaded copy. Other participants can simultaneously start working in there downloaded copies.
- After the participant is done making changes, he commits them into the repository, along with a log message of what was changed and why this was done.
- Other participants can track recent changes to the repository by synchronizing their locally stored copies with the centrally stored ‘master’.
The system tracks the changes that are made to the code, and which version of the repository these changes were made in. In this way, conflicting changes to the same part of the project can be traced. The conflicts can be solved by choosing the best change, or integrating both changes in one new version. CVS also enables one to easily go back to a previous version of a file and retrieve it.
Subversion (svn) is a version control system designed specifically to be a modern replacement for CVS. The major advantages of Subversion over CVS are described in the main article about Subversion.
[edit] Testing tools
Since OSS projects undergo frequent integration, tools that help automate testing during system integration are used. An example of such tool is Tinderbox. Tinderbox enables participants in an OSS project to detect errors during system integration. Tinderbox runs a continuous build process and informs users about the parts of source code that have issues and on which platform(s) these issues arise. Furthermore, this tool identifies the author of the offending code. The author is then held responsible for ensuring that error is resolved. Opensourcetesting.org is a website on which open source testing tools are collected. Mainly because normal testing tools are quite expensive and often have features that are not needed, open source testing tools are gaining popularity.
[edit] Bug tracking
Bug tracking is sometimes referred to as error or defect tracking.
Bug tracking is an important aspect of OSS projects. Bug tracking includes the following tasks: keeping a record of all reported bugs, whether the bug has been fixed or not, which version of the software does the bug belong to, and whether the bug submitter has agreed that the bug has been fixed (squashed). Popular bug tracking systems include GNATS and Bugzilla.
GNU GNATS is a set of tools for tracking bugs reported by users to a central site. It allows problem report management and communication with users via various means. GNATS stores all the information about problem reports in its databases and provides tools for querying, editing, and maintenance of the databases.
Bugzilla is a "Defect Tracking System" or "Bug-Tracking System". It allows individual or groups of developers to keep track and manage outstanding bugs in their product.
Opensourcetesting.org maintains a list of open source bug tracking tools. This list contains open source bug tracking tools that are hosted on Sourceforge, and is updated weekly.
[edit] Communication & Collaboration
Since the participants in an Open source software development project are dispersed, there is a need for tools to aid in organizing communication between project participants. This is accomplished with the aid of websites (Freshmeat, GNU Savannah, SourceForge), mailing lists (GNU Mailman) and instant messengers (MSN, ICQ, and also IRC). The above mentioned Open Source Software development tools are an essential and integral part of the Open Source Software development model.
[edit] Package management
A package management system is a collection of tools to automate the process of installing, upgrading, configuring, and removing software packages from a computer. The RedHat Package Manager (RPM) is a package management system used by a number of Linux distributions.
[edit] Compiling
A compiler is a computer program (or set of programs) that translates text written in a computer language (the source language) into another computer language (the target language). The Amsterdam Compiler Kit is an Open source compiler kit.
[edit] Debugging
A debugger is a computer program that is used to debug (and sometimes test or optimize) other programs. GNU Debugger (GDB) is an example of a debugger used in Open source software development. This debugger offers remote debugging, what makes it especially applicable to Open source software development. Also, some memory leak detectors have been designed to work with GDB.
[edit] Memory leak & validation
A memory leak tool or memory debugger is a programming tool for finding memory leaks and buffer overflows. A memory leak is a particular kind of unnecessary memory consumption by a computer program, where the program fails to release memory that is no longer needed. Examples of memory leak detection tools used by Mozilla are the XPCOM Memory Leak tools. Validation tools are used to check if pieces of code conform to the specified syntax. They are most often used in the context of HTML/XML, but can also be used with programming languages. An example of a validation tool is LCLint, now called Splint.
[edit] Performance profiling
Performance profilers are tools used to measure product performance. MOZ_TIMELINE, for example, is a timing instrumentation used by Mozilla to measure application startup times.
[edit] Open source software development phases
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 placed on the right side. 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. In table 1, the activities displayed in the figure are explained.
The process starts with a choice between the adopting of an existing project, or the starting of a new project. The difference between these two is explained in the section ‘New projects vs. existing projects’. 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.
[edit] Open source software licensing
Licensing is a major issue in Open source software development. See the section on Open-source license for more information.
[edit] Open source software development methods
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. Besides requirements, often volunteer staff is attracted to help developing 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”.
Alfonso Fuggetta mentions 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”. One Open source development method mentioned by Fuggetta is the Agile method Extreme Programming. All the Agile methods are in essence applicable to Open source software development, because of their iterative and incremental character. Another Agile method, Internet Speed Development, is also suitable for Open source software development in particular because of the distributed development principle it adopts. Internet Speed Development used geographically distributed teams to ‘work around the clock’. This method is mostly adopted by large closed source firms like Microsoft, because only big software firms are able to create distributed development centers in different time zones. Of course if software is developed by a large group of volunteers in different countries, this is being achieved naturally and without the investment needed like with closed source software development.
[edit] New projects vs. existing projects
There are some differences between the use of Open source software development for new projects (new software products that are developed from scratch) and existing projects (existing non-open source software projects which development is continued following the Open source software development method. The major difference is that new projects most of the time do not start with an Initiation phase, because already a body of code, a workplan and a development team exist. In new projects, the Initiation phase does have to be done.
[edit] Example of Open source software development: the Mozilla Foundation
Mockus et al. describe the history of the Mozilla Organization (that has now become the Mozilla Foundation), and their browser project, Mozilla. The Mozilla Foundation was founded in 1998 to create the next-generation internet suite for Netscape. Netscape released most of the code base for its popular Netscape Communicator internet suite under an open source license. In other words, this product is an example of a project using commercially developed code as the basis for an Open source software project. In the beginning of the project, Mozilla had trouble getting enough labor force for the development team. After the documentation was improved, tutorials were written, and the development tools and processes refined, participation slowly started to increase. Mozilla does not depend on volunteers to man its development team; instead programmers are employed. There does, however, remain a large group of volunteers involved in the A roadmap document is maintained, in which specifications for future releases are written, as well as the dates for which releases are scheduled. Anyone can report bugs or make remarks on releases. The Bugzilla problem reporting tool is used for the tracking of bugs. Work is divided by letting the developers choose which part of the code development suits them best, according to their skill and expertise. The development of code to fix bugs is often attached to the problem report in Bugzilla. Every day the main body of code is updated, and a check is done to test if the code is still working. If the code does not work anymore, the bugs in the code are traced and solved. Code is inspected before it is implemented into the main body of code existing so far. Release management is done by the method of ‘milestone’-releases. In this method, approximately once per month a release of the software is done, but always when the so far developed code is ready for the release. It is, in other words, a human decision when this release is done, and not an automated process. For the release management the tool Tinderbox is used.
[edit] References
- ↑ Raymond, E.S. (1999). The Cathedral & the Bazaar. O'Reilly Retrieved from http://www.catb.org/~esr/writings/cathedral-bazaar/. See also: The Cathedral and the Bazaar.
- ↑ Bar, M. & Fogel, K. (2003). Open Source Development with CVS, 3rd Edition. Paraglyph Press. (ISBN 1-932111-81-6)
- ↑ Sharma, S., Sugumaran, V. & Rajagopalan, B. (2002). A framework for creating hybrid-open source software communities. Information Systems Journal 12 (1), 7-25.
- ↑ Robbins, J. E. (2003). Adopting Open Source Software Engineering (OSSE) Practices by Adopting OSSE Tools. Making Sense of the Bazaar: Perspectives on Open Source and Free Software, Fall 2003.
- ↑ Abrahamsson, P, Salo, O. & Warsta, J. (2002). Agile software development methods: Review and Analysis. VTT Publications.
- ↑ Fuggetta, A. (2003). Open source software - an evaluation, Journal of Systems and Software, 66, 77-90.
- ↑ Mockus, A., Fielding, R. & Herbsleb, J. (2002). Two case studies of open source software development: Apache and mozilla, ACM Transactions on Software Engineering and Methodology 11 (3), 1 – 38.
[edit] See also
- Open Source Wiki Project
- Open-source software
- Software development process
- Extreme Programming
- Agile Software Development
- Internet-Speed Development
- Release Management
- Software engineering
- Revision control
- Meta-Modeling
- Meta-Process Modeling
| Activity | Sub-activity | Description |
|---|---|---|
| INITIATION | PROBLEM DISCOVERY | The INITIATION PHASE starts with the PROBLEM DISCOVERY. During this phase problems to be addressed during the project are gathered, often by a large group. For these problems, a PROBLEM DESCRIPTION is made. These PROBLEM DESCRIPTIONS can be reported and discussed using an E-mail list, a problem reporting system and a USENET newsgroup. |
| FINDING VOLUNTEERS | After identifying problems, volunteers and also paid personnel are recruited to work on these problems. These people together form the DEVELOPMENT TEAM. | |
| SOLUTION IDENTIFICATION | The INITIATION PHASE ends with identifying solutions for the discovered problems. Often there are multiple solutions for the identified problems. Through discussion the best solution is selected for each solution. These solutions are used to create a WORKPLAN, with a description of how to get to these solutions. | |
| EXECUTION | CODE DEVELOPMENT & TESTING | The EXECUTION PHASE is initiated with the CODE DEVELOPMENT AND TESTING. CODE is most likely to be developed using an Agile software development method, with an iterative & incremental design. Developers sometimes develop code individually, and test the newly CODE on a local copy of the so far developed CODE. CODE development can however also be done in geographically distributed teams and by directly changing centrally stored CODE, maintained by a versioning system. |
| CODE CHANGE REVIEW | After the development and testing of a piece of CODE, this CODE is reviewed and tested by other developers. If any problems are found with the CODE, suggestions for improvement are made to the owner of the piece of CODE. After the owner changes the CODE to overcome the identified problems, the CODE is again reviewed and tested. This process is repeated until no (major) problems or flaws are found in the CODE, and the CODE is approved for implementation. | |
| CODE COMMIT & DOCUMENTATION | Approved CODE can be added to the body of so-far developed CODE. Changes of the body of code are done through a version control system. The working of such a system is explained in the section ‘Open source software development tools’. Changes to the CODE are reviewed by developers in- and outside the core team which developed the change. | |
| RELEASING | RELEASE MANAGEMENT | When a RELEASE date draws near, one of the members of the DEVELOPMENT TEAM volunteers for the function of release manager. The release manager identifies outstanding problems and their solutions and makes suggested changes. After the product is approved for releasing, a RELEASE is done. |
