At a recent Platform Engineering Conference, I had the privilege of attending an inspiring session led by technology leaders from a major bank. They shared their transformation journey of migrating to a central platform out of siloed cloud automation across teams. This internal platform successfully broke free from team-specific automations, enabling the modernization of hundreds of applications delivered within an impressively short time frame.
When asked how they managed to unify disparate teams—each deeply attached to their own custom-built frameworks—their response was as insightful as it was effective: they made the internal platform open for contributions from power developers across the organization.
By doing so, they empowered developers to feel included and valued, allowing them to contribute their innovations to the central platform. This simple approach fostered a sense of ownership and collaboration, which not only dismantled silos but also enriched the platform with a diverse array of well-tested, robust components. This tells the potential of innersourcing in platform engineering and infrastructure automation.
Advantage of Inner Sourcing
Innersourcing—the practice of applying open-source principles within an organization—has already gained interest in how software development is conducted internally in large organizations, reducing duplicated efforts and fostering shared ownership.
These same principles can be effectively applied to software delivery and platform engineering. By adopting innersourcing practices in platform engineering, organizations can break down silos and encourage contributions from various teams, enhancing adoption of central platform initiatives.
Hard Platforms End with Hard Landing
In our conversations with multiple large enterprises, we’ve seen several failed initiatives - a recurring theme: platform engineering initiatives that start strong but fizzle out after limited adoption.
These efforts often stall, not due to technical shortcomings but because of rigid platforms and inflexible structures that fail to resonate with developers.
Of course, a platform needs to be opinionated—after all, that’s what makes it a platform. It has to offer guarantees and enforce certain standards, and some aspects must be closely guarded. But when a platform lacks extensibility—or worse, transparency—it’s almost guaranteed to face friction from the very developers it’s supposed to serve.
The “just bring your code, and the platform will handle everything” approach sounds great in theory, but it rarely works in large enterprises. Developers want to be involved, to have their unique needs addressed, and to feel like valued contributors rather than just users of a monolithic system.
Here are some of the developer voices that need to be addressed -
Transparency: Are the platform’s paved roads transparent enough for me to understand what’s happening under the hood?
Custom Needs: What if the paved road created by the platform engineering team doesn’t meet my specific project requirements?
Contribution: I’ve developed well-architected components for my project. Can I contribute these to the central platform?
These concerns underline the need for an inclusive approach for platform builders driving a central initiative for an entire organization.
Enabling InnerSourcing for Platform Success
Innersourcing can transform how organizations build and adopt platforms.
- Raises the quality bar for the Platform: Keeping Innersourcing as a requirement enforces platform builders to design and develop in an open, collaborative environment. This naturally raises the bar for quality, ensuring that all components are well-architected and extensible, capable of adapting to diverse needs across the organization.
- Inclusive Approach to Drive Change: By encouraging contributions from teams across the organization, innersourcing fosters collaboration and inclusivity, empowering teams to shape the platform collectively and more importantly advocate for adoption.
- Avoids Platform Obsolescence: Continuous contributions ensure the platform evolves with changing needs, preventing it from becoming outdated or irrelevant over time.
Here’s how platform engineers and I&O leaders can leverage it:
Clarity on the Core and the Context: Clearly communicate the key idea and guarantees of the platform. Outline what the platform aims to achieve, the boundaries of its core responsibilities, and which parts are open for contributions. This sets expectations and helps developers understand where and how they can add value.
Open for Contributions: Allow power developers to contribute to the central platform, much like open-source development. This fosters collaboration and inclusivity.
Review & Preview Process: Establish a transparent and well-documented process for reviewing pull requests (PRs) to the central platform. This ensures quality while keeping the door open for meaningful contributions. Empower teams to preview new module versions and test them in isolation. This helps identify and resolve issues early, minimizing disruption during adoption.
Controlled Rollouts: Provide mechanisms for selective rollouts or forced releases. Allow teams to pin module versions or roll back to stable ones, ensuring they can move at their own pace without compromising on reliability.
Transparency and Metrics: Offer project owners access to detailed logs and metrics for the modules they use. This visibility helps teams understand module behavior and troubleshoot issues, building trust in the platform.
By adopting these practices, organizations can create platforms that are not just tools but thriving ecosystems. Innersourcing transforms the traditional top-down model of platform development into a collaborative, iterative process—one where every team has a stake in the platform’s success.
Facets.Cloud and InnerSourcing
Facets.Cloud empowers organizations to move away from project-specific automation and embrace standardization through its platform-as-a-product model. By incorporating innersourcing principles, Facets enables power users of the organizations to build on its platform-as-a-service for catering to team-specific needs. Here’s how Facets has adopted and operationalized these principles:
Provide Clarity on the Core and the Context:
Facets delivers clear guarantees by managing critical responsibilities like generating project-specific Infrastructure as Code (IaC), maintaining automation state management, and ensuring cloud portability. At the same time, it avoids rigidity by offering guidelines for writing project-agnostic automation code rather than enforcing strict adherence to standard modules. This balance allows teams to innovate while relying on the platform’s core strengths.
Open for Contributions:
Platform engineers and power developers can leverage reference modules provided by Facets to create their own custom modules for unique use cases. These modules can then be registered with the platform, which takes over the controls of their execution during appropriate invocations. The developers of our customers have used this flexibility to integrate custom cloud solutions, toolchains, built reusable modules, Slack bots, and other creative enhancements.
Review & Preview Process:
Contributed modules are stored in a Git repository, enabling Platform Engineers to review and approve qualified changes. Once approved, these changes can be tested in a preview mode, allowing selective testing of new versions without disrupting ongoing operations.
Controlled Rollouts:
Facets provides project owners with the ability to control rollout speeds and mitigate risks. They can choose to adopt the latest version of a module or pin specific versions to maintain stability. This approach minimizes the blast radius of potential issues during module updates.
Building Transparency:
Transparency is built into the core of the Facets platform. Project owners can access details about the modules being used in their projects, view execution logs, and even examine the generated code. This visibility ensures developers and teams have a deep understanding of how the platform and its innersourced modules are functioning, fostering trust and collaboration.
Conclusion
Innersourcing for platform engineering may not be a one-size-fits-all solution. For smaller organizations, a purely opinionated platform might suffice, offering simplicity and efficiency that aligns with their scale and needs. However, for larger enterprises and platforms aiming for longevity, innersourcing provides a compelling avenue to explore. By fostering collaboration, transparency, and adaptability, innersourcing equips platform engineers to build solutions that not only meet immediate demands but also evolve with the organization, ensuring sustained relevance and success.
