The open source model, applied internally

DevOps promised faster delivery of value through a blend of people, process, and technology. But value means different things to different organizations: reliability with minimal downtime, responsiveness to user feedback, or a stronger focus on quality gates like testing, compliance, and governance. Too often, the technology piece gets all the attention while people and processes quietly determine whether those goals are actually met.

Look at how most enterprises run software development. Projects are closed by default. Access requires approval and justification. Work gets duplicated as teams solve the same problems in isolation. Now contrast that with open source communities, which operate asynchronously, openly, and remotely at global scale, welcoming external contributions and making decisions in public. Conway’s Law tells us software mirrors organizational structure. If teams can't collaborate, that limitation ships in the product—and with it, the mindset that a problem belongs to someone else's team.

Three common organizational patterns

Siloed teams

When teams are closed by default, silos form naturally. Multiple teams end up solving identical challenges, reinventing wheels instead of building on shared work.

Center of Excellence

A Center of Excellence (CoE) is a common remedy: a central team that acts as custodian of shared, reusable resources. On paper this should encourage re-use and optimization, but in practice it often becomes a bottleneck. Application teams become customers of the CoE, submitting requests that get prioritized into its backlog—but each team has different priorities. When Team A needs something critical for a release, someone's work gets deprioritized. Organizational politics ensue, and the CoE becomes a source of friction rather than enablement.

Communities of practice

An evolution of the CoE model is the community of practice: subject matter experts from across application teams form a virtual team around a shared goal. No central team serves them; they collaborate directly. This aligns naturally with innersource—a group of people who aren't in the same business unit but work together on common problems. Unresolved questions remain, such as who owns the roadmap, who handles breaking changes, and who maintains the resulting work. But the model at least exposes how organizational structure shapes what gets built.

What innersource actually means

The core idea is simple: open source practices are not limited to open source projects. Innersource applies them to proprietary software within an organization. The InnerSource Commons community has documented patterns for this journey, including starting as an experiment and using an InnerSource Portal to aid project discovery.

The shift is cultural as much as technical. Instead of siloed teams focused only on their own backlog, engineering teams collaborate across organizational boundaries. They make decisions in the open and accept contributions from anywhere in the company. All the DevOps practices already in place remain relevant—arguably more so:

  • GitHub Issues let any team request features or report bugs directly against another team's project. If the host team deprioritizes it, the requester has the option to contribute the fix themselves.
  • Branches and forks give contributors—host team or guest—an isolated environment to develop changes without touching the production codebase.
  • Pull requests let contributors propose changes to the host team early and often, enabling regular feedback loops.
  • CI/CD keeps contributions consistent. Triggering GitHub Actions on pull requests enforces the same quality standards whether code comes from the host team or external contributors.

Putting innersource into practice on GitHub

GitHub was built around open source communities, and those capabilities extend to proprietary work. Several features are particularly useful for getting started.

Default to internal repositories

For GitHub Enterprise customers, internal repositories give visibility to any user in the enterprise account. They're a straightforward way to reduce silo problems by default.

Sensitive projects—a new product in stealth, incorporated IP, or regulatory constraints—can still be restricted when necessary. But flipping the default so that repositories are internally visible goes a long way toward opening up collaboration across the business.

Branch protection and required status checks

Consistent processes for bringing changes into production require consistent quality gates. Branch protection rules enforce those standards, and status checks define the specific conditions code must meet.

Checks can cover tests, build verification, or scans for new security vulnerabilities. Making them required via branch protection rules pushes higher-quality code into production as a matter of course.

CODEOWNERS files

When certain team members specialize in specific areas of the codebase, CODEOWNERS files automatically designate them as required reviewers for any changes to protected files or folders.

Empowerment and guardrails

Innersource can feel risky to engineering leaders. Governance and compliance don't have to be casualties, though—they can live inside the development lifecycle instead of being thrown over the fence at go-live. Similarly, GitHub Actions includes features for governing, adopting, and scaling automation across an enterprise.

Secure by default

With GitHub Advanced Security, features like Dependabot and secret scanning can be configured at the repository, organization, or enterprise level. Making security alerts an organization-wide standard encourages teams to resolve them promptly rather than treating security as an afterthought.

For teams exploring innersource further, the innersource landing page offers additional guidance, and GitHub's expert services team can help organizations navigate the transition.