Picture a company where five teams have each built their own logging library. Nobody knew the other four existed, so each team spent weeks solving problems a neighbor had solved months earlier. The company now pays to maintain all five.

InnerSource is a practice built to stop this from happening. It takes the way open source projects collaborate and applies it to the code inside your company: readable code, pull requests from outsiders, and maintainers who review and mentor. By the end of this article, you’ll understand where InnerSource came from and the problem it solves. You’ll also know the roles and principles that make it work, and where it falls short.

Disclosure: Jeff Bailey, who writes this blog, serves on the board of the InnerSource Commons.

What InnerSource Is

InnerSource is the application of open source practices and principles to software development inside a company (InnerSource Learning Path introduction). The code remains proprietary. What changes is who can read it and who can propose changes to it: anyone in the company, not only the team that owns it.

The mechanics look familiar if you’ve used GitHub. Code lives in repositories that every employee can find and read. A team that needs a change opens an issue, writes the change, and submits a pull request, a proposed change that waits for the owners’ approval. The owning team reviews it, asks for revisions, and merges it when it fits.

Where the Term Comes From

Tim O’Reilly coined “inner sourcing” in his December 2000 column Open Source and OpenGL. He described how CollabNet, a business founded the year before with Brian Behlendorf of the Apache Group, helped companies “use open source development techniques within the corporation,” even before they were ready to release their software as public open source. The practice spread as engineers who contributed to open source brought its habits to their day jobs. Those habits included code review on every change, design discussions in the open, and contributions from people outside the core team.

In 2015, Danese Cooper founded the InnerSource Commons as part of a bootstrapping effort for PayPal’s program (Adopting InnerSource). As of October 2026, the community supports over 3,000 people from more than 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation, incorporated in February 2020, is a 501(c)(3) public charity (About InnerSource Commons).

Why InnerSource Exists

Large organizations split work across teams, and each team owns its code. That ownership works well until one team needs something from another. Take a checkout team whose page depends on a pricing API owned by a different team. The checkout team needs a new discount field, and the pricing team has other priorities.

The InnerSource Learning Path describes three options the consuming team usually has, and each one costs something:

  • Wait it out. The checkout team ships without the field and hopes the request rises in the pricing team’s backlog. Sometimes it never does.
  • Work around it. The checkout team builds its own pricing logic. It now maintains code outside its expertise, no other team benefits, and the company owns two pricing services. Repeat that across a company where nobody can see each other’s code, and you get the five logging libraries.
  • Escalate. The checkout team asks a manager to force the work onto the pricing team. Both teams leave their planned work, and the checkout team spends credibility every time it does this.

InnerSource adds a fourth option. The checkout team writes the discount field itself and submits it to the pricing team’s repository, and the pricing team reviews and merges it. The feature arrives on the checkout team’s schedule, the company keeps one pricing service, and every other consumer of the API gets the field too.

The silos follow a known pattern. Conway’s Law predicts that systems mirror the communication structure of the organizations that build them, so teams that rarely talk produce components that rarely share. InnerSource opens a channel across those boundaries without redrawing the org chart.

Why AI Raises the Stakes

AI coding assistants make the workaround option much cheaper. When building a tool takes an afternoon, building your own feels faster than finding someone else’s.

Amazon offers an early public example. In April 2026, Business Insider reported on an internal Amazon document. “AI is making our tool duplication problem worse,” it said. “More duplication is being created faster, and less of it is being cleaned up.”

The document said AI “dramatically lowers the barrier to building new tools,” so engineers build their own instead of searching for existing ones (Business Insider). An Amazon spokesperson told the publication that the document reflects a single team’s perspective.

Duplication stays expensive even when code is cheap to write, because every copy still needs security patches and an owner who answers the page when it breaks. InnerSource attacks the problem at discovery. When internal code is visible and open to contribution, a team can find the tool that already exists before it builds another one. Extending that tool can take longer than generating a private copy, because the host team has to review the change. The company still ends up with one tool to patch and one owner to page. How Is AI Impacting Software Engineering? covers how InnerSource counters other AI pressures, such as review overload.

How InnerSource Works

InnerSource communities rely on a small set of roles, defined in the InnerSource Commons Learning Path.

Host team

The host team owns the codebase and forms the community around it. It sets the house rules: coding standards, a README explaining what the project does, and a CONTRIBUTING file explaining how outsiders can help.

Contributor

A contributor adds to a project through code, documentation, bug reports, or feature requests, and may or may not belong to the host team. The Learning Path also calls contributors guests, because another team may send them to build a feature it needs (Introducing the Trusted Committer Role). A guest is responsible for fitting in with the host team’s expectations and process.

Trusted committer

The trusted committer makes cross-team contributions land. Trusted committers are always members of the host community. They make important technical decisions and mentor contributors until their changes are ready to merge (Introducing the Trusted Committer Role). The Learning Path defines the role by its responsibilities, which include product quality, community health, lowering the barriers to contributing, and advocating for the community’s needs.

Contributors can grow into the role. The Trusted Committer pattern describes maintainers inviting frequent, engaged contributors to become trusted committers and listing them publicly in the project’s README. Mercado Libre, for example, adds a section to its CONTRIBUTING.md file that lists the project’s trusted committers.

Product owner

The product owner defines and prioritizes what the project builds, as in agile teams (Introducing the Trusted Committer Role). In InnerSource, the product owner works with trusted committers to decide whether a contributed feature belongs in the product. In small grassroots projects, the trusted committer often plays both roles.

For product managers, InnerSource changes both sides of a dependency. On a project you own, you and the trusted committers decide which outside contributions fit the roadmap. When another team’s backlog blocks your roadmap, you can send a contributor instead of filing a request and waiting.

How a contribution flows

The roles meet in a single loop. Coordination happens before code, so a contributor doesn’t spend a week on a change the host team would reject.

flowchart TB A[Contributor needs a change in another team's project] --> B[Open an issue and discuss the approach] B --> C{Product owner and trusted committer: does it fit the project?} C -- No --> D[Redirect to a different design or a separate project] C -- Yes --> E[Contributor writes the change and opens a pull request] E --> F[Trusted committer reviews and mentors] F -- Changes requested --> E F -- Approved --> G[Host team merges and maintains the code]

The Principles Behind It

The InnerSource Commons pattern Document your Guiding Principles lists six principles that organizations adapt to their own context:

  • Transparent hosting. Source code, documentation, and project data are available and easy to find for anyone in the organization.
  • Contributions over feature requests. Every stakeholder is a potential contributor. Contributions remain suggestions rather than requirements, and coordinating before writing code avoids wasted effort.
  • Mistakes as learning. When work is visible across the company, so are mistakes. The pattern calls for a culture that treats them as chances to learn rather than failures to avoid at all costs.
  • Written over verbal communication. Teams on different schedules collaborate asynchronously, and decisions are finalized in writing. The side effect is passive documentation for newcomers.
  • A searchable archive. Discussions and decisions are archived with stable URLs. People-related and security discussions are the exceptions and stay private.
  • Rewarded trusted committership. All contributions count, code or not, and people who keep supporting a project are invited to become trusted committers.

Bosch’s InnerSource program, BIOS, used a different list: openness, transparency, voluntariness, self-determination, and meritocracy (Document your Guiding Principles). The wording varies between companies. The pattern’s advice is to write yours down, so teams without open source experience know what they are signing up for.

How InnerSource Relates to Open Source

InnerSource borrows from open source but runs inside organizational limits. The code stays proprietary, the contributors are employees, and governance has to fit around reporting lines and budgets.

Open source is a public park. Anyone can walk in and propose a new trail, and the park’s stewards decide what gets built. InnerSource moves the park inside a fenced company campus. The stewards work the same way, but only employees get through the gate, and each visitor’s manager decides how many hours they can spend on trails.

The fence brings benefits. Teams inside one legal entity share proprietary code without an open source license review, and managers can allocate time to contributions because contributors are on the payroll. Companies made up of many legal entities often need an internal agreement first, which the InnerSource License pattern handles with one reusable license. It also brings costs: the pool of contributors is smaller, and a contributor’s manager can pull them onto other work halfway through a change.

An Open Source Program Office (OSPO) manages how a company uses and contributes to external open source. Because both teach the same practices, an existing OSPO is a natural ally for an InnerSource program.

Who Uses InnerSource

Danese Cooper and Klaas-Jan Stol’s book Adopting InnerSource (O’Reilly, 2018) collects case studies from five organizations:

  • Bell Laboratories, home to one of the earliest known InnerSource projects.
  • Robert Bosch, whose experimental BIOS program led to new products.
  • PayPal, where executives escalating feature requests kept blowing up planned sprint work. In PayPal’s first experiment, InnerSource cut the share of each sprint a team spent on escalation-driven interruptions from 65% to under 5% (Adopting InnerSource, chapter 5).
  • Europace, which shows adoption at a mid-sized German financial services company rather than a global giant.
  • Ericsson, which built a layered product without dedicated platform teams. Feature teams added what they needed to the shared platform layers, and a small unit called Community Developed Software coached them in open source practices. The authors report that the goal of preventing platform bottlenecks was achieved, though InnerSource didn’t suit every component (Adopting InnerSource, chapter 7).

The InnerSource Patterns catalog adds known instances from GitHub, Nike, Mercado Libre, Siemens, and Mercedes-Benz.

Trade-offs and Limitations

The benefits come from reuse and fewer escalations. An independent literature survey by Maximilian Capraro and Dirk Riehle analyzed 43 InnerSource publications. It models both the benefits and the challenges of adoption (Inner Source Definition, Benefits, and Challenges). The reported benefits include faster time to market, lower development costs, more successful reuse, and higher code quality. The authors, who abbreviate inner source as IS, add a caution: most of the literature they surveyed didn’t validate those benefits, so “IS benefits should be treated as observations, not as generally valid truth.” They also identify eight adoption challenges, starting with resistance to the significant change InnerSource demands.

Teams build on shared components instead of rebuilding them, and a codebase documented for outside contributors is documented for new hires too. Contributors also learn other teams’ code and meet engineers they wouldn’t otherwise work with (What Problems Does InnerSource Solve?).

The costs fall mostly on host teams:

  • Review time. Every outside pull request takes the host team’s time, often for a feature it didn’t prioritize.
  • Maintenance burden. Merged code becomes the host team’s to maintain. GitHub limits this burden with principles for cross-team work. Contributing teams support a feature through deployment and beyond, and they build it without adding tech debt, the shortcuts a host team would otherwise have to clean up later (Document your Guiding Principles).
  • Documentation upkeep. README and CONTRIBUTING files help only while they’re current.
  • Culture change. Teams used to owning everything privately need time and leadership support to work in the open.

InnerSource also fits some projects better than others. The Learning Path’s project fit guidance asks three questions:

  • Will contributions come? Signs include heavy usage, more feature requests than the team can fill, and users building workarounds.
  • Will the host team support them? Support means a CONTRIBUTING file, up-front guidance, and timely reviews.
  • Is the project company-specific? It should be specific to the company, or keeping it internal should give the company a strategic advantage. If neither is true, the guidance recommends open source to reach a larger pool of contributors.

Common Misconceptions

Can anyone commit to any codebase?

No. The host team controls what merges. Contributors propose changes, and trusted committers decide whether they land.

Does InnerSource replace team ownership?

No. Ownership stays where it was. InnerSource adds a contribution path next to it, and the host team still sets direction and makes architectural calls.

Is InnerSource just open source behind the firewall?

Not quite. Employment creates constraints that volunteer open source projects never face. A contributor’s manager has to approve the time, and the work has to count when reviews come around. The Trusted Committer pattern points out that trusted committer status can support a contributor’s annual review.

Is InnerSource a tool you install?

No. An internal Git host and a searchable project portal help, but they only make code visible. Without the principles above, a company with every repository open still has teams that never read each other’s code.

Conclusion

InnerSource gives a team a fourth option when it needs something from another team: write the change, propose it, and let the owners review it. Ownership stays put, while the code becomes visible and a trusted committer helps an outsider’s change land. AI makes a private copy faster to build, but every copy still needs patches and an owner. When a project passes the fit questions, extending the tool that already exists stays the cheaper choice for the company.

Next Steps

  • Read the InnerSource Learning Path section for the role you’d play: contributor, trusted committer, or product owner.
  • Browse the InnerSource Patterns catalog for solutions to adoption problems you expect, starting with the Trusted Committer pattern.
  • Pick one project your team owns that other teams depend on, and check whether its README and CONTRIBUTING file would let an outsider make a change.
  • Read What Is an OSPO? if your company already has an open source program office.

References