InnerSource Practice

Overview & Expected Benefits

Overview

InnerSource means using successful and productive patterns from Open Source and apply them to projects inside Thales.

InnerSource is, simply, the use of Open Source principles and practices inside proprietary organizations.
InnerSource empowers individual engineers to contribute code from within their team to another team in order to speed up the process of adding functionality (features) or fixing defects.
InnerSource also democratizes development and control over the direction of the project by encouraging pull requests over feature requests.
The traditional development practice put all decision making and control in the hands of a single team that maintained the code, who were petitioned by users to add enhancements through feature requests.
In contrast, with Open Source and InnerSource, anyone who wants to make a change downloads his or her own version of the code through a pull request (a term popularized by the prevailing code management system GitHub), adds the desired feature, and submits the code for approval.

— Adopting InnerSource by Danese Cooper, Klaas-Jan Stol | O’Reilly Media, Inc. (2018)

For further reading, see InnerSource Commons .

Expected Benefits

Adopting InnerSource practices offers numerous advantages, such as:

• Breaking Down Silos and Bottlenecks, enabling a massive cross-GBU and cross-BL collaboration within Thales
• Reuse, saving significant time, energy and money by not reinventing the wheel
• Knowledge Sharing, helping Thales become a learning company
• Innovation, by allowing new input and creating serendipity
• Improving Quality, by allowing careful reviews
• Staff Mobility and Process Standardization

Practice Description

Identify existing InnerSource assets

Before starting a new development, you first have to identify existing InnerSource assets that might partially or fully meet your needs.

Reuse an existing InnerSource asset

If an existing InnerSource asset partially or fully meet your needs, you can reuse it according to the InnerSource license that you can find in a file located at the root of the repository.

Improve and contribute to an existing InnerSource asset

Check contributing guide of the project, and if doesn’t exist … If you have found a defect or a bug in an existing InnerSource asset, you can:

• create a new issue or bug report
• propose a solution to fix that defect via a merge request

If you have found a missing feature in an existing InnerSource asset, you can:

• create a new issue or feature request
• propose a solution to implement that feature via a merge request

Create and share a new InnerSource asset

If none of the existing InnerSource assets meet your needs, even partially, then you can share your work as an InnerSource asset.

In order to share your work as an InnerSource asset, you have to use the InnerSource checklist.

For more information about the InnerSource checklist, see Thales InnerSource .

Review merge requests

When you receive a merge request, you have to carefully review it to determine if it is ready to be integrated into your InnerSource asset.

To write helpful review feedback, you can use Conventional Comments .

Use the decision tree

To help you make the correct decision, you can use the following decision tree:

flowchart TD
    Start((" ")) --> Q1{"Does my project already<br/>exist either in<br/><b>Open</b> or<br/><b>InnerSource</b> ?"}

    Q1 -->|Yes| Q2{"Does it answer all<br/>my needs ?"}
    Q1 -->|No| Q3{"Does one or several<br/>component already<br/>exists in Open or<br/>InnerSource ?"}

    Q2 -->|Yes| Reuse["<b>Reuse</b>"]
    Q2 -->|No| Contribute["<b>Contribute</b>"]

    Q3 -->|Yes| Contribute
    Q3 -->|No| Develop["<b>Develop</b>"]

    Develop -->|It's relevant to share ?| Share["<b>Share</b>"]