You’d think we would be running out of terrible/great (delete as applicable) 80s songs to try and shoehorn into the titles of these blog posts. Turns out, not quite yet!
“How can I help?” is a phrase often used in Open Source projects by enthusiastic users and developers. There are a lot of moving parts that make up the snap ecosystem. Which means there’s a whole bunch of places to get involved!
Finding somewhere to get started can be daunting, but we’re here to signpost your way. Whatever your skill level, and time available, we’re sure we can find an opportunity for an enthusiast to make their mark.
Let’s start with snaps themselves. Typically, users will care more about the software they use on a daily basis than the tools that builds it, or the servers that host the bits. Users of the Firefox snap care about the experience of that application, whereas a VLC user is more interested in media playback or video capture using that application.
As such providing feedback to the publishers of those snaps is a great first step on the way to getting involved. Many snap publishers have pre-release or beta builds of their software in different channels in the Snap Store. For example, Firefox and VLC both have newer – possibly unstable – versions of their applications in the beta channel.
$ snap info firefox
summary: Mozilla Firefox web browser
latest/stable: 80.0.1-1 2020-09-01 (418) 172MB -
latest/candidate: 80.0.1-1 2020-08-31 (418) 172MB -
latest/beta: 81.0b8-1 2020-09-08 (422) 167MB -
esr/stable: 68.12.0esr-1 2020-08-24 (412) 220MB -
esr/candidate: 78.2.0esr-1 2020-08-24 (413) 170MB -
$ snap info vlc
summary: The ultimate media player
latest/stable: 3.0.11 2020-06-16 (1700) 304MB -
latest/candidate: 3.0.11 2020-06-05 (1700) 304MB -
latest/beta: 220.127.116.11-77-g19987b81fc 2020-09-08 (1884) 308MB -
latest/edge: 4.0.0-dev-13019-ge1021bba8e 2020-09-09 (1885) 352MB -
One super simple way to help those projects is to install from or refresh to the beta channel, and use those builds as your daily driver.
$ snap install firefox --beta # Install the beta
$ snap refresh firefox --beta # Refresh from stable to beta
It’s worth getting familiar with the bug reporting and feedback processes for the software you care about. It’s also a good plan to find out where the developers and QA team hang out online, so you can discuss potential issues with them when they occur.
If you do encounter issues with the beta builds, have a conversation with the publisher, search for existing issues, or file an issue if one does not already exist. Get involved before the application enters the stable channel, and therefore help improve the application quality/stability before it reaches a wider audience.
If the issue turns out to be a show-stopper for you, it’s trivial to switch back to the stable channel until it’s fixed.
$ snap refresh firefox --stable
Snap Store Desktop
Beyond specific snaps, there’s a further commonly used component in the snap ecosystem – the graphical Snap Store desktop application. Not to be confused with the (identically named) backend “Snap Store”, the graphical desktop application is based on the GNOME Software code-base. In Ubuntu, the application is referred to as “Ubuntu Software” on the desktop icon. This is for consistency in documentation and usability with previous releases.
Prior to Ubuntu 20.04 LTS, Ubuntu Software was shipped as a deb from the Ubuntu archive. In Ubuntu 20.04 LTS, the default graphical storefront was changed to the Snap Store code base, supplied as a snap itself. On other Linux distributions, the snap-store snap can be installed to provide a graphical frontend to the Snap Store.
Contrary to popular opinion, a fair number of Linux desktop users prefer a graphical user interface to browse application stores, and manage the installation of software. As such, the Snap Store GUI Frontend is an important component.
One simple way to contribute is to use the Snap Store GUI Frontend whenever managing installation and removal of snaps. It also has a permissions option to enable users to configure interface connections. Using this method may uncover bugs that many expert users wouldn’t see, as they often prefer command-line methods for software package management.
Snap Store Web
The most visible public face of snaps is the Snap Store Web. Every snap in the store has its own page which details metadata, installation options, documentation, and sometimes a global user map, & usage across Linux distributions. There’s a bunch of opportunities here.
Sometimes, applications have outdated metadata, missing or old screenshots, incorrect license information, or other errors. It’s up to the publisher to ensure that this information is correct. Oftentimes it can be overlooked, and so it’s useful to have many eyeballs on it, providing feedback to the upstream publisher where the data is incorrect.
The Web frontend is frequently updated with design, bug, and feature fixes. As such, bugs may be introduced into the store experience. Those can easily be reported and discussed in the relevant project(s) on GitHub.
With snapcraft, we’re heading further towards the developer end of the scale. Snapcraft is one of the primary ways we recommend developers build and publish (their) snaps. As such, it’s a crucial part of the build and publish process. It gets a lot of testing before release, but as with all software, bugs can be introduced in each new release.
Snapcraft is a relatively complex codebase, which features plugins to support many common build systems. Snapcraft has to support diverse ways to build software. With this in mind, it can benefit from more developers trying new versions out, before they hit the stable channel.
There are some simple ways to exercise new versions of snapcraft in the candidate channel. Running the online snapcraft tutorials in the documentation or trying to rebuild existing publicly available snaps are both worthwhile activities.
In addition, when new features in snapcraft are announced on the forum, the developers welcome new users exercising the added functionality.
Snapd is what you might consider the essence of snaps. It’s a background service, which mediates the downloads of snaps from the store, manages their installation, removal, takes snapshots and more. Snapd is written in Go, and is a pivotal component in the stack.
Snapd needs to run reliably and efficiently on devices from IoT through desktop and up to the cloud. Therefore the snapd release cycle is somewhat conservative.
Building snapd is surprisingly easy when using snapcraft. The source repository contains the snapcraft.yaml required to rebuild snapd, as a snap itself. This makes iterating on the snapd codebase in a clean environment very easy.
|Project||Software Repository||Issue Tracker|
|Snap Store Desktop||Launchpad||Launchpad|
|Snap Store Web||GitHub||GitHub|