Inner source: Difference between revisions
Added Capital One based on Article by Jared Smith, Capital One’s open source community outreach Manager. |
No edit summary |
||
| Line 49: | Line 49: | ||
:* Openness and availability of knowledge |
:* Openness and availability of knowledge |
||
; Higher employee motivation |
; Higher employee motivation |
||
== Prevalence == |
== Prevalence == |
||
| Line 64: | Line 65: | ||
* [[PayPal]]<ref>{{Cite book|url=http://www.oreilly.com/programming/free/getting-started-with-innersource.csp|title=Getting Started with InnerSource|last=Oram|first=Andy|publisher=O’Reilly Media, Inc.|year=2015|isbn=978-1-491-93758-7|location=|pages=|quote=|via=}}</ref> |
* [[PayPal]]<ref>{{Cite book|url=http://www.oreilly.com/programming/free/getting-started-with-innersource.csp|title=Getting Started with InnerSource|last=Oram|first=Andy|publisher=O’Reilly Media, Inc.|year=2015|isbn=978-1-491-93758-7|location=|pages=|quote=|via=}}</ref> |
||
* [[Capital_One]]<ref>{{Cite book|url=https://www.oreilly.com/ideas/using-open-source-methods-for-internal-software-projects|title=Using open source methods for internal software projects|last=Smith|first=Jared|publisher=O’Reilly Media, Inc.|year=2016|isbn=|location=|pages=|quote=|via=}}</ref> |
* [[Capital_One]]<ref>{{Cite book|url=https://www.oreilly.com/ideas/using-open-source-methods-for-internal-software-projects|title=Using open source methods for internal software projects|last=Smith|first=Jared|publisher=O’Reilly Media, Inc.|year=2016|isbn=|location=|pages=|quote=|via=}}</ref> |
||
==Key Factors for Adopting Inner Source== |
|||
Inner source can be a promising approach for large organizations that develop software. However, it may not be appropriate in all settings. Nine key factors can be consulted to gauge the extent to which inner source may be appropriate. These are divided into three categories.<ref name="KeyFactors2014">{{Cite journal | doi = 10.1145/2533685| title = Key factors for adopting inner source| journal = ACM Transactions on Software Engineering and Methodology| volume = 23| issue = 2| pages = 1| year = 2014| last1 = Stol | first1 = K. J. | last2 = Avgeriou | first2 = P. | last3 = Babar | first3 = M. A. | last4 = Lucas | first4 = Y. | last5 = Fitzgerald | first5 = B. }}</ref> |
|||
===Product factors=== |
|||
* Seed product to attract a community |
|||
* Multiple stakeholders for a variety of contributions |
|||
* Modularity to attract contributors and users |
|||
===Process and Tools factors=== |
|||
* Practices that support "Bazaar-style" development |
|||
* Practices that support "Bazaar-style" quality assurance |
|||
* Standardization of tools to facilitate collaboration |
|||
===Organization and Community factors=== |
|||
* Coordination and leadership to support the emergence of an internal meritocracy |
|||
* Transparency to open up the organization |
|||
* Management support and motivation to involve people |
|||
== References == |
== References == |
||
Revision as of 15:00, 24 May 2017
Inner source is the use of open source software development practices and the establishment of an open source-like culture within organizations. The organization may still develop proprietary software, but internally opens up its development. The term was coined by Tim O'Reilly in 2000.[1]
Motivation
Open source is recognized to be capable of delivering high quality software.[2] Furthermore, the open collaboration in open source enables collaboration even between competitors (e.g. ARM and Intel working on Linux kernel on merit-based decisions).
Consequently, software developing organizations want to benefits from its outcomes (the software components and tools), but also from the development practices exercised and established in the open source world.
Used open source practices
Besides several practices established in foundations such as Apache Software Foundation, Linux Foundation, and Eclipse Foundation, inner source and open source projects require open collaboration, open communication, and a proper quality assurance.
Open Collaboration
All required development artefacts (e.g. code, documentation, issue tracker, etc.) have to be accessible for all employees of a company leveraging inner source. Central software forges are an essential tool for implementing open collaboration.
Based on the principles of open collaboration (egalitarian, meritocratic, and self-organizing) every contributor who is willing to help an inner source project is typically welcome. Contributions to inner source projects are typically judged meritocratically based on the value they bring to the project. Meritocracy can also be enabled by open communication as decisions are discussed publicly. Although an organization does not necessarily become completely self-organizing to adopt inner source, inner source allows individuals, organizational units, and project communities a higher degree of self-organization.
Open Communication
Inner source projects and programs rely on open communication to make all communication openly accessible for all employees. Open communication is communication that is public (within the company), written, archived, and complete. The goal is to allow any individual or party that has stake or interest in an inner source project to participate in the communication. As open communication discussions are archived, a detailed documentation of the software is passively gathered that allows to go back and revisit historic discussions and decisions.
Quality assurance through separation of contribution from integration
A dedicated code review and the separation of contributors and committers (integrators, developers with write access) assures the quality of an open source project, and, therefore, also for inner source project.
Benefits
Beyond the quality attributes of open source software the following benefits are reported:[3][4]
- More efficient and effective development
-
- Faster Time-to-Market
- Reduced development costs
- Overcoming organizational unit boundaries
-
- Cost and risk sharing among organizational units
- Collaboration across organizational unit boundaries
- Program-wirde information exchange
- More successful reuse
-
- Use of competences missing at component providers
- Independence between reusers and providers
- Relief of component providers
- Better software product
-
- increased code quality
- More innovative development
- More flexible utilization of developers
-
- Simplified developer deployment
- Collaboration of detached developers
- Enhanced knowledge management
-
- Community-based learning
- Openness and availability of knowledge
- Higher employee motivation
Prevalence
Among others the following companies are known for adopting inner source:[3]
Key Factors for Adopting Inner Source
Inner source can be a promising approach for large organizations that develop software. However, it may not be appropriate in all settings. Nine key factors can be consulted to gauge the extent to which inner source may be appropriate. These are divided into three categories.[7]
Product factors
- Seed product to attract a community
- Multiple stakeholders for a variety of contributions
- Modularity to attract contributors and users
Process and Tools factors
- Practices that support "Bazaar-style" development
- Practices that support "Bazaar-style" quality assurance
- Standardization of tools to facilitate collaboration
Organization and Community factors
- Coordination and leadership to support the emergence of an internal meritocracy
- Transparency to open up the organization
- Management support and motivation to involve people
References
- ^ O'Reilly, Tim. "Open Source and OpenGL - O'Reilly Media". archive.oreilly.com. Retrieved 22 February 2017.
- ^ Kevin Crowston, Kangning Wei, James Howison, Andrea Wiggins, ACM, ed. (in German), Free/Libre open-source software development: What we know and what we do not know, 44, ACM Computing Surveys, doi:10.1145/2089125.2089127, ISSN 0360-0300
- ^ a b Capraro, Maximilian; Riehle, Dirk (2016-12-01). "Inner Source Definition, Benefits, and Challenges". ACM Comput. Surv. 49 (4): 67:1–67:36. doi:10.1145/2856821. ISSN 0360-0300.
- ^ Stol, Klaas-Jan; Fitzgerald, Brian (2015-07-01). "Inner Source - Adopting Open Source Development Practices within Organizations: A tutorial". IEEE Software. 32 (4): 60–67. doi:10.1109/MS.2014.77. ISSN 0740-7459.
- ^ Oram, Andy (2015). Getting Started with InnerSource. O’Reilly Media, Inc. ISBN 978-1-491-93758-7.
- ^ Smith, Jared (2016). Using open source methods for internal software projects. O’Reilly Media, Inc.
- ^ Stol, K. J.; Avgeriou, P.; Babar, M. A.; Lucas, Y.; Fitzgerald, B. (2014). "Key factors for adopting inner source". ACM Transactions on Software Engineering and Methodology. 23 (2): 1. doi:10.1145/2533685.