Managing a corporate open source software asset

Abstract

Introduction We define corporate open source (COS) as applying the precepts and methodologies prevalent in the open source development community for creating industrial-strength software projects in a corporation for internal use. It may seem that open source style development - using informal processes, voluntary assignment to tasks, and having few financial incentives - may not be a good match for commercial environments. Our ongoing work, however, demonstrates that under the right circumstances, corporations can benefit from open source development techniques. We present two approaches to managing COS projects, and expand in detail on one of them. Our results indicate that open source approaches require significant adaptation to succeed in commercial settings. In particular, they require substantial support from business divisions within a corporation to successfully leverage the shared asset. Our ongoing research has attempted to determine whether corporations can effectively leverage the open source development model to create and manage software projects inside the corporate domain. We have observed how the precepts and methodologies of the open source development had to be adapted in order to create commercial grade software. In particular changes are required in order to accommodate a market-driven schedule and feature decisions that are not wholly amenable to an open source development approach. Our contributions in this article include describing two methods to effectively manage COS assets: an Infrastructure-based COS model, and a Project-specific COS model. We report experiences with the management aspects of the latter COS model, which includes our findings that this model requires a greater amount of support to get a new business division onboard when compared to the minimal support provided by traditional open source projects. However, the benefits of Project-specific COS outweigh the costs once the business division is fully on-board: the development costs are amortized over the number of divisions using the common asset, and the asset itself benefits from contributions from the expanded use. Open source practices and tools have proven potential to overcome many of the well-known difficulties of geographically distributed software development, and to allow widely distributed users of software to add features and functionality they want with a minimum of conflict and management overhead. Dinkelacker et al. discuss Progressive Open Source as a set of tools and techniques for a corporation to host multiple open source projects within a company and between third parties. In the context of their work, our work on COS corresponds to and furthers their work on what is referred to as "Inner Source" in their paper. Our previous work attempted to determine whether open source tools and practices are a good fit for developing commercial-grade software especially in the light of the differences between the two camps: open source development is more iterative in nature when compared to the staged method of software development practiced at many corporations; the incentive structure between the two varies, as does the motivation factor; commercial software is usually characterized by process methodologies (CMMI, ISO, TL9000, among others), that are typically absent in open source development. We reached the conclusion that certain commercial projects can indeed benefit from open source development methodology, especially those projects where: • a technology is needed by several product groups (hence there is reason to pool resources), • the technology is relatively immature so that requirements and features are not fully known at the outset (so there is a need to evolve continuously), • product groups have different needs and specific expertise in customizing the software for their needs (so everyone benefits from the contributions of each group), and • the initial product has a sound, modular architecture (so that it is feasible to merge all the diverse changes into a single development branch). Furthering our previous work, the discussion in this article presents a management view of maintaining a COS asset. We discuss project management and planning aspects that are intrinsic to projects managed in this style.

A comparative study of challenges in integrating Open Source Software and Inner Source Software

“…Gurbani et al [24] describe two different models to implement an Inner Source program: infrastructure-based and project-based. We discuss both models below.…”

“…In the project-based Inner Source model, there is one division (called the ''core team'') within the organization funded by other divisions that take over the responsibility of a critical resource (shared asset) and makes it available to the other divisions as a shared asset [24]. Gurbani et al have reported on a project-based Inner Source model applied at Alcatel-Lucent [5,24], where the shared asset was a telecommunications signaling server used in a Software Product Line (SPL) [26].…”

“…Gurbani et al have reported on a project-based Inner Source model applied at Alcatel-Lucent [5,24], where the shared asset was a telecommunications signaling server used in a Software Product Line (SPL) [26]. Wesselius reports on a projectbased Inner Source model as applied at Philips Healthcare and discusses business model aspects [4].…”

“…Most notable are the studies of Inner Source at HP [1,6,25], AlcatelLucent [5,24], and Philips Healthcare [4,18]. These studies all report on how OSS principles have been applied within these organizations, and focus on what works and what does not work within a corporate environment.…”

“…Delivery advocate is one of a few roles identified in [24] and is a member of the core team that assists a business division to integrate the shared asset. By being physically present as a local helpdesk, it becomes easier to help business divisions to integrate the shared asset.…”