The Duplication Problem
Your company might have a perfect, battle-tested rate-limiting library. If no one outside the team that built it knows it exists, every other team will build their own. You end up with seven rate-limiting libraries, each with different bugs, different APIs, and different maintenance burdens.
Discoverability is the prerequisite for reuse. Before teams can contribute to shared code, they need to be able to find it.
Mechanisms for Discoverability
Internal Project Portal
A searchable, browsable catalog of internal libraries, services, and tools — think of it as an internal npm registry or an "App Store" for internal code. Each entry should include: what the project does, which teams use it, who the maintainers are, and a link to the repo. Tools like GitHub Enterprise's topic search, GitLab's project catalog, or custom-built portals serve this purpose.
Standardized Repository Tagging
Require all InnerSource-eligible repos to use a consistent tagging scheme. For example:
Topics: innersource, auth, python, platform-team
This makes repos findable via search without requiring a separate portal.
Internal Tech Talks and Engineering Newsletters
A 20-minute "show and tell" at an engineering all-hands — "Here's the logging library we built, here's why you'd use it instead of rolling your own" — is one of the highest-ROI discoverability investments. It reaches engineers who would never think to search for a solution.
Architecture Review Boards
Requiring teams to check for existing solutions before building new ones — as part of a design review process — creates a structural forcing function for reuse. An architect reviewing a proposal can say "Team A already solved this; have you talked to them?"