Adopting InnerSource at ASOS
InnerSource is the practice of taking lessons learnt from the Open-Source community and applying them to the way we develop software within an organisation. In essence, it involves opening up our codebases to all of our teams, accepting contributions and encouraging community-driven development, and it’s something we’ve been trialling in Commerce Digital Tech at ASOS during the last year. Here are our findings.
Why use InnerSource?
We’ve already had success with InnerSource in the Web teams at ASOS, and the reasons to adopt it elsewhere are myriad, including, but not limited to:
Increasing quality
Having more eyes on a codebase means improved software quality and security. By defaulting to open we’re urged to write useful documentation and to keep the comprehensibility of our code at the forefront of all of our changes. Both projects and the engineers working on them benefit from the breadth of skills and knowledge which exist across the organisation.
Creating a culture of collaboration
Knowledge silos are broken down, and instead, knowledge sharing becomes the default. New partnerships are formed, and patterns and lessons learnt spread organically throughout the organisation. This shared understanding becomes a new dialect and a foundation for innovation.
Providing flexibility in development
Because any team can contribute to a feature, we introduce options for parallelising the delivery of changes and remove the bottlenecks of high-contention teams.
Roles and responsibilities
There are two key roles involved in all InnerSource contributions—maintainers and contributors.
Maintainers are the owners of a codebase. They mandate whether a contribution is suitable and ready for acceptance. In a high-performing InnerSource environment they’ll be involved not just during the culmination of a change, but at its inception too.
Contributors are any groups or individuals looking to improve, adapt or fix problems in an InnerSource codebase. Contributions may range from making code changes to improving documentation; from raising bugs to commenting on issues.
How we manage contributions
To ensure the success of InnerSource contributions, we’ve established guidelines to support effective changes, encouraging useful conversation at key points in the change lifecycle.
1. InnerSource readiness
Every InnerSource repository must have a basic level of documentation, including a descriptive README.md, introducing the project, and a CONTRIBUTING.md, explaining how to contribute and who to communicate with.
We’ve learnt that having a good README.md is so helpful to newcomers, and so often missed in a large organisation, that we mandate them for all repositories, regardless of whether they intend to accept InnerSource contributions or not. It’s a small investment, that pays dividends: it’s conducive to a great developer experience, and paves the way for the InnerSource mindset shift, putting projects in good stead for the future.
2. Kick-off conversations
A conversation should take place between the contributors and the maintainers discussing the scope of the change, proposed implementation, responsibilities and release plan. This conversation is incredibly valuable and helps thwart misunderstandings early on, setting contributors off on the right foot.
3. Pull requests
The product of an InnerSource contribution is a pull request. A robust pull request process combined with a thorough continuous integration experience should give strong confidence that a change is fit to be accepted.
4. Retrospectives
Alongside the regular team retrospectives, a dedicated InnerSource retrospective should be run with representatives from both the contributing and maintaining teams. Here we evaluate the InnerSource experience, discuss improvements and take actions. These actions, as well as improving the individual project’s process, inform the overarching process.
Challenges faced
Discoverability
A common concern with large organisations new to InnerSource is, “how do I find repositories to contribute to?”.
At ASOS, a landscape view of services allows us to understand their boundaries and the interactions between them. This is a great starting point for visualising the impacts of cross-cutting features.
Our recent migration to GitHub Enterprise allows us to assign topics to repositories, highlighting those that are ‘InnerSource ready’, the domains they relate to, and the teams who own them.
We’re making plans to expand on this functionality, building a developer portal to aid navigation and growing a “gig economy”—putting common problems out to tender to encourage community-driven development. This is just another example of an InnerSource innovation, driving engineering efficiency initiatives.
Post-pull request support
In the majority of cases, the pull request process, along with the assurance of a thorough CI/CD process, is sufficient in transferring ownership to the maintaining team.
With more involved changes, sometimes it’s necessary to request additional support from the contributing team. Patterns like the 30-day warranty can help improve trust, having the contributing team commit to support and bug fixes for a given period.
Pull request overload
Services or libraries with a large number of consumers are likely to see an uplift in the volume of inbound pull requests as InnerSource takes off.
This can become overwhelming for maintaining teams, so the practice of setting Service Level Objectives (SLOs) for review turnaround times may help set expectations. These should be discussed during kick-off conversations.
Continuing our journey
In the time that we’ve been adopting InnerSource, we’ve learnt a lot. We’ve hit problems that have felt insurmountable and at times have questioned ourselves, but in every case we’ve ended up in a better place than where we started.
InnerSource has allowed us to deliver dozens of cross-cutting features more efficiently, spanning multiple teams and services. We’ve seen libraries evolve from maintainer-led to contributor-led, putting direction in the hands of the people who want to shape it. We’ve made process improvements that have benefited both the contributors and the maintaining teams. And finally, we’ve shared knowledge and patterns, supporting developer crossover and growing our developer community. InnerSource is another tool for our toolbox, but one which positively impacts almost every engineering initiative we’re implementing at ASOS.
Now we’re looking at the next steps on our InnerSource journey, expanding to new teams and domains. I fully anticipate that we’ll hit other roadblocks along the way, but I’m confident that the outcomes will be a boon for all those involved.