• Corpus ID: 18678946

Management of community contributions A case study on the Android and Linux software ecosystems

@inproceedings{Bettenburg2013ManagementOC,
  title={Management of community contributions A case study on the Android and Linux software ecosystems},
  author={Nicolas Bettenburg and A. Hassan and Bram Adams and Daniel M. Germ{\'a}n},
  year={2013}
}
In recent years, many companies have realized that collaboration with a thriving user or developer community is a major factor in creating innovative technology driven by market demand. As a result, businesses have sought ways to stimulate contributions from developers outside their corporate walls, and integrate external developers into their development process. To support software companies in this process, this paper presents an empirical study on the contribution management processes of… 

Figures and Tables from this paper

Source Software Ecosystem : A Systematic Literature

TLDR
Study of open source software ecosystem (OSS-Ecosystem) and its roles, impacts and actors in software engineering domain will reveal how practitioners and researchers encounter open sourceSoftware ecosystem and the results will be applicable to other software technology products and ICT business.

Participation in Modern Code Review An Empirical Study of the Android , Qt , and OpenStack Projects

Software code review is a well-established software quality practice. Recently, Modern Code Review (MCR) has been widely adopted in both open source and proprietary projects. Our prior work shows

The impact of human factors on the participation decision of reviewers in modern code review

TLDR
Investigating the factors that are associated with the participation decision of an invited reviewer can help practitioners better understand about how human factors associate with theparticipation decision of reviewers and serve as guidelines for inviting reviewers, leading to a better inviting decision and a better reviewer participation.

Modern Release Engineering in a Nutshell -- Why Researchers Should Care

  • B. AdamsShane McIntosh
  • Business, Engineering
    2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER)
  • 2016
TLDR
This paper argues that the involvement of researchers is essential, by providing a brief introduction to the six major phases of the release engineering pipeline, a roadmap of future research, and a checklist of three major ways that the release Engineering process of a system under study can invalidate the findings of software engineering studies.

Review participation in modern code review

TLDR
This study investigates the characteristics of patches that do not attract reviewers, are not discussed, and receive slow initial feedback and suggests that the patches with these characteristics should be given more attention in order to increase review participation, which will likely lead to a more responsive review process.

The Secret Life of Patches: A Firefox Case Study

TLDR
A quantitative comparison showed that while the patch lifecycle remains mostly unchanged after switching to rapid release, the patches submitted by casual contributors are disproportionately more likely to be abandoned compared to core contributors, suggesting that patches from casual developers should receive extra care to both ensure quality and encourage future community contributions.

Supporting Development Decisions with Software Analytics

TLDR
The thesis of this dissertation is that by employing software analytics to various development tasks and activities, this work can provide software practitioners better insights into their processes, systems, products, and users, to help them make more informed data-driven decisions.

Informing development decisions: From data to information

  • Olga Baysal
  • Computer Science
    2013 35th International Conference on Software Engineering (ICSE)
  • 2013
TLDR
This research demonstrates that by employing software development analytics, developers can help developers make informed decisions around user adoption of a software project, code review process, as well as improve developers' awareness of their working context.

An empirical study of the impact of modern code review practices on software quality

TLDR
Through a case study of the Qt, VTK, and ITK projects, it is found that code review coverage, participation, and expertise share a significant link with software quality.

On licensing and other conditions for contributing to widely used open source projects: an exploratory analysis

TLDR
It is found that strong copyleft licenses are most common and are used in the majority of the projects, and use of no specific other conditions in addition to the license terms is more common for projects using strong copylesft licensing compared to projects using non-copyleft licensing.

References

SHOWING 1-10 OF 38 REFERENCES

Patch Review Processes in Open Source Software Development Communities: A Comparative Case Study

  • J. AsundiR. Jayant
  • Computer Science
    2007 40th Annual Hawaii International Conference on System Sciences (HICSS'07)
  • 2007
TLDR
The results show that while the patch review processes are not exactly identical across various F/OSS projects, the core members across all projects play the vital role of gate-keepers to ensure a high level of review for submitted patches.

A case study of open source software development: the Apache server

  • A. MockusR. FieldingJ. Herbsleb
  • Computer Science
    Proceedings of the 2000 International Conference on Software Engineering. ICSE 2000 the New Millennium
  • 2000
TLDR
This analysis of the development process of the Apache web server reveals a unique process, which performs well on important measures, and concludes that hybrid forms of development that borrow the most effective techniques from both the OSS and commercial worlds may lead to high performance software processes.

Two case studies of open source software development: Apache and Mozilla

TLDR
This work examines data from two major open source projects, the Apache web server and the Mozilla browser, and quantifies aspects of developer participation, core team size, code ownership, productivity, defect density, and problem resolution intervals for these OSS projects.

Managing open source contributions for software project sustainability

TLDR
An improved patch contribution process for managing open source software "patch" (source code and documentation change) contributions will lower the contribution barrier, helping to improve the sustainability of critical open source projects.

An Analysis of Open Source Business Models

TLDR
This paper's focus is on explicating the different business models that are seen in the open-source arena, and how they are being used to generate revenues and reduce costs.

Will my patch make it? And how fast? Case study on the Linux kernel

TLDR
This paper crosslinks and analyzes eight years of patch reviews from the kernel mailing lists and committed patches from the Git repository to understand which patches are accepted and how long it takes those patches to get to the end user.

Open Borders? Immigration in Open Source Projects

TLDR
A quantitative case study of the process by which people join FLOSS projects is mounted, using data mined from the Apache Web server, Postgres, and Python to develop a theory of open source project joining, and evaluates this theory based on the data.

Detecting Patch Submission and Acceptance in OSS Projects

TLDR
It is argued that the process of patch submission and acceptance into the codebase is an important piece of the open source puzzle and that the use of patch-related data can be helpful in understanding how OSS projects work.

Open source software peer review practices

TLDR
It is concluded that Apache reviews can be described as early, frequent reviews of small, independent, complete contributions conducted asynchronously by a potentially large, but actually small, group of self-selected experts leading to an efficient and effective peer review technique.

The social structure of free and open source software development

TLDR
It is suggested that FLOSS projects might have to work hard to achieve the expected development advantages which have been assumed to flow from "going open", and the variation in communications structure across projects means that communications centralization is useful for comparisons between FLOSS teams.