Inner Source (or Inner Sourcing) is a term coined by Tim O’Reilly in 2001 that referenced to the,
“use of open source techniques within the corporation”.
Although more that 25% of the deployee code in the most influential IT companies was Open Source in 2015, IT departments didn’t show much interest in collaboration or innovation process. (Gartner, 2015).
But recently there are so many mainstream IT firms that are allocating resources to Open Source contributions, not only for the benefits of the code, but the benefits of the methodology brought to the organization such as collaborations, innovation and quality control.
Inner Source takes the lessons learned from developing Open Source software and applies them to the processes that companies follow to develop software internally.
Innersourcing’s benefits for the company
So many authors talk about the benefits of built open source structures in IT departments. Here are some of them:
- Faster development, using test and continuous integration to fix bugs. A larger community support the code, explore vulnerabilities and find solutions.
- Documentation. All the code has good documentation that allows all companies to have the same insights and reduce the curve adoption.
- Code Re-use. All people across the organization know the architecture developed by other teams and how to apply it.
- Collaboration across teams is welcome and doesn’t cause stringency, as the metodology is designed for this reason.
- Encourage innovation, as the whole company is focus on the same goals. Innovation is everyone’s concern.
- Improves meritocracy and healthy competition that promotes the growth of knowledge and the “hacker ethic” (Himanen terms).
Inner Sourcing’s characteristics
Move your company into Inner Source techniques can be triky. It’s important to learn how to manage OSS development.
- Developers share their work across world wide communities, not just their team or departments. In OSS projects anyone can comment the code, and make pull requests to submit changes to customize for ad hoc reasons or improvement.
- Everyone can create a new repository and adapt it to their project. So, you have to create or adapt OSS rules to support different branches of your projects.
- You have to be able to work remotely, because the contributions to your projects come all over the world.
- Unit Testing is a must. In Open Source and inner source, testing is done constantly, as changes are checked in, this protects against failures during production runs.
How to measure it
Inner Source rise up the quality of your code and there are some metrics you can use to know how healthy your Inner Source project is beyond code’s qualitative analysis.
To know how many contributors you have, how many commits and how often it is updated will help you feel confident with your inner sourcing techniques.
You can also measure who is contributing, their productivity, their commitment to the project and how each project attracts and retains talent/contributors over time..