Why shared code stays hidden

Innersource — reusing code inside an organization the way open source projects reuse code in public — runs into a predictable wall at scale: discoverability. With thousands of repositories spread across product lines, an engineer about to start a new project rarely knows what already exists that could be reused. Searching is hit-or-miss, and even a well-written, modular internal library only helps if someone finds it before writing the same thing again.

The root cause is organizational. Most companies group engineers by product, not by function. So when someone builds a reusable component, they share it with their immediate team and maybe a few support colleagues. The people in other divisions who could benefit never hear about it. That gap is structural, which means casual networking alone won't close it — the fix has to be built into the way teams work.

Three practices that improve visibility

Addressing discoverability means combining cultural habits with structural mechanisms. These approaches have the most leverage:

  • Start an innersource community of practice. A recurring meeting or dedicated channel gives people working on shared projects a place to coordinate. Unlike informal networking, a community of practice persists beyond individual relationships and helps prevent duplicate work.
  • Identify strategic opportunities. Look for groups that do similar work but sit far apart on the org chart. Bringing them together through knowledge-sharing sessions and brainstorming workshops can reveal which areas are best suited for innersource projects.
  • Standardize tooling. If teams use different languages and frameworks, reusable code has to be ported before it can be shared. Common tooling removes that barrier and makes sharing practical.

Practical tools: project portals and crawlers

On the tactical side, a project portal can make existing innersource work much more visible. The SAP InnerSource Project Portal is one approach: it creates a single searchable website listing all internal projects, giving reusable code exposure across the whole organization and inviting contributions from teams that would otherwise never see it.

Getting the portal running requires two extra pieces: hosting and a crawler that determines which repositories should appear. Hosting can be handled with GitHub's private Pages feature, which is a one-click setup in the repository settings. For the crawler, the innersource-crawler project generates a repos.json file, and a GitHub Action feeds that data into the portal site. If the goal is to list every internally visible repository, the ea-repo-list tool is a solid alternative for the crawler role.

For teams that want a different look, Enterprise Showcase offers a static GitHub Pages site that presents all internally visible projects in one central location.

These are not heavy investments. You can fork the portal repo and the crawler repo, adjust the configuration for your organization, and run the GitHub Action on the crawler fork. Combined with a community of practice and shared tooling, that gives your innersource program a discovery mechanism that outlasts any individual teammate's network.