Requirements Elicitation in Open-Source Programs

What is Open Source? The way an open-source program comes into being is that a developer writes a program for his own use to meet his own needs and then distributes it freely for the rest of the community to use if desired [1]. This type of program is not necessarily open source—it is just free software. There is more to an open-source program; the original programmer distributes the source code along with the binary version of the program and anyone willing to make an effort can check the code before compiling and running the program. Over the years, the term open source has meant different things. The Open Source Initiative (OSI) was created to try to standardize the definition and even license programs. According to the OSI definition, in order for software to be truly open source, it must exhibit certain characteristics, some of which are: • Free redistribution. • Inclusion of the source code. • Allowance for modifications of the program/product distributed under the same terms as the original. • Restricted distribution of modified source code to distribution of patches. • No discrimination against individuals or groups. • No discrimination against a specific field. • Distribution of license. The license attached to the product applies to all parts of the product and does not depend on a program being a particular software distribution One of the key points listed above is that open-source software allows for modifications to be made to the source code of a program written by others. In The Cathedral and the Bazaar, Eric Raymond describes how an open-source program is created [2]. A programmer writes a (sometimes small) program and distributes it, usually by posting in a news group the location from which it can be downloaded. Others download it, use it, fix it (if warranted), and add features so that it is more useful. The creation is a group effort, and the program evolves (sometimes over a very short time). One of the central points of this paper is that the program users become its co-developers.

[1]  Robert J. Stahl,et al.  We can agree after all! Achieving consensus for a critical thinking component of a gifted program using the Delphi technique 1 , 1991 .

[2]  Richard E. Fairley,et al.  The concept of operations: The bridge from operational requirements to technical specifications , 1994, Proceedings of IEEE International Conference on Requirements Engineering.

[3]  Joseph A. Goguen,et al.  Techniques for requirements elicitation , 1993, [1993] Proceedings of the IEEE International Symposium on Requirements Engineering.