Engineering Culture, Developer Experience

Sharing our Backstage Plugins Journey: Lessons learned from open sourcing 


Frida Jacobsson sharing our journey of open-sourcing the Backstage plugin.

There have been many happenings within the Axis Backstage™ team lately. In November 2023, we took the step of open sourcing our internal Backstage plugins to the world. Since then, our repository has quickly become one of the most visited in our GitHub organization.

In this blog post, I will share why the Axis Backstage team decided to start our open source journey (and why we almost didn’t). I will describe how it has boosted us as a team and made us better developers. Additionally, I’ll discuss key factors to to consider when initiating your own open source projects. 

Our Journey

As Backstage developers, we work with Axis own instance of Backstage. Backstage is a developer portal initially developed by Spotify to improve discoverability of developer information within organizations and minimize developers’ context switching. Our team has been actively involved in contributing to the Backstage community since early 2022. 

In October 2023, the Spotify developers and Backstage maintainers announced that the main Backstage repository in GitHub had grown too large to effectively manage and maintain. Consequently, they had decided to no longer accept any further external plugins directly in the main repository. Faced with this decision, the Axis Backstage team had two options: To no longer share our internal plugins with the community or start open sourcing our plugins in our own repository. 

We will not sugarcoat it: The thought of creating an open source repository felt demanding at first. Open source work requires time, both for initial setup and ongoing maintenance. When you own the repository, you need to handle code maintenance, contributions, version control, and community building. This has all been done for us when we were only contributing to the main repository. In addition, the idea of receiving more bug reports and issues was not very appealing to us. 

However, we did decide to create our own AxisCommunications/backstage-plugins repository, and today we are very happy with our decision. Let me tell you why: 

1. Help from the community

Open sourcing cultivates a community, fostering collaborative development, and encourages contributions and bug fixes. And actually, more reported issues mean your products are being used, which is a wonderful feeling. 

2. Reputation and building trust

Open sourcing can strengthen your company by improving its reputation, gaining visibility, and setting a positive example. It can also increase the likelihood that other companies will choose to open source their plugins (plugins that you can benefit from!). 

3. Helps accelerate development 

By instilling a sense of ownership and responsibility among developers, open sourcing motivates individuals to strive for excellence in the code base. It fosters teamwork and serves as a powerful motivator for continuous improvement.  

4. Great motivator

With the code exposed to the public eye, you are suddenly even more motivated to make the project the best possible. Therefore, open sourcing makes us even more thorough and methodical as developers. It is suddenly a bit embarrassing to push your back-of-the-closet code or to leave your plugin without any tests. A little bit of shame can really inspire you to make positive changes and improvements. 

Lessons learned

Since the publication of our Axis Backstage plugins repository, we have now published four plugins in total. GitHub has been integrated into our development workflow, a GitHub CI/CD-pipeline has been set up, and our contributing guidelines and our Code of Conduct have been created. Our repository has already had contributions and feature requests from several different organizations. Every Thursday, there is a new release of our plugins.  

Reflecting on our journey, there are some insights and aspects we wish we had considered beforehand. Hopefully these can support you when you decide to dive into open sourcing: 

1. How much time should you spend? 

When prioritizing your new open source tasks alongside other assignments, it’s helpful to have a predefined plan with set limitations in place beforehand. For instance, how much time do you plan to dedicate to resolving issues that will help other organizations? What types of issues should be prioritized as high? What can wait?  

2. How should you handle releases and contributions? 

Documenting details about how to contribute to your repository is important for your community. For instance, should contributors create a Pull Request (PR) directly, or consult with you first to see if you are even interested in the change? 

Another helpful aspect is ensuring an efficient release plan. For instance, in our open source repository we have to manage separate releases for multiple packages. To handle this, we use the open source tool Changesets to manage our versioning and changelogs. This requires our contributors to describe, with every Pull Request, the changes they’ve made and how they should be integrated into releases. As a result, our team can automatically generate release logs from these changesets, eliminating the need for manual intervention and saving us valuable time.

3. How to make it as easy for others to contribute?

Remember, you don’t have to fix everything alone. Instead, empower others to contribute! By creating a self-sufficient community and making it easy for everyone to clone the repository and start contributing, people can create what they need independently. It saves time for both you and them.

Ensuring a safe and clear coding environment for contributors is another essential aspect. This involves integrating lint checks, code tests, prettier checks, and preventing your contributors from pushing code when they don’t comply with these standards. By doing so, you avoid having insufficient reviews become a distraction for you. Your team’s maintenance load will decrease as you won’t need to rectify numerous minor issues manually, thereby saving time. In addition, make sure the developer environment is easy to set up and run. We made it possible to run each plugin individually with mocked data, which turns out to be of tremendous help when you want to test your new changes.

Sign off

What does the future have in store for the Axis Backstage team? First, we are looking to develop more plugins and expand our presence within the Backstage community. It would be great if other Axis employees could join in and develop their own plugins. We are also very thankful for all the contributions that has been made to our repository, and we are happy to be continuing working together with the community. 

Thank you for reading.



  • Frida Jacobsson

    I am a web developer who specializes in improving the developer experience for AXIS OS developers. When I’m not coding, I enjoy hiking and camping. I’m also a hobby hamburger reviewer, always on the lookout for the perfect burger.

    View all posts