14.3 InnerSource

Why GH-900 tests InnerSource

Domain 7.5 asks you to explain how InnerSource applies open-source principles within organizations. The skill sits in the community domain because the habits are the same as public open source—README, Issues, pull requests, discoverability, CODEOWNERS—while the audience is not the internet. Microsoft Learn's module How to manage a successful InnerSource program and GitHub's Enterprise Cloud guide Using innersource in your enterprise are the two official sources. GH-900 will pair them: Learn supplies the definition and benefits; GitHub Docs supply internal visibility and base permissions.

If a scenario says "every engineer in the company should find and reuse our shared login library, but customers must never clone it," the answer is InnerSource on an internal repository—not a public open-source release, and not a private repo that only one team can see.

Definition: open-source patterns, limited audience

Microsoft Learn: anyone can freely use, modify, and share open-source software. InnerSource is the practice of applying open-source patterns to projects with a limited audience. Example: a company program that mirrors a typical open-source project except that it is only accessible to employees. Learn's one-line gloss: an open-source program behind your company's firewall.

That sentence is the exam hinge. InnerSource copies workflow, not legal status. You still use GitHub Flow (branch, pull request, review, merge). You still write a README so strangers-to-the-repo can onboard. You still welcome contributions through Issues. You do not automatically grant the public a license, and you do not surrender company intellectual property. A later open-source release is a separate legal decision.

Benefits Learn wants you to name

Internal visibility. Developers read other teams' source, Issues, pull requests, and plans. They see how a similar problem was already solved and they get better data on velocity and direction. Duplicated internal services shrink because people can find the existing one.

Reduced friction. A consumer team that needs a bug fix in another team's library has a channel: open an issue or a pull request. If the owning team cannot merge in time, Learn notes the consumer may fork the internal project to unblock—still inside the company, still on GitHub.

Standardized practices. Different teams can keep different acceptance rules as long as they communicate those rules the same way (CONTRIBUTING.md, templates, CODEOWNERS). InnerSource is a chance to adopt shared conventions even when processes are not identical.

Learn also points at GitHub Discussions and GitHub Projects as extra InnerSource collaboration surfaces. GitHub's enterprise article adds sharing Actions and reusable workflows in an internal repository, publishing internal GitHub Packages, and creating template repositories so other teams start from a known skeleton.

Visibility: internal is the InnerSource switch

GitHub repositories have three visibility levels. Users who do not meet the requirement see a not found page.

Internal repositories are only available to GitHub Enterprise customers. Microsoft Learn states that note in italics because it is a common GH-900 trap: a Free organization has public and private, not internal. You cannot "turn on InnerSource visibility" on github.com without an enterprise.

GitHub's enterprise InnerSource guide: unless a repository contains sensitive information, prefer internal visibility. Internal means any member of any organization in the enterprise can view the repository, even if they are not a member of the owning organization. That is the whole point—discoverability across org-chart silos—without placing the git history on the public internet.

Base permission: Read so people can actually see it

Visibility is not enough if the organization's base permission is No permission. Base permission is the default access organization members have to all of that organization's repositories. GitHub's InnerSource guidance: organizations should generally have at least a Read base permission so every organization member can see every repository. Owners then use teams to grant Write, Maintain, or Admin on specific repos.

Sensitive repositories go in a dedicated organization with a more restrictive base permission, plus specific teams. Do not set the whole enterprise to No permission and then wonder why InnerSource search returns nothing.

Learn's five repository roles still apply: Read (view and discuss), Triage (manage issues and PRs without write), Write (push), Maintain (manage without the most destructive actions), Admin (full, including security and deletion). InnerSource contributors from other teams often start at Read or Triage and earn Write through a merged pull request, exactly as in public open source.

Make InnerSource discoverable and reviewable

GitHub's enterprise article treats discoverability as the first InnerSource practice. People cannot reuse what they cannot find.

READMEs. Repository READMEs are files, so they are searchable like code. Add organization-level and enterprise-level READMEs as a map to projects. For longer internal docs, use GitHub Pages or wikis. Learn: GitHub auto-surfaces README.md from .github/, then the repository root, then docs/, in that order if more than one exists. Use a descriptive repository name (warehouse-api, not misc) and a one- or two-sentence description.

Topics. Classify repositories by language, owning team, or system so enterprise search and topic filters work the same way github.com/topics works in public open source.

CONTRIBUTING.md. GitHub looks in the root, /docs, or /.github. If the file exists, GitHub links it when someone opens an issue or pull request. Spell out how to propose a change, what belongs in a bug report, and which branch workflow you use (GitHub Flow is the default recommendation when you have not written one).

CODEOWNERS. Name individuals or teams who must review paths. InnerSource without owners becomes a junk drawer. Learn and GitHub both treat a clearly defined maintainer team—ideally including representatives from consuming teams—as required for shared services.

Issue and pull request templates. .github/ISSUE_TEMPLATE.md (or the newer template directory) and .github/PULL_REQUEST_TEMPLATE.md turn inbound work into a form. That is how you scale contributions from people who do not sit with the owning team.

Share template repositories, internal packages, and reusable Actions so InnerSource is not only "please read our monolith." GitHub specifically recommends a dedicated internal repository for Actions and reusable workflows that any enterprise workflow can call.

InnerSource is not open source

Hold this contrast for the exam:

Learn still suggests licensing a repository "so customers know how they can use, change, and distribute the software" when you are publishing. That sentence is about open source or an explicit internal license policy. It does not mean InnerSource repos must use MIT. Many companies keep InnerSource proprietary and document reuse in CONTRIBUTING or an internal policy instead.

Keep contractors off the internal corpus

GitHub's InnerSource guide has a dedicated "hide content from external collaborators" section.

• If you use Enterprise Managed Users (EMUs), provision the contractor as a guest collaborator. Guest collaborators do not get access to internal repositories by default. They receive base permissions only in organizations where they are members, and they can be added as repository collaborators on specific repos.
• If you do not use EMUs, add the person as an outside collaborator on the repositories they need, and do not add them as an organization member. Outside collaborators (called repository collaborators under EMU) see only the repositories you attach. They do not receive the organization's base permission and they do not automatically see internal repositories elsewhere in the enterprise.

Exam trap: "internal visibility means every GitHub.com user can read it." Internal is enterprise members, not the internet. Second trap: "add the vendor as an org member with Read so they can file issues"—that may also grant them the InnerSource corpus via base permission. Use guest or outside collaborator instead.

Measuring InnerSource without harming culture

Learn warns that naive metrics damage culture. Prefer process over output (review turnaround, pull request size, work in progress, time to open). Measure against targets, not absolutes. Measure teams, not individuals: unique contributors, projects reusing code, cross-team @mentions. Do not put "lines of code InnerSourced" on a leaderboard.

Exam scenarios and traps

• "Apply open-source workflow to proprietary code so every employee can find it" → InnerSource, internal visibility, Read base permission.
• "Internal visibility is available on GitHub Free" → false. GitHub Enterprise only.
• "InnerSource requires an MIT license because it is open source" → false. It is not public open source; IP stays with the company unless they publish.
• "Set base permission to None and grant Write only to the owning team" → that hides InnerSource from the rest of the org. Sensitive repos belong in a separate, tighter organization, not as the enterprise default.
• "Contractors should be org members so they inherit internal repos" → opposite of the docs. Use guest collaborators (EMU) or outside collaborators.
• CODEOWNERS, CONTRIBUTING.md, issue/PR templates, README, and topics are the same community-health files you already learned for public repos; InnerSource reuses them.
• Forking an internal repo to unblock a consumer team is an InnerSource friction-reducer, not a leak, as long as visibility stays internal.

If you can define InnerSource in one sentence, pick internal plus Read, refuse to call it a public license, and keep contractors on guest/outside collaborator seats, you have Domain 7.5.