Inner source practices

At the April 5 session Grace described a small problem that turned out to be a big idea. The editors had asked the web team for months to change how trail difficulty appeared on TrailCheck. The web team agreed it was a good change but never had time. Finally Owen, who had learned enough over the winter, opened a pull request against trailcheck himself, Priya reviewed it, and it was live in two days. "Why did that take four months to ask for and two days to do?" Grace asked. Priya's answer was that Tidewater had just practiced inner source without meaning to. This lesson covers what inner source is, how GitHub supports it, and the community features that make work easy to find and follow.

What inner source is

Inner source means applying the practices of open-source development inside an organization. Code and documents are open to everyone in the company rather than locked inside the team that owns them; anyone can read them, report problems and propose changes; the owning team reviews and accepts contributions; and the conversation happens in the open, in issues and pull requests, where others can learn from it. The term was coined in 2000, and many large companies now use it to reduce duplicated work, spread knowledge and get past bottlenecks like the one Grace described.

Inner source is not the same as making everything public. The repositories stay private to the organization; what changes is who inside the organization can see and contribute. It is also not a free-for-all: the owning team still decides what is merged, and the same protections, reviews and checks apply. The difference is that a person outside the team can contribute instead of waiting.

The principles

The InnerSource Commons, a community of practitioners, describes four principles that make inner source work. Openness: projects are easy to find and easy to join, with clear documentation of how to contribute. Transparency: decisions, discussions and reviews are visible, so people understand why things are the way they are. Prioritized mentorship: the owning team treats helping contributors as real work, not an interruption. And voluntary code contribution: people contribute because they want or need to, and the owning team remains free to decline what does not fit.

Roles in an inner source project

Inner source borrows its roles from open source. The host team owns the repository and is responsible for it. Within the host team, trusted committers are the people who review and merge contributions and mentor the contributors; in GitHub terms they are usually code owners with Write or Maintain access. Contributors are people from other teams who report issues and open pull requests. A product owner for the host team decides what the project should and should not do, which tells contributors in advance which proposals are likely to be accepted.

How GitHub supports inner source

Most of what inner source needs is already in GitHub. Visibility comes first. In an enterprise, an internal repository is visible to every member of every organization in the enterprise but not to the public, which is designed for exactly this purpose. In a single organization like Tidewater, a base permission of Read, from lesson 1, gives the same effect for private repositories. Contributors who cannot push to a repository can fork it, if forking is allowed for internal or private repositories, or the host team can grant them a role that lets them push branches but not merge, with protection rules making sure everything goes through review.

Process comes next. CONTRIBUTING.md files, issue and pull request templates, and CODEOWNERS files from lessons 4 and 5 tell contributors what to do and route their work to the trusted committers automatically. Branch protection and rulesets from lesson 3 mean the host team does not have to fear contributions, because nothing reaches main without review and checks. Discussions give contributors a place to ask before they build. Repository templates let a team share a well-set-up starting point, so new projects begin with the right health files and workflows already in place.

Making repositories discoverable

Inner source fails if people cannot find what exists. A repository is discoverable when it has a clear name, a one-line description, topics (searchable tags such as maps, style-guide or data-validation), a README that explains what it is and how to contribute, and, in larger organizations, custom properties, labels that owners define for repositories, such as team, product or data sensitivity, which can be used to search and to target rulesets. GitHub search can then find repositories by topic, language or property across the organization.

Stars, watching and following

GitHub has several ways to keep track of people and projects, and the GH-900 outline includes them under the community domain. Starring a repository bookmarks it in your list of stars and signals appreciation; star counts are a rough measure of interest, and you can organize your stars into lists. Watching a repository decides which notifications you receive about it: all activity, only participating and mentions, or custom choices such as releases, issues or security alerts. Following a person or an organization adds their public activity, such as new repositories and releases, to your dashboard feed. GitHub's Explore pages and topics pages highlight trending repositories and collections to help people discover projects.

Getting a repository ready for contributors

Priya turned the session's ideas into a readiness checklist that a host team completes before inviting contributions from other teams. A repository that fails several items is not ready, however willing the team is, because contributors who hit an undocumented setup or wait weeks for a review rarely try a second time.

When the contributor is outside the company

The partner publisher that borrows the style guide sits at the edge of inner source. Its editor is not part of Tidewater, so she is an outside collaborator on style-guide only, as lesson 2 described, and the guide itself was made public in lesson 2's example so that other publishers could adapt it through forks. In practice the same habits served both groups: the partner editor used the same contributing guide, the same issue forms and the same review process as Tidewater's own staff. That is a common pattern. Projects that start as inner source and work well often become open source later, because the documentation, review habits and protections are already in place. Lesson 12 follows exactly that path for the trail-report format.

Measuring whether it works

Inner source is a change in habits, so it helps to measure it. Useful signs include the number of pull requests from people outside the host team, how long contributions wait for a first review, how many contributions are accepted, and how many duplicate projects are avoided. A repository's Insights tab shows contributors, commit activity and pull request trends, and for public repositories, traffic. Rosa made a simple monthly count for trailcheck and style-guide.

Common obstacles

Inner source has predictable obstacles. Host teams worry about the extra review work and about being responsible for code they did not write, which prioritized mentorship and clear contribution rules address. Contributors hesitate if their first pull request is ignored, which is why a service promise, such as a first review within three working days, matters more than any tool. Managers may not count contributions to other teams' projects as real work, which needs to be settled openly. And discoverability decays as repositories multiply, so descriptions, topics and READMEs need the same occasional review as access.

Grace's difficulty display, live since February, became the team's standard example. When new staff asked how to get a change into the website, the answer was no longer "ask the web team and wait" but "open an issue, and if you can, open a pull request; Priya and Dmitri will help you get it right."