InnerSource is an approach inspired by OpenSource, but applied to the scope of a company only. Many of these companies do not want to see their code revealed publicly for confidentiality reasons for example. Thus, InnerSource offers them the benefits of OpenSource, i.e. collaboration, innovation, and improvement, without opening the doors of their source code to anyone.
Like OpenSource, InnerSource gives access to the source code and its modification and use, but only to people within a company. The projects proposed in InnerSource can be helpful to any developer of the company who wants to use them, contribute or get inspiration. This is particularly interesting when companies have dozens of teams or when they are distributed around the world and therefore do not have the opportunity to see each other and exchange often. With InnerSource, they can collaborate and participate in developing a common code.
Furthermore, asynchronous contributions are quite convenient in a global epidemic where our work habits and values are changing. Developers choose whether or not to use the available InnerSource code based on their needs if it’s relevant in their context. Usually, teams schedule time together to discuss the issues they face, and other projects cannot move forward during this time. Thanks to asynchronicity, developers can move forward on their own and get help easily. They can arrange their schedule as they wish to contribute or make validations/reviews with Pull Requests.
First of all, thanks to the collaborative nature of InnerSource, all the developers can leverage their skills to contribute to internal projects. It fosters developers’ collaboration in InnerSource projects, bringing more inputs and more improvements. Because of this collaboration, developers are much more likely to constantly review their code and accept feedback. With the diversity of topics in programming, it is impossible for a developer to know everything today. By joining forces, the quality of each project is improved.
But also, be able to participate and have access to some of the other projects creates a strong team cohesion within the whole company and a feeling of being part of a community. The different teams are not locked into each other, and the mindset of the entire company changes. Companies that allow their employees to try new things and be freer in their work also offer them a healthy work environment.
#3: Financial gains and innovation:
According to a Forrester study, InnerSource represents a saving of 45 minutes per day per developer. It brings a financial advantage to the company with all its benefits: improved delivery and reduced maintenance costs. On a global scale, InnerSource boosts innovation. Since projects move forward more efficiently and employees feel comfortable enough, they have time and ease to make mistakes more often, try again, and experiment; this is how innovation can happen. However, according to a recent study by Stack Overflow, only 16% of companies have taken InnerSource initiatives.
#4: Developer Experience:
IT is a sector where turnover is widespread. Sharing knowledge is therefore essential to avoid knowledge loss. InnerSource fosters everyone to share their knowledge with other developers. It becomes much easier for a developer to learn new things. Also, it is easier for new developers to get familiar with the technical culture of the company. InnerSource consolidates teams’ motivation and continuous learning, building stronger ties with the company and preventing turnover risks.
First and foremost, we must not overlook an essential point: Three types of InnerSource users exist:
Maintainers are in charge of driving the product vision and managing the organizational aspects of the project.
Contributors contributed to the project (code, documentation, …)
Members use the project, participate in conversations, and bring their opinions on the project’s direction.
We must accept that few developers will be maintainers and contributors, most of whom will be community members. A few people must remain leaders to keep the projects’ essence and ensure it continues to move forward, to prevent their abandonment due to lack of contributions.
You’ll probably rely on platforms such GitLab or GitHub to centralize the source code of the projects. Still, you’ll also need to be rigorous on documentation: how to use the project (the famous “Get started”), and how to contribute. Without this, how could people join your community?
You can start by identifying projects or sub-projects that make sense to be reused by other projects in your organization: an authentication system, a custom ORM/Framework, …
Best coding practices ensure code quality and should be known by every developer in the company. Note that we’re talking about any practice relevant to the organization’s context.
The Promyze solution was designed to boost InnerSource at two levels:
These best practices can be visible from any team in the company and can be reused in their context.
Talking about best practices helps combines both code reuse and methodologies reuse. It’s an excellent start with Inner Source; developers can share their knowledge, collaborate, and find solutions.
InnerSource will likely bring value to every company that implements it and knows how to use it correctly. It is a precept that should at least be retained and adapted according to the company’s context, and it’s a necessary step if you plan to go to OpenSource. And you, have you already implemented an InnerSource strategy?
Promyze, the collaborative platform dedicated to improve developers’ skills through best practices sharing and definition.
Crafted from Bordeaux, France.