OpenSource to InnerSource: Why Enterprises are Adopting this Strategy
And how to implement the InnerSource development strategy for composable software
Open-source is great. It allows us to develop faster and better, leverage the collective intelligence of a diverse community, and innovate through collaboration. We reuse what’s already available and contribute by reporting issues and suggesting PRs.
In contrast, dev teams in enterprises often operate in silos where other teams’ code is inaccessible to them. This leads to poor code reuse and prevents teams from contributing to the projects they consume (APIs, shared libs, etc).
When we contribute back to a project, we are able to fix bugs that impact us and add the missing features that we need. We do that instead of creating various workarounds for ourselves or waiting for someone else, with different priorities then ours, to make the necessary changes. However, this is not an option when teams in and organization are siloed.
The good news is that the principles of open-source can be successfully applied within an organization in what is known as InnerSource. By adopting this collaborative spirit, companies can reap the same benefits as they would in the open-source world but within the confines of their proprietary projects.
By treating internal projects as open-source, we break down silos and encourage a culture of contribution. We foster a collaborative environment where knowledge and skills are shared across teams.
Documentation and easy onboarding
Internal projects adopt an InnerSource approach by setting up clear guidelines for contributions, providing robust documentation, and an easy onboarding process, resulting in a better understanding of how to work with the software and contribute effectively.
The ‘trusted committer’ role
A ‘trusted committer’ role is established (for each project) to guide the process, ensure that contributions align with the project goals, and maintain a high-quality codebase. These trusted committers perform critical reviews, manage the merging of pull requests, and often serve as a point of contact for new contributors.
Several platforms and tools support the InnerSource process, but I’d like to focus on one made specifically for composable architecture. As you’ll see, composable software principles align perfectly with InnerSource's principles.
The Bit Platform for InnerSource with composable software
Bit platform is a collaboration hub for Bit components, distributed reusable pieces of code shared across projects within an organization. Bit platform helps teams implement an InnerSource ecosystem by simplifying the process of sharing, documenting, and updating components.
It promotes transparency and collaboration among developers by making each component easily discoverable and providing a streamlined workflow for contributing changes.
One of the benefits of component-based software is that it is easier to read, understand, and maintain. This clarity and modularity not only facilitate contributions from developers who are not familiar with the entire codebase but also allow for greater flexibility in reusing code for different purposes.
Reusing components maintained by other teams
‘Contributors’ in an InnerSource eco-system start their journey as ‘users’ looking for components that fulfill a particular need in their project.
For example, the team working on Acme’s client-side app needs a UI ‘card’ component for their project. Before creating this component from scratch, the team would look for it in the organization’s entire collection of components hosted on Bit Platform.
in the open source space, we often look at usage stats or community feedback to gauge the quality and reliability of the software we intend to use. The same “community discussions” and usage statistics are available for proprietary software in the Bit platform, providing insights into each component’s performance and relevance.
An InnerSource platform has to make code easily discoverable. Search capabilities are critical, but also component documentation. Bit greatly helps by presenting component previews, interactive playgrounds, and auto-generated documentation.
The organization hosts its components in separated access-controlled domain-specific scopes, which correspond to the different teams in the organization. The core team maintaining the scope would have varying levels of write permissions, while other teams would be limited to only using components and suggesting changes.
Contributing to another team’s components
The team working on the client-side app for the Acme organization uses the ‘discussions’ API for customer engagement. They need to add a new feature to enable image attachments in discussions. Instead of forking the project or building a custom solution, they can make a contribution directly to the API using Bit.
They’ll start by searching for the ‘discussion server’ component on the Bit platform.
Once the Bit component has been found, the team can import (clone) it into their project, modify it, and test the impact of these modifications on their project, even while still in development!
The ‘discussion server’ component has a single direct dependent, the ‘acme platform,’ which is the entry point for the entire system maintained by the Acme organization.
To validate this change, the two components will be tested and built, in sequence, using the Ripple CI system offered by the Bit platform.
Once the build is complete, the team can use the Bit platform to create a ‘change request’ to the relevant trusted committer.
‘Change requests’ from different teams are organized in one central place for the trusted committer.
The trusted committer can then review this change request, which includes changes to the code of one component and changes to the dependency graph of another component (the dependent component).
Conclusion
In conclusion, adopting InnerSource practices and using tools like the Bit platform helps align internal projects with open-source methodologies, fostering a much more collaborative, efficient, and innovative development process within organizations. It eliminates redundancy, accelerates development cycles, and facilitates cross-functional team interactions, ultimately leading to better-engineered products.
Moreover, it creates an ecosystem where the boundaries between different departments become less rigid, enabling a smoother flow of ideas and solutions. This not only boosts morale by giving developers a sense of ownership and contribution to other parts of the company’s software but also enhances the overall technical proficiency as developers gain experience from different codebases and projects.
