Introduction: Breaking Down Silos

The Problem with Walled Gardens

Imagine a large company where every department has its own filing cabinet, locked with a different key. The legal team has a template for vendor contracts. The sales team needs the same template, doesn't know it exists, and pays a lawyer to draft a new one from scratch. The company now has two contract templates to maintain, and the legal team's work went unrecognized.

This is exactly what happens with software inside large organizations. Teams build in isolation, duplicate effort, and block each other's progress — not out of malice, but because the systems and culture don't encourage sharing.

The Open Source Contrast

Some of the most reliable, widely-used software in the world — Linux, Kubernetes, Python, PostgreSQL — was built by thousands of strangers collaborating across the globe. These projects share a set of properties that make them work:

• Transparency: Anyone can read the code, the issue tracker, and the design discussions.
• Meritocracy: Good contributions get merged regardless of who submitted them.
• Shared ownership: Many people feel responsible for the project's health.
• Low friction contribution: Clear documentation and processes let newcomers contribute quickly.

The result is software that evolves rapidly, catches bugs early (many eyes on the code), and avoids duplication of effort.

What InnerSource Is

InnerSource is the practice of applying open source collaboration principles to software development inside an organization's firewall. The code stays private to the company, but the way people work together mirrors how open source communities operate.

Consider a concrete example. Team A builds a user authentication library. Team C needs a small feature — say, support for SAML-based single sign-on. In a traditional organization, Team C files a ticket and waits three months because Team A is busy. In an InnerSource organization:

1. Team C reads Team A's CONTRIBUTING.md to understand the process.
2. Team C forks the repo internally, implements the SAML feature, and writes tests.
3. Team C opens a Pull Request against Team A's repo.
4. Team A reviews, gives feedback, and merges the contribution.
5. Team C is unblocked. Team A gets a free, tested feature. The company avoids a duplicate authentication library.

This sounds straightforward, but making it work reliably requires deliberate structure, cultural change, and aligned incentives. The rest of this lesson covers exactly that.