Abstract: Although open source and the related processes have become an inherent part of the computer industry, companies and other contributors are often reluctant when it comes to active involvement and participation. The reasons are manifold. Strong ones are that most open source projects are self-governing, without a fixed road map or schedule, each which its own development process. This seems to make them unreliable and unpredictable, because personal intentions cannot be enforced and rely on the open source community in charge of leading the projects.
Within an exemplary case study, a new feature spawning multiple layers of a GNU/Linux based operating system, and thus different open source projects, will be implemented and submitted for inclusion. All this bounded by a predefined, fixed time frame, which might be exemplary for schedule and budget driven company structures. The underlying development processes of the Linux kernel, a middle ware project called UDisks and the GNOME desktop will be considered and acted upon accordingly.
As a whole, the feature submission failed, because it was not possible to include all the required changes in all target projects in time. The failure has two main reasons: First, it is caused by technical problems which could occur in every software project, and thus not related to open source processes in particular. Second, and more relevant for this research, delays occurred due to common obstacles one has to face in the individual open source development processes. Individuals cannot put as much pressure as they like on the projects and are kind of at their mercy.
As an overall outcome, trying to include a new feature in different open source projects depending on each other is possible, however, unpredictable to a certain extent. The open source community has its own rules and processes, companies or other contributors cannot rely on being able to influence in whatever way they want. The advancements heavily depend on the relevant community and project members and thus the process involved. Conclusion: When submitting patches, always expect another iteration.
Reference: Holger Macht. A Case Study in Open Source Patch Submission. Studienarbeit, Friedrich Alexander-University of Erlangen-Nürnberg: 2012.