Een paar weken geleden kondigde Canonical cross-distributie ondersteuning aan voor Snap applicatie delivery mechanisme, een die mobiele, desktop en server-gebaseerde applicaties zou kunnen ondersteunen. De aankondiging maakte enkele pluimen los binnen de Linux-gemeenschap, die weinig bewijs zagen van andere Linux distro’s die Snaps ondersteunen.
Snap is Canonical’s poging om de app verpakking en levering mechanisme op het Linux-platform te verfijnen. De oorsprong van Snap vindt zijn wortels in Click, een oplossing die Canonical creëerde voor zijn mobiele platform terug in 2014, om de complexiteit van het leveren van apps aan Ubuntu-telefoon- en tabletgebruikers aan te pakken, een ecosysteem dat veel verschilt van desktops en servers. Bovendien moest mobiel ook apps beperken en sandboxen, zodat ze niet het hele platform in gevaar zouden brengen.
Click stelde ontwikkelaars in staat om alle afhankelijkheden in een enkel app-pakket te bundelen, zodat gebruikers en ontwikkelaars zich geen zorgen hoefden te maken over conflicterende systemen en app-bibliotheken. Het stelde ontwikkelaars in staat om de nieuwste bibliotheken in hun apps te gebruiken, om nieuwe functies aan te bieden, omdat ze werden losgekoppeld van de bibliotheken die op het systeem waren geïnstalleerd.
Beyond Mobile to Servers and IoT
Click evolueerde in Snap en Canonical breidde het potentiële gebruik ervan uit naar de server, cloud, Internet of Things (IoT) en desktop-ruimtes. Met de release van Ubuntu 16.04 in april, bracht Canonical officieel Snap naar de Ubuntu-desktop.
Canonical ontwikkelt ook Snappy Ubuntu Core, een klein Linux-gebaseerd besturingssysteem voor grootschalige cloud container implementaties, IoT-apparaten en nog veel meer, en alles wat overgangsupdates en een kleine voetafdruk nodig heeft. Snappy Ubuntu Core werkt min of meer zoals Google’s Chrome OS en CoreOS waar het tijdelijke image-gebaseerde updates biedt voor het systeem en apps die kunnen worden teruggedraaid. Tegelijkertijd biedt het de opsluiting die bekend is in de containerwereld.
Snap is de ziel van die technologie.
The Linux Mess of App Delivery
Het bestaande app delivery model op Linux heeft veel gebreken. De Linux-wereld is meestal verdeeld in twee kampen van app verpakking: rpm en deb. Ook zijn er verschillende versies van dezelfde distributies die verschillende bibliotheken gebruiken, dus het wordt een hele uitdaging voor app-ontwikkelaars om apps voor Linux te verpakken.
Dientengevolge kunnen app-ontwikkelaars niet profiteren van de nieuwste bibliotheken en meer functies bieden aan hun gebruikers als de distributie nog steeds oudere bibliotheken gebruikt.
In de meeste gevallen verpakken open source app-ontwikkelaars hun apps niet voor distributies. Populaire of reeds lang bestaande apps worden meestal verpakt door de distro-ontwikkelaars. Nieuwere of minder populaire apps worden ofwel door de upstream-ontwikkelaars verpakt voor elke distro die ze willen ondersteunen, of ze worden helemaal niet als distropakket aangeboden. Wanneer een nieuwe versie van een app wordt uitgebracht, testen deze ontwikkelaars de app en maken het dan beschikbaar voor de distro. Zoals je ziet, in plaats van dat de app-ontwikkelaar slechts één app schrijft voor het hele platform, wat in dit geval Linux is, zijn er veel mensen die die app naar gebruikers brengen.
Het voegt meer complexiteit toe.
Er zijn gevallen waarin Windows en MacOS onmiddellijk de nieuwste versies krijgen, omdat apps worden verpakt door primaire ontwikkelaars, terwijl Linux distro’s een tijdje kunnen duren. Dat is niet alles; sommige distro’s krijgen ze snel, en sommige moeten weken of maanden wachten.
In het geval van commerciële apps zoals Skype, Dropbox, Chrome, is het de taak van de primaire ontwikkelaar om apps te verpakken en binaries voor verschillende distributies aan te bieden. Veel apps werken niet op oudere, nog ondersteunde, versies van veel distributies.
In een woord, het is een puinhoop.
Zelfs de maker van Linux, Linus Torvalds, is niet blij met het bestaande app delivery model op Linux. Hij biedt geen binaries van zijn apps voor het Linux-platform aan vanwege deze puinhoop. Dirk Hohndel, de beheerder van Subsurface (een project gestart door Linus), legt uit: “De huidige situatie met tientallen distributies, elk met verschillende regels, elk met verschillende versies van verschillende bibliotheken, sommige met bepaalde bibliotheken die ontbreken, elk met verschillende verpakkingstools en verpakkingsformaten … dat vertelt app-ontwikkelaars in feite ‘ga weg, concentreer je op platforms die zich bekommeren om applicaties.
“Applicatie-packaging is enorm belangrijk, maar dat geldt ook voor de herkomst en het onderhoud van alle betrokken onderdelen,” beaamde Gunnar Hellekson, directeur productmanagement voor Red Hat Enterprise Linux.
Snap is ontworpen om enige orde in deze stand van zaken te brengen. Maar of het zal worden overgenomen is een geheel andere vraag.
Hellekson betoogde dat tools zoals Snap niet “op magische wijze interoperabiliteitsproblemen tussen Linux-distributies oplossen, en in feite meer verantwoordelijkheid voor onderhoud en beveiliging verschuiven naar de leveranciers van toepassingen. Op deze manier kunnen ze het ontwikkelen op Linux nog moeilijker maken, ondanks de vele voordelen voor de gebruikers.”
“Snap’s voordelen zijn direct gerelateerd aan zijn nadelen … in essentie is Snap het equivalent van static linking – het is handig aan de ene kant, creëert duplicatie en uitdagingen met betrekking tot beveiliging (en security patching) aan de andere kant,” zei Gerald Pfeifer, SUSE vice-president van producten en technologie programma’s.
Hoewel niet iedereen dezelfde mening is toegedaan. Brandon Philips, mede-oprichter en chief technology officer van CoreOS, vertelde ons dat containers de toekomst zijn van apps op Linux. Maar Docker-containers kunnen niet overal worden gebruikt. Ze hebben hun beperkingen. Wat we nodig hebben is een container-achtige oplossing, iets als Snap.
Tijdens een ander interview vertelde vooraanstaand Linux kernel ontwikkelaar Greg Kroah-Hartman ons dat Android al acht of negen jaar containers doet “voor je applicaties. Elke applicatie draait in zijn eigen namespace. Het kan niet daarbuiten kijken. Dat is de manier waarop je het moet doen. Dat is de toekomst van Linux en de manier waarop systemen werken.” Hij zei dat Snap hetzelfde concept is, hetzelfde idee.
Snap Goes Cross Platform
Het succes van Snap hangt sterk af van de adoptie ervan door de grotere open source-gemeenschap. Wat heb je aan een app-formaat als niemand het gebruikt? Als een Ubuntu-only technologie, die misschien niet eens officieel wordt ondersteund door zijn afgeleiden zoals Linux Mint, KDE neon of elementary OS, zou Snap een niet zo succesvolle carrière tegemoet kunnen zien.
Toen Canonical Snap aankondigde, beweerde het in een persconferentie dat het met verschillende distributies heeft gewerkt om ondersteuning voor Snap toe te voegen.
Canonical zei dat Snaps van nature beschikbaar zijn voor Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity, en Xubuntu. Canonical werkt ook aan de validatie van Snaps op CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt en Red Hat Enterprise Linux.
Canonical en SUSE zijn momenteel niet betrokken bij de ontwikkeling rond samenwerking op Snaps, en in feite lijkt het erop dat dit niet het resultaat was van een open ontwerp en ontwikkeling door de gemeenschap,” Gerald Pfeifer, SUSE.
De aankondiging van Canonical dat ze met andere distributies hebben samengewerkt, leverde enige kritiek op van sommige leden van de open-sourcegemeenschap. Fedora-ontwikkelaars waren niet blij met deze aankondiging en bekritiseerden Canonical door te stellen dat er geen enkele samenwerking was tussen de twee projecten.
Toen we navraag deden bij Canonical-oprichter Mark Shuttleworth over deze beschuldigingen, antwoordde hij: “We hebben briefing gedaan met het Red Hat-desktopteam en staan altijd open voor samenwerking met alle Linux-distributies om Snaps mogelijk te maken.”
Dit bleek echter nieuws te zijn voor Red Hat, die de Fedora-distributie onder zijn hoede heeft.
“Terwijl we met Canonical samenwerken in verschillende gemeenschappen, waren we net zo verrast als iedereen toen ze onze betrokkenheid bij dit specifieke initiatief aankondigden. We staan open voor meer discussie hierover, en om te zien hoe de Linux-gemeenschap in het algemeen wil samenwerken,” zei Hellekson.
SUSE-functionarissen bagatelliseerden ook elke samenwerking. “Canonical en SUSE zijn momenteel niet betrokken bij de ontwikkeling rond samenwerking op Snaps, en in feite lijkt het erop dat dit niet het resultaat was van een open gemeenschap ontwerp en ontwikkeling,” zei Pfeifer.
Wat leek te zijn gebeurd is dat Canonical samenwerkte met sommige ontwikkelaars, misschien slechts een handvol, van andere projecten en ze hielpen bij het verpakken van Snaps voor andere distributies.
Canonical is niet perfect
Een deel van de pushback die Canonical heeft gekregen kan een bijproduct zijn van hoe het zaken doet.
Vooreerst, andere Linux bedrijven, zoals Red Hat en SUSE, handhaven een zeer duidelijke scheiding van bevoegdheden als het gaat om Fedora en openSUSE. Fedora en openSUSE zijn tamelijk onafhankelijke, door de gemeenschap gestuurde projecten waar beslissingen worden genomen door de leden van de gemeenschap en niet door de sponsorende bedrijven.
In tegenstelling, Ubuntu is een Canonical product dat toevallig ook een gemeenschapsproject is. Daardoor heeft Canonical, in tegenstelling tot openSUSE en Fedora, directe controle over Ubuntu. We hebben al geleerd in het geval van ownCloud; het is echt moeilijk om een evenwicht te bewaren tussen de behoeften van de gemeenschap en het bedrijf; het eindigt vaak in een ramp zoals ownCloud.
De vraag rijst hoe men ‘werkt’ met een project?
Velen hebben ook het gevoel dat er een gebrek aan transparantie is bij Ubuntu. Veel vooraanstaande Ubuntu-medewerkers hebben hun frustratie geuit over het feit dat Canonical belangrijke aankondigingen over Ubuntu geheim hield, zelfs voor de kernleden. Ubuntu-leden hadden geen idee over Ubuntu voor Windows of het noodlottige Edge-project.
“We houden geen dingen achter,” antwoordde Red Hat CEO Jim Whitehurst op een vraag over de aanpak van dat bedrijf voor open source. “Wanneer we dingen bouwen, verbergen we het niet voor mensen om een grote onthulling te doen en te zeggen ‘hier is de code.’ Dat doen we niet. We werken in gemeenschappen vanaf dag één, de hele tijd. Ik denk dat we proberen om echt goede deelnemers te zijn, en ik denk dat dat doorkomt.”
Naast deze verschillen, staat Canonical ook bekend om het maken van een aantal misstappen als het gaat om het vrijgeven van informatie. Dit lijkt zeker het geval te zijn bij de aankondiging van cross-distributie ondersteuning voor Snap; de formulering die Fedora ontwikkelaars irriteerde was “Ontwikkelaars van meerdere Linux distributies.” Om duidelijk te zijn, Canonical heeft nooit expliciet in haar persbericht vermeld dat het samenwerkte met Fedora. En op basis van de informatie die we hebben verzameld, was er geen “officiële” betrokkenheid met Linux distro’s zoals Fedora, Red Hat, SUSE of anderen.
Dat gezegd hebbende, rijst de vraag hoe men “samenwerkt” met een project? Als een ontwikkelaar die aan een app werkt samenwerkt met een Ubuntu-ontwikkelaar, een Fedora-ontwikkelaar en een openSUSE-ontwikkelaar om die app naar die platforms te brengen, zou het dan verkeerd zijn om te zeggen dat de ontwikkelaar met meerdere distributies heeft samengewerkt om de app naar hen te brengen? Of heeft de ontwikkelaar officiële betrokkenheid nodig van projectleiders van deze distro’s om een dergelijke verklaring te kunnen afleggen? Het is tenslotte een gedistribueerde, open source gemeenschap.
Waar blijft Snap?
De grotere vraag is, zal Snap officieel worden overgenomen door andere distro’s? Dat is waar het een beetje ingewikkeld wordt. Het wordt een technologische en politieke kwestie.
Op de eerste plaats is Snap niet de enige oplossing die er is. Er zijn veel projecten die geprobeerd hebben om distro agnostische verpakking ecosystemen voor de Linux ecosystemen aan te bieden. Maar het kan moeilijk zijn om consensus te vinden binnen de Linux distro wereld. Er is AppImage en Flatpak, die geschikte alternatieven bieden voor Snap; deze projecten bestaan al veel langer dan Snap.
Dus waarom heeft Canonical deze oplossingen niet geadopteerd in plaats van te beginnen met Click of Snap?
“We keken ernaar, en ontdekten dat AppImage perfect werkt voor ‘leaf-node’ desktop applicaties,” zei Shuttleworth. Een leaf-node applicatie is een applicatie die niet hoeft te integreren met een andere app. Snap is meer ontworpen om apps met afhankelijkheden en gerelateerde applicaties te verpakken. “Snaps hebben een reeks mogelijkheden om die verbindingen te beschrijven – interfaces, stekkers en slots, evenals gedeelde bestanden enzovoort.”
Daarnaast vertelde Shuttleworth dat Snap is ontworpen voor hogere beveiligingsniveaus in vergelijking met AppImage, deels omdat het team dat aan de mobiele telefoon werkte gericht was op beveiliging en efficiëntie, en deels omdat Snap nieuwere kernelmogelijkheden gebruikt.
Flatpak zou het slachtoffer zijn geworden van de rivaliteit tussen Canonical en Red Hat toen het werd ontwikkeld door Fedora-mensen. Toen ik er naar vroeg, deed Shuttleworth het af als een project dat werd ontwikkeld door een enkele ontwikkelaar.
Dat verklaart waarom Canonical doorging met Snap.
Nu, zullen andere distro’s het adopteren? Fedora ontwikkelaars hebben al verklaard dat ze Snap niet zullen gebruiken. Een Fedora ontwikkelaar schreef op de mailing list: “We hebben natuurlijk geen plannen om Snappy te adopteren in Fedora, en in feite werken meerdere Fedora ontwikkelaars aan een concurrerende oplossing, Flatpak.”
Red Hat omarmde eerder een Canonical project voor systeem-initialisatie genaamd Upstart. Hellekson zei: “Dit zijn zeer vroege dagen voor al deze verpakking inspanningen, en we kijken ernaar uit om samen te werken met alle gerelateerde gemeenschappen om het leven zo gemakkelijk mogelijk te maken voor Linux-gebruikers.”
Naast de rivaliteit tussen Red Hat en Canonical, zijn er enkele technische problemen die andere projecten kunnen ontmoedigen om samen te werken aan Snap. Een van die redenen is dat ontwikkelaars een CLA (Contributor License Agreement) moeten ondertekenen als ze bijdragen aan het Snap-project. Michael Hall, een Canonical ontwikkelaar, zei dat een “CLA nodig is wanneer een ontwikkelaar wil bijdragen aan het Snap-project zelf. Er is geen CLA nodig om Snaps van applicaties te maken of te distribueren.”
CLA’s stellen Canonical in staat om de licentie van het project te wijzigen. Dat is gunstig voor Canonical, omdat ze een project een nieuwe licentie kunnen geven, waardoor het kan worden gebruikt met niet-vrije of niet-compatibele licenties. Ontwikkelaars houden meestal niet van CLA’s.
Frank Karlitschek van Nextcloud vertelde ons dat het CLA’s van Nextcloud beëindigt, omdat hij vond dat CLA’s geen erg goede reputatie hebben binnen de open source-gemeenschap.
Toen we Red Hat vroegen of CLA’s de samenwerking rond Snap zouden dempen, zei Hellekson: “Contributor License Agreements maken het voor ons inderdaad moeilijk om deel te nemen. Wij geloven dat eenvoudige, open source licenties een betere, meer inclusieve benadering is.”
Het antwoord van SUSE was ongeveer hetzelfde. Pfeifer zei: “SUSE engineers en medewerkers blijven bijdragen aan een overvloed aan open source projecten, zowel in bedrijfstijd als onze eigen tijd, en waar nodig hebben we CLA’s ondertekend. Echter, waar en wanneer we ook projecten starten of beïnvloeden, we proberen weg te blijven van CLA’s. We houden in het algemeen niet van CLA’s die een copyright toekennen dat organisaties in staat stelt om open source code opnieuw te licenseren met een niet-open source licentie.”
Toen we Shuttleworth vroegen of hij zou overwegen om CLA’s van Snap te laten vallen om bredere steun van andere distro’s te krijgen, begon hij met uit te leggen waarom CLA’s goed zijn, maar zei toen ook dat “als dat een verschil zou maken, dan ja, dan zouden we een manier vinden om het te laten vallen.”
En toen was er een?
Op den duur kunnen volwassenheid, populariteit en technische superioriteit van de een boven de ander ons met één oplossing opzadelen. We hebben dat eerder gezien met Upstart en systemd, waar systemd als superieure technologie naar voren kwam en de standaard werd op alle drie toonaangevende Linux distro’s: Ubuntu, RHEL en SUSE.
In beide gevallen bevinden beide technologieën zich in een zeer vroeg stadium van ontwikkeling, en het is moeilijk te zeggen welk project zal slagen. Het is echter vrij duidelijk dat in de container-centrische wereld, Linux wel een nieuw app delivery mechanisme nodig heeft.
Vele bedrijven en gemeenschappen hebben hun steun uitgesproken voor oplossingen zoals Snap. Samsung en Dell voegden zich bij Canonical in het persgesprek en verklaarden de behoefte aan een dergelijke oplossing. Aan de desktop kant, hebben projecten als LibreOffice en Firefox al hun steun uitgesproken voor Snap.
De tijd zal leren of Snap zal worden overgenomen buiten Ubuntu of niet. Wat de toekomst ook brengt voor Snap, we moeten Canonical nageven dat het de grenzen heeft verlegd, en de rest van de Linux-gemeenschap heeft gedwongen om zich eindelijk te concentreren op het oplossen van een probleem waar we of zo comfortabel mee waren geworden of, misschien, nooit de motivatie hadden om het op te lossen.
CoreOS en Red Hat zijn sponsors van The New Stack.