Back in 2014, platform engineers at Spotify identified a problem: the number of internal tools was growing rapidly, and as a result engineers around the company were struggling to find the tools and information they needed to work efficiently. Reducing the number of tools is the obvious way to address this problem, but how do you consolidate all the tools in one place without disempowering and slowing down the teams working on them?

Fast-forward 10 years, and Backstage has had a massive impact on developer productivity at Spotify, making teams that use it heavily about 2.3x more active on GitHub, and 30% more productive overall. And it doesn’t stop there: in 2020, we open-sourced the Backstage framework to help other companies build their own internal developer portal – and thousands of companies are using it today.

Backstage is now a central pillar of our software development workflow: it catalogs our software ecosystem, helps our engineers follow best-practices and measure the tech health of the components they own, and centralizes and streamlines repeatable tasks. But how can we bring all this together in Backstage? And how does the value we get from it internally translate to adopters of the open-source framework? The answer is plugins.

In this talk we explain how the Backstage plugin system brings disparate pieces of functionality together in one place, helping platform teams to build independently while still shipping a cohesive product for our engineering teams to use. We’ll explain the architecture of the plugin system, and walk through some specific examples of how Backstage (and individual plugins themselves) can be extended and interconnected, and how we make use of this to distribute ownership at Spotify.

Finally, we’ll talk about how the extensibility model of Backstage helps companies offering commercial products in the IDP space add value to the open-source Backstage offering, from specific plugins to entirely new IDP products like Spotify Portal for Backstage.