Skype is used by hundreds of millions of users globally to make free video and voice calls, send files, video and instant messages. It has been two years since Skype first launched to Linux users on the Electron framework. This brings us to the present day, where the team recently launched their first snap and at the recent Snapcraft Summit, Senior Software Engineer Jonas Tajrych explains Skype’s progress from first discovering snaps in 2016 to its release.
I was contacted by Canonical in 2016 close to when snaps were first launched. Back then, it was impossible to get Skype working as there was no classic mode available and we were missing a lot of critical interfaces. Then in September 2017, I joined the Ubuntu Rally in New York where we got the snap working for the first time. Martin Wimpress at Canonical had started working with us directly on it a few months before which helped a lot.
We see snaps as a way to access more users. For Linux maintenance, we must work across taking into account the different distributions and users to accommodate. Therefore maintaining is not that simple. The benefit of snaps means we don’t need to test on so many platforms – we can maintain one package and make sure that works across most of the distros. It was that one factor which was the driver for us to invest in building a snap.
In addition, automatic updates are a plus. Skype has update repos for .deb and rpm which means previously we were reliant on our users to update manually. Skype now ships updates almost every week and nearly instant updates are important for us. We are keen to ensure our users are running the latest and greatest Skype.
Many people adopt snaps for the security benefits too. We need to access files and devices to allow Skype to work as intended so the sandboxing in confinement mode would restrict this. Saying that, security is important for us as we need to ensure users have the latest version as mentioned.
In addition to those mentioned above, we couldn’t get all dependencies installed that were needed. With snaps, this should go away as all dependencies are packaged inside.
We were already using .deb and rpm so snaps was a 3rd way of doing it and quite comparable. We do now have to build on machines running Ubuntu 16.04 or higher when before we were building on Debian.
Our snap has recently launched but we certainly see the store providing benefits. Specifically, it is a better presentation than just having a repository. Having attended the Snapcraft Summit and seeing the future plans for Snapcraft.io and the store, then things will only improve. Although the store wasn’t originally the selling point for us, it does increase discoverability in addition to our own website.
Maintenance costs should be lower as prior to the snap, we could only target major Linux distros and couldn’t guarantee it works on all. The snap opens the market for us. We often find people are working on unsupported distros which is an issue for us at the moment – snaps will help resolve that.
We are using stable only. However, we already have a special track for Insiders who provide early feedback to us. That is invaluable.
I’m looking forward to the store changes. Snapcraft is good but the documentation could be better. Overall though, everything is pretty ok as is.
Just do it! I hope it will pick up and grow as a format. Developers now have a motivation to adopt snaps and create unification. Personally, I hope it will replace other packaging systems and ideally we would just have snaps for Linux. It’s a promising format.