Borrowing Open Source Practices at Europace

Case study taken from Isabel Drost-Fromm’s chapter/article in ‘Adopting Inner Source’ (July 2018)

Introduction

Europace is a medium sized Fintech company based in Berlin, Germany. The organisation commenced its formal InnerSource program in 2017 and learning was shared in the article one year later. 

Within this one year time frame, Europace reported that where InnerSource processes and practices were applied, there was a noticeable improvement in development times, higher quality code and higher rates of cross-team collaboration. It was also noted that new processes yielded higher project accountability amongst developers for projects and a growing culture of mentoring across teams.

InnerSource Objectives

In 2015, Europace started exploring alternative organisational and governance models for the company. The aim of this was to develop a new company-wide framework that would create a culture of ‘decentralised self-organization’ (I can put a link here …). In this new structure, responsibility and decision-making would shift to staff with the most expertise. 

This mission was based on the ‘… fundamental belief … that Europace employees are experts in their field and very capable of making the right decisions.’ 

(do I reference?  Page 88 of article)

Within this context, InnerSource provided both a holistic model and useful guidelines for progressing this vision. 

InnerSource’s mirroring of best practices from Open Source also offered the potential to resolve challenges within the growing company such as the:

• Increased level of development silos amongst development teams. 
• Technological interdependency and the associated challenges of development prioritization.
• Information gaps and lost ‘project memory’ due to minimal documentation on projects. 
• Need to move to asynchronous communication and decision-making to facilitate remote working.

InnerSource – The First Year at Europace

Obtaining buy-in and staff engagement

• Creating an InnerSource role

Firstly, a specific role was established for co-ordinating InnerSource efforts. The new InnerSource Co-ordinator’s experience in Open Source and with the Apache Software Foundation was invaluable in terms of understanding, communicating, implementation and problem-solving on the Europace InnerSource journey.

• The strategic importance of building relationships

The next step was to engage with different stakeholders in Europace and initiate conversations about the merits of getting involved. The approach taken was to invite people for informal one-to-one lunches. The conversations were particularly useful for identifying concerns and potential obstacles. 

Once common challenges were identified, informal group lunches were set up for interested parties to share learning. This then evolved into a monthly roundtable lunch meetings for information exchange and problem solving.

• Trusted Committership at the ‘meta level’

In this early phase, InnerSource enthusiasts supported their peers to transition to new processes for communication and recording decisions. Others also mentored teams, answered questions and promoted InnerSource to colleagues.  This core group were invited to become Trusted Committers for the InnerSource programme.

Assigning Trusted Committer status provided public recognition for the efforts of InnerSource advocates and mentors. It also highlighted who was driving the program within the company. 

New processes, new tools

• Increasing transparency in communication and decision-making

Tracing development and product decisions had become a challenge within Europace.  A need had been identified to capture communications and decisions in written form. 

InnerSource advocates actively encouraged colleagues and also led the way in promoting the transition from a reliance on verbal decision-making to using Slack, GitHub discussion or other archived media. 

• Improving task transparency to facilitate collaboration

Up to this point, planning had mostly taken place on Trello boards or JIRA. However, teams often limited both read and write access to their own units. This created obstacles for cross-team collaboration.

As GitHub exposes information by default, the transition to GitHub made it easier for all teams to search ‘… across issues, communications on pull requests, and code.’

• The InnerSource repository – Leading by example and making it safe to fail

The InnerSource program needed to model transparency, provide a space for people to ask questions to the community and also track relevant documentation collected.

The program followed an “infrastructure-based” InnerSource program (need footnote). 

Communication processes were designed to reflect InnerSource principles (as above) and in true InnerSource fashion, tools that were already available in the organisation were reused. 

A GitHub repository (‘ep-innersource’) tracked all InnerSource program work and decisions. A dedicated Slack channel was created for general discussions about the program.

The GitHub repository also served as a space for people to try out the processes and technology in a safe environment where there was no risk of disrupting production systems.

• The transition to Pull Requests

Although some Europace staff were already familiar with GitHub, teams were now encouraged to start using pull requests as a way to address technological interdependency.

Contributors (from any team) who wanted to make changes had permission to download the code through a pull request on GitHub. They could add or change a feature and then submit it to the Trusted Committer on the host team for approval. Code would then be merged into the master codebase or the contributor was requested to make further revisions. 

Within weeks, there was a more widespread adoption of pull requests as a model for collaboration.

• Promoting accountability on InnerSource projects – The Trusted Committer

Trusted Committership (link to ISC learning path here) was introduced to facilitate cross-team collaboration, retain project memory and also promote accountability for the project over time. 

Trusted Committers provided a safeguard that ensured product quality while also reducing barriers to contributions. Trusted Committers were also responsible for mentoring developers who wished to contribute code or fixes.

Once contributors earned the trust of maintainers, they were awarded write access to the repository.

Developing a common internal understanding of InnerSource

Initially, InnerSource was defined as a way to apply Open Source principles to company projects. 

However, as the program evolved, it was important to build staff’s understanding not only of ‘how’ to do InnerSource but also the principles and good practices underpinning successful InnerSource adoption within Europace.

The InnerSource programme developed awareness and knowledge amongst teams by facilitating collaborative work to: 

• Document InnerSource learning in the company’s tech blog.
• Submit an InnerSource pattern to InnerSource Commons.
• Create a set of InnerSource principles for Europace.

As with all InnerSource programs, requests for contributions and reviews were publicized on the Slack channel. The initiatives were also posted on GitHub and where necessary, the InnerSource lead contacted key people to request reviews.

InnerSource Results

Within a year, the InnerSource projects rolled out at Europace had demonstrated the benefits of this model of collaboration:

• The move to GitHub and the company-wide push to document decisions on key platforms led to increased project transparency and a corresponding reduction of information fragmentation.
• As decision making, architecture design discussions, documentation and code were closer together on GitHub, changes were easier to track and understand. This reduced the need for many formal requirements for documentation up front. Consequently, this raised the interest of project managers and UX designers in projects.
• Asynchronous decision making (through Slack and GitHub) facilitated greater involvement from staff members who were not initially involved on projects. Rather than depending on co-location or face-to-face meetings, staff could share expertise across team, time and geographical boundaries.
• Trusted Committership led to greater accountability amongst developers. As Mentoring of developers was built into this process, it became recognised as a valuable staff contribution.
• The use of pull requests enabled senior project members to provide input and support on projects outside of their responsibilities. Also, the safety net of pull requests and code reviews allowed new developers the opportunity to make valuable contributions.
• Use of pull requests also facilitated ‘…a speed up in development’

• Both the quality of code and code reviews improved substantially.

Conclusion

Promoting InnerSource practices within the company and on a number of projects demonstrated the value of InnerSource in terms of developing higher quality code, encouraging code reuse and addressing existing problems such as loss of project memory and information fragmentation. Using InnerSource on selected projects established the benefits of cross-team collaboration not only for projects but for staff as well. New developers were given the opportunity to develop their skills whilst more established developers were recognised as Trusted Committers and mentors.

Phase 2 of Europace’s InnerSource programme would focus on new challenges relation to scaling up and further roll-out of the program.

However, from a Europace perspective, the initial adoption phase was considered highly successful.