Why Rules Matter
Opening up your repositories to everyone in the company without structure isn't InnerSource — it's chaos. Imagine a shared codebase where anyone can merge anything at any time, with no review process. Within weeks, the codebase would be unstable, inconsistent, and unmaintainable. Successful open source projects avoid this through clear governance: defined roles, documented processes, and explicit standards.
InnerSource borrows the same governance model.
The Maintainer Role
Every InnerSource project needs dedicated Maintainers — the "owners" of the project, typically members of the team that originally built it. Crucially, a Maintainer's job is not just to write code. When a project becomes InnerSourced, the Maintainer's role shifts significantly toward community management and technical leadership.
A Maintainer's core responsibilities:
| Responsibility | Description |
|---|---|
| Triage | Promptly acknowledge new issues and Pull Requests from other teams, even if just to say "we'll review this by Friday." |
| Review | Evaluate outside contributions for correctness, test coverage, style, and architectural fit. |
| Mentorship | Guide contributors on how to improve their code rather than simply rejecting it. |
| Gatekeeping | Make the final call on what gets merged to protect project stability. |
| Documentation | Keep contribution guides and architecture docs current so contributors can self-serve. |
The mentorship responsibility is often underestimated. When a developer from another team submits a Pull Request, they may not know your team's conventions. A Maintainer who responds with "this doesn't follow our patterns, rejected" will kill contribution momentum. A Maintainer who responds with "here's what we need to change and why" builds a capable contributor base.
Contribution Guidelines: The CONTRIBUTING.md File
How does someone from another department know how to help without breaking things? They read the CONTRIBUTING.md file — a document at the root of the repository that answers every question a new contributor might have before they even write a line of code.
A well-structured CONTRIBUTING.md covers:
# Contributing to AuthLib
## Getting Started
1. Clone the repo: `git clone https://github.internal.company.com/platform/authlib`
2. Install dependencies: `make install`
3. Run the test suite: `make test` — all tests must pass before you begin.
## Before You Write Code
- Open an issue describing the problem or feature. Tag it `proposal`.
- Wait for a Maintainer to comment with `approved-for-contribution` before investing time.
- This prevents you from building something we can't merge.
## Code Standards
- All code must be formatted with `gofmt` (Go) or `black` (Python).
- New features require unit tests with >80% coverage of the new code.
- Public functions must have docstrings.
## The Pull Request Process
1. Branch from `main`. Name your branch `feature/<issue-number>-short-description`.
2. Keep PRs small — under 400 lines of diff where possible.
3. Fill out the PR template completely.
4. Tag `@platform-team` for review. Expect a first response within 2 business days.
## Code of Conduct
We follow the [Company Engineering Code of Conduct]. Be constructive. Be kind.
Without this file, potential contributors face a blank wall. They don't know how to set up the environment, what the standards are, or who to talk to. Most will give up and build their own solution instead.
Key Point: Governance in InnerSource is not bureaucracy for its own sake — it's the scaffolding that makes trust possible between teams who don't share a manager. Without it, the first bad merge will cause teams to lock their repos back down.