This week I was lucky enough to be invited along as a guest to a Canonical sprint in Heidelberg, Germany, to topic of which is the Snappy packaging system(http://snapcraft.io), pioneered by the folks here at Canonical.
I like to think I keep up with current events pretty well in the Linux world and it hadn’t escaped my attention over the previous couple of months that there had been a lot of negative press surrounding the Snappy packaging format quoting a lot of Redhat based distros. As with Juju, I turned up to an event not fully understanding the project, not fully understanding its purpose, or for that matter, why I’d been invited!
The thing that struck me on the first day was the diverse group of people here at the sprint. Of course the majority were Canonical employees, but there were people here from a number of different Linux distributions and a number of big Linux based open source projects and of course people like me. Canonical had really excelled in making sure people from across the Linux world had been invited to attend and it really showed.
Day 1 was like a who’s who of people who I’ve known virtually for many years in the Linux community but never seen in the flesh, so once I’d picked my jaw back up off of the floor and got to work, it was very interesting sitting in a number of discussions where very clever people who understand how the Linux systems all inter-operate , figure out how to make snappy work across the whole Linux ecosystem.
So I guess at this point it’s worth mentioning what Snaps are. Originally developed by Canonical for their phones and mobile devices, Snaps allow programs to be run in a confined environment wherever the snap daemon runs. So you can run the same code on Ubuntu Classic or Core, Arch, Redhat etc without any modifications. How can this be assured? Snaps allow developers to bundle all the dependencies they require in a single package, they can also delegate certain dependencies back to the underlying system. To ensure data security and enhanced platform security, Snaps are also sandboxed and their file system access tightly controlled. For application developers, this is great because it allows them to build once, run everywhere. For end users it also allows them to roll back should they mess up an upgrade. Not only that but they will also be able to restore all the old configuration data at the same time!
Back to the sprint, day 2 I wanted to try some stuff, it’s all well and good sitting in planning meetings but I still didn’t understand how it all worked. So I started “snapping” a couple of Java applications to see how hard it was… it wasn’t, which is great. But I was also aware that to get people using Snaps there needs to be a simple way for them to be able to build and integrate Snaps into their build chain. They don’t want to have to learn lots of new stuff because open source developers generally have enough on their plate. I’m a Java developer, so I wanted a way for me to be able to leverage my existing Java builds but package up the finished artifacts into something that I can deploy instantly. To fit that requirement I started work on my first Maven plugin: https://github.com/buggtb/snappy-maven-plugin . This is very much work in progress but it means I can now build snaps for all my Java apps, hopefully more build tools for different build systems will appear like this to help onboard developers with minimum disruption to what they already do.
Wednesday night was a show and tell night and there was lots of cool stuff on display, I ended up being the last talk of the night and presented “Don’t forget the end users” (https://docs.google.com/presentation/d/1UdKSsuXpYSy25V9HuxnqgzQRmlC1DEtLJUgEY-5PDoc/edit?usp=sharing), I took a bit of a risk and trolled Mark slightly whilst he was in the room, I hope he see’s the funny side otherwise I’m not being invited back to another Canonical event! But I think the message was important, when you’re going and building all this cool new stuff, don’t forget, to make them a success you need the buy in and support of a diverse community of developers. If you just inflict new build tools and standards upon them, they will push back, you need to engage and work with them to make sure they understand why the new platform is going to be of benefit to them!
One interesting take away we had from chatting on Wednesday night, and I think Juju suffers from the same affliction, is the naming.
- Juju Charms
and so on. Canonical need to do more to make it easier for both developers and end users to find and ingest the information they need.
Snaps could easily be the future of packaging on the Linux platform, but there is competition from Flatpak and others. Engaging the communities and proving its worth is key and they are off to a good start. Similarly ease of usage and access for both developers and end users is very important.
Finally, I’d like to thank Mark, Claire, Dustin for inviting me to the event, I’d also like to thank everyone I engaged with over the last week in understanding and helping me realise how useful snaps are going to be.