Management of the Open Source Software Requirements. Kati Koistinen

1 Management of the Open Source Software Requirements Kati Koistinen

2 Table of Contents Abstract 1. Introduction 2. The Proprietary vs. Open Source Software Requirements Engineering Process 2.1 Requirements Elicitation 2.2 Requirements Modeling and Specification 2.3 Requirement Analysis 2.4 Requirements Validation 2.5 Communicating Requirements 3. Creation of OSS Requirements 4. Understanding Requirements 5. Some Open Source Software Engineering Tools 6. Conclusions References

3 Abstract This research is done by familiarizing to scientific articles that have studied Open Source Software communities and their processes in requirement management. The goal of this study was to find out how Open Source Software communities are forming, handling and managing requirements of the their software because their way of working is quite much different than in proprietary software development. OSS communities are very rarely using the same processes as is used in proprietary software development and also different OSS communities may not be using the same manners in defining their software. OSS requirement are composed informally from many different sources and usually those are emails and other discussion forums. OSS developers are in many communities also the users of the Open Source Software product so they are often the biggest group where requirements are coming from. Keywords: Requirements processes, Open Source Software (OSS), requirement, feature

4 1. Introduction Most well-known OSS projects are the Linux operating system and the Apache Web Server because of their size, success and influence. Overall there are nowadays thousands of active OSS projects working with different kind of applications. Because Open Source Software programs have spreaded so much it is very important to also study about their way of working and developing their code. Open Source Software teams are almost purely virtual which means that developers are contributing from all over the world, meet very rarely or never face-to-face and activities they are doing are coordinated primarily by computer mediated methods. (Crowston et al. 2012; Potdar & Chang, 2004.) Organizations that are used to work with proprietary software have also gradually started to use and develop Open Source Software. Open Source Software has certain requirements as all software does. Open Source Software is however very strongly related also to licenses that needs to be considered very well when working with Open Source Software. Open Source Software communities are usually formed from developers who personally like to use that certain product that is under development or who just want to make that product work better. Developers are in most cases doing development work voluntarily so they usually have own thoughts about the product how it should look like, how it should work, is some certain feature possible to be included in that system, etc. This research is very interesting to do because it differs from researching proprietary software requirements. Research is done by familiarizing to relevant scientific articles and other written materials. Research has revealed that Open Source Software projects does not have same kind of requirements engineering processes as proprietary software projects usually does and requirements are also managed in different ways. It is assumed that there is no general model or globally accepted framework that defines how OSS is or should be developed (Scacchi, 2009). Requirements of Open Source can be thought in two different ways. When you are choosing software to use you have probably certain requirements that you want software to fulfill. Also when you are going to develop a software you have to think about its requirements. This research focuses on requirements that have to be taken care of during the development work. Chapter 2 presents requirements and differences between proprietary and Open Source Software engineering process, chapter 3 describes how OSS requirements may be created, chapter 4 describes how OSS requirements should be understood and chapter 5 describes some of the tools used is OSS development. This paper concludes with summary of the key findings. Studying about Open Source Software Requirements management is extremely fascinating because OSS project teams does not follow certain routes or do all the requirement specification by following certain rules but they still are able to produce software that is very reliable, has good quality and is in use also when some people are still developing it to become even better. Scacchi (2004) has also mentioned that software that these communities have developed is extremely valuable, generally reliable, globally distributed, is available for anyone to be found at little or no cost, and readily used in its associated community.

5 A better understanding of the Open Source Software requirements management is needed. This article reveals as a result of familiarizing to scientific articles how Open Source Software communities are managing OSS requirements. 2. The Proprietary vs. Open Source Software Requirements Engineering Process Proprietary software requirements have been initially defined to ensure that everything that customer wants and has expressed to be needed to include and develop in software system will be there and defined requirements can be used as software development contracts, delivery, and payment schedules. (Scacchi, 2009.) Proprietary software projects in most cases use certain methods, models, tools and processes in their software development. Requirements in proprietary software development are usually found out by using five requirements engineering processes. Those are used to ensure that system to be developed will be reliable, have high quality and all in all is trustworthy. (Scacchi, 2002.) Open Source Software communities seem not to follow the same requirements engineering processes as proprietary software projects usually does (Scacchi, 2002). There have been some requirements but people have been guessing where those requirements have come from. Massey (2001) has defined some of those requirements sources as following: Open source software requirements may come directly from the developers. Developers are usually the end users so they are very good persons to tell what system needs and how it should be done so that it would serve their own needs. (Massey, 2001; Potdar & Chang, 2004.) Open source software requirements may come from users of open source software. Open Source Software is usually used by multitude of users especially when the developed system has good reputation because of its quality and reliability. Open Source Software communities also aim to have lot of users because eventually some of them becomes a new developers for the project. (Massey, 2001; Potdar & Chang, 2004.) Open source software requirements may come from the implementation of explicit standards. Much of open source software available today consists solely or largely of programs implementing pre-existing standards. (Massey, 2001.) Open source software requirements may come from the emulation of implicit standards. Open Source Software communities may want to provide also Open Source version from some popular proprietary software so that users are able to use same kind of software as Open Source as some proprietary software is. (Massey, 2001.) Open source software requirements may come from the need to build learning prototypes. Open source requirements are frequently the result of the desire to learn. It is often in the nature of open source development environments and execution platforms to support this kind of rapid development of learning prototypes. (Massey, 2001.)

6 As can be seen from this list defining where OSS requirements may come, developers are in many cases those who are saying what is required and how should that requirement to be fulfilled. Requirements are very often formed from messages and discussions that have happened in Web sites or forums and which also are available for open review, elaboration, refutation or refinement. (Scacchi, 2004.) Open Source Software communities just don t try to follow certain instructions and processes in their software development. (Massey, 2001.) Partly it is also their own culture which kind of insists that because the software is done often by everyone s free will and free time it can t be destroyed by forcing everyone to use certain manners in software development. 2.1 Requirements Elicitation Requirements Elicitation is used to define objectives that system should include, how it should work and what really is needed in final system. Those items may be investigated with users, customers and stakeholders. Elicitation can be done by different approaches e.g. with questionnaire surveys, interviews, documentation reviews, having group meetings, or by any suitable way to communicate between development team and the end user/customers. (Scacchi, 2002.) OSSD does not have elicitation phase because requirements are clear to developer, either requested by a user or by themselves and after that requirements just need to be analyzed and implemented. (Potdar & Chang, 2004.) Anyway in OSSD this activity may be called as Informal Post-Hoc Assertion of OSS Requirements (Scacchi, 2009). In OSSD requirements may become visible by many different ways in Web environment where developers are communicating with other developers and system users. Source of the requirement may be in the email conversation or some other discussion channel e.g. chat which are visible for all participants. After requirement has become visible it is then added on a Web site where it is available for all to be used as they need it. Instead of using OSS requirements they may be defined as asserted system capabilities because of their differences compared to proprietary software requirements and because they may be already implemented before they are defined as requirements in that certain system or in some other related system that already exists. Sometimes OSS requirements appear from somewhere and the source may not be visible or it is not marked anywhere so that anyone does not know what the origin of that certain requirement is. (Scacchi, 2009.) 2.2 Requirements Modeling and Specification

7 This phase includes actions that are done to find out functional and non-functional requirements. It is important to clarify all necessary requirements and model those in very detailed level. Functional requirements include system processing states, events and system data. Nonfunctional requirements include goals, capabilities and constraints. (Scacchi, 2002.) In OSSD this activity may be called as Continually Emerging Webs of Software Discourse (Scacchi, 2009). OSS communities don t usually have any contractual obligations or requirements to be followed in their development work and every requirement does not need detailed design before they can be implemented (Scacchi, 2009; Potdar & Chang, 2004). Noll (2008) has presented different categories that are defined by how requirement is proposed for the development: developer may have proposed new requirement by his/her own personal experience, developer has done propose by his/her personal knowledge of what users need, user has posted a bug or request for enhancement, requirement is derived from the success of an extension or someone has noticed that certain feature in competitive product and proposed that. OSS capabilities may be created by the experience of the OSS community members who are themselves using the system or either through the iterative discussions in emails and forums between different people. These communications makes it possible to people to discuss about functional and non-functional requirements even more closely and by that the requirements become more detailed and condensed and those will enable the development of narrative descriptions. (Scacchi, 2009.) This discourse is rendered in multiple, dispersed descriptions that can be found in email and discussion forum archives, on Web pages that populate community Web sites, and in other informal software descriptions that are posted, hyperlinked, or passively referenced through the assumed common knowledge that community participants expect their cohorts to possess. (Scacchi, 2009.) By this way developers and other system users create together more deep understanding about the capabilities they have found to be implemented and what they have found to be still unclear, how to plan and define those so that they will be found, investigated and developed by developers who usually are working with same kind of issues. (Scacchi, 2009.) 2.3 Requirement Analysis This phase is done to clarify that all specified requirements are thought thoroughly so that they are added in the specification correctly and as they are thought to be. More complex analysis may include more detailed analysis about e.g. more complex tasks in modeled system. (Scacchi, 2002.) In OSSD this activity may be called as Requirements Reading, Sense-Making, and Accountability (Scacchi, 2009). OSS requirements are analyzed by using just a little or not

8 at all automated analysis, formal reasoning or illustration about the software requirements specifications opposite to proprietary requirements analyzing. Instead of focusing too much on formal analysis focus has been set more to understanding what functionality has already been implemented and to what others have discussed about it. This procedure makes it possible to new participants evolve themselves to the project at the same time when other tasks are ongoing. Community members usually notice and understand the functional and non-functional requirements after implementation has been done and think and decide what requirements are needed to make OSS system development proceed. (Scacchi, 2009.) 2.4 Requirements Validation Domain experts are doing this phase by evaluating how well the system solution has been designed to be useful and validate also system requirements that are making system more comprehensible and what is possible and what is not possible. It is possible to use also techniques that are used to inspect requirements related to usability and feasibility. After validation has been done the requirements engineer is better able to say that are customer s expectations that kind of that those are eventually possible to carry out. (Scacchi, 2002.) In OSSD this activity may be called as Condensing Discourse That Hardens and Concentrates System Functionality and Community Development (Scacchi, 2009). OSS requirements are the result of design, implementation, testing descriptions, software artifacts, user manuals and usage artifacts such as input data and program invocation scripts mixed together. These requirements are shared through different kind of internet media (Web pages, sites, hypertext links, source code directories, emails, etc.) that are available for anyone interested persons. OSS communities are doing all requirements descriptions informally without certain steps to be followed and that leads to that requirements validation is not done so that all work related to validation tasks are defined beforehand instead it is more happening beside all other tasks that just give the same kind of result than original validation methods. (Scacchi, 2009.) For example in Firefox project requirements are validated by consensus of the core developers (Noll, 2009). 2.5 Communicating Requirements This is very important phase because it is essential to document requirements so that people are able to read, analyze, re-write and validate those (Nuseibeh et al. 2000). Also in proprietary software projects has been noticed that it is important to make documentation in that way that it is readable and traceable so that many or even all people working with that project are able to use and if needed even modify that documentation. (Scacchi, 2002; Nuseibeh et al. 2000.)

9 In OSSD this activity may be called as Global Access to OSS Webs (Scacchi, 2009). Despite of OSS requirements informality communities tend to organize and store them in a persistent form which is freely and globally accessible by anyone. This distribution is done by the same routes as how the requirements are originally gathered by using community Web sites, other related sites and hyperlinkage, source code directories, threaded email and other discussion forums, descriptions of known bugs and desired system enhancements, records of multiple system versions, etc. Persistence, hypertext-style organization and linkage, and global access to OSS descriptions appear as conditions that do not receive much attention within the proprietary requirements engineering approaches, with few exceptions (Scacchi, 2009). All of these conditions help community members and also other people to follow how the system is developed and how it is progressing. (Scacchi, 2009.) 3. Creation of OSS Requirements Open Source requirements are mostly created from informal sources opposite to proprietary software engineering where requirements are defined through many formal phases. OSS communities elicit, analyze, specify, validate and manage the functional and non-functional requirements through different Web-based artifacts, informalisms (Scacchi, 2009). Scacchi (2009) has presented two dozen different informalisms that are being used by different OSSD projects. Every one of those also includes subtypes that can be identified. Because OSSD projects don t follow same kind of procedure in requirement management as proprietary software projects does, these software informalisms are used for describing or presenting OSS requirements. Even these informalisms exists it is not meant that those should be changed to formal requirements. (Scacchi, 2009.) Informalisms that communities use are: Communication methods such as email, discussion forums, bulletin boards or group blogs, news postings, instant messaging or internet relay chat. These communication methods can be defined as project digests that helps to provide an overview of major development activities, problems, goals or debates. Scenarios of usage includes Web pages or screenshots, how-to guides, to-do lists, Frequently Asked Questions and other itemized lists, project wikis, traditional system documentation and external publications. OSS project property licenses define what developers and other people are able to do with the code to follow the rules setted in license. Architecture diagrams, intra-application functionality realized via scripting languages, incorporate externally developed software modules or plug-ins, integrate software modules from other OSSD efforts are informally used resources. All of the software informalisms are found or accessed from project related Web sites or portals. OSSD multi-project Web sites, community software Web sites, project specific Web sites,

10 embedded project source code Webs (directories), project repositories (CVS), software bug reports, issue tracking database like Bugzilla and Social media Web sites. (Scacchi, 2009.) Nowadays OSS communities have even easier way to communicate with each other via social media. Most probably if not all, most of the team members are using some social media system beside their work so time used in sharing all information to others may have decreased and it is easier to share pictures and other related materials to all interested people. All these 24 types of software informalisms establish a very wide web of informal, semistructured, or processable information resource. That web is progressing all the time and it is used to capture, organize, and distribute knowledge that embodies the requirements for an OSSD project. Contrary to OSS projects that have informal requirements, higher education and military communities are usually developing and using formal requirement specification documents. Reason to that is that their software must be surely done by using certain guides in their software development projects. (Scacchi, 2009.) 4. Understanding Requirements Open Source software requirements are usually collected from different communication media such as emails, forums, from discussions between members and other social actions that negotiate interest, commitment, and accountability. (Scacchi, 2002.) Users of those communication ways can be either the developers, users of that system or some other persons who just want to propose new feature, report a bug or just are interested in that system. Open Source Software development does not include one correct solution how development should be done. Requirements in OSS versus proprietary software are different. OSS development is continuous, so also the requirements are developing continuously. Requirements are thought as capabilities that are composed as a result of socio-technical interaction that people have during the development process and when the system is already in use. (Scacchi, 2009.) OSSD projects don t value so much the traditionally respected software system requirements like consistency, completeness, traceability and internal correctness. Instead of traditionally respected requirements OSS communities value more the preferences which help to enhance community development, participation and other socio-technical problems. Because of the different type of requirements in OSSD it is possible to give alternative to develop open system for developers and users and which also is in very stable ground. (Scacchi, 2009.) In OSSD developers and the users are very often the same persons so in OSS communities (Scacchi, 2009; Potdar & Chang, 2004) they don t have to worry about the end-users and their wishes because they already know who is using that certain system. This gives a very good advantage to OSSD versus proprietary software development because they don t have to use so much effort and time to find out what the end-users may think about the system and is everything

11 developed as is thought to be. Much less misunderstandings certainly exist inside the OSSD communities than in others where most of the end-users may not be evolved to the system development at any level. OSS requirements tend to be distributed across space, time, people, and the artifacts that interlink them (Scacchi, 2009). That defines requirements as decentralized which means that they co-exist and co-evolve within different artifacts, online conversations, and repositories, as well as within the continually emerging interactions and collective actions of OSSD project participants and surrounding project social world (Scacchi, 2009). Traditional software engineering defines that requirements are managed and handled within a centralized administrative authority so again OSSD serves an alternative for requirements elicitation and analyzing. (Scacchi, 2009.) Developers in OSS communities are in most cases the source for the requirements. Usually requirement is noticed after something has been implemented and has realized that what was the requirement opposite to that requirement is defined before it is implemented. Requirement is build up according to what developer has done and it usually happens before any note about that feature has been discussed anywhere at any level. It does not involve many different phases to inform other community members what was done and how it was done and usually it is not even required that developers should report or document what tasks they have done. This also is good advantage so that members will not be frustrated to think about all the documentation they need to do but instead just to focus on the coding and implementation. (Scacchi, 2009.) 5. Some Open Source Software Engineering Tools Open Source Software communities seem not to use many visible tools in their requirements management. Anyway they use mailing lists as a tool to proceed with the new requirements. When someone announces about the issue that should be considered to be done in Open Source Software project, other members in that community are able to agree or disagree with that issue by giving answer in this mailing list conversation. To get decisions done in consensus with everyone, communities may use some kind of voting process, where defined members are able to vote about the issue. Voting is often done using the convention that a message starting with the text +1 is a vote in favor of a proposal, a message with +0 or -0 is an abstention with a comment, and a message with -1 is a veto, which must include a thoughtful justification. (Robbins, 2002.) Some projects want to keep these processes informal and are making decisions by discussing about the issue with the designated module or version owner. (Scacchi, 2004.) OSS communities are using software version control tools widely. Software version control is part of a configuration management activity and it is happening all the time over and over again. The use of these tools requires coordination but it enables to stabilize and synchronize kind of invisible development that is happening dispersed. Anyway this coordination is essential so

12 that development won t start to suffer from many people doing contribution to system software simultaneously, mixing it totally and maybe generating unwanted side effects what would happen without any coordination. Version controlling may be done by each project team or by administrator who is deciding what can be checked in and who are able to check in new or modified software source code content. (Scacchi, 2004.) Software maintenance-adding and subtracting system functionality, debugging, restructuring, tuning, conversion (for example, internationalization), and migration across platforms-is a widespread, recurring process in OSS development communities. (Scacchi, 2004.) Issue Tracking (Bugzilla, Scarab) tool is also used e.g. in situation when developers want to evaluate that is some certain component reusable. Mailing lists provide good way of saving messages as archives that are very usable when some information about certain issue is needed. Project Web-sites includes usually description of the project, a user guide, documentation that developers have done, names for important persons of that project, license that is used and guideline that tells how the participation is possible. Sites may include also other relevant materials. HOWTO, FAQs are also widely used but FAQ-O-Matics are not so widely used in projects. These help users in different tasks and provide good information for possible new volunteers. Wiki, TWiki and SubWiki are used to easily share information about the project without risks that someone would do something dangerous for the information. They are accessible anywhere and very easy way of share documentation. Other tools used are build systems (Make, Automake, Autoconf...), design and code generation (ArgoUML, Dia...), quality assurance tools (JUnit, PHPUnit, NUnit...) and collaborative development environments (SourceCast, SourceForge). (Robbins, 2002.) Evolutionary redevelopment, reinvention and revitalization can be said to be done as reinvention. Development is happening all the time and system software is changing and having new features all the time. Reinvention is happening by sharing, examining, modifying and redistributing concepts and techniques. (Scacchi, 2004.) Some projects don t have and are not able to get enough developers for the software development work. Scacchi (2004) has mentioned project to need at least five to fifteen core developers so that project would be able produce a viable system. OSS development teams may use different division between team members which means that members are having certain title that has been given according to person ability and skills and this is called as layered meritocracies. This kind of teams are organized dynamically but loosely connected virtual enterprise. Virtual enterprise means that project team relies on a virtual project management that is directing mobilization, coordination, controlling, building and assuring the quality of development activities. This gives possibility for anyone interested to take more responsibility of some issue which would benefit the whole development team and single developers in their common work. (Scacchi, 2004.)

13 All technology transfer such as publication and sharing is done mostly by using OSS project Web sites or other easily accessible system and that practice is in use by the all community members. OSS projects might use very many development tools as stand-alone systems, integrated development environments or their own application s subsystem components. OSS projects are also using asynchronous communication systems which are permanent, can be found by anyone, can be traced, are publicly available and globally accessible anywhere from the world. (Scacchi, 2004.) OSS technology transfer is a socio-technical process which means that development of constructive social relationship, informally negotiated social agreements and a routine willingness to search, view, download and try OSS assets are required. Software team members also have to engage to participate in public discussion about OSS system. It is essential for OSSD to build community and get permanent members and those should be continually happening activities that enable OSS remain without using any centrally planned and managed software development centers but instead doing all the work as opposite ways, more freely. (Scacchi, 2004.) Potdar & Chang (2004) have proposed a model called Requirement Oriented Pendulum model (Figure 1.) that provides a mechanism to track which requirements have been submitted and which of those have been implemented and tested. This model has four different stages: Requirement Analysis and Specification, Implementation and Testing, Validation and Component Submission. Figure 1: The Pendulum model for Open Source (Potdar & Chang, 2004).

14 6. Conclusions This study familiarized to different written materials about OSS development and processes used in requirement management. I think that this study is useful for future research for finding even more closely what kind of requirement management tools and processes are used in different OSS communities and how they are developing as new OSS communities arise all the time. Gathering information about OSS requirements management is difficult by just familiarizing to written materials because communities don t follow same guidelines in their development processes and they differ from proprietary requirement engineering processes. It is not possible to read documentation about what they have done because communities don t necessarily write any formal documents about their work. Requirements do exist, though finding or recognizing them demands familiarity and immersion within the community and its discussions. (Scacchi, 2002.) For me as a newbie in OSS development processes it is quite demanding to find out how processes and development has been done inside these communities. Open source software projects do not share same kind of documentation as in proprietary software projects. Many of the OSS development communities may use same kind of procedures but in most cases those still are informal and are not going to change as formal processes. This gives OSS communities big freedom to solve their development processes as they want to and use any appropriate tools if they want to but no-one can t force to use them. As a conclusion can be said that more research should be done in this area because most of the earlier researches have been done quite many years ago and this area has not been studied much during last years. Lot of written materials about OSS can be found but more detailed research is necessary to find out better OSS requirements. This area is also difficult to research because most of the Open Source projects have their own style of going forward and doing things. All projects do not have same procedures so in future studies, some empirical studies should be done to find out these issues better.

15 References Crowston, K., Wei, K., Howison, J., and Wiggins, A. (2012). Free/libre open source software development: What we know and what we do not know. ACM Comput. Surv. Vol. 44, No. 2, Article 7. ACM New York, NY, USA, Feb. 2012. Massey, B. (2001). Where Do Open Source Requirements Come From (And What Should We Do About It)?. In Proc. 2nd Workshop On Open-Source Software Engineering, Orlando, FL, May 2002. Noll, J. (2008). Requirements Acquisition in Open Source Development: Firefox 2.0. Open Source Development Communities and Quality, volume 275/2008, 69-79, Springer Boston. Nuseibeh, R., Easterbrook, S. (2000). Requirements Engineering: A Roadmap. A. Finkelstein (ed.), The Future of Software Engineering, ACM and IEEE Computer Society Press. Potdar, V., Chang, E. (2004). Open source and proprietary source software development methodologies. The 26th International Conference on Software Engineering (ICSE 2004): Proceedings of the 4th Workshop on Open Source Software Engineering, Edinburgh, Ireland. May, 105-109. IEEE. Robbins, J. E. (2002). Adopting OSS methods by adopting OSS tools. In Proceedings of the International Conference on Software Engineering 2nd Workshop on Open Source Software Engineering. Scacchi, W. (2002). Understanding the Requirements for Developing Open Source Software Systems. IEE Proceedings Software, 149(1):24 39, Feb. 2002. Scacchi W. (2004). Free and open source software development practices in the game community. IEEE Software 21(1): 59 67. Scacchi, W. (2009). Understanding Requirements for Open Source Software. K. Lyytinen et al. (Eds.): Design Requirements Workshop, LNBIP 14, pp. 467 494. Springer-Verlag Berlin Heidelberg.