A STUDY ON OPEN SOURCE SOFTWARE RELEASE MANAGEMENT
Dr. Arul Kumar. N
1, Dr. Raghuraman.V
21 Faculty, IT department in IBRA
2 Senior Faculty, Department of business study in IBRA
ABSTRACT
Since 1990s, Open Source Software has made a major impact on the Software industry and has changed the way the software is developed. Normally, Open Source Software is developed in a collaborative manner and most of the contributors are volunteers. Although this collaborative form of development has produced a significant amount of software, the development process is often described as unstructured and unorganized. Some existing research investigates the Open Source Software phenomenon in a quality perception and studies where enhancements are possible to the development process. Release Management in Open Source Software Development plays a significant role in every Software project. Since Release is related with the delivery of a high quality product to OSS user community. This paper explore Release practices employed by Open Source Software and shows problems that occur. A challenge that has been identified is the complexity of coordinating a distributed of volunteers in order to align their work for a Development
.
Keywords: Open Source Software (OSS), Release Management
Contents1. Introduction 2. Exploratory Study 3. Discussion 4. Conclusions
I. INTRODUCTION
Release management is a significant part of quality management in OSS development since it is concerned with the distribution of high quality software to users [2]. Development Process in OSS is considered as a highly iterative development model in which new development process are typically made obtainable very often. In spite of the development process in some projects, there are often problems with design process for developers.
This paper makes an exploratory study in order to get an enhanced picture of actual practices and problems related with Release management in OSS projects. The research area has been studied from a quality perception.
II. EXPLORATORY STUDY
2.1 Methodology
For this study, interviews with thirty skilled developers from different OSS projects were carried out. The interviews were carried out at a conference over the course of two days. Interviewees were either Part time developers or full time developers of OSS projects. The collection of OSS projects in which developers
participated was very varied, ranging from small to large and complex projects, and included projects of all categories, such as desktop application and server application and development tools. This great diversity gives a good coverage of process found in the OSS community.
2.2 Types of Release Management
The study has discovered that the general term ‘Release management’ is used to refer to three different types of Process. These types differ quite significantly regarding the viewers they address and the effort required to define the process. The three types are:
– Design Release intended to developers involved in working on the project or experienced users who need cutting edge technology.
– Development Release based on a significant new features and functionality stabilized development process tree was developed.
– Testing Release these processes uses bug fixing as well as distribute generally well tested software to user community.
Since developers are professionals, development Release does not have to be refined and therefore relatively easy to organize. Minor updates to Testing Release also require little attention since they usually only consist few fixes for critical or security bugs. On the other hand, design Release requires significant effort: the software needs to be systematically tested as per the prototype, documentation needs to be created and the software needs to be defined. Since the main tasks are associated with the preparation of major Release, the focus will therefore be on Release management aimed at user community.
In terms of a project Release strategy, projects are classified according to the following two release process:
– Prototype Development process: the basic principle of this strategy is to perform a new process when a specific set of model has been fulfilled and certain goals attained, normally a number of features which developers perceive as important. This strategy is in line with traditional software development in which water- fall development model is followed.
– Iterative Development Release: in this approach a specific requirement is set for the Release well in advance and a schedule created so people can plan accordingly. Prior to the Release, there is a deadline date on which all features are assessed to resolve whether they can be incorporated in the Release or have to be postponed for further Release.
2.3 Skills of the Developers
The role of the developer is varied and challenging because they have to act together with a large number of community, realize technical issues but also know how to design and coordinate.
The following significant skills have been identified:
– Team building: showing user community that their input is valuable. Developers also need respect in the OSS community in order to execute their work.
– Vision: showing co-developers in which direction the project should be moving.
– Self-control: Developers have to focus on overall goal and cannot make everyone happy.
– Responsiveness: walking through every line of code that has changed.
– Inference: evaluating the risk and possible impact of a particular change.
– Communication: writing Release notes, asking for feedback, interacting with user community.
– Management skills: planning, organizing, talking to people, confirming that different tasks
are performed.
It is interesting to note that developers in small and large projects play an immensely different role even though they basically have the same responsibility, in order to produce a high quality software product. In a small project, the developers usually has an executive role which involves the preparation of the product in different formats that can be distributed, the creation of Release notes and the actual distribution of the product. On the other hand, in large projects, there is a major emphasis on coordination that needs to be executed by the Developer. They have to confirm that different components of the software are ready at the similar time and that co-developers are associated towards the common goal of building a stable product.
2.4 Tools and Practices
Regardless of the important role of Release management acting in the delivery of quality software to user community, there is little knowledge as to how OSS projects perform Releasing. This section covers tools and practices employed during Release management.
The study has exposed that there are few committed tools used in Release management. However, many OSS projects have tightly integrated their development tools in their whole development Release, including quality management. In particular, the practice of version control and bug tracking systems supports significant functions during Release management as they give a upright indication of the performance of the project.
In addition to the use of these tools, there are specific practices which are related to Release management:
– Freezing: development Release is locked down in order to focus on the removal of defects and publication of the product.
– Scheduling: quite few OSS projects make use of a schedule but it is a important component in those projects which employ a release strategy.
– Creating milestones: some OSS projects have loosely defined milestones but it depend the volunteer nature of most OSS projects there is no guarantee that they will actually be achieved.
– Setting limits: many OSS projects set deadlines but they are not always met because the developer community has no control over volunteer participants.
– Developing on different architectures: as part of the OSS project’s development plan, it is beneficial to develop the software on a number of different hardware platforms because each of them may reveal bugs not detectable on another platform.
– User testing: one of the main advantages from preparing a product is based on the feedback possibly attained from a wide range of user community. Even though projects which heavily adopt automatic test Release consider that the most significant visions usually come from user community.
– Following a Release check list: a number of OSS projects use a check list to confirm that all steps that are essential to make a new product are followed.
–Post release review: unpredictably few OSS projects have a formal post release review but these are frequently casual discussions on the mailing list of the OSS project, in particular when there were problems in the product.
1.5 Problems
As discussed earlier, the Release of developing a new stable product for user community is quite complex and elaborate since the software needs to be completely tested, documented and released. The Release management often faces certain difficulties, the most common difficulties of which are as follows:
– Most important features not ready: planning in OSS projects is very difficult and it happens regularly that most important features which are on the critical path are not ready. These blockers need to be determined so the development Release can continue.
– Interdependencies: with the increasing complexity of software, there are growing levels of interdependencies between software. This can lead to problems with a project’s Release when those other components are not ready.
– Supporting Previous software product: there is in general a lack of resources in the OSS community and in many projects previous releases receive little support. Some developers which distribute a given product may involve and offer basic support but it may still be difficult for other users of the software.
– Little interest in doing user development: even though this study has emphasized the importance of Release, many developers show little interest in making product. Since developers by generally use the development version they frequently do not understand the need for a user product or do not see when a product is massively out of date.
– Vendors roll in development: when OSS projects do not publish new products, some vendors start development Release because they want to develop for their customers need. This situation is difficult because it can lead to fragmentation and for the reason that development Releases are generally not as well tested as user community.
– Applying changes without testing: some OSS projects apply many changes with relatively less testing. At the time of the product release, many problems are discovered and this leads to major delays.
–Coordination problem: development in OSS projects is done in a extremely parallel way in which different developers autonomously work on features they are interested in. Towards the testing Release, all of this development needs to be line up and these parallel streams have to become stable at the same time. This can require significant amount of coordination.
II. DISCUSSION
This study has given vision on problems and practices related to Release management in OSS development, an important area which has been relatively so far unexplored. A major observation is that the groundwork of development Release is associated with significant problems, specifically in major projects. Minor projects are often face human resource problems but major projects deal with a most important issue, namely that of coordination in a loosely defined team of OSS community towards the common goal of making a product. These developers typically work independently in similar development streams which require little coordination with other developers of the project. However, during the development for the next product, these similar development streams need to be integrated and that requires coordination. Even more difficult is that each independent development stream has to be accomplished at the same time even though there is usually no deadline which provides guidance. When freezes are announced, developer’s wants to get their features and fixes in and the in height number of changes drives back the release date. Each postponement is seen as a further occasion to make more changes, in that way triggering even more delays. The current study has identified such problems in a number of OSS projects but there is also indication that some OSS projects have established ways to deal with these problems. There is significant interest among projects in the Release management, in which quality management is used as direction for the release and a schedule is followed. This Release strategy is used in a number of growing projects, such as OpenOffice.org, GNOME and X.org. Release management promise
solutions to deal with the complexity of large developer projects towards a common goal. However, further work is needed to study this Release strategy in detail for quality improvement.
III. CONCLUSIONS
This paper has given vision on an important and as yet fairly unexplored area of OSS development. The main finding of this study is that OSS projects, in specific those with a lot of developers, face severe encounters during the preparations for a product. These challenges are related to the coordination of a developer team which is not only major but also geographically isolated and mainly are volunteer participants. While OSS projects often rely on self-assignment of responsibilities with little coordination, all developers need to line up their activities towards a common goal during development. The Release management has been suggested as an instrument to coordinate large volunteer projects but further work is needed to explore this Release management towards quality improvement.
REFERENCES
[1] Alexis Leon: A Guide to Software Configuration Management, Artech House Computer Library, 2000.
[2] Arul Kumar, N; Mangalam, C.K. (2012). Release process on quality improvement in open source [3] software project management. Journal of Computer Science, August 2012, Vol.8(6), pp.1008-1011.
[4] Audris Mockus, Roy T. Fielding, James Herbsleb: A Case Study of Open Source Software Development:
[5] The Apache Server, in Proceedings of the International Conference on Software Engineering, Limerick, [6] Ireland, June 4-11, 2000.
[7] H. Ronald Berlack: Software Configuration Management, John Wiley & Sons, 1992.
[8] Ian Sommerville: Software Engineering, Fifth Edition, Addison-Wesley, 1996.
[9] Joseph Feller and Brian Fitzgerald: A Framework Analysis of the Open Source Development Paradigm, in [10] Proceedings of the 21st Annual International Conference on Information Systems, Brisbane, Australia, [11] 2000.
[12] Kent Beck: Extreme Programming explained: embrace change, Addison-Wesley, 1999.
[13] Laura Wingerd, Christopher Seiwald: High-Level Best Practices in Software Configuration Management, [14] in Proceedings of the Eight Symposium on System Configuration Management, Brussels, Belgium, [15] July 20-21, 1998.
[16] Marion Kelly: Configuration Management – The Changing Image, McGraw-Hill Book Company, 1996.
[17] Peter H. Feiler: Configuration Management Models in Commercial Environments, CMU/SEI-91-TR-7, [18] Carnegie-Mellon University/Software Engineering Institute, March 1991.
[19] Steve McConnell: Open Source Methodology - Ready for Prime Time?, IEEE Software, July/August 1999.
[20] Ulf Asklund: Configuration Management for Distributed Development – Practice and Needs, Dissertation [21] 10, Lund Institute of Technology, 1999.
[22] Ulf Asklund, Lars Bendix: Configuration Management for Open Source Software, Technical Report R-01- [23] 5005, Aalborg University, January 2001.
[24] Wayne A. Babich: Software Configuration Management - Coordination for Team Productivity, Addison- [25] Wesley Publishing Company, 1986.
