An Introduction to InnerSource

As more organizations are adopting and contributing to open source software, so too are they adopting open source principles and methodologies for their internal development processes. The term for how these companies use open source methodologies within their organizations is InnerSource.

What Does InnerSource Mean?

The term InnerSource was coined by Tim O’Reilly back in 2000, and, according to Adopting InnerSource by Danese Cooper and Klaas-Jan Stol (published by O’Reilly Media), refers to “the use of open source principles and practices inside proprietary organizations. InnerSource empowers individual engineers to contribute code from within their team to another team in order to speed up the process of adding functionality (features) or fixing defects.” 

In other words, InnerSource uses the best practices learned from successful open source projects and applies them to proprietary projects. “InnerSource also democratizes development and control over the direction of the project by encouraging pull requests over feature requests,” the authors write.

Additionally, they note, it’s useful to explain what InnerSource is not:

InnerSource is not simply adopting GitHub or GitLab within your organization and arguing that all source code is now transparent. While tooling is important, it’s only an enabler and not a guarantee for success. Also, InnerSource does not mean paying your developers to work on open source projects: that’s simply sponsoring open source development. When you release the source code you’re working on to the public with an open Source license, it’s not InnerSource.

How Is InnerSource Used?

“The traditional way companies develop software inside companies is quite different from the open source collaborative model,” says Nithya Ruff, Head of Comcast's Open Source Program Office and Linux Foundation Board member.

“Because of how budgets, organization structures, and incentives work, teams work in silos, are top-driven, and have no incentive to share and collaborate across the organization,” she says.

According to Danese Cooper, PayPal, for example, has found InnerSource “useful for helping to break down engineering silos, increasing emphasis on code craftsmanship and, more generally, for increasing employee collaboration and satisfaction.”

Ruff also explains the difference in motivation between using open source and InnerSource, noting that open source contributors are often trying to solve a technical issue. With InnerSource, however, “one main reason is to enable another team to work more effectively with the platform or to reduce a duplicate effort,” she says.

Some organizations, Ruff notes, have opened all their repositories for anyone in the company to collaborate on. And, she says, a huge driver has been to stage projects as InnerSource before fully open sourcing them. This approach “allows the team to hone a good collaboration strategy and practice before open sourcing.”

Adopting InnerSource

GitHub maintains that “InnerSource can shift how individuals see themselves and their responsibilities, making organizational structure an important consideration. An effective InnerSource process should be informal, mentored, self-selecting, and supportive of its participants.”

Both open source and InnerSource approaches depend on the model of collaborative development. “Adopting InnerSource practices is like starting an open source community within your organization. As with open source, transparent collaboration mobilizes a community’s collective knowledge and skills to create better software. An InnerSource community, in contrast, contains the knowledge, skills, and abilities of people and tools within a single enterprise,” says GitHub.

Nonetheless, the InnerSource approach requires dedicated effort to succeed. “To effectively adopt InnerSource practices, contributors need to be able to work easily across silos and other organizational divisions,” GitHub states.

“Working across teams inside an organization on common source code is a culture change for a traditional enterprise,” says Ruff. “And both approaches need sponsorship and support from the top to thrive inside an organization.”

Learn More

Comments