## Introduction Your team needs one small change to another team's library. You file a feature request. It lands in their backlog behind six months of their own priorities. So you fork the library, patch it, and move on. A year later the organization runs two copies of the same code, each with its own bugs, and nobody remembers why. I've worked in organizations where five teams built five versions of the same logging library. Nobody knew the other versions existed. Each team spent weeks solving problems that another team had solved months earlier. That waste is invisible on any budget line, which is exactly why it keeps happening. I serve on the InnerSource Commons board, so weigh my enthusiasm for its patterns with that in mind. **InnerSource** is the application of open source practices and principles to software development inside one organization, as the [InnerSource Commons learning path][isc-intro] defines it. Code stays private to the company. Inside the company, it works like an open source project: anyone can find it, read it, propose a change, and earn the trust to review other people's changes. This matters because silos are expensive. When teams can't see or change each other's code, the organization pays for the same work several times, blocked teams wait on queues they don't control, and knowledge leaves with whoever wrote the code. InnerSource gives a blocked team a third option between waiting and forking: contribute the change directly. **What this is (and isn't):** This article explains how InnerSource works, why its principles and roles produce reuse and collaboration, and how to tell whether a program is working. It omits vendor tooling comparisons, legal and accounting rules for cross-charging work between business units, and step-by-step setup of any specific platform. **Why InnerSource fundamentals matter:** * **Less duplicate work.** Teams reuse and extend shared code instead of rebuilding it in parallel. * **Fewer blocked teams.** A team that needs a change can make it, instead of waiting in another team's backlog. * **Faster onboarding.** Open code, written discussions, and contribution guides teach new engineers how systems work without a guided tour. * **Better code and broader skills.** Review from outside the host team catches problems, and contributors learn systems they would never otherwise touch. This article outlines a basic workflow most InnerSource projects follow: 1. **Open**: make the code readable to every engineer in the company, and document how to contribute. 2. **Find**: make the project discoverable, so a team with a need can locate it. 3. **Contribute**: write the change in the team that needs it, and submit it. 4. **Review and mentor**: have trusted committers review the change and teach the contributor. 5. **Recognize and measure**: credit the people who did the work and track reuse, so leadership keeps funding it. > Type: **Explanation** (understanding-oriented). > Primary audience: **beginner to intermediate** engineers, tech leads, and engineering managers who want teams to share code instead of duplicating it. ### Prerequisites & Audience **Prerequisites:** You know how a pull request and code review work, and you've worked in an organization with more than one development team. Familiarity with open source helps; [Fundamentals of Open Source][open-source] covers the practices InnerSource borrows. **Primary audience:** Engineers who keep getting blocked by other teams, tech leads who own code other teams depend on, and managers or program leads deciding whether to start an InnerSource program. **Jump to:** * [What InnerSource Is][jump-s1] • [The Four Principles][jump-s2] • [Roles and the Trusted Committer][jump-s3]. * [Patterns][jump-s4] • [Running a Program][jump-s5] • [Measuring InnerSource][jump-s6]. * [Common Mistakes][jump-s7] • [Common Misconceptions][jump-s8] • [When Not to Use InnerSource][jump-s9]. * [Laws, Bias, and Fallacies][jump-laws] • [Future Trends][jump-trends] • [Glossary][jump-glossary]. If InnerSource is new to you, read from top to bottom. If you own a project and want contributions, start with [Roles and the Trusted Committer][jump-s3]. **Escape routes:** If you need to convince leadership, read [Measuring InnerSource][jump-s6], then [Common Mistakes][jump-s7]. If you're deciding whether InnerSource fits at all, skip to [When Not to Use InnerSource][jump-s9]. [jump-s1]: #section-1-what-innersource-is [jump-s2]: #section-2-the-four-principles [jump-s3]: #section-3-roles-and-the-trusted-committer [jump-s4]: #section-4-patterns-that-make-it-work [jump-s5]: #section-5-running-an-innersource-program [jump-s6]: #section-6-measuring-innersource [jump-s7]: #section-7-common-innersource-mistakes [jump-s8]: #section-8-common-misconceptions [jump-s9]: #section-9-when-not-to-use-innersource [jump-laws]: #laws-bias-and-fallacies [jump-trends]: #future-trends [jump-glossary]: #glossary ### TL;DR – InnerSource Fundamentals in One Pass If you only remember one workflow, make it this: * **Open by default** so any engineer can find the code and understand how to change it. * **Make it findable** so a team with a need can locate the project through a portal or search. * **Prefer contributions over feature requests** so a blocked team writes the fix instead of waiting in a queue. * **Let trusted committers mentor** so outside changes meet the host team's standards without burning out the host team. * **Measure reuse** so leadership sees the effort the program saved, with pull request counts kept as a health check. **The InnerSource workflow:** ```mermaid graph TB N[A team needs a change in another team's code] --> F[Find the project through a portal or search] F --> R[Read the README and CONTRIBUTING guide] R --> I[Discuss the change in an issue] I --> P[Submit a pull request] P --> T[Trusted committer reviews and mentors] T --> M[Merge, with the contributor backing the fix] M --> X[Reuse is recorded and the contributor gets credit] style N fill:#fff3e0 style F fill:#e1f5fe style R fill:#e1f5fe style I fill:#f3e5f5 style P fill:#f3e5f5 style T fill:#e8f5e8 style M fill:#e8f5e8 style X fill:#fce4ec ``` ### Learning Outcomes By the end of this article, you will be able to: * Explain **why** InnerSource reduces duplicate work, and how it differs from both open source and ordinary internal code sharing. * Describe **why** each of the four InnerSource principles is necessary, and what breaks when one is missing. * Explain **why** the trusted committer role makes contributions sustainable for the host team. * Choose **which** InnerSource patterns solve common problems such as untrusted contributions and undiscoverable projects. * Describe **how** to measure an InnerSource program so the numbers reflect value rather than activity. * Decide **when** InnerSource is the wrong tool and a simpler arrangement will serve better. ## Section 1: What InnerSource Is InnerSource takes the working habits of open source projects and applies them inside one company's walls. Those habits include public code, written discussion, pull requests from strangers, and review by maintainers. Tim O'Reilly used the phrase in December 2000. Describing work at CollabNet, he wrote that they had helped companies with "what we call 'inner sourcing'--that is, helping them to use open source development techniques within the corporation," in his [Ask Tim column on open source and OpenGL][oreilly-2000]. The practice spread through large companies over the next fifteen years, and [Capraro and Riehle's 2016 survey][capraro-riehle] reviews the research on those adoptions. Danese Cooper founded the InnerSource Commons in 2015 as part of bootstrapping InnerSource at PayPal, according to [Adopting InnerSource][isc-adopting]. The community now counts more than 3,000 people from over 800 organizations, according to the [InnerSource Commons home page][isc-home]. Open source works like a public park: anyone can visit and offer to plant a tree or fix a trail, and the park's caretakers decide what goes in. InnerSource is a shared garden inside a gated community. The residents (guest contributors) collaborate on it, the gardeners (the host team) still decide what gets planted, and the fence stays up. ### Who Owns What **The host team owns the project.** InnerSource does not dissolve ownership. The team that owns a library or service still sets its direction, keeps it running, and decides which changes to accept. **Guest contributors change it.** An engineer from another team who needs something writes the change and submits it, the same way an outside contributor sends a pull request to an open source project. **The code is visible across the company.** Any engineer can read the repository, its issues, its roadmap, and the reasoning behind past decisions. Visibility is what lets a contributor work without a meeting. ### Why This Works The core problem InnerSource solves is the dependency queue. When team A needs a change in team B's code, team A traditionally has two choices: file a feature request and wait, or copy the code and diverge. Both are bad. Feature requests pile up behind team B's own priorities, forks drift apart, and the organization pays for the same work twice without noticing. InnerSource adds a third choice: team A writes the change, and team B reviews it. Team B's capacity stops being the bottleneck for everyone who depends on it, because the people who need the change supply the labor. Team B keeps control through review, and team A learns how team B's system works along the way. ### How InnerSource Differs from Open Source The mechanics differ because a company differs from a volunteer community. Corporate hierarchies, budgets, performance reviews, and employment contracts create constraints that open source projects never face. A contributor's manager can say no. A host team's quarterly goals may not include reviewing other teams' work. Nobody gets famous on the public internet for an internal merge. Those constraints explain why InnerSource needs things open source rarely bothers with: explicit permission to spend time on other teams' code, recognition that counts in performance reviews, and metrics that justify the program to finance. [Fundamentals of Open Source][open-source] covers the public side of these practices, including licensing, which mostly drops out of InnerSource because the code never leaves the company. InnerSource also differs from ordinary internal code sharing. Most companies run a forge, a shared code host such as GitHub Enterprise or GitLab, and ordinary sharing puts a repository there and stops. Read access lets another team copy the code, but it gives them no way to change the original. InnerSource adds what makes a change possible: a contribution guide, a host team that commits to review, trusted committers who mentor, and managers who count that work. Section 7 shows what happens when a company stops at the shared forge. ### Trade-offs and Limitations InnerSource has costs. Writing and maintaining contribution guidelines takes effort. Reviewing outside contributions takes time the host team could spend on its own roadmap. Building a culture of openness in a company used to silos takes patience and visible support from leadership. The payoff compounds slowly. Early contributions trickle in. As trust builds and the process matures, the trickle becomes a steady stream, but only if someone keeps the program alive through the slow start. Section 7 describes a company that gave up after a year. ## Section 2: The Four Principles The InnerSource Commons names four principles as "the bedrock of any successful instance of InnerSource" on its [InnerSource Principles][isc-principles] page: openness, transparency, prioritized mentorship, and voluntary code contribution. Each one removes a specific barrier between a team with a need and the code that could meet it. ### Openness An open project is easy to find and easy to start contributing to. The InnerSource Commons says projects "should be discoverable and well-documented through README.md and CONTRIBUTING.md files within the root of the repo," and that anyone in the organization should be able to ramp up "without an inordinate amount of direct guidance from host team members." Openness works because every barrier filters out contributors. A repository that requires an access request, a meeting, and tribal knowledge loses most of the people who would have fixed something small. A repository with a clear README and contribution guide converts curiosity into pull requests. ### Transparency Guest contributors need to understand where a project is going before they can help. Transparency means a contributor can see the project's direction, its outstanding requirements, the progress on those requirements, and how the host team makes decisions. Without transparency, a guest team writes a change that conflicts with a redesign it never heard about, and the host team rejects it. Both sides lose a week and some goodwill. Written roadmaps and public decision records prevent that collision, which makes technical writing a core skill for a host team; [Fundamentals of Technical Writing][technical-writing] covers it. ### Prioritized Mentorship Trusted committers carry mentorship from the host team to guest contributors. In the InnerSource Commons' words, that mentorship has to happen "at the time that the contributor needs it as opposed to when it's convenient to the host team." Mentorship takes host-team time away from its own roadmap, which makes it the easiest principle to let slide. A contributor who waits two weeks for a review learns that contributing is slower than forking, and doesn't come back. Treating mentorship as real work, scheduled and credited, keeps the contribution path faster than the alternatives. ### Voluntary Code Contribution Both sides participate by choice. "Never is a host team required to accept a contribution that isn't in ultimate alignment with their overall mission," the principles page says, and no guest team has to contribute against its own priorities. The word *code* matters too: filing issues and fixing docs help, but the benefits come when collaboration reaches the code itself. Voluntary participation works because forced collaboration produces resentful reviews and abandoned contributions. When both teams opt in, each has checked that the work serves its own goals, so the collaboration survives the next reorganization. ### Why Principles Differ Between Sources You'll find other lists. The [Document your Guiding Principles][pattern-principles] pattern lists six guidelines, including "Contributions over feature requests" and "Mistakes are opportunities for learning," and a Bosch example on the same page lists five of its own. The variation is deliberate. That pattern says each organization should write down its own purpose and principles, because the slogan "applying open source best practices" means little to engineers who have never worked in open source. Start from the four, then write the version your company will actually follow. ### Quick Check: The Four Principles Before moving on, test your understanding: * What happens to contributions when a project is visible but has no README or contribution guide? * Why does a guest team need to see the host team's roadmap before writing a change? * Why can't a host team be required to accept a contribution? **Answer guidance:** **Ideal result:** You can explain three things. Every barrier filters out contributors. A change written without the roadmap risks colliding with a redesign and getting rejected. Forced acceptance produces resentful reviews and abandoned code. If an answer feels fuzzy, reread the subsection for that principle. ## Section 3: Roles and the Trusted Committer InnerSource works through a few roles, and the InnerSource Commons [learning path][isc-learning-path] offers free training for most of them. ### The Four Roles **Contributor.** The engineer who changes code they don't own. A good contributor discusses the change before writing it, follows the project's guide, and stays around to fix what breaks. **Trusted committer.** A recognized member of the project's community who reviews contributions, mentors contributors, and advocates for the project. The InnerSource Commons describes the role as "one of the key roles in an InnerSource community" in its [trusted committer learning path][isc-tc-path]. **Product owner.** The person who sets the project's direction. In InnerSource, that includes deciding which outside contributions fit the project's mission. **Maintainer.** The host team members with final responsibility for the code. The [Trusted Committer pattern][pattern-tc] keeps the two roles separate and says that more involvement in the project gives trusted committers "a path to Maintainer if they so desire." ### Why the Trusted Committer Matters The trusted committer is the role that makes InnerSource work. A host team that reviews every outside contribution itself runs out of time, and contributions stall. Trusted committers spread that load to people who already know the code, often frequent contributors from other teams. The [Trusted Committer pattern][pattern-tc] was first published internally at Nike and drafted as a pull request in June 2018, according to the pattern's status notes. It describes the full lifecycle: spot frequent contributors, invite them to the role, recognize them publicly, check in weekly at first and then every few weeks, and thank them publicly when they step down. The role also builds people. A trusted committer relationship works like an apprenticeship: a maintainer reviews, explains, and grants more responsibility as judgment develops. I made the case in [How Is AI Impacting Software Engineering?][ai-impact] that it builds technical leadership experience that typically takes a decade to gain. [Fundamentals of Technical Leadership][technical-leadership] covers the rest of that growth. ### Where the Roles Are Written Down Most of the roles show up in two files at the root of the repository. The pattern recommends listing trusted committers in the README. A minimal version looks like this: ```markdown # payments-client A shared client library for the internal payments API. ## Project Leaders ### Maintainers - Payments Platform team ### Trusted Committers - Priya N. (Checkout team) - Marcus L. (Subscriptions team) ``` The contribution guide tells a guest contributor what to expect before they write a line of code: ```markdown # Contributing to payments-client 1. Open an issue describing the change before starting work. 2. A trusted committer replies within two business days. 3. Include tests for any behavior you change. 4. Your team fixes bugs in your contribution for 30 days after release. Ask questions in #payments-client. ``` These files matter because they replace meetings. A contributor who can read who reviews, how fast, and under what rules can start alone. Each promise in the guide, such as a two-day response time, is a commitment the host team has to keep, so promise only what you can staff. ### What the Trusted Committer Role Costs The trusted committer role costs time, and someone has to pay for it. If the role is unfunded volunteer work on top of a full workload, trusted committers burn out and review times climb. Bosch, listed as a known instance in the pattern, funded people in this role for 100% of their time early in its program, though it didn't use the trusted committer title. You don't need that level of funding to start, but the role needs protected time, sized to how many teams depend on the project. ### Quick Check: Roles Before moving on, test your understanding: * Why does a host team that reviews every contribution itself eventually stop getting contributions? * What is the difference between a trusted committer and a maintainer? * What happens when a host team misses the response time its contribution guide promises? **Answer guidance:** **Ideal result:** You can explain three things. Review capacity is the bottleneck trusted committers relieve. The trusted committer role carries recognition and responsibility short of final ownership, which stays with the maintainer. A missed response-time promise teaches contributors that forking is faster. If any answer is unclear, reread the Why the Trusted Committer Matters subsection. ## Section 4: Patterns That Make It Work InnerSource practitioners document recurring problems and their solutions as patterns. The InnerSource Commons publishes them in the free [InnerSource Patterns book][patterns-book], which contains 26 patterns. Each pattern names a problem, the forces behind it, a solution, and companies where it worked. Patterns are useful because the same problems show up in almost every program. You don't need to invent a fix for distrust of outside contributions; someone at another company already tested one. ### Patterns Worth Knowing First * **[Standard Base Documentation][pattern-base-docs].** Every project ships a README, a CONTRIBUTING guide, and a COMMUNICATION file in a consistent shape, so a contributor who learned one project can navigate the next. * **[30 Day Warranty][pattern-warranty].** The contributing team agrees to fix bugs in its contribution for a period after it reaches production. Host teams hesitate to accept code they'll have to support; the warranty moves that risk back to the team that wrote it. * **[InnerSource Portal][pattern-portal].** An internal catalog, usually built from repository metadata, where engineers search for projects that accept contributions. It solves discoverability, the first barrier in the workflow. * **[Service vs. Library][pattern-service-library].** Teams that run their own services hesitate to share one, because nobody wants to answer pages for another team's customers. This pattern shares the business logic as a library with shared ownership, and each team runs its own deployment. The pattern's alias is "It's inner source, not inner deployment." * **[Start as an Experiment][pattern-experiment].** Launch InnerSource as a time-boxed experiment with agreed success criteria. An experiment is easier for skeptical managers to approve than a permanent program, and it produces evidence either way. * **[Dedicated Community Leader][pattern-community-leader].** Give the first InnerSource community a leader with both technical and communication skills, and give that person enough time to do the job. * **[Contracted Contributor][pattern-contracted].** Formalize contribution time through an agreement between the contributor, their line manager, and a central InnerSource office, so the work stops depending on a manager's goodwill each sprint. ### Why Patterns Beat Mandates A mandate tells teams to collaborate. A pattern tells them how, under named conditions, with a known cost. A host team that adopts the 30 Day Warranty has a concrete reason to accept a contribution it would otherwise reject, and the contributing team takes on a concrete obligation. ## Section 5: Running an InnerSource Program A single open repository is an InnerSource project. Many projects, plus training, tooling, recognition, and metrics, make a program. Programs need someone to run them, and they need management support that survives the first budget review. ### The InnerSource Program Office Many companies create an InnerSource Program Office (ISPO), a central group that supports adoption. An ISPO typically runs training, maintains the portal, helps projects write contribution guides, and collects metrics. Its job is to make collaboration easier; teams still choose whether to take part. If your company already runs an Open Source Program Office (OSPO), that team is a natural ally. It already understands contribution workflows, community health, and the culture change open source requires. [A List of OSPO Resources][ospo-resources] collects guides and communities for both kinds of office. ### Why Middle Management Decides the Outcome Executives sponsor InnerSource and engineers do the work, but middle managers control the time. If every engineer's capacity is already planned at 100% against team goals, nobody has an hour for another team's project, however much the chief technology officer likes the idea. Programs succeed when managers count contribution and review as real work in planning and in performance reviews. The InnerSource Commons [maturity model][pattern-maturity] captures this in its culture scale. The scale starts at silos, where teams work in isolation, and moves through reactive and contributive stages. It ends at activist, where teams "actively seek help, mentor and recruit new contributors." Moving up that scale takes management support. The [Dedicated Community Leader][pattern-community-leader] pattern describes a company where top-level management sponsored InnerSource but middle management was "not yet sold on InnerSource," and that company abandoned its pilot. ### Why Culture Comes Before Tools The maturity model lists a belief that holds teams back: they think "it's all about migrating to a shared software development forge" such as GitHub or GitLab. A shared forge is necessary, since nobody can contribute to code they can't see, but it isn't sufficient. InnerSource also requires a culture where visible mistakes drive improvement instead of blame. Because host-team mistakes are widely visible, the maturity model says culture needs to "celebrate failure as an opportunity for growth and learning." Without that safety, transparency becomes a liability, and people stop showing their work. ## Section 6: Measuring InnerSource Leadership funds what it can see. A program that can't show value gets cut in the next budget cycle, no matter how much engineers like it. ### What to Measure The [InnerSource Value Metrics white paper][finos-metrics] comes from FINOS (the Fintech Open Source Foundation) and the InnerSource Commons. It proposes a framework built on four kinds of value: cost savings from reuse, faster time-to-market, reduced maintenance effort, and shared contributions across teams. The paper focuses on financial services but applies to any large company with many teams. Reuse is the anchor. If five teams use one shared component instead of each building their own, the organization built it once and avoided four builds. The white paper estimates that value from three inputs: how many teams adopted the component, roughly what it would have cost each to build from scratch, and what adoption cost them instead. Dependency manifests and software bills of materials give you the first input without a survey. ### Activity Versus Value Counting pull requests, contributors, and stars is easy, and these counts tell you whether the community is alive. They don't tell you whether the company saved anything. A program that reports only activity invites the question every finance partner eventually asks: so what? Pair activity metrics with value metrics in every report to leadership. [Fundamentals of Metrics][metrics] covers the broader discipline of choosing measures that drive good decisions. The maturity model treats monitoring policies as a governance area. At the top level, the organization provides guidelines, training, and shared infrastructure for measuring both the whole program and individual projects, so each team doesn't invent its own numbers. ### Quick Check: Measuring InnerSource Before moving on, test your understanding: * Why does a program that reports only contributor counts struggle in a budget review? * What three inputs estimate the value of a shared component? * Where can you find adoption data without running a survey? **Answer guidance:** **Ideal result:** You can explain three things. Activity shows health but not savings. Value comes from the number of adoptions, the cost each team would have paid to build from scratch, and the cost of adopting instead. Dependency manifests and software bills of materials show who adopted what. If an answer is unclear, reread What to Measure. ## Section 7: Common InnerSource Mistakes These mistakes stall programs that started with real enthusiasm. Most trace back to treating InnerSource as a tool rollout instead of a change in how teams work together. ### Treating InnerSource as a Tooling Migration The mistake: moving every repository to a shared forge, announcing that code is now "InnerSource," and waiting for contributions. Nothing changes, because nothing about review capacity, recognition, or management support changed. **Incorrect:** "All repos are on GitHub Enterprise now, so teams can contribute to each other's code." **Correct:** "Three pilot projects have contribution guides, named trusted committers, and a two-day review promise. Managers have budgeted time for review." ### Under-Investing in the Community Leader The [Dedicated Community Leader][pattern-community-leader] pattern tells a cautionary story about a company that put a new hire in charge of its first InnerSource community at 50% of his time. After six months, contributions were thin, so it replaced him with a longer-tenured employee at 30% of his time. Six months later, the company concluded that InnerSource didn't work and abandoned it. A part-time leader answers questions and reviews contributions in the gaps between other work, so early contributors wait, and the pilot never builds momentum. The program never got a fair test. **Incorrect:** "Whoever has spare capacity can lead the community part-time." **Correct:** "The community leader has open source experience, the technical and communication skills to lead, and a wide internal network, and community work is the whole job, as the pattern recommends." ### Accepting Contributions Without Support A host team that merges outside code and then owns every bug in it learns to reject contributions. Pair acceptance with a warranty period and tests, so the contributing team backs its change while the host team learns the code. ### Mandating Contribution Forcing teams to contribute, or forcing host teams to accept, breaks the voluntary principle. Mandated contributions arrive half-finished, mandated reviews become rubber stamps, and both sides resent the program. Make contribution the fastest path to what a team already wants, and it happens without a mandate. ### Measuring Only Activity Reporting contributor counts to leadership works until someone asks what the company got for it. Record which teams already depend on each pilot project before launch, then track adoption and avoided effort from there, so the first hard budget question has a before-and-after answer. ### Quick Check: Common Mistakes Test your understanding: * Why does moving code to a shared forge fail to produce contributions on its own? * Why does a part-time community leader often doom a pilot? * What does a warranty period change for the host team? **Answer guidance:** **Ideal result:** You can explain three things. Visibility is necessary, but contributions depend on review capacity, recognition, and management support. A thinly staffed leader can't respond fast enough to build momentum. A warranty shifts support risk back to the contributing team. If any answer is fuzzy, revisit Sections 3 through 5. ## Section 8: Common Misconceptions * **"InnerSource means anyone can change anything."** Anyone can propose a change. The host team reviews every change and decides what to merge, the same way open source maintainers do. * **"We'll lose ownership of our code."** Team ownership remains intact. The host team sets direction and approves changes, and a warranty period keeps the contributing team responsible for bugs in its own change, so accepting outside code doesn't mean inheriting it. * **"InnerSource is only for huge companies."** The patterns scale down. Any organization with more than one development team, and code that more than one team depends on, can use them. * **"InnerSource is just open source inside the firewall."** The practices carry over; the incentives don't. Section 1 explains why that gap means InnerSource needs explicit time allocation and recognition that open source never asks for. * **"The InnerSource Commons will run our program for us."** The InnerSource Commons is a community that shares patterns, research, and support. Your company still has to establish and run its own program, with its own leaders and metrics. ## Section 9: When Not to Use InnerSource InnerSource sometimes costs more than it returns. Skipping it where it doesn't fit frees effort for the projects where it pays. **Only one team uses the code.** With no second consumer, there is nobody to contribute and nothing to reuse. Keep good docs and move on. **The code is a throwaway prototype.** Contribution guides and review promises cost more than they return for code that will be deleted next month. Wait until something stabilizes and gains a second user. **Access must stay need-to-know.** Some code, such as security controls, regulated data handling, or unannounced products, can't be visible to the whole company. Share interfaces and documentation instead of source, or limit the community to people with clearance. **The host team can't staff review.** Advertising a project as open to contributions without anyone to review them is worse than staying closed, because it teaches contributors that InnerSource doesn't work. Fund review first, then open up. **The organization punishes visible mistakes.** If showing unfinished work gets people blamed, transparency will backfire. Work on that culture first, or start with a small group that already trusts each other. Even when full InnerSource doesn't fit, a minimal version usually helps: put code where other teams can read it, write a README that explains what it does, and name a contact. Discoverability alone prevents some of the duplicate builds. ## Laws, Bias, and Fallacies How people reason about sharing code shapes InnerSource outcomes as much as any tool or pattern does. ### Laws and Named Principles * **Conway's Law.** Melvin Conway argued in [How Do Committees Invent?][conway] that organizations "produce designs which are copies of the communication structures of these organizations." How it shows up: siloed teams build siloed, duplicated systems. InnerSource bends the law deliberately, because contributions across teams create communication paths the org chart lacks. * **Linus's Law.** Eric Raymond's phrasing in [The Cathedral and the Bazaar][linus-law] is "Given enough eyeballs, all bugs are shallow." How it shows up: a shared library reviewed and used by five teams surfaces bugs faster than five private copies reviewed by one team each. The eyeballs only help when people actually read the shared code, which is why review capacity matters. * **Goodhart's Law.** People optimize a number once it becomes a target, and it stops measuring what you cared about; [Fundamentals of Metrics][metrics] covers the law in depth. How it shows up: set a quota for cross-team pull requests and you'll get trivial pull requests. Measure reuse and avoided effort instead of raw activity. ### Bias * **Not Invented Here.** Teams distrust code they didn't write and rebuild it. What goes wrong: a team spends a quarter writing its own authentication client because the shared one "probably doesn't fit." What to do instead: read the shared code and its issues first, and propose the missing piece as a contribution. * **Sunk-cost bias.** Teams keep maintaining their fork because they already invested in it. What goes wrong: two diverged copies keep accumulating separate bug fixes for years. What to do instead: compare the future cost of maintaining the fork with the one-time cost of merging back. * **Status quo bias.** Managers default to the familiar dependency queue even when it fails. What goes wrong: a team waits two quarters for a feature it could have written in a week. What to do instead: run one time-boxed experiment and compare the results. ### Fallacies * **False dilemma.** "Either we wait for their backlog or we fork." Scenario: a blocked team never considers writing the change and submitting it, which is the option InnerSource exists to create. * **Appeal to authority.** "PayPal and Bosch did it, so it will work here." Scenario: a company copies another company's program without that company's funding, culture, or leadership support, and blames InnerSource when it stalls. * **Slippery slope.** "If outsiders can submit code, we'll lose control of our service." Scenario: a host team refuses all contributions, although review, a warranty, and the right to say no keep control exactly where it was. * **Nirvana fallacy.** "We'll start InnerSource once we have the perfect program design." Scenario: a company spends a year on governance documents while teams keep duplicating work. One project with a contribution guide would have taught more. ## Building an InnerSource Practice That Lasts ### What to Remember * **InnerSource adds a third option.** A blocked team can contribute the change instead of waiting or forking. * **Four principles carry the practice.** Openness, transparency, prioritized mentorship, and voluntary code contribution each remove a specific barrier. * **Trusted committers make it sustainable.** Spreading review and mentorship beyond the host team keeps contributions flowing. * **Patterns solve known problems.** Warranties, portals, and base documentation address distrust and discoverability with tested solutions. * **Measure value.** Reuse and avoided effort keep leadership funding the program, while activity counts only show that the community is alive. ### How These Concepts Connect Openness lets a team find the code, and transparency tells them where it's going. Mentorship from trusted committers turns their first contribution into an accepted one, and voluntary participation means both teams wanted the result. Patterns fill the gaps that principles leave, such as who supports a contribution after it ships. Measurement closes the loop by showing leadership what all of it saved, which keeps the time and funding available for the next contribution. ### Getting Started with InnerSource If you're new to InnerSource, start with a narrow, repeatable workflow: 1. **Pick one project** that at least two other teams already depend on. 2. **Write a README and a CONTRIBUTING guide** that state who reviews, how fast, and under what rules. 3. **Name one or two trusted committers** and list them in the README. 4. **Accept your first external pull request**, and back it with a short warranty. 5. **Record who adopted the project** and roughly what each team avoided building. Once this feels routine, apply the same workflow to the next most-depended-on project. ### Self-Assessment – Can You Explain These in Your Own Words? Before moving on, see if you can explain these concepts in your own words: * Why InnerSource reduces duplicate work, and why a shared forge alone doesn't. * What each of the four principles prevents. * Why the trusted committer role matters to the host team. * How to measure a program so the numbers survive a budget review. * When InnerSource costs more than it returns, and what minimal version to use instead. ## Future Trends InnerSource practices change slowly, but a few shifts are worth watching. ### AI Makes Duplication Cheaper AI coding assistants make it fast to build a new internal tool instead of finding an existing one. Business Insider reported on an internal Amazon document that said, "AI is making our tool duplication problem worse," and "More duplication is being created faster, and less of it is being cleaned up," in its [April 2026 article on AI sprawl at Amazon][bi-amazon]. An Amazon spokesperson said the document reflected one team's view. **What this means:** The cost of duplication used to limit it. When building a copy takes an afternoon, discoverability and reuse become the main defense against a sprawl of near-identical tools. **How to prepare:** Make shared projects easy for both people and assistants to find, and review AI-generated tools against what already exists before they ship. I covered the broader shift in [How Is AI Impacting Software Engineering?][ai-impact]. ### Platform Support for InnerSource Code platforms are adding InnerSource-specific features. In July 2026, GitHub made [innersource security advisories][gh-advisories] generally available. They let GitHub Advanced Security enterprise customers publish internal vulnerability notices and use Dependabot to alert and update every internal repository that uses an affected component. **What this means:** Shared internal components can get the same security response as open source dependencies, which removes one argument for keeping private copies. **How to prepare:** Treat your most-reused internal components like published packages, with versions, release notes, and a way to tell consumers about problems. ## Limitations and When to Get Help These fundamentals cover how InnerSource works and how to start. Some situations go beyond them. **Cross-charging and funding.** Paying for contributor time across business units, or reimbursing teams that contribute, involves finance and sometimes legal or tax questions. Bring in finance partners early. **Large, regulated programs.** Companies in finance, healthcare, or defense have access and audit rules that shape what can be shared. Your security and compliance teams need to help design the program. **Scaling past a few projects.** Running a program across hundreds of projects needs dedicated staff, tooling, and metrics infrastructure. The InnerSource Commons community, its [research reports][isc-research], and its patterns are a good place to learn from companies that have done it. When you bring in help, share your goals and the problems you've seen in your own words. Ask for patterns with known instances similar to your company, and keep the first change small enough to measure. ## Glossary ## References ### Related Articles **Open collaboration:** [Fundamentals of Open Source][open-source] covers the public practices InnerSource borrows. [A List of OSPO Resources][ospo-resources] collects guides for the program offices that often launch InnerSource. **People and measurement:** [Fundamentals of Technical Leadership][technical-leadership] covers the growth the trusted committer role starts. [Fundamentals of Metrics][metrics] explains how to choose measures that drive decisions. [Fundamentals of Technical Writing][technical-writing] helps with the READMEs and contribution guides that carry most of the load. **Systems and teams:** [Fundamentals of Software Architecture][software-architecture] covers system structure, the half of Conway's Law that mirrors the org chart; InnerSource works on the other half by changing how teams communicate. [How Is AI Impacting Software Engineering?][ai-impact] connects InnerSource to the review and duplication problems AI amplifies. ### Foundational Sources * O'Reilly, T. (2000). [Open Source and OpenGL][oreilly-2000], the Ask Tim column that used "inner sourcing" to describe open source techniques inside a corporation. * Conway, M. E. (1968). [How Do Committees Invent?][conway], the paper behind Conway's Law. * Raymond, E. S. (2000). [The Cathedral and the Bazaar: Release Early, Release Often][linus-law], version 3.0, the source of Linus's Law. * Stol, K., and Fitzgerald, B. (2015). [Inner Source: Adopting Open Source Development Practices within Organizations: A Tutorial][stol-fitzgerald], *IEEE Software* 32(4). * Capraro, M., and Riehle, D. (2016). [Inner Source Definition, Benefits, and Challenges][capraro-riehle], *ACM Computing Surveys* 49(4). ### InnerSource Commons Resources * [InnerSource Learning Path][isc-learning-path], free training for contributors, trusted committers, product owners, and project leaders. * [InnerSource Principles][isc-principles], the four principles quoted in this article. * [InnerSource Patterns][patterns-book], the free book of patterns with known instances. * [Getting Started with InnerSource][book-getting-started] by Andy Oram (O'Reilly, 2015), a short free introduction. * [Adopting InnerSource: Principles and Case Studies][isc-adopting] by Danese Cooper and Klaas-Jan Stol (O'Reilly, 2018), case studies from PayPal, Bosch, and others. * [State of InnerSource research][isc-research], survey reports from 2016 through 2025. ### Measurement and Tools * [InnerSource Value Metrics white paper][finos-metrics], FINOS and the InnerSource Commons on quantifying reuse and time-to-market. * [Managing InnerSource Projects][managing-innersource], a framework for governance, infrastructure, culture, funding, and measurement. * [Innersource security advisories][gh-advisories], GitHub's July 2026 changelog entry. **Note on verification:** InnerSource patterns, metrics frameworks, and platform features keep evolving. Check the InnerSource Commons pages for the current version of any pattern before you adopt it. [isc-intro]: https://innersourcecommons.org/learn/learning-path/introduction/ [isc-principles]: https://innersourcecommons.org/learn/learning-path/introduction/05/ [isc-learning-path]: https://innersourcecommons.org/learn/learning-path/ [isc-tc-path]: https://innersourcecommons.org/learn/learning-path/trusted-committer/ [isc-home]: https://innersourcecommons.org/ [isc-adopting]: https://innersourcecommons.org/learn/books/adopting-innersource-principles-and-case-studies/ [isc-research]: https://innersourcecommons.org/learn/research/ [book-getting-started]: https://innersourcecommons.org/learn/books/getting-started-with-innersource/ [oreilly-2000]: https://web.archive.org/web/2015/http://archive.oreilly.com/pub/a/oreilly/ask_tim/2000/opengl_1200.html [patterns-book]: https://patterns.innersourcecommons.org/ [pattern-principles]: https://patterns.innersourcecommons.org/p/document-your-guiding-principles [pattern-tc]: https://patterns.innersourcecommons.org/p/trusted-committer [pattern-base-docs]: https://patterns.innersourcecommons.org/p/base-documentation [pattern-warranty]: https://patterns.innersourcecommons.org/p/30-day-warranty [pattern-portal]: https://patterns.innersourcecommons.org/p/innersource-portal [pattern-service-library]: https://patterns.innersourcecommons.org/p/service-vs-library [pattern-experiment]: https://patterns.innersourcecommons.org/p/start-as-experiment [pattern-community-leader]: https://patterns.innersourcecommons.org/p/dedicated-community-leader [pattern-contracted]: https://patterns.innersourcecommons.org/p/contracted-contributor [pattern-maturity]: https://patterns.innersourcecommons.org/p/maturity-model [finos-metrics]: https://www.finos.org/innersource-value-metrics-white-paper [managing-innersource]: https://innersourcecommons.gitbook.io/managing-innersource-projects/introduction/framework [gh-advisories]: https://github.blog/changelog/2026-07-08-innersource-security-advisories-are-generally-available/ [bi-amazon]: https://www.businessinsider.com/ai-sprawl-amazon-tool-duplication-data-risk-2026-4 [conway]: http://www.melconway.com/Home/Committees_Paper.html [linus-law]: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html [stol-fitzgerald]: https://doi.org/10.1109/MS.2014.77 [capraro-riehle]: https://doi.org/10.1145/2856821 [open-source]: https://jeffbailey.us/blog/2025/03/06/fundamentals-of-open-source/ [ospo-resources]: https://jeffbailey.us/blog/2026/01/31/a-list-of-ospo-resources/ [technical-leadership]: https://jeffbailey.us/blog/2026/04/26/fundamentals-of-technical-leadership/ [metrics]: https://jeffbailey.us/blog/2025/11/09/fundamentals-of-metrics/ [technical-writing]: https://jeffbailey.us/blog/2025/10/12/fundamentals-of-technical-writing/ [software-architecture]: https://jeffbailey.us/blog/2025/10/19/fundamentals-of-software-architecture/ [ai-impact]: https://jeffbailey.us/blog/2026/05/27/how-is-ai-impacting-software-engineering/