Skip to main content

Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting us. A member of our team will be in touch shortly. Close

  1. Blog
  2. Article

Alan Pope
on 25 September 2020


The Snap Store has been designed to enable upstream developers and enthusiastic community contributors to publish snaps. As with most Linux packaging solutions, the wider community are often responsible for starting and maintaining software packages. This is a double-edged sword, especially for humans with limited life spans and other shiny things to steal their attention.

If a community contributor decides to move on from maintaining software packaging, has too many other things on their plate, or life just gets in the way, it’s not necessarily a problem. Users are appreciative that someone packaged up their favourite application, but can get upset quickly if that software is no longer updated. Snap publishers who are overwhelmed or busy doing other things have some options here.

Automate yourself out of existence

We recommend the first course of action is to ensure snaps are published via automated tools to reduce manual steps in the publishing workflow. Using the snapcraft build service or 3rd party tools such as Travis or Circle CI will reduce the workload on a typical snap publisher. A well crafted snapcraft yaml will often result in automated builds getting published in the edge channel before the publisher even notices. All that’s left for the publisher is to test the edge build and then publish to beta, candidate or stable channels as appropriate.

Share the love

The Snap Store has a concept of “Collaborators”. The responsibility of maintaining a snap published in the Snap Store can be shared among a group of people. The maintainer of a snap can invite others to share responsibility over the publishing, metadata maintenance and release of a snap. The list of collaborators can be managed in the Snap Store web dashboard. This can help to easily spread the load.

A peaceful handover of power

When the maintainer of a snap has decided to focus on other things, we can handle that too. Where possible, we recommend snap publishers transition their applications to another individual or organisation rather than let them become outdated. Ideally snaps should be published in the Snap Store by the upstream project. So the first port of call would be to offer to transition the snap upstream. Sometimes this isn’t possible if the developers are unable to take on the additional workload themselves, however small that might be.

Alternatively we recommend seeking out another enthusiastic, trustworthy community member to take on the mantle of maintaining the snap package. Often just starting a conversation on the upstream issue tracker, or in their real-time chat of choice will yield good results. Someone keen may even be found within the wider community of the upstream project.

If that fails, a further option would be to find someone within the snapcraft community. There are a group of dedicated snapcraft enthusiasts who love the challenge of maintaining new snaps, and taking on existing ones if necessary. They can be found in the snapcraft forums. Start a new thread, looking for a new maintainer, and typically one can be found.

Once a new maintainer is found, the transition from one publisher to another can be actioned via the forums. Start a thread in the store-requests category indicating who the snap(s) are moving from, and who to. The store admins team can do the necessary validation checks behind the scenes, and move the snap(s) to their new home. It’s then up to the new maintainer to hook up whatever build or CI system is needed to seamlessly continue publishing of the snap.

Note that when a snap is transferred, by default the previous maintainer is kept as a collaborator on the snap. They can continue to be involved but without being named as the publisher, or they can be removed as a collaborator, and no longer maintain the snap.

So the take away from this is, if you’re feeling overwhelmed and need to offload maintainership of snaps to others, don’t panic. We can help, and our community can too.

Photo by Osman Rana on Unsplash

Related posts


Igor Ljubuncic
16 June 2023

Snapcraft 8.0 and the respectable end of core18

Ubuntu Article

‘E’s not pinin’! ‘E’s passed on! This base is no more! He has ceased to be! ‘E’s expired and gone to meet ‘is maker! ‘E’s a stiff! Bereft of life, ‘e rests in peace! If you hadn’t nailed ‘im to the perch ‘e’d be pushing up the daisies! ‘Is software processes are now ‘istory! ‘E’s ...


Igor Ljubuncic
21 March 2023

Craft team welcomes you to another episode of its adventures

Ubuntu Article

Welcome to the second article in the Craft team saga. Previously, on Craft Team, we gave you a brief introduction into the team’s function, we announced our desire to share the ins and outs of our day-to-day work with the community, and gave you an overview of roughly two weeks of coding and fun. Today, ...


Igor Ljubuncic
16 December 2022

Snapcrafters: 2022 wrap-up

Community Article

This article was written by Merlijn Sebrechts and Dani Llewellyn from the Snapcrafters community. ===== Last year, we officially re-launched the “Snapcrafters” initiative. We’re a community of volunteers who build and maintain unofficial snap packages. Although snaps make it easy for developers to publish their software directly to users, ...