The Future of Inner Source
As the number of computers, mobile phones, IoT devices, and sensors continues to grow so is the number of applications. Every company no matter their industry or size are rapidly becoming a software provider. Even traditional hardware or manufacturing companies turn to software to develop competitive differentiators. For instance, the average high-end car is now powered by more than 100 million lines of code. The world’s most valuable companies all have something in common: their assets are mostly intangible, and that ratio is only increasing year after year.
Not only is the volume of code increasing, but also the pace of change that comes from the variety of programming languages frameworks and subsequent versions keeps accelerating. According to a recent Gartner report, software maintenance represents as much as 80% of their annual IT budget. Engineering leaders are dealing with the growing complexity of their codebases and often struggling to innovate due to a lack of visibility on their own assets.
It’s Open Source That’s Eating the Software World
One way to overcome that challenge is to share the maintenance burden and necessity to innovate with others either internally or externally. Open Source Software is often seen as a competitive lever with companies either adopting 3rd party software or donating their own to independent foundations. The success of the Open Source model comes with major structural changes for the world economy as a whole.
In a recent blog series, Open Source leader Joseph Jacks shares a lot of valuable insights related to commercial open source software, projects, business models and values. As you can see in Joseph’s Commercial Open Source Software Company index, the number and valuations of companies which are building upon open source projects as their primary mission are simply astonishing. In addition to maintaining and releasing new versions of their open source projects, open core companies need to define a productization strategy for monetization. That business strategy is neither set overnight nor set in stone. It’s a slow and collaborative process that evolves with the level of maturity and adoption of the core open source projects. From basic enterprise support and services or light enterprise plugins to fully hosted platform with an entirely distinct codebase, there are many different shades of open core models. The choice of the open core and licensing models greatly impact the level of collaboration between the commercial open source software companies and their respective communities as well as internal company cultures.
Inner Source Is Now a Reality
As major consumers and producers of open source software, many Fortune 500 companies have become sponsoring members of the Linux Foundation, the home of the most successful open source software projects. By participating in that external ecosystem and engaging with specific developer communities, these companies are exposed to a completely different set of engineering practices and culture based on collaboration. Using the same methodology to develop proprietary products internally is a popular engineering discipline called Inner Source. That concept is not new, it was initially defined by Tim O’Reilly in 2000 and popularized by Innovative companies such as Red Hat, PayPal and Bloomberg which have been embracing Inner Source for years. There are plenty of resources available on the topic including use cases and best practices highlighting requirements for successful Inner Source adoption. In this post, we’ll look at the 3 pillars of Inner Source: culture, development process and automation tooling.
Managing an open source project at scale and preserving a healthy community comes with many challenges. Maintainers should thrive to create a welcoming environment where code development, discussions and decisions are not only open to all but also where contributors are helpful, positive, and supportive of newcomers. With Inner Source, the same culture and values apply to project behind companies firewalls.
Inner Source processes are first and foremost designed with the contributor experience in mind. The contribution process should be simple, clear and well documented to minimize the friction between maintainers and contributors. Only a small number of interactions and back and forth should be needed from the first time a contributor visit a repository to the pull request getting merged. A structured readme and roadmap, the extensive use of GitHub labels, milestones and ownership rules should provide enough visibility to contributors to break down silos and avoid frustration.
Automation tooling is the last pillar of Inner Source but certainly not the least important. Templates can be automatically added to new issue creation in specific GitHub repositories. Most successful open source projects make extensive use of continuous integration services for automated testing and quality assurance. Bots such as Derek can now help automate simple tasks such as assigning or auto labeling newly created issues. Despite recent progress, a lot more can be done to bring automation to the next level.
The Future of Inner Source
The future looks bright for Inner Source. The emergence of concepts such as “Code as Data” and the development of Open Source tools for large-scale code retrieval and analysis can help developers with their Inner Source initiatives. For instance, developers will be able to easily find code similarities and duplication across an entire organization and through its codebase history. This should further help engineering teams identify opportunities for collaboration and provide inputs to train Machine Learning models and applications for assisted code reviews. It also provides executives with engineering analytics and business insights to both inform Inner Source practices and assess its benefits. In other words, companies are now one step closer to treating their codebase as one of their most valuable assets.
Feature image via Pixabay.