Content uploaded by Klaas-Jan Stol
Author content
All content in this area was uploaded by Klaas-Jan Stol on Mar 11, 2015
Content may be subject to copyright.
A preview of the PDF is not available
Why and How Should Open Source Projects Adopt Time-Based Releases?
Abstract
Traditional release strategies have a number of associated problems, which can be overcome by time-based release management. We present findings from interviews with key members of seven prominent volunteer-based open source projects, all of which have adopted a time-based release strategy. We discuss the importance of release planning, the numerous challenges that can result from a lack of such planning, and the benefits of time-based releases. Finally, we discuss how an open source project can adopt a time-based release strategy.
... Hybrid versions has also used [29]. Earlier work has reported a favor towards the time-based strategy [20], [29]. With fixed release dates and intervals, firms can better adapt their internal plans so that additional patchwork and differentiating features may be added in time for product shipment to market [20], [21]. ...
... Earlier work has reported a favor towards the time-based strategy [20], [29]. With fixed release dates and intervals, firms can better adapt their internal plans so that additional patchwork and differentiating features may be added in time for product shipment to market [20], [21]. Other issues associated with time-based release strategy include: rushed implementations, workload accumulation, outdated software and delayed releases [20]. ...
... With fixed release dates and intervals, firms can better adapt their internal plans so that additional patchwork and differentiating features may be added in time for product shipment to market [20], [21]. Other issues associated with time-based release strategy include: rushed implementations, workload accumulation, outdated software and delayed releases [20]. ...
Requirements Engineering has recently been greatly influenced by the way how firms use Open Source Software (OSS) and Software Ecosystems (SECOs) as a part of their product development and business models. This is further emphasized by the paradigm of Open Innovation, which highlights how firms should strive to use both internal and external resources to advance their internal innovation and technology capabilities. The evolution from market-driven requirements engineering and management processes, has reshaped the understanding of what a requirement is, and how it is documented and used. In this work, we suggest a model for analyzing and managing requirements that is designed in the context of OSS and SECOs, including the advances and challenges that it brings. The model clarifies how the main stages of requirements engineering and management processes can be adjusted to benefit from the openness that the new context offers. We believe that the model is a first step towards the inevitable adaptation of requirements engineering to an open and informal arena, where processes and collaboration are decentralized, transparency and governance are the key success factors.
... In OI this area has had limited coverage with some exceptions [25,17] compared to the field of OSS (e.g. [14,27,15,5]). Michlmayr et al. [15] describes how release strategies used by OSS communities can be classified into feature-based and time-based. ...
... Hybrid versions has also been reported [27]. Literature has however favored the time-based strategy [14,27]. With fixed release dates and intervals, firms can better adapt their internal plans so that additional patchwork and differentiating features may be added in time for product shipment to market [14]. ...
... Literature has however favored the time-based strategy [14,27]. With fixed release dates and intervals, firms can better adapt their internal plans so that additional patchwork and differentiating features may be added in time for product shipment to market [14]. Other issues reported by Michlmayr et al. [14], which could be refrained with a time-based release strategy, are rushed implementations, workload accumulation, outdated software and delayed releases. ...
In recent years Open Innovation (OI) has gained much attention and made firms aware that they need to consider the open environment surrounding them. To facilitate this shift Requirements Engineering (RE) needs to be adapted in order to manage the increase and complexity of new requirements sources as well as networks of stakeholders. In response we build on and advance an earlier proposed software engineering framework for fostering OI, focusing on stakeholder management, when to open up, and prioritization and release planning. Literature in open source RE is contrasted against recent findings of OI in software engineering to establish a current view of the area. Based on the synthesized findings we propose a research agenda within the areas under focus, along with a framing-model to help researchers frame and break down their research questions to consider the different angles implied by the OI model.
... When the release strategy is selected, the release cycle time is to be chosen. The release cycle time is defined as the time between the start of the development of a software product and its actual release [90]. ...
... Michlmayr et al. [90] identified five factors that affect the choice of release interval: regularity and predictability; nature of the project and its users; commercial factors; cost and effort; and network effects. ...
The advent of delivering new features faster has led many software projects to change their development processes towards more rapid release models where releases are shipped using release cycles of weeks or days. The adoption of rapid release practices has significantly reduced the amount of stabilization time, the time it takes for a software product’s failure rate to reach close to the steady-state, available for new features. This forces organizations to change their development process and tools to release to the public, in a timely manner and with good quality. Rapid releases are claimed to offer a reduced time-to-market and faster user feedback; end-users bene- fit of faster access to functionality improvements and security updates and improve turnaround time for fixing bad bugs. Despite these benefits, previous research has shown that rapid releases often come at the expense of reduced software reliability. Despite the increasing adoption of rapid releases in open-source and commercial soft- ware, the effects of this practice on the software development process are not well understood.
The goal of this thesis is to provide a deeper understanding of how rapid releases impact different parts of the open-source software development process. We present empirical evidence about the short and long-term impact of rapid releases on the bug handling and testing process in open source organizations; and the plan and tools needed for successful adoption of rapid releases. This thesis presents an empirical case study of rapid releases in Eclipse and Mozilla Firefox projects. We follow a mixed-methods approach where we analyze software repositories, containing different types of data such as source code, testing data and software issues; and we conduct a survey with Eclipse developers. This helps understand the evolution and changes of the software development process, the plans and practices needed for successful adoption of rapid releases, and identifying several future research directions calling for further investigation.
... Coordination through open superposition (the process of incrementally developing open source software components by layering development tasks independently) can improve the quality and the popularity of a project (Howison & Crowston, 2014;Medappa & Srivastavaa, 2019). Code quality can be improved by time-based releases, testing, peer review, version control, reducing complexity and public discussion of issues (Rigby et al., 2008;Conley & Sproull, 2009;Mauerer & Jaeger, 2013;Michlmayr et al., 2015;Geiger et al., 2021). Effective bug fixing activities have a positive influence on project success (Singh, 2010). ...
... 4 However, the feedback received clearly indicated that using a period of study of 1 month was not a good choice. For the analysis presented here, we have set 6 months as the most convenient "Period of study n" , as this is the usual time between releases for many projects (Michlmayr et al. 2015). By doing this, all cycles of six months will be affected by the same process (development, feature freeze, release, etc.). ...
Effort estimation models are a fundamental tool in software management, and used as a forecast for resources, constraints and costs associated to software development. For Free/Open Source Software (FOSS) projects, effort estimation is especially complex: professional developers work alongside occasional, volunteer developers, so the overall effort (in person-months) becomes non-trivial to determine. The objective of this work it to develop a simple effort estimation model for FOSS projects, based on the historic data of developers’ effort. The model is fed with direct developer feedback to ensure its accuracy. After extracting the personal development profiles of several thousands of developers from 6 large FOSS projects, we asked them to fill in a questionnaire to determine if they should be considered as full-time developers in the project that they work in. Their feedback was used to fine-tune the value of an effort threshold, above which developers can be considered as full-time. With the help of the over 1,000 questionnaires received, we were able to determine, for every project in our sample, the threshold of commits that separates full-time from non-full-time developers. We finally offer guidelines and a tool to apply our model to FOSS projects that use a version control system.
... However, the feedback received clearly indicated that using a period of study of 1 month was not a good choice. For the analysis presented here, we have set 6 months as the most convenient "Period of study n" , as this is the usual time between releases for many projects [38]. By doing this, all cycles of six months will be affected by the same process (development, feature freeze, release, etc.). ...
Effort estimation models are a fundamental tool in software management, and used as a forecast for resources, constraints and costs associated to software development. For Free/Open Source Software (FOSS) projects, effort estimation is especially complex: professional developers work alongside occasional, volunteer developers, so the overall effort (in person-months) becomes non-trivial to determine. The objective of this work it to develop a simple effort estimation model for FOSS projects, based on the historic data of developers' effort. The model is fed with direct developer feedback to ensure its accuracy. After extracting the personal development profiles of several thousands of developers from 6 large FOSS projects, we asked them to fill in a questionnaire to determine if they should be considered as full-time developers in the project that they work in. Their feedback was used to fine-tune the value of an effort threshold, above which developers can be considered as full-time. With the help of the over 1,000 questionnaires received, we were able to determine, for every project in our sample, the threshold of commits that separates full-time from non-full-time developers.%, and that minimizes the type I and type II errors. We finally offer guidelines and a tool to apply our model to FOSS projects that use a version control system.
One opportunity for organizations to participate in open source software (OSS) development is through
organizations OSS
(orgsOSS), a term we use to describe a group of organizations that commit resources to collectively develop OSS. This archetype of OSS development is distinct from other types that include organizations, yet is understudied. As organizations increasingly contribute to and rely on OSS as part of their strategy, understanding how they can collaborate to build software holds importance for the future of software development. This study collects a unique dataset of development tasks from a large orgsOSS project spanning over two years and seven releases. Building on existing OSS research, we explore norms with respect to collaboration, i.e., how developers assign, discuss, and complete tasks, in an orgsOSS project. Interestingly, our analysis reveals that developers in orgsOSS do not always adhere to ideals of widespread sharing and participation espoused by traditional OSS, however some developer and task characteristics helped foster these ideals. Based on these and other findings, we develop a set of propositions and associated collaboration mechanisms that are important to future orgsOSS and other similarly structured software development projects.
Context
Several large-scale companies such as Google and Netflix chose to adopt short release cycles (e.g., rapid releases) in recent years. Although this allows these companies to provide updates and features faster for their users, it also causes developers to have less time to dedicate to development activities other than feature development.
Objective
In this paper, we investigate how refactoring activities were impacted by the adoption of shorter releases.
Method
We extract all refactorings applied over a period of two years during traditional yearly releases and almost two years during shorter quarterly releases in three Eclipse projects. We then analyze both time periods’ refactoring activities to understand how refactoring activities can be impacted by shortening the release cycles.
Results
We observe reduced refactoring activities in one project and a decrease in more complex refactoring operations after shortening the release cycles. We also find that weekly efforts dedicated to refactoring activities was lower across all projects after shortening the release cycles.
Conclusion
Shorter releases may impact software development tasks such as refactoring in unintended ways. Not applying specific types of refactoring may also affect the software’s quality in the long term. Using this case study and past work on shorter releases, potential short release adopters can now better plan their transition to shorter releases knowing which areas of development may be affected.
Context: Sentiment Analysis applies computational techniques for both automated and semi-automated identification of human behavior. There is a trend to use such techniques in Sentiment Analysis tasks in the Software Engineering context. Objective: Characterize the influence of developers sentiments on software practices and artifacts in open source software projects. Methods: We conducted a Systematic Literature Review (SLR) to identify references in the literature related to the influence of developers sentiments on software practices and artifacts. Results: Evidence showed an increasing number of studies in this theme shedding light on issues related to the influence of developers sentiments on software practices. Practices focusing on developers productivity and collaboration, as well as source code, are the most vulnerable to sentiments variation. Conclusions: Based on the results provided in this SLR, we intend to present an updated and comprehensive overview regarding how the sentiments of developers can positively or negatively impact software practices and artifacts.
Zusammenfassung
Die ersten „Free-, Libre-, und Open-Source- Software“-Gemeinschaften (FLOSS) bestanden fast durchgängig aus Freiwilligen. Diese Personen trugen zu den Projekten unabhängig von ihrem Arbeitgeber bei. Auch wenn gelegentlich Unternehmen Interesse an den Open- Source-Aktivitäten ihrer Mitarbeiter hatten, war doch deren aktive Beteiligung persönlich motiviert. Das GNU-Projekt, die erste solche Open-Source-Gemeinschaft, wie auch die nächste Generation an Open-Source-Projekten der 1980er und 1990er Jahre, folgte diesem Muster. Während der folgenden 1990er Jahre entwickelten Unternehmen ein Interesse an Open- Source-Gemeinschaften. Unternehmen stellten Entwickler aus den Projekten ein, um Einfluss zu gewinnen, oder sie beauftragten ihre Angestellten aktiv mitzuarbeiten, ebenfalls mit dem Ziel, Einfluss zu gewinnen. In den 2000er Jahren dann entstanden Open-Source-Gemeinschaften, in denen die Unternehmen selbst als aktive Mitspieler agierten. Diese Entwicklung definierte die Projektregeln und die Rollen von Frewilligen neu. Trotz dieser Entwicklung spielen unabhängige Entwickler weiterhin eine wichtige Rolle. Dieser Artikel untersucht den Übergang von der freiwilligen-getriebenen Gemeinschaft hin zur unternehmens-getriebenen Gemeinschaft und exploriert Struktur und Verhalten dieser neuen Form von Open-Source-Gemeinschaft.
Inner source, the adoption and tailoring of Open Source development practices inside organizations, is a topic of increasing interest. While Inner Source offers a number of benefits, in our experience many practitioners are unclear as to what Inner Source is, and what steps to take towards adoption. In this article we present a tutorial in which we outline nine key factors, pertaining to product, process and organization, which we have found to be important in working with organizations who are interested in Inner Source. This paper illustrates these nine factors with three inner source initiatives that we have studied.
Free, open source software development communities can become large and complex. They can also be a focus of interest for competing companies relying on their outcomes, with employees joining the development and maintenance effort. In those cases, it's especially important for both companies and communities to understand how this collaboration is working and how it matches their policies and expectations. This articles looks at two cases (OpenStack and WebKit) that the authors studied using analytics techniques. They conclude that such analytics can improve factual knowledge about how development communities are performing in aspects that are of interest to companies.
I anatomize a successful open-source project, fetchmail, that was run as a deliberate test of some surprising theories about software engineering suggested by the history of Linux. I discuss these theories in terms of two fundamentally different development styles, the "cathedral" model of most of the commercial world versus the "bazaar" model of the Linux world. I show that these models derive from opposing assumptions about the nature of the software-debugging task. I then make a sustained argument from the Linux experience for the proposition that "Given enough eyeballs, all bugs are shallow", suggest productive analogies with other self-correcting systems of selfish agents, and conclude with some exploration of the implications of this insight for the future of software.
Many software companies are shifting from the traditional multi-month release cycle to shorter release cycles. For example, Google Chrome and Mozilla Firefox release new versions every 6 weeks. These shorter release cycles reduce the users’ waiting time for a new release and offer better feedback and marketing opportunities to companies, but it is unclear if the quality of the software product improves as well, since developers and testers are under more pressure. In this paper, we extend our previous empirical study of Mozilla Firefox on the impact of rapid releases on quality assurance with feedback by Mozilla project members. The study compares crash rates, median uptime, and the proportion of pre- and post-release bugs in traditional releases with those in rapid releases, and we also analyze the source code changes made by developers to identify potential changes in the development process. We found that (1) with shorter release cycles, users do not experience significantly more pre- or post-release bugs (percentage-wise) and (2) bugs are fixed faster, yet (3) users experience these bugs earlier during software execution (the program crashes earlier). Increased integration activity and propagation of harder bugs to later versions account for some of these findings. Overall, our case study suggests that a clear release engineering process with thorough automation is one of the major challenges when switching to rapid releases.
As the Free and Open Source (FOSS) concept has matured, its commercial significance has also increased, and issues such as quality and sustainability have moved to the fore. In this study, the authors focus on time-based release management in large volunteer FOSS projects, and reveal how they address quality and sustainability issues. They discuss the differences between release management in the traditional software context and contrast it with FOSS settings. Based on detailed case studies of a number of prominent FOSS projects, they describe the move to time-based release management and identify the factors and criteria necessary for a successful transition. The authors also consider the implications for software development more generally in the current dynamic Internet-enabled environment.
Release engineering deals with all activities in between regular development and actual usage of a software product by the end user, i.e., integration, build, test execution, packaging and delivery of software. Although research on this topic goes back for decades, the increasing heterogeneity and variability of software products along with the recent trend to reduce the release cycle to days or even hours starts to question some of the common beliefs and practices of the field. In this context, the International Workshop on Release Engineering (RELENG) aims to provide a highly interactive forum for researchers and practitioners to address the challenges of, find solutions for and share experiences with release engineering, and to build connections between the various communities.
The release and deployment phase of the software development process is often overlooked as part of broader software engineering research. In this paper, we discuss early results from a set of multiple semi-structured interviews with practicing release engineers. Subjects for the interviews are drawn from a number of different commercial software development organizations, and our interviews focus on why release process faults and failures occur, how organizations recover from them, and how they can be predicted, avoided or prevented in the future. Along the way, the interviews provide insight into the state of release engineering today, and interesting relationships between software architecture and release processes.
Release Planning is the process of decision making about what features are to be implemented (or revised) in which release of a software product. While release planning for proprietary software products is well-studied, little investigation has been performed for open source products. Various types of feature dependencies are known to impact both the planning and the subsequent maintenance process. In this paper, we provide the basic layout of a method to formulate and analyze feature dependencies defined at the code level. Dependencies are defined from evolutionary analysis of the commit graph of OSS code development and syntactical dependencies. We demonstrate our method with an explorative study of an open source project, the Spring Framework. From the analysis of the development cycles of two major releases over forty-one months, we could correlate late, increased feature dependencies with an increased number for subsequent improvements and bug fixes.
Do you use software peer reviews? Are you happy with your current code review practices? Even though formal inspection is recognized as one of the most effective ways to improve software quality, many software organizations struggle to effectively implement a formal inspection regime. Open source projects use an agile peer review process-based on asynchronous, frequent, incremental reviews that are carried out by invested codevelopers-that contrasts with heavyweight inspection processes. The authors describe lessons from the OSS process that transfer to proprietary software development. They also present a selection of popular tools that support lightweight, collaborative, code review processes and nonintrusive metric collection.