Allow me to tell you about Backstage in the form of a story. Assume you're at a medium-to-large-sized company, in a team tasked with boosting developer productivity. You've developed a kick-ass pipeline to calculate test flakiness based on historical build logs and some data from your internal userinfo service. Problem is, userinfo has suddenly started exhibiting p99 response times in the 10s of seconds. It's not feeling well.
You go to backstage.yourcompany.net and search for userinfo. You reach the overview page for the service. It shows a ton of information, some of it pertaining to who owns and operates the service. Apparently it's the devcore team, they're on #devcore-support on slack according to the page but they're in the US west coast timezone so they're asleep. Well you are using the PagerDuty plugin in Backstage so there's a big "page us" button right there.
So now you've got the issues solved and you need to expose the pipeline output somehow. Cool, you go to backstage.yourcompany.net and click "Create", and select one of the templates. It scaffolds a Go service in your GitHub org, according to your company's best practices. All the builds and deployments are already set up and hot. You add some code to your service and shortly it's up and running and serving the pipeline output with caching out of S3. You check backstage.yourcompany.net to see how all aspects of your service's runtime status is looking. All good. Now, how do you actually get that useful data into your company's other devs' hands?
Well you COULD make an entire microsite, or some CLI tool orrrr... Come to think of it, they are already all using backstage.yourcompany.net, and there's already an integration in there showing all builds for all services, and it has all of the utilities and auth and bells and whistles already in place for you. So you make an internal backstage plugin. You find that it's pretty much a matter of cloning your internal backstage repo, running a create-plugin script, and boom you are up and running. You add a data source feeding off of your new Go service, you add a column to the builds table ... and you have your own team review and merge it because it's covered by CODEOWNERS. And everybody rejoiced and told you how useful this new column was to them. You start getting a bit famous on your internal Slack, actually.
Now you are getting greedy. You feel that actually, this plugin could be useful to the general public - as long as the build logs are in a known format, you can eat them. You start open sourcing the pipeline, and the service - and, critically, also the backstage plugin.
This is how things are internally at Spotify today. What we released here today is not this entire story yet, but we are lifting more and more out into the open at a rapid pace. Check the repo and microsite for more info, and hold tight.
More is coming.