Open source legend has it that Tim O’Reilly coined the term InnerSource back in 2000. While O’Reilly confesses that he doesn’t remember coming up with the term, he does remember recommending to IBM late in the 1990’s that they adopt some of the elements that make open source magic, namely — “collaboration, community, and low barriers to entry for those who wanted to share with each other.” Today, more and more organizations are adopting InnerSource as a strategy, leveraging the methods and philosophy that power open source and make it great, to improve their internal development processes.
InnerSource is the strategy incorporating open source methods into the development processes of commercial companies, and using them to create and publish proprietary software. In the words of Danese Cooper, long-time open source developer and evangelist who brought open source to PayPal, InnerSource is “the application of best practices, processes, culture, and methodologies taken from the open source world and applied to internal software development and innovation efforts.”
Leveraging the lessons learned from the open source community about the best ways to work collaboratively on software projects, companies using InnerSource adopt and implement open source methodologies in their in-house software projects. InnerSource strategies were brought into companies like Bloomberg, PayPal and more to help foster creativity, innovation, and communication, within large, global, and often highly regulated and hierarchal development outfits.
Considering how central open source components have become in today’s software development ecosystem, it’s only natural that companies also adopt InnerSource, embracing the methods that make open source projects so great. While commercial organizations might not be as interested as Cooper, O’Reilly, and other open source leaders in getting their code out into the world, companies are showing a lot of interest in what the open source meritocracy’s software development methods can bring to their bottom line, when implemented in-house.
InnerSource allows a development team in an organization to take ownership over its repositories and maintain them, while inviting other teams to collaborate. InnerSourcing projects means that one development team can enjoy fixes and feature enhancements from another. It provides developers access to a larger code repository, helping them to avoid wasting resources on duplication.
The InnerSource Commons provide a quick overview of the methodologies that make open source great, and the benefits that they can bring to development teams when implemented internally in an organization:
Rather than sharing code with the select few that are managing or participating in a specific project, as is often done in larger organizations, everyone in-house is free to view software projects, allowing the developers of the project to get feedback fro a larger and more diverse audience.
Projects are no longer siloed within one team, enabling development teams across the organization to both improve the code, customize it to their needs, and share it back.
When collaboration is prioritized and projects are shared across a large and scattered audience, informal conversations or emails between a select few aren’t enough, and documenting updates and features becomes imperative. Documentation is shared in an accessible location, open to collaboration, and provides a clear, detailed history of a project.
Open source enables developers to collaborate easily regardless of geographic location. Organizations with teams and working across different locations and timezones can allow anyone working remotely to work on the same code or contribute different files to the same project.
The open source community was far ahead of the curve when it came to testing early and often. Today, shifting left and testing continuously throughout development is a common DevOps process in organizations. As part of InnerSource methodologies, developers check for security and quality flaws throughout the SDLC. The fact that the code is open to the entire development outfit to poke and prod at, prides organizations with the “thousand eyeballs” that help ensure a secure and high-quality product.
Providing access to a large codebase and documentation developed by a large and versatile group of experienced engineers allows new team members with a manual and sandbox to learn more and hone their skills.
In order to ensure that InnerSource is implemented well and helps organizations overcome these issues, Guy Martin of Red Hat has a few tips for getting InnerSource right. First, organizations that set out on the InnerSource journey must make sure that they set clear goals and start with the collaborators most willing and able to adopt the new methodologies.
In addition, it’s important to enable effortless collaboration using the correct issue trackers and documentation tools accessible to all, across teams and locations. Once all the tools and processes for collaboration and open communication are in place, define your contribution governance model. Martin recommends providing community contributors with a sense of shared control: “in a true meritocratic community, those contributing the most value to the project can and should be given membership in the ‘committer circle’”.
Martin also recommends making sure that contributors are recognized for their work within the InnerSource community, and that each company pay close attention and address any barriers that might arise within their specific organizational culture.
Finally, don’t forget the basic open source practice — now adopted by many industries, of releasing early and often, starting out with a few select projects, to provide stakeholders and skeptics with real examples of how InnerSource can boost both quality and innovation.
Since open source usage has been embraced wholeheartedly by the software development industry, organizations have realized that beyond leveraging the open source projects that the community provides, InnerSource can take them one step further, and help them adopt the processes and methods behind the open source projects they love.
Letting go of old habits, breaking down barriers, and challenging traditional hierarchies is never easy, especially in large and established organizations. However, our favorite open source projects continue to provide excellent tools and platforms that prove that collaboration and open communication are the way to go when creating innovative, secure software products at scale and speed.