Building InnerSource practices through an internal developer portal

‍This article first appeared in The New Stack, which you can read here.‍

Strengthening collaboration and breaking down silos are what InnerSource is all about; the methodology encourages an open-source way of thinking towards software development. It’s not a new practice; in fact, the term was first coined back in December 2000 by Tim O’Reilly, founder of O’Reilly Media. Despite it being a somewhat older term in an industry that loves to move on to the latest buzzwords and trends, it is still very much an approach that many engineering teams want to incorporate into their organizations. Gartner expects 40% of software engineering organizations to have InnerSource programs by 2026.

This is because they believe that the approach will improve code reusability, increase standardization and inspire a culture of autonomy and ownership among developers. Ultimately, the goal of InnerSource is to reduce duplication in development, lack of reuse and the resulting increased costs. But enterprises tend to struggle with the handoff between overarching strategy and tactical implementation. 

While no single tool can ensure that InnerSource will be adopted by developers, there are approaches that can help to implement InnerSource - including the use of an internal developer portal.

Here, we run down five key ways you can use an internal developer portal to help implement and encourage InnerSource within an organization:

The importance of a ‘trusted committer’

In her book “Understanding the InnerSource Checklist”, Silona Bonewald describes the role of a “trusted committer” as crucial to implementing InnerSource best practices. The trusted committer is a developer - often on a two week rotation - that mentors other developers and ensures standards are met when people create new PRs. Trusted committers lead the effort to reduce silos for their service by:

• Maintaining contribution guidelines
• Reviewing incoming pull requests to ensure they’re in accordance with these guidelines
• Mentoring developers who fall outside of the contribution guidelines 
• Requesting help from those who commit code to their service.

Portals create a place that makes the work of trusted committers easier, seen, acknowledged and easy to follow. 

In the most basic sense, an internal developer portal makes the presence of trusted committers known, just like software ownership can be driven through a portal. Having a portal can ensure ‘trusted committers’ for each service are known and rewarded by: 

• Including an automatically updated ‘trusted committer’ schedule;
• Assigning a “trusted committer” tag or property to the developer who is currently serving in this role; and
• Gamifying the contribution of each trusted committer by maintaining a dashboard (depicting, for example, the number of PRs merged under their watch or the speed with which they respond to each PR).

Finally, Bonewald notes that serving as a trusted committer takes developers away from writing code, so passively recording their contributions using a portal is an excellent way to provide objective performance metrics in year-end performance conversations.

Bonewald suggests a promotion path to “Fellow” for developers who excel as trusted committers, which could be a tag or property depicted proudly on their user profile in a portal.

Boosting discoverability

This method and the next are particularly important for organizations that have grown inorganically through acquisitions. Whether acquired companies have become a part of a single legal entity or become subsidiaries, the administrative burden of consolidating into a single source code management tool or adding all developers to all existing source code management tools is an insurmountable task and, without doing this, InnerSource efforts tend to languish in slide decks instead of thriving in the daily work of developers.

An alternative to consolidating tools or organizations is to integrate all existing repositories into a single catalog that acts as a foundation for a portal, where developers may discover metadata about all available services without exposing the source code by default. In doing so, developers can understand what a service does, how to contribute to it, and who the trusted committer is without ever seeing the source code. This immediately reduces duplication of both services and APIs.

Being able to send access requests to the right person

Once developers are prepared to contribute to or use the service they’ve discovered using a portal, they can use a self-service action to request access to only the repository in question. By implementing dynamic approvals, this request can be sent to the right person, whether that is the trusted committer, product manager or technical lead.

Creating new services that are InnerSource-ready from the outset

Engineering organizations that do not use a portal already struggle with streamlining new service creation: developers must submit individual, co-dependent tickets for a new repository, new pipelines, new project management tools, and others. Adding InnerSource requirements to scaffolding a new service is yet another trigger for developers to switch context when they should be – and want to be – writing code.

A welcome alternative to a ticket-driven process is a self-service action that allows developers to easily satisfy these requirements from the beginning. Instead of directing them to find, modify, and add the InnerSource documentation requirements (README.md, CONTRIBUTING.md, GETTINGSTARTED.md, and HELPWANTED.md), simply ask them to fill out the minimum requirements for these from the beginning in a self-service form. The automation that creates the new repository, pipeline, project management tool, and others can write these files to the new repository, allowing developers to shift their focus to writing the code for the new service nearly immediately.

Scorecards for services

The approach above will satisfy InnerSource requirements for new services, but organizations tend to have a vast number of existing services that must be evaluated for compliance with InnerSource standards. Before instructing an InnerSource or DevOps team to create a repository scanner that evaluates all repositories, consider using a custom scorecard in a portal. A scorecard can be used to define, measure and track metrics related to each service or entity in an internal developer portal. In this case, a scorecard can help establish metrics to grade compliance with InnerSource standards, which will help managers or team leads to understand the gaps in existing services, then drive time-bound initiatives to fill those gaps.

Conclusion

By implementing a portal and deliberately configuring it to serve InnerSource purposes, engineering leaders can enjoy the benefits of InnerSource in their organizations. Developers will similarly enjoy the benefits of enhanced discoverability, ability to easily scaffold a new InnerSource-ready service, and quickly finding the right person to support their contributions.