Simply hosting source code in a company GitHub organization does not make a project open for internal contribution. To qualify as inner source, a project must follow a defined set of standards for setup, contribution, and long-term maintenance. These standards span the following categories:

• Defined Project Roles
• Clear Contribution Rules
• Automated Build, Test, and Deployment
• Comprehensive Project Documentation
• Issue and Task Tracking

The following sections describe lightweight, scalable standards to help teams open up projects to internal contributors.

While not strictly required, using a common Git-based platform (e.g., GitHub Enterprise) is highly recommended. Many of the standards below rely on features such as pull requests, issues, and markdown-based documentation. If using a different system, equivalent processes should be implemented.

Success depends on committed people with clearly defined responsibilities. Typical inner source roles include:

Maintainer

The project lead, responsible for:

• Setting the technical roadmap
• Overseeing contributions and releases
• Reviewing and merging pull requests
• Maintaining documentation and testing practices
• Coordinating releases (e.g., packaging, tagging, publishing)

Core contributors who:

• Review and merge code
• Maintain documentation and testing
• Support contributors and fill in for Maintainers when needed

Anyone from outside the core team who submits code, documentation, or feedback. Contributors submit changes via pull request and must follow project guidelines.

At minimum, each project must include:

• CONTRIBUTING.md – Contribution rules, how to become a Committer/Maintainer, and project governance.
• README.md – Project overview, roles, build instructions, license, and support links.

All projects should adhere to the following baseline practices:

Use a standardized branching model (e.g., Git Flow) to reduce ambiguity for contributors.

Establish clear coding conventions. Reference a well-known style guide or enforce via CI tools.

• Fork & Pull – For Contributors: Fork the repo, make changes, and open a pull request.
• Branch & Pull – For Maintainers and Committers: Work in a dedicated branch, then open a PR.

Use structured commit messages:

Short summary (50 chars max)

DESCRIPTION: Longer explanation, wrapped at ~72 chars.
ISSUES: LINKED-123, LINKED-456
- Optional bullet points

All code must include unit tests and pass existing tests before submission.

Every pull request must be reviewed and approved by at least one Maintainer or Committer.

Use GitHub Issues (or equivalent) to log bugs, enhancements, and questions. Integration with tools like Jira is optional but recommended for larger teams.

Documentation is essential and must be maintained as part of every contribution.

Required

• Project Overview – In README.md: Roles, purpose, how to build/test, support contacts
• Contribution Guidelines – In CONTRIBUTING.md: All rules for submission and review
• Technical Docs – Architectural details, component explanations, glossaries, etc. (e.g., in a GitHub Wiki or Markdown files)

Establish automated pipelines using internal orchestration tools (e.g., Jenkins, CircleCI, GitHub Actions):

• CI Pipeline – Runs on each commit and pull request to ensure code builds and tests pass
• CD Pipeline – Deploys artifacts to a shared registry when approved (e.g., for internal libraries)

Use a centralized issue tracking system (e.g., Jira) to:

• Maintain backlogs
• Organize sprints or milestones
• Accept internal bug/feature requests

Include the project’s tracking location in the README.md.

To raise awareness of your inner source project:

• List it on your company’s internal developer portal
• Write an internal blog post about the initiative
• Notify relevant stakeholders who can help promote the project

Consider creating templates or shared examples for:

• CONTRIBUTING.md
• README.md
• Pull request templates
• Issue labels and workflows

These assets will help teams onboard faster and ensure consistency across projects.