Presenters

Source

Building a Thriving Backstage Plugin Ecosystem: Insights from the Experts! 🚀

Hello, fellow tech enthusiasts and platform engineers! I just wrapped up an incredible panel discussion at my first Backstage Con, and let me tell you, the energy was electric! Moderated by the brilliant Hope Hadfield from Red Hat, our panel dove deep into the heart of what makes Backstage so powerful: its vibrant plugin ecosystem. As this ecosystem matures, new questions emerge around sustainability, governance, and quality. Today, we unpack the burning questions and discover how we can collectively build an even healthier, more robust Backstage future.

Joining Hope were four fantastic panelists, each bringing unique perspectives:

  • Paul Schultz (Red Hat): A Backstage veteran who drove the creation of the auditor service.
  • Aramis Sennyey (DoorDash): A core maintainer passionate about OpenAPI tooling and docs.
  • Heikki Hellgren (OP Financial Group): The creative mind behind the Q&A and Toolbox plugins, and a key contributor to core notifications and signals.
  • Peter Macdonald (Vodafone Ziggo): A docs maintainer and community plugin contributor, known for his Open Policy Agent plugins.

Let’s dive into their invaluable insights!

🏗️ Unpacking the Initial Hurdles: The Backstage Architecture Challenge

When new contributors first dip their toes into Backstage plugin development, they often hit a common wall: the architecture. Heikki kicked us off, candidly admitting that understanding where to put everything within a plugin’s many packages can be incredibly difficult. Should components and APIs go into the React package or the frontend module package? The intricacies of architectural restrictions, like preventing one frontend plugin from depending on another, require significant effort to grasp.

Peter echoed this, highlighting that the architecture, along with simply knowing where to start, remains a significant challenge for many. Aramis added a crucial point: while the architecture makes perfect sense once you’re immersed in the ecosystem, the initial struggle lies in deciding when to embrace complexity versus opting for simpler package placement. He even confessed that the routing framework was a personal hurdle for him for over two years, initially deterring him from recommending frontend plugins.

Paul humorously recalled his initial thought: “What the heck did I just get myself into?” He emphasized that we, as developers, often overlook the diverse personas interacting with Backstage – not just developers, but platform engineers, managers, and documentation writers. Supporting these different user journeys, especially in the age of AI, presents a new challenge: how do we structure documentation to differentiate between undifferentiated work and critical review tasks?

🛣️ Paving the Golden Path: Smoothing the Contribution Journey

So, how do we make that first contribution experience smoother? Peter, as a docs maintainer, championed the need for more and better documentation, specifically golden path documentation. He envisions these as guided tours, moving from a skeleton to a fully-fleshed-out plugin, providing real-world architectural examples. Imagine combining this with LLMs and AI agents! You could simply ask an agent, “How do I build a frontend plugin that does X?”, and receive a clear, step-by-step guide, demystifying the architecture without overwhelming you.

Heikki enthusiastically agreed on the golden path documentation and suggested we begin sharing agent skills through a central point. He also extended an invitation to the Contribute Fest on Thursday – a perfect opportunity for new contributors to get hands-on support!

Aramis highlighted that the biggest hurdle is often the very first contribution. Whether it’s supporting a new deployment path or fixing a minor doc error, getting that initial contribution merged makes the next 10, 100, or even 200 contributions significantly easier. Paul shared optimism for the future, envisioning a dedicated skills repository and smoother plugin migrations with the ongoing Material UI to Backstage UI (MUI to Backstage UI) transition.

⚖️ The Innovation Tightrope: Balancing Progress with Stability

Innovation is constant in the Backstage community, but how do we balance this with the need for quality and efficient plugin maintenance? Aramis, as a core maintainer, explained that new architectural systems, like the backend system launched two years ago, come with generous adoption windows before deprecations. However, a significant concern is the current Backstage versioning, which, despite being semantic versioning (SER), has introduced breaking changes within minor releases (e.g., 1.48 to 1.49). He suggested moving towards clearer quarterly or monthly releases and decoupling plugin versioning to provide better predictability.

Paul underscored the difficulty of migrations, citing the ongoing React Router 6 to 7 transition. He questioned how downstream consumers, especially companies often several releases behind, can keep up. This highlights a tension between company needs and community needs. He floated the idea of the community being more open to keeping plugins up-to-date and backporting to company instances.

Heikki shared his personal strategy: strict major version control for his own plugins. For example, he immediately bumped a major version when his plugin supported the new backend system, clearly signaling breaking changes to users. Peter articulated the “anxiety cycle” faced by companies like Vodafone Ziggo: they need to build new features, but these features require migration to newer systems, yet they can’t migrate until the new features are built. He believes a slower, more predictable quarterly release cycle would significantly help companies stay updated and reduce this stress.

🧑‍🍼 Stewarding Your “Baby”: Responsible Plugin Ownership

What does responsible stewardship look like for plugin maintainers as the community expands? Paul emphasized that keeping plugins up-to-date is paramount. He pointed out the automated update schedule in the community plugins repo, which eases this burden for authors. He also highlighted the importance of being open to feedback and criticism, understanding its source, and being prepared to hand off your “baby” – your plugin – if you need to step away from the community.

Aramis posed a critical question: how do we, as maintainers, reliably create a strong plugin ecosystem for our plugins, considering versioning strategies and scaling this across the entire Backstage ecosystem? Heikki believes active communication with users is key. He strives to answer issues for his Q&A plugin within a day, ensuring users know the plan for fixes or new features.

Peter added that while communication is vital, it’s also okay to say no to feature requests if they don’t align. He also brought up the idea of consolidating plugins. Instead of 15 different GitHub plugins or 20 AWS plugins, we should strive for single, comprehensive plugins that cover broad areas. This approach could foster larger, more cohesive communities rather than splintering efforts.

⚡ Lightning Insights: Best Practices from the Repo Trenches

In a rapid-fire round, the panelists shared quick lessons on ownership, testing, and dependency management:

  • Paul: Advocated for repo-level workspace tooling and skeletons to easily scaffold new plugin repositories, especially for companies unable to contribute directly to the community repo.
  • Aramis: Suggested leveraging GitHub Actions for quick plugin development setup. He also highlighted how OpenAPI tooling, by tying backend plugins to a schema, provides stronger guarantees against breaking changes and smoother API evolution.
  • Heikki: Recommended integrating end-to-end testing into plugin skeletons, noting its effectiveness in catching bugs, a practice currently more prevalent in the core Backstage repository.
  • Peter: Proposed a dedicated documentation site for community plugins, moving beyond simple READMEs to offer more comprehensive guidance.

🗣️ Audience Spotlight: Your Burning Questions Answered

The panel wrapped up with an engaging Q&A session, addressing some critical concerns from the audience:

  • Q: How do we maintain UI consistency with the new Backstage UI, which changes frequently with major releases?

    • A (Paul): While it’s been volatile, the Backstage UI has stabilized recently. Keep up-to-date with official releases. Use UI snapshots when updating plugins and implement before-and-after compare functionality. Everyone will eventually transition to Backstage UI, so open an issue in the core repo if you spot anything missing.

  • Q: Many plugins are forked internally rather than contributed upstream due to ease. Are there efforts to encourage upstream contributions?

    • A (Aramis): It’s a balance. Open-source development is often slower than internal, rapid iteration. Forking is viable if a plugin is feature-complete or won’t accept your changes. However, if the ecosystem is evolving, maintaining a fork can be costly. The ideal approach: develop internally, validate what works, contribute those improvements back upstream, and then switch your fork back to the main branch.

  • Q: With over 250 plugins in the marketplace, many are unmaintained. Is there a policy to archive inactive plugins?

    • A (Peter): Yes, the community is exploring an automated process to mark plugins as active, inactive, or archived. Some community plugins currently lack official owners, which forces maintainers to step in. They are actively seeking individuals to take ownership of these plugins, as maintaining unfamiliar tech (like a Jenkins plugin if you don’t use Jenkins) is challenging.
    • A (Aramis): A plugin quality score could also be beneficial, allowing users to see supported versions without needing to deep-dive into the code.

  • Q: Our teams build frontend plugins in external repositories, pushing to npm. Templating these repos and keeping versions updated is difficult. Is there a better way?

    • A (Paul): Unfortunately, there’s no perfect solution right now, but the community is exploring options. He highlighted the need for self-service templating for companies managing hundreds of plugins.
    • A (Aramis): He inquired if they were using dynamic plugins (MF and backend) as an alternative to npm versioning. Dynamic plugins could allow teams to consume a plugin simply by pointing a Docker container at a URL, isolating the versioning lifecycle. (Paul noted an upcoming talk on this topic!)
    • A (Peter): Shared their internal strategy in a monorepo: extending yarn new to create templated plugins. This not only streamlines development but also enforces consistent styling, preventing plugins from feeling like “different portals.”
    • A (Paul): Added that with Backstage 1.49, the CLI is now modular, creating a prime opportunity for someone to contribute a plugin to help with skeleton creation.

What an illuminating discussion! The path to a perfectly healthy Backstage plugin ecosystem is a journey, not a destination. It requires collaboration, clear communication, robust documentation, and a willingness to adapt. By embracing these insights, we can collectively build a more sustainable, high-quality, and enjoyable experience for everyone in the Backstage community.

Thank you to our incredible panelists and moderator for sharing their wisdom! Let’s keep building! ✨

Appendix