TL;DR — Key Takeaways
- Enable contributions, not bottlenecks: Platform teams can scale their capabilities by giving developers clear, supported ways to extend shared platforms without requiring central teams to build everything.
- Governance makes collaboration work: Well-defined extension interfaces and predictable review commitments help maintain quality, security and consistency while encouraging developer participation.
- Maintenance needs an owner and a budget: Sustainable platform extensibility requires funded maintenance and clear accountability, ensuring community contributions don’t become long-term operational liabilities.
A developer platform can attract more users without generating more contributions because it already does what those users need. Platform leaders should investigate whether developers can accomplish their goals before treating a quiet contribution pipeline as evidence of disengagement.
Quail Lincoln, senior software engineer II in engineering enablement at observability vendor Honeycomb, questions the assumption that adoption should produce a growing pool of contributors.
“I would argue that ‘gaining users without gaining contributors’ is a success state for a platform: it means that the platform is effectively solving the jobs of its users,” they said.
The concern arises when developers compromise their applications or workflows to fit the platform’s limitations. Lincoln said teams may reshape solutions around what the platform permits, even when doing so produces a worse result.
Platform teams need ways to discover unmet needs and accommodate changes without requiring every user to become a platform maintainer.
Make Contribution Opportunities Clear
Contributing to another team’s system carries uncertainty about priorities and plans. A developer might see an immediate improvement without knowing whether it conflicts with work already underway.
“If I’m making changes to something that another team owns, I don’t have much insight into their roadmap or what future things I’m making more difficult,” Lincoln said.
A visible roadmap can identify improvements the platform team wants but cannot immediately prioritize. That gives potential contributors a starting point and reduces the risk of investing time in changes that maintainers cannot accept.
Platform teams should also define where customization is supported. For a code review agent, that might mean allowing application teams to supply instructions about issues specific to their codebase.
“All that said, platform teams should give clear interfaces for how developers can customize the platform for their needs,” Lincoln explained.
Those interfaces should be accompanied by telemetry that lets contributors judge whether their changes produce the intended results. A defined extension point is more useful when developers can evaluate its behavior.
Give Feedback a Clear Path into Priorities
Participation also includes reporting bugs, requesting capabilities and explaining where existing tools fall short. Developers who cannot contribute code can still identify problems that deserve attention.
An accessible feedback channel gives users somewhere to raise those needs. Platform teams then need a process for distinguishing small fixes from requests requiring broader design or prioritization decisions.
Lincoln described an approach in which minor bugs and friction receive direct attention, while larger requests enter internal discussions and roadmap planning.
For platform leaders, those conversations help clarify the underlying requirement before committing to an implementation. A feature request can become an opportunity to understand what the developer is trying to accomplish and where existing capabilities fall short.
Review turnaround, maintenance responsibilities and funding also require agreement between the teams involved.
“This really comes down to regular cross-team working norms in your organization,” Lincoln said.
An invitation to contribute should therefore connect with established ways of assigning work and resolving competing priorities. Repository access alone does not settle who will review a change or support it afterward.
Use Experiments to Guide Development
Independent developer tools can reveal needs the shared platform has not addressed. Allowing experimentation gives application teams room to test ideas while providing maintainers with evidence about possible additions.
Lincoln described migrating independently configured code review agents into a shared reviewer. Although the replacement supported a narrower range of capabilities, conversations during migration exposed use cases that informed further development.
Platform teams can apply that approach when consolidating other tools: investigate why variations exist before deciding which behaviors to preserve. Some may reflect requirements worth supporting; others may be experiments whose value remains uncertain.
A supported platform and team-owned experiments can coexist, with lessons from those experiments feeding future priorities.
“We offer a paved road, and seeing experimentation helps us inform our product direction,” Lincoln said.