InnerSource – how to implement it?

InnerSource adopts OpenSource practices to code that remains proprietary and can only be seen within one organization or a small set of collaborating organizations. This approach helps reduce dependencies between development teams, break silos and remove bottlenecks, as well as increases knowledge-sharing within the company.

In this article, I would like to describe how we implemented InnerSource practices in the Sportsbook department and how we teamed up with another department, Trading, to create the InnerSource Community of Practice focused on exchanging our experiences and knowledge.

Variants of implementation

According to the theory, there are three variants of InnerSource implementation – universal, selective, or project-specific. Universal implementation means that there is no software component that is not inner-sourced. In the selective variant, only agreed software artefacts are published as InnerSource and none of the remaining software components is inner-sourced. In the project-specific approach, only a specific InnerSource project is run within the InnerSource program, and most software components are not inner-sourced.

For the Sportsbook department, we decided to focus on the selective variant. Another approach that we are considering for the future is the project-specific one. Each of the two solutions allows us to decide and choose the best solution for a specific development task or an initiative depending on the circumstances. Implementing InnerSource to all software components is less flexible for us and could potentially bring a mismatch of perceived and actual code ownership in the long run.

Step 1 – Define current state and future goals

InnerSource for Sportsbook was nothing new. For example, our cooperation with the International department has been based on this approach, as Sportsbook remains the owner of the repositories that the International team has to use and contributes to:

Diagram 1: Scheme of cooperation between International (Contributing Team) and Sportsbook (Owning Team)

When we started promoting InnerSource in the Sportsbook department, our main goal was to increase awareness of the practices among development teams and product owners. In addition, we wanted to increase the number of development tasks implemented in the InnerSource model and not limit them to cooperating with the International department.

Step 2 – Gain the support of Senior Management

We started by analyzing the stakeholders in our department that we would like to persuade to use the InnerSource working model. The Head of Engineering and the Delivery Team gave us full support right from the start. The software development teams also supported this idea and even identified it as a natural way of dealing with dependencies. However, we wanted to ensure that all the teams followed best practices. Another challenge was to highlight the benefits of InnerSource to the Product Teams. To achieve this, we organized a session for the Head of Product and senior Product Managers with a specially crafted presentation on how InnerSource can enable faster delivery of the business value to our customers.

A project management technique called ‘Stakeholder Analysis’ can be beneficial in preparing a communication strategy. Using the diagram below, we analyze our work environment and, based on the strength and potential interest in the project (in this case, in the InnerSource concept), we select the appropriate strategy for dealing with each group of stakeholders:

Diagram 2: Stakeholder analysis

Step 3 – Evangelize Development Teams

The next important step was to encourage the development teams to do more InnerSource work and to teach them good practices. To achieve that, we met with each development team and their product owner. Altogether we organized 6 sessions for 11 development teams from Sportsbook and one development team from International. Sessions were prepared and conducted by the Principal Engineering Team and consisted of: (1) theoretical fundamentals, (2) review of the typical software development process using InnerSource, (3) responsibilities of an owning and of the contributor team and (4) some practical examples.

Our practical sessions were particularly interesting among development teams, as they consisted of very realistic short scenes prepared by our principal engineers. One of them played a role of a developer from a contributor team, while the second one acted as a developer from an owning team. Each scene showed a real problem that may be encountered while working in the InnerSource model, and the participants were asked for possible solutions to the presented problem.

Step 4 – Prepare code repositories

The next important step is to ensure that our code repositories are properly prepared for InnerSource so that any contributor team can work with them. This means a clear ownership definition and availability of the README.md and CONTRIBUTING.md files. During our sessions with the development teams, we showed templates and discussed the correct contents of README.md and CONTRIBUTING.md.  After our sessions, the development teams were asked to review these files and make sure they were properly prepared. We also made the templates available in Gitlab for each new project.

Step 5 – Establish an InnerSource Community of Practice

In parallel, we established a Cross-department Community of Practice between Sportsbook and Trading. Trading was quite advanced in implementing InnerSource and we wanted to learn from them. We agreed to meet every two weeks to discuss the progress.

One interesting insight worth mentioning is the new role in an owning team called “Sheriff”, which was invented and implemented by Trading.  The sheriff role rotates; it is a single point of contact for anyone wishing to engage with an owning team, so the rest of the owning team’s members can focus single-mindedly on the tasks in their sprint backlog.

Step 6 – Make InnerSource an integral part of your planning sessions

Another important element is keeping track of all potential InnerSource tasks and projects. Quarterly Planning Sessions are a good time, so we agreed with our Product Delivery Team to make InnerSource an integral part of our planning. As a result, all InnerSourced tasks are marked on a team’s Mural wall during Quarterly Planning Session using an additional item.

Step 7 – Review and plan for follow-up improvements

Six months after the start of the project, we undertook a review and presented the results of our activities. It was also an excellent opportunity to plan improvements.

What have we achieved after the implementation of all the described steps? First, we gained a great deal of awareness about the InnerSource practices among delivery leads, product owners and development teams. Second, our teams were motivated to review and prepare their code repositories. Third, InnerSource is not limited to cooperation with the International department; we also use it in-house among our development teams.

What should we improve in the future? Currently, we are involved in many discussions about how to define the appropriate metrics, thanks to which we could better present the results of our InnerSource actions to higher management. We enhanced our InnerSource Community of Practice and invited other departments to exchange their experiences.

In what context does InnerSource work and what should be avoided? InnerSource is a great method if we want to expand teams' competences and reduce bottlenecks in the long run. According to our experience, it is best to start with small pieces of work that are not critical for a project. You must bear in mind that the delivery time will initially be longer due to the learning curve of the contributing team.

Selecting InnerSource as a working model should occur naturally. It is a mutual agreement between the owning and the collaborating team. InnerSouce should be supported, but not dictated by management. It cannot be seen only as a remedy for resource capacity issues.

Summary

This article presents a strategy that helped us to promote InnerSource among development teams. Introducing best practices in development teams is not an easy task. The greatest challenge here is to encourage development teams to consider changes to their routines and adopt new practices. The second biggest challenge relates to the strategy of a company or a department. The more a new practice is in line with the company’s strategy, the more support it will get from senior management, and the better the chances of its successful implementation.

Katarzyna Osuch-Bukowska
Engineering Manager & Principal Engineering Lead, Sportsbook