Innersource is the practice of creating reusable code for the purpose of sharing within the boundaries of an organization. Innersource at scale within an organization can be difficult to accomplish for many reasons, but one common challenge is the “discovery problem,” best described as the challenge of spreading awareness about what opportunities or existing innersource projects exist in an organization.

Understanding the problem

Imagine for a moment that you’re in an organization with over 2,000 repositories across several different product lines. You’re about to start a new project and are looking for reusable code within your organization that might help you meet your tight project deadline. In this situation, it can be a very daunting task to search for all the right terms or determine if a project is even written in a reusable, modular way.

This discovery problem is an important one to solve for organizations. What typically occurs when an engineer creates some reusable software is they share that project with their limited network which typically includes colleagues on the same project as well as various support teams. But, the best case scenario here would be for the author to share the reusable project with other product lines or functional teams to maximize the visibility and access. This gap in awareness exists because common organizational structures today emphasize team groupings based on what product is being developed rather than grouping people with similar job roles together.

Given the structural nature of this obstacle, the solution should also be structural. Encouraging more networking can be helpful, but alone it doesn’t provide lasting results. Instead, I suggest focusing on solutions that can live beyond personnel changes and can be included in standard software development processes. Below are some general best practices, as well as a specific project I’ve seen success with.

Building better discoverability

Improving discoverability requires a multi-faceted approach in order to include the structural and cultural components. Here are some helpful practices to keep in mind while addressing the discoverability problem.

• Start an innersource community of practice. Starting a regular meeting or establishing a channel for those who work on innersource projects can help practitioners collaborate. This aids in preventing rework and giving participants a sense of team beyond their direct team. Communities of practice go beyond networking alone by creating a discussion space that is not tied to personal relationships. More information is available on how to start a community of practice atopensource.com.
• Identify strategic opportunities. Spend time identifying what groups might work in similar roles even if they’re distant on an org chart. Bringing these folks together through networking events, brown bag knowledge sharing, and brainstorm sessions can tease out the strategic areas to pursue innersource projects.
• Standardize tooling. A major obstacle to discoverability is a lack of shared technology and tools. Standardizing tooling can help ensure that those looking to share code will not need to “port” it to their preferred language or framework.

Using a project portal

There are also some tactical things you can do to encourage innersource adoption. I’ve found that building a project portal is a good way to get people involved and increase project visibility. SAP released a beautiful project calledSAP InnerSource Project Portal that helps address this challenge. The project portal lists all projects within an organization on a single searchable website with an easy to use interface.

This not only helps innersource projects to gain exposure across an organization, but also increases the potential for new contributors to improve the project.

As you can read from theirREADME.md, the only additional pieces needed to get this project running are hosting, and an innersource crawler. Hosting provides private access to the organization users to be able to view and use the website, and the innersource crawler provides the necessary information about which repositories should be listed. Luckily, GitHub recently announcedprivate pages, which fits perfectly as the hosting piece. This makes hosting aone-click setup in the settings tab of the repository.

As for the innersource crawler, I have createda project to handle that part. Then I use thisGitHub Action that takes therepos.json created by the crawler and feeds it to the project portal website. If you wish to have all repositories that are internally visible included in your InnerSource Portal, then theea-repo-list is a great option for this.

If you prefer a different look you could also check out the alternative solution calledEnterprise Showcase. This solution provides a static website hosted on GitHub Pages that displays all of your internally visible projects in one easy to use location.

If discoverability is a problem that your organization is facing in its innersource journey, I would encourage you to try out the practices I’ve outlined in this post. And if you’re keen to get started right away, you can fork theSAP portal repo and theinnersource crawler repo, make your configuration changes to fit your organization, and run theGitHub Action on your crawler repo fork.

Written by

Zack Koppert

@zkoppert

• GitHub Actions
• innersource
• remote work