Platform Engineering and InnerSource: Building Developer Communities at Scale
The Backstage Moment: When the Real Work Begins #
Your organization has done it. You’ve successfully implemented Backstage. You’ve given conference talks about your platform engineering transformation. You’ve shown how your developer portal provides visibility into everything across your engineering organization. You’ve ticked all the boxes.
But here’s the uncomfortable truth: implementing Backstage doesn’t mean you’ve “done” platform engineering—it means you’ve finally reached the starting line.
Platform engineering isn’t equal to Backstage, just as it isn’t equal to any specific tool or solution. Everyone knows this intellectually, yet organizations consistently fall into the same trap: they focus on the technology and forget the culture.
The Recurring Failure Pattern of Shared Platforms #
Before we dive into what platform engineering actually requires, let’s acknowledge the elephant in the room: most shared platforms and common libraries have historically failed. This isn’t a secret—it’s a well-documented pattern that platform engineering is supposed to solve.
But why do they fail? The answer always follows one of two predictable patterns:
Pattern 1: The Service Desk Trap Your platform team becomes a service desk, drowning in feature requests, common requirements, and dependency management from every team in the organization. Conflicting requirements pour in, forcing you to either become a custom development shop for every use case or watch your platform fork into unmaintainable branches. Long-term maintenance cycles compound the problem—you’re not just building features, you’re maintaining a zoo of custom implementations that grow more complex over time.
Pattern 2: The Ivory Tower When the flood of requests becomes overwhelming, platform teams start saying “no.” They reject user requirements, refuse to accommodate edge cases, and insist that teams use the platform as-is. The result? Teams build their own solutions. The shared platform becomes irrelevant. Game over.
These failures aren’t structural—they’re cultural. Having fancy portals and sophisticated tooling doesn’t solve the fundamental problem: how do you create collaborative, sustainable relationships between platform providers and platform consumers?
The Missing Cultural Implementation #
Think about your current GitHub setup. It probably serves as your organization’s default “portal”—a single place where you can discover repositories, collaborate through issues, and access documentation. When you had 100 repositories, you didn’t need Backstage. GitHub was enough. But as you scaled to thousands of repositories, you needed that additional layer of organization and discovery.
The same principle applies to platform engineering. The infrastructure and tooling are just the foundation. What you’re really building is a developer community—and communities require intentional cultural practices, not just better tools.
This is where platform engineering intersects powerfully with Infrastructure as Code principles. Platform engineering involves template generation, standardized deployments, and automated provisioning—all concepts that align with treating infrastructure as software. But unlike traditional IaC, platform engineering must also address the human elements: how do developers discover what’s available? How do they request changes? How do they contribute improvements?
Learning from Cloud Vendors: The Developer Community Playbook #
Here’s a perspective shift that changes everything: as a platform team, you’re essentially running an internal cloud vendor. You’re taking the complexity of AWS, Azure, and GCP—with their hundreds or thousands of services—and distilling them into a simplified, enterprise-grade platform that your developers can easily deploy.
And how do cloud vendors communicate with developers? Through GitHub. Through documentation repositories. Through GitHub Discussions. Through open source components and transparent issue tracking. Through threaded conversations that are preserved and searchable. Through voting mechanisms where community feedback drives product decisions.
I’ve seen this firsthand during my time as a cloud architect at Microsoft. Ultimately, customer voice drives everything. Product teams desperately want to understand user pain points, validate whether issues affect many users, and measure business impact. Sometimes this involves manual information gathering and customer nomination processes, but increasingly, it resembles the open forum model where large numbers of users vote on features and product teams engage directly in public discussions.
This isn’t coincidental—it’s the proven model for developer-focused products at scale.
InnerSource: The Cultural Bridge #
InnerSource provides the missing cultural framework for platform engineering success. It’s not about opening up all your internal code or expecting magical contributions from your organization. It’s about gradually transforming toward a more open, transparent, collaborative environment.
InnerSource enables the collaborative culture that platform engineering requires. It makes pull requests and transparent discussions the norm rather than the exception. Most importantly, it creates an environment where engineers can flourish as both contributors and consumers.
Here’s why this matters for platform teams: your customers are internal developers—engineers who speak the language of code, understand GitHub workflows, and can contribute meaningfully to platform development. The methodologies for communicating with internal developer communities are fundamentally different from Agile approaches designed for end-user products.
Your platform users communicate through source code management systems. They’re technical. They can contribute code, documentation, and meaningful improvements. InnerSource provides the proven patterns for harnessing this capability.
Team Topologies and Collaboration Patterns #
Team Topologies, the bestselling book that everyone references when discussing platform engineering, outlines various collaboration patterns between teams. But here’s a crucial insight: not all team types benefit equally from InnerSource approaches.
Platform Teams and InnerSource: A Perfect Match Platform teams have the highest dependency relationships in most organizations. When one library is used by 100 people, collaborative development benefits all 100 users. It prevents reinvention, reduces review burden, and creates economies of scale. This high-dependency, high-reuse pattern makes InnerSource incredibly valuable for platform teams.
Stream-Aligned Teams: Less Natural Fit Stream-aligned teams, by design, have completely separate domain knowledge and minimal cross-team dependencies. Collaboration between stream-aligned teams is naturally limited because they’re optimized for independence. When dependencies exist, they’re more likely to be consumer-provider relationships rather than collaborative development relationships.
This distinction matters. Platform teams naturally benefit from InnerSource because they mirror the dynamics of successful open source projects: high reuse, diverse contributors, and shared maintenance benefits.
The AI Era: Amplifying Platform Engineering Through Better Information Architecture #
As we enter the AI era, platform engineering becomes even more critical—and InnerSource principles become even more valuable. Here’s why:
AI-Assisted Platform Development Instead of having humans immediately respond to user issues, platforms can assign initial triage and solution attempts to AI systems. But this requires information architecture that AI can understand: consolidated information in GitHub repositories, clear documentation, comprehensive issue histories, and standardized templates.
The ideal user journey becomes: discover platform capabilities through your portal → encounter an issue → create a GitHub issue → platform team assigns the issue to AI for initial analysis → human review and implementation. This flow only works when all relevant information—documentation, conversation history, related tickets—lives in AI-accessible formats.
The Information Consolidation Challenge I understand the constraints. Not everyone has GitHub Enterprise licenses. Source code might be hosted on internal blogs or AWS CodeCommit. Related documentation might live in Google Docs. Various communication channels might be scattered across Slack, Discord, and other platforms.
But here’s the critical insight: every workaround you implement to accommodate these constraints increases your platform team’s operational burden. Multiple communication channels create fragmented conversations. Distributed information reduces traceability. Inconsistent workflows lead to duplication and confusion.
While AI doesn’t fundamentally change what platform teams need to do, it makes the quality of your information architecture more critical than ever. AI can significantly reduce the effort required to solve common platform issues—but only if you’ve structured your information for AI consumption.
Practical Implementation: The Four Principles of InnerSource for Platform Teams #
1. Openness: Making Projects Discoverable and Contributable #
Your platform components need to be more than just available—they need to be accessible for contribution. Simply registering repositories in Backstage isn’t enough. Each repository needs clear documentation about who maintains it, how to contribute, where to report bugs, and how to request features.
Without this transparency, teams can’t engage meaningfully with your platform components. They become consumers rather than collaborators, recreating the unsustainable service desk dynamic.
2. Transparency: Visible Decision-Making #
Transparency means documenting not just what your platform provides, but why design decisions were made. When you provide a GitHub Actions template or a deployment pipeline, users need to understand the reasoning behind its design, whether it’s appropriate for their use case, and whether they should contribute improvements or create customized versions.
Closed decision-making leads to uninformed forking, duplicate solutions, and chaos in your platform ecosystem.
3. Prioritized Mentorship: Developer Onboarding at Scale #
Platform teams serve developer communities. Your “customers” need onboarding processes, contribution guidelines, and clear paths for engagement. This isn’t about managing external contributors—it’s about creating sustainable ways for internal teams to engage with and improve your platform.
4. Voluntary Code Contribution: Community-Driven Platform Evolution #
The goal isn’t for platform teams to handle every request. It’s to create conditions where users can contribute improvements back to the platform. This requires cultural change: platform components need to be designed for external contribution, not just consumption.
These four principles form the foundation of successful InnerSource implementations.
Beyond Tools: Creating Sustainable Developer Communities #
Using GitHub doesn’t automatically create InnerSource. Sharing code doesn’t automatically create community. What matters is bidirectional contribution and collaborative culture.
Platform engineering without community becomes just another way of providing solutions to developers rather than building with them. The most successful platform teams create ecosystems where:
- Users contribute templates and tools back to the platform
- Feature requests become collaborative development opportunities
- Knowledge sharing happens naturally through transparent processes
- Platform evolution is driven by actual user needs, not platform team assumptions
Companies like Netflix and Spotify have demonstrated how platform teams can build thriving developer communities around their platforms.
The Path Forward: Starting Small, Building Community #
You don’t need to transform your entire organization overnight. Start with one platform component. Make it truly open for contribution. Document not just how to use it, but how to improve it. Create clear paths for user feedback and contribution.
Build your core fan base—the developers who become genuine advocates for your platform approach. Enable them to contribute meaningfully to platform evolution.
Platform engineering at scale isn’t about building better tools—it’s about building better communities around those tools. InnerSource provides the proven patterns for creating these communities within enterprise constraints.
The most successful platform teams understand that they’re not just infrastructure providers—they’re community builders, facilitating collaboration between developers who share common needs and can contribute to common solutions.
Your platform engineering journey doesn’t end when you deploy Backstage. It begins when you start building the collaborative culture that will sustain and evolve your platform over time.
