How to Make Finding Inner Source Projects Easy

In 2006, we set-up SAP forge to make finding and collaborating on inner source projects easy. The advice of how to design a forge or portal for this purpose hasn’t really changed over the years. The most important advice is:

Make the forge available at one place (and one place only) with a memorable URL like forge.acme.corp

The second most important advice is on the design of the home page of the forge. There are a couple of independent mechanisms that should be present. In order of descending importance (read: prominence of screen real estate given):

1. Provide keyword-based search for projects (for this projects on the forge need to be indexable and provide some information about themselves)
2. Present project based on relevant meta-data to indicate relevance and status like stars of projects, current activity levels, number of active users, etc.
3. Provide hierarchical browsing of projects (for this, projects need to classify themselves as belong to categories; tagging also works but feeds more into search)
4. Provide lucky chance encounters (for this, the forge needs to pick random projects and present them to users by chance; this way every project gets some visibility.

This advice has endured over a long-time, as this gallery of (historic) screenshots of software forges until about 2010 shows:

These features are less present on GitHub these days (but were for most of its life so far). Microsoft understands developers, so I’m sure they’ll resurface in VSCode as Microsoft connects VSCode, GitHub, and Azure for their end-run around AWS.

More on inner source under building products / inner source.