Inner sourcing has become a popular buzzword in platform engineering, often touted as a universal solution to some of the most pressing challenges in the field. The benefits of inner sourcing are frequently advertised as scaling platform development and adoption by enabling anyone to contribute rather than be blocked by a centralized controlling team.
While these goals are ambitious and clearly impactful, inner sourcing isn’t how you get there; enabling multi-player mode and democratizing the platform are key. To get to what I mean by this, let’s start by defining inner sourcing.
What is Inner Sourcing?
Inner sourcing is the practice of adopting open-source principles such as collaborative development, shared ownership and transparency within an organization or other closed community. It borrows heavily from the world of open-source software (OSS), where developers across teams or organizational boundaries collaborate to create, maintain and improve software projects.
One of the core tenets of this model is that everyone contributes to the same code base. Any changes must be aligned with the vision of the wider community and be accepted by a small group of trusted maintainers.
In the context of platform engineering, the promise is that if a platform user isn’t happy with their experience, they can contribute not only a bug report or feature request, but a whole working solution. This means that they are theoretically in control of their own destiny.
The Problem With Inner Sourcing as a “Cure-All”
While the dream of inner sourcing is to unblock users from making the platform they always dreamed of, the reality paints a very different picture.
First of all, most users are not themselves experts in designing, coding, testing and releasing the tools they depend on. This is like asking a chef to forge their own knives if they aren’t happy with the blade shape. And even if those chefs could forge knives, the question is whether their time is best spent doing so. If a core contribution model for platform growth is ad hoc submissions from users, you may be closer to provisional on the CNCF Maturity Model than you may think.
And then comes the behavior when a feature is not incorporated. Typically, when a feature request is not accepted, a user has the choice to live with the current deteriorated experience, but in an inner sourcing situation, since the users have already implemented the code, they are more likely to fork the code, leading to internal overhead and competing solutions.
So, if inner sourcing can cause all these headaches, how can you achieve the ambitious goals around high-growth and high-adoption platforms in another way? The answer lies in rethinking what your platform is and how it enables both producers and consumers.
Focus on Democratizing the Platform
The key to unlocking higher engagement and fewer bottlenecks is to focus less on encouraging core feature bloat in the platform itself and more on enabling subject matter experts (SMEs) to host their capabilities on the platform. Think of your platform as a marketplace where producers (the SMEs) and consumers (the platform users) come together, supported by robust tools and processes.
Learn From Etsy’s Product Team
Consider Etsy, a marketplace that serves two main audiences:
- Sellers: Crafting individuals who want their products to be discoverable and desirable.
- Buyers: People looking for unique, high-quality items for gifting, home decorating, or personal use.
Etsy’s product team builds features that empower sellers to present their offerings effectively while helping buyers find and commit to the “just right” item.
Nearly all platforms being talked about today, both vendor and in-house, are scrambling for the best possible buyer (app developer) experience. But we all know that the network effect means that without a balance on both sides, a platform is doomed to fail.
With this in mind, your platform team needs to keep in mind that they have many users. While some consume capabilities, many are the experts creating those compute, networking and storage capabilities, or they are setting key business requirements such as cost, compliance and green energy.
Build Producer APIs, Not Just User APIs
It is well understood that all platforms, really all software, today should expose APIs for user interactions. These APIs provide a structure for interacting with the platform’s core business logic, allowing users to use or even create multiple interfaces and allowing the API developers to continue to iterate behind a clear contract with their users.
While many of today’s platform products focus on application developers facing APIs, nearly all neglect the needs of their other users – the SME capability producers. This leads to static, limited platforms rather than dynamic, multi-faceted ecosystems.
To realize a true platform ecosystem, invest in producer APIs that empower internal experts to:
- Define their capabilities in a simple, consistent way.
- Clearly articulate the dependencies and requirements for their capabilities.
- Seamlessly define and integrate with the platform’s operational rules.
This approach shifts the burden of a new requirement or a new feature from the platform team to the SMEs who are best suited to implement those updates while ensuring the platform remains scalable and reliable.
Unleashed Platform Features
One of the reasons this style of platform building feels so alien to people is that today, most platform teams are a slight variation of previous operations teams. These teams are the experts in provisioning and managing compute and storage, and they are the points of contact for other departments like finance and security when requirements need to be applied system-wide.
One of the greatest side effects of democratization is the delegation of capability development and support. And just like any other delegation, this can unlock tremendous amounts of time for the platform engineers to act more like those Etsy product engineers we described earlier in this article – to focus on ecosystem enablement, such as access, experience and validation for users on both the consuming and producing side of the platform. This can take the form of tools that:
- Enforce best practices: For example, by implementing guardrails around user APIs to ensure better outcomes.
- Manage dependencies: Simplify the complexity of resolving and coordinating capability dependencies.
- Provide observability: Offer both producers and users the insights they need to operate their capabilities effectively.
By empowering SMEs and focusing on tools that enhance collaboration and quality, you can create a platform that supports sustainable growth and innovation.
Conclusion
While living the open source values of transparency and collaboration on all codebases in your organization is a great goal, inner sourcing alone isn’t a way to scale your platform capabilities. The only way to do that is to democratize and decentralize platform capability creation and support while maintaining centralized visibility and even control over the standards for these capabilities.
The solution for application developers’ cognitive load being too high isn’t to shift it all to a single centralized team; it is to find a way to channel and amplify the experts within the organization to provide shared services.