Why innersource belongs on the enterprise roadmap

Open source has already reshaped how software gets built. Innersource applies that same playbook—transparent repositories, contributors, maintainers, and pull requests—to proprietary code behind the firewall. For companies with distributed teams, redundant projects, or slow onboarding, the case for formalizing these practices is strong.

Innersource isn't a new methodology. It borrows principles proven by decades of large-scale open source work (Git, Linux, Python) and applies them to closed source projects. Enterprises are beginning to treat internal code as open by default, so that ideas, fixes, and improvements can come from anywhere in the organization.

Collaboration doesn't stop at time zones

As engineering teams spread across the globe, making collaboration transparent and asynchronous has become a business requirement, not a perk. Zendesk, with offices from Copenhagen to San Francisco, runs internal projects with open source-like structures: maintainers own services, contributors submit improvements, and everyone works in the open. This keeps pull requests and conversations flowing across office boundaries without burdening any single team.

The model works because ownership is explicit. Documentation makes the contribution process predictable, while project owners manage competing workstreams without closing themselves off to outside input. For Ford's Timothy Carmean, the advice to teams is direct: "Make your repository public. Then let people use it, open pull requests, and have conversations about it."

Better ideas, faster shipping

Opening a project invites more than code changes—it invites ideas about the process itself. Ford's Tom Erickson believes developers should be able to suggest improvements to how teams work and adopt "a style of working that's more open and fits their needs." That alignment between culture and process, he argues, is what lets teams "ship higher quality software faster."

At Stripe, teams regularly work on each other's code, but every change still routes through a standardized review process. Documented contribution and review guidelines shift the burden of "what's next" away from individual engineers. For Stripe Developer Advocate Michael Glukhovsky, the result is freedom: "If you see something that needs to get fixed, you can submit a pull request, and start a conversation."

From silos to discoverable code

Few things sting like discovering that another team independently built what you've already perfected. Code that isn't visible tends to be code that gets duplicated—often with small inconsistencies that compound. Innersource makes existing assets findable so teams can build on each other's work. Florent Zara, Innersource Project Lead at ENGIE Digital, puts it plainly: the goal "is to break down silos and encourage people to work together."

Centralizing code on platforms like GitHub—as Ford does—makes it much easier for developers to locate already-built solutions. Ford Chief Engineer Florian Frischmuth says, "Our environment allows developers to find solutions that have already been developed. They can collaborate on those, and then reuse them."

Security improves with more eyes

Opening code internally may seem to conflict with security best practices. In practice, the opposite holds true at Nationwide Insurance. Teams at the company once kept projects close to the chest, but Associate Vice President Cindy Payne found that the projects teams were most reluctant to share often were the ones that most benefited from outside input. More collaborators means more spots to catch bugs early, and security expertise can get involved in the process sooner. When vulnerabilities do arise, exposure allows teams to assess impact and triage faster.

Self-service beats request-and-wait

Many organizations still run on a central request model: put in a ticket, wait for an admin to spin up a repository. The approach creates two layers of overhead: administrative maintenance and friction against trying new things. A self-service model cuts those barriers and saves time at scale. Nationwide's shift to self-service repositories removed blockers and freed up infrastructure costs. As Payne puts it, the immediate savings turned into "more capacity for teams to do the most valuable work for our business."

Zsuzsanna Gnandt, Innersource Project Manager at automotive supplier Continental, frames the benefit in terms of innovation: "With innersource, we want to enable all developers with the freedom to be creative, to drive innovation without barriers, and to be appreciated for their contributions across the company."

The principles that have sustained open source communities—transparency, contribution guidelines, and clear ownership—are becoming standard for internal engineering organizations. Innersource is less an experiment and more the way proprietary software now gets built.