This is part 1 of a series of blog posts based on the talk Jordan Petridis and I gave at LAS 2019 in Barcelona. Read part 2 here.
In our community there is this idea that “Linux” is the third platform next to Windows and macOS. It’s closely connected to things like the “year of the Linux desktop”, and can be seen in the language around things like Flatpak, which bills itself as “The Future of Apps on Linux” and the Linux App Summit, which is “designed to accelerate the growth of the Linux application ecosystem”.
But what does that actually mean? What does a healthy app ecosystem look like? And why don’t we have one?
I think the core of the problem is actually the layer below that: Before we can have healthy ecosystems, we need healthy platforms to build them on.
What is a Platform?
The word “platform” is often used without a clear definition of what exactly that entails. If we look at other successful platforms there are a ton of different things enabling their success, which are easy to miss when you just look at the surface.
On the developer side you need an operating system developers can use to make apps. You also need a developer SDK and tooling which are integrated with the operating system. You need developer documentation, tutorials, etc. so people can learn how to develop for the platform. And of course once the apps are built there needs to be an app store to submit them to.
Developers can’t make great apps all by themselves, for that you also need designers. Designers need tools to mock up and prototype apps, platform UI patterns for things like layout and navigation, so every app doesn’t have to reinvent the wheel, and a visual design language so designers can make their app fit in with the rest of the system visually. You also need Human Interface Guidelines documenting all of the above, as well as tutorials and other educational resources to help people learn to design for the platform.
On the end user side you need a consumer OS with an integrated app store, where people can get the great apps developers make. The consumer OS can be the same as the developer OS, but doesn’t have to be (e.g. it isn’t for Android or iOS). You also need a way for people to get help/support when they have problems with their system (whether that’s physical stores, a help website, or just easily google-able Stackoverflow questions).
That’s a lot of different things, but we can group them into four major pieces which are needed in order for something to be a real platform:
- Operating System
- Developer Platform
- Design Language
- App Store
So if we look at the free software world, where are the platforms?
Linux?
Linux is a kernel, which can be used to build OSes, which can be used to build platforms. Some people (e.g. Google with Android) have done so, but a kernel by itself doesn’t have any of the four things outlined above, and therefore is not a platform.
FreeDesktop.org?
What about “Desktop Linux”, which is what people usually mean when they say “Linux”? The problem is that this term doesn’t have a clear definition. You could take it to mean “FreeDesktop.org”, but that also doesn’t come close to being a platform. FreeDesktop is a set of standards that can be used to build platforms (and/or ensure some level of compatibility between different platforms). Endorsement of a single platform or set of technologies goes directly against FreeDesktop’s aims, and as such it should only be thought of as the common building blocks platforms might share.
Ubuntu?
What about distributions? Ubuntu is one of the most popular ones, and unlike others it has its own app store. It still isn’t a platform though, because it doesn’t have the most critical pieces: a developer SDK/technology stack, and a design language.
Other distributions are in a similar but worse position because they don’t have an app store.
GNOME?
GNOME is the most popular desktop stack, and it does have an SDK and design language. However, it only sort of has an app store (because GNOME people work on Flathub), and it doesn’t have an OS. Many distributions ship GNOME, but they are all different in various ways (more on this later), so they don’t provide a unified development target.
Elementary?
Interestingly, the only project which currently has all the pieces is elementary. It has an OS, an SDK, a HIG, and an app store to submit apps to. The OS is largely Ubuntu and the technology stack largely GNOME, but it develops its own desktop and apps on top of that, and does the integration work to make it into a complete consumer product.
This begs the question, why is elementary the only one?
The Means of Distribution
The reasons for this are largely historical. In the early days, free software desktops were a bunch of independently developed components. They were not necessarily designed for each other, or well integrated. This meant in order to have a usable system, someone needed to curate these components and assemble them into an operating system: The first distributions were born.
Over the last decades this landscape has changed drastically, however. While GNOME 1 was a set of loosely coupled components, GNOME 2 was already much more cohesive and GNOME 3 is now essentially an integrated product. The shell, core apps, and underlying technologies are all designed with each other in mind, and provide a complete OS experience.
Desktops like GNOME have expanded their scope to cover most of the responsibilities of platforms, and are in effect platforms now, minus the OS part. They have a very clear vision of how the system should work, and app developers target them directly.
The elementary project has taken this development to its logical end point, and made its own vertically integrated OS and app store. This is why it’s the only “real” platform in the free software space at the moment.
Distributions, on the other hand, have not really changed since the 90s. They still do integration work on desktop components, package system and applications, set defaults, and make UX decisions. They still operate as if they’re making a product from independent components, even though the actual product work is happening at the desktop layer now.
This disconnect has led to tensions in many areas, which affect both the quality of the system user experience, and the health of the app ecosystem.
What’s interesting about this situation is that desktop developers are now in the same situation app developers have always been in. Unlike desktops, apps have always been complete products. Because of this they have always suffered from the fragmentation and disconnect between developers and users introduced by distribution packaging.
Grievances with the distribution model, which affect both app and desktop developers, include:
- Release schedule: Developers don’t have control over the pace at which people get updates to their software. For apps this can mean people still get old versions of software with issues that were fixed upstream years ago. For desktops it’s even worse, because it means app developers don’t know what version of the platform to target, especially since this can vary wildly (some distributions release every 6 months, others every 2+ years).
- Packaging errors: Distribution packaging is prone to errors because individual packagers are overloaded (often maintaining dozens or hundreds of packages), and don’t know the software as well as the developers.
- Overriding upstream decisions: When distributions disagree with upstream decisions, they sometimes keep old version of software, or apply downstream patches that override the author’s intentions. This is very frustrating if you’re an app developer, because users never experience your app as you intended it to be. However, similar to the release schedule issue, it’s even worse when it happens to the core system, because it fragments the platform for app developers.
- Distro Theming: App developers test with the platform stylesheet and icons, so when distributions change these it can break applications in highly visible ways (invisible widgets, unreadable text, wrong icon metaphors). This is especially bad for third party apps, which get little or no testing from the downstream stylesheet developers. This blog post explains the issue in more detail.
The Wrong Incentives
The reason for a lot of these issues is the incentives on the distribution side. Distributions are shipping software directly to end users, so it’s very tempting to solve any issues they find downstream and just ship them directly. But because the distributions don’t actually develop the software this leads to a number of other problems:
- Perpetual rebasing: Any change that isn’t upstreamed needs to be rebased on every future version of the upstream software.
- Incoherent user experience: Downstream solutions to UX problems are often simplistic and don’t fix the entire issue, because they don’t have the development resources for a proper fix. This leads to awkward half-redesigns, which aren’t as polished or thought-through as the original design.
- Ecosystem fragmentation: Every downstream change adds yet another variable app developers need to test for. The more distributions do it, the worse it gets.
The Endless OS shell is a great example of this. They started out with vanilla GNOME Shell, but then added ever more downstream patches in order to address issues found in in-house usability tests. This means that they end up having to do huge rebases every release, which is a lot of work. At the same time, the issues that prompted the changes do not get fixed upstream (Endless have recently changed their strategy and are working upstream much more now, so hopefully this will get better in the future).
This situation is clearly bad for everyone involved: Distributions spend a ton of resources rebasing their patches forever, app developers don’t have a clear target, and end users get a sub-par experience.
So, what could we do to improve this? We’ll discuss that in part 2 of this series :)
> Distributions, on the other hand, have not really changed since the 90s. They still do integration work on desktop components, package system and applications, set defaults, and make UX decisions. They still operate as if they’re making a product from independent components, even though the actual product work is happening at the desktop layer now.
I’m not sure I agree with that — because it seems to ignore the fact that the major distros are also the major contributors to the desktops. Not meaning to dismiss the efforts of independent developers, but an awful lot of the work on projects like Gnome is done by people paid by the likes of RedHat and Canonical.
And it’s been that way for a long time… in the early days of dbus and HAL and NetworkManager, a lot of work was being done to transform Gnome from just a UI shell, to something that could integrate with the OS and hardware. And again, much of that work, both in Gnome and in the stack below it, was being done by developers working for the big distros. Today, the same thing is happening with integrating the likes of Systemd, Flatpak, etc.
So yeah, while I agree with your conclusions about the lack of a defined “platform”, I think you’re drawing a false division between desktops and distros… because to a large degree, it’s the same people doing both.
> I think you’re drawing a false division between desktops and distros… because to a large degree, it’s the same people doing both.
Yes and no. It’s true that many of the people who work upstream also work on distributions (myself included). and in fact those are largely the people who have been moving desktops towards being platforms because they know better than anyone that the status quo isn’t working.
Just because the same people are doing work on both things, that doesn’t make the desktop/distro divide any less real in terms of outcomes.
Issues like release cadence mismatch or downstream UX changes can apply even when most of the downstream people want to work upstream, because they don’t control everything about how the distribution is put together (e.g. for technical or business reasons).
For example, PureOS ships with GNOME 3.30 currently, because it’s based on Debian stable, even though Purism has a very strong upstream-first ethos. It’s the same story with RHEL, which a lot of GNOME upstream maintainers also work on. Ask them whether they think the desktop/distro divide exists ;)
How about a “Linux” distro, with a “Linux” desktop, a “Linux” theme, a ” Linux” packaging system, a “Linux” SDK, etc… all using the Linux kernel… And we call *it* Linux?
Focuse on it being able to run on older hardware… select core elements that are the least resource hogging.
Establish a set desktop environment that doesn’t change on it’s face.
Obviously it would be able to install all software packages and people can tweet it to their liking… but all these distros and desktops constantly making superficial changes is quite hellish for end users and probably more so for developers.
Linux, out of the box, 100%
The rest is vanity and hubris…
Many downstream changes [not flowing upstream] base on a strong disagreement between upstream and downstream, usually upstream outright rejecting the change, or demanding more work nobody feels justified downstream. Some even result a fork since it’s so impossible to find a common ground.
Some fine example may be Devuan (since Debian basically forced systemd down on people’s throat) or MATE (since Gnome basically forced Gnome [s]hell down on people’s throat). I’m not sure such problems could be easily solved to prevent fragmentation, and the hard solutions nobody’s really eager to get done.
I wonder what your plan is to resolve. Docker/flatpak/electron/… kind of “solution” (when you package half the OS with every app every time) is a really horrible solution, in my not very humble opinion. I’m for shared resources. But then you meet distros with different versions of shared libs, which is fine, except they’re mutually incompatible, which is not. So a [foreign] package for Ubuntu won’t work on Debian or Arch, and vice versa. And don’t even start to talk about 3D video cards and hw manufacturers, closed source drivers and…
[a “10 TONS” weight falls on my head and flat me]
No ones shoving anything down anyone’s throat, you’re not forced to use Debian or GNOME.
You can have a mature platform without a centralized “app store”. If we’ve learned anything from app stores it’s that they inevitably get cluttered with malware and/or bloatware.
The problem of distributing Linux programs to multiple distributions has already been solved by things like appImages, flatpaks, snaps and so on. The classic repositories due require extra maintenance work but it keeps the ecosystem free of bloatware.
A centralized solution isn’t required as it would only disrupt that which makes Linux different and popular.
The “let’s do it because everybody else is doing it” mentality doesn’t always yield the best solution. It only artificially limits innovation and creates security and reliability problems for the sake of theoretical convenience.
Windows hasn’t had an app store for the better part of its existence and people still avoid the app store as its full of bloatware.
Taking an already successful OS like Linux and changing it to be like the others won’t bolster its success. On the contrary. You will only take away that which made it successful in the first place.
>A centralized solution isn’t required as it would only disrupt that which makes Linux different and popular.
Linux is popular?
“Linux different and popular.”
Without a doubt: best joke of the year!
> You can have a mature platform without a centralized “app store”.
Nobody said anything about centralization…
> A centralized solution isn’t required as it would only disrupt that which makes Linux different and popular.
Linux isn’t different, nor popular. Its stuck doing the same thing system administratos have been doing since the 80s. And again, nobody said anything about a centralized solution, having a default place for people to discover and install apps doesn’t mean it will be the only way to do so.
>The “let’s do it because everybody else is doing it” mentality doesn’t always yield the best solution. It only artificially limits innovation and creates security and reliability problems for the sake of theoretical convenience.
If you think this is cause everybody else does it, you clearly didn’t read or understood the blogpost.
> Windows hasn’t had an app store for the better part of its existence and people still avoid the app store as its full of bloatware.
Since windows 95 people were going to *Physical* stores, and were buying floppy and cds with *Applications*
> Taking an already successful OS like Linux
You clearly missed the memo of the title of the post :)
> When distributions disagree with upstream decisions, they sometimes keep old version of software, or apply downstream patches that override the author’s intentions. This is very frustrating if you’re an app developer, because users never experience your app as you intended it to be.
I’d say this cuts both ways. The distro maintainers give us independent review and evaluation of upstream decisions and act as a sanity check on upstreams, making things uniform and removing the crazy parts and undoing the worst decisions. Upstreams can be very idiosyncratic and each upstream has different design goals, and the role of the distribution is to coerce software designed with different priorities into one coherent set. The fact that there are different sets of principles is one of the reasons why we have so many distributions.
Occasionally, distro packagers make mistakes, no doubt, but this doesn’t change the fact that the packaging guidelines, QE, communal testing of binary packages, and standarized packaging provide value to users. You can’t build a system using e.g. gnome alone, at least not a practical one. Most people want many many other applications that are developed externally, and the distro is the source that makes them easily available.
> Developers don’t have control over the pace at which people get updates to their software.
This is a good thing. The release cadence for Fedora is never going to be the same as the release cadence for RHEL, and it shouldn’t be. Slowness is the price that is paid for extensive testing and stability. Some people chose to chose that.
In the theoretical future where e.g. gnome was fully regression free, distros would be more likely to push newer versions into stable releases more often. Once that happens, that issue will be resolved automatically. But it is very hard to provide that kind of stability with software that is undergoing strong development, and we’re clearly not there yet.
What about KDE Neon. It has nearly everything, but App Center/Shop.
Qt framework is a property owned by Qt Company with three types of licenses: GPL 3.0, LGPL 2.1 and Qt commercial license.
So, any company with a commercial software developed with Qt may buy a commercial license from Qt Company if the company desire.
KDE Neon seems like a step in the right direction, but when I last talked to KDE people about it they said they think about it primarily as a tool for development, rather than a consumer product. Would be cool if they pushed it in more of a product direction.
Your analysis is spot on. I thik you identify why the ‘year of linux desktop’ has not come to pass. Windows 8 was a failure, but linux had no platform to fill the gap. As an end user, I want the stability and ease of use that a platform implies. I’m tired of all the infernal, never ending tweaking that the typical distro requires. And the confusing proliferation of package managers has not filled the gap of an app store.
ElementaryOS is going in the right direction. I used it for years, but unfortunately all of those cool custom apps are full of bugs, and fixing them has not been a priority. After waiting through 3 releases for them to fix their bugs, I’ve moved on.
I now use Windows Linux Subsystem and Crostini to run any linux apps I require. Windows and ChromeOS both expose the linux kernal as a component that is easy to use. Crostini, in particular makes it easy to use linux desktop apps. I view it as Debian with a Chrome Desktop Environment. After years of distro surfing, it finally fills the ‘platform void’ for me as an end user. I’m not a true believer of free and open source – I honestly don’t care. I just want something that works and is easy to use. I think most consumers feel the same way.
Gnome really needs to control the full stack, the experience still feels like something I used in 2003, It’s much improved but still feels like bits and pieces are bolted on.
Agree.
Gnome OS has to be built as a unified source code platform with all companies work together in cooperation at the same code.
Maybe even Gnome need change from a non-profit foundation to a non-profit Alliance or Consortium following success model used by Wi-fi, Bluetooth, Mopria, USB, Khronos.
Thank you so much for this blog post. It sheds so much light and coherence. It also makes one understand how hard is to sync all these layers, now that we do know how many layers are and what they are.
You need and OS need an SDK you need shipment methods, you need Design and a set of protocols, and all these mixed together.
It’s like a scissors, rock, paper game with Gnome, Ubuntu, and a bunch of other things.
Hope I’ve got it. Please keep posting such ideas when you got them!
I think some of the statements are a bit unfair wrt. distribution packagers.
I am the maintainer of elementary / Pantheon (plus some 200+ other packages) on fedora, and a member of the Fedora Packaging Committee, so I do have “some” experience in that area. At least for fedora, it’s usually preferred to 1. write downstream patches in a way that makes it possible to send them back upstream, and 2. to actually send them upstream. You’ll probably find at least one commit by me in almost all elementary git repositories, since I’ve tried to actively collaborate with them, and – I agree – maintaining downstream patches is painful, and only introduces points of failure. Still, the result is that – with only very few minor exceptions – the packages for elementary components are as close to the upstream preferences as possible.
Additionally, while packagers might not know the project as well as the upstream maintainer, they usually *do* know the intricacies of (distribution) packaging better. This doesn’t apply to flatpak (et al.) of course – but these tools also have a learning curve. *Somebody* has to learn how to distribute software effectively, efficiently, and correctly, no matter the distribution method (deb, rpm, flatpak, etc.) – distribution packagers (and the tooling they use) just have a head start here because that’s what they’ve been doing for literally decades.
Congratulations, Tobias.
Great reflection!
A lot of this makes at least some sense but, while I am sure it wasn’t your intention, it occasionally comes off as needlessly abbrasive.
Theming, for example: I know it’s a mess, I’ve been on the app end of it and dealt with bug reports and all, and it irks designers the wrong way. But people want it and not because they don’t want to emerge from their parents’ basements but because Adwaita is hard for a lot of people.
I hate it too but 1366×768 screens are still a thing, and Adwaita’s huge widgets are a pain on them. Increasing font size for legibility makes it worse. On my mom’s laptop, its vivid white and blue tones will make your eyes sore — at 64, there’s no way shhe’ll put up with it.
Every time someone speaks of these things, the answer is unsympathetic. UX, CONSISTENCY, DESIGN, BAD BAD BAD DISTROS.
Attempting to at least listen to these things and providing very minor improvements, like a compact mode for Adwaita, would go a long way towards a community-like response. But I guess pointing out how everyone who isn’t a UX designer is completely and hopelessly wrong forever and ever and totally doesn’t know what they need works too, what do I know…
(Sorry for throwaway but a lot of my work is FOSS-related and being overly negativistic about these things isn’t too well-received lately…)
> Every time someone speaks of these things, the answer is unsympathetic. UX, CONSISTENCY, DESIGN, BAD BAD BAD DISTROS.
I’m not sure what you’re referring to exactly, but that’s not been my experience. More often than not it’s just that those things are difficult to fix properly, and nobody has the time/interest to do it.
Let’s take the “compact mode” you mentioned as an example: Doing something like that in a clean way is much, much harder than it might seem on the surface. If we were to add a mode that changes sizes/margins/padding on most widgets, that would mean an additional variable every app developer needs to test their app against. We currently already have such a variable, which is officially supported (High Contrast), but even so, many apps don’t test for it and therefore look broken with it. If we were to add more variables, we’d need to ensure app developers test them. Fixing that would be a major initiative involving work across many parts of the stack (toolkit, stylesheet, settings, developer tools, documentation/outreach etc.).
Initiatives like this are a ton of work, and as I’m sure you’re aware, upstream is stretched thin as is. Because they’re not currently working on a problem doesn’t mean they’re not interested in a fix for it, just that it’s not the highest priority.
The problem is that instead of coming upstream and doing that work, people often just do the easiest possible downstream hack and call it a day. Of course, that makes everything worse because the issues are not actually fixed and the downstream “solutions” have probematic side-effects that hurt both their users and the ecosystem as a whole.
tl;dr: If you want something fixed start by discussing the problem (not a specific solution) upstream, get consensus on a path forward, and put in the work to get it done. That’s how free software development works. Complaining about other people not working on something, or shipping downstream patches isn’t going to help anyone long term.
Interesting article, thank you for sharing with us.
Hi Tobias,
This is the second time you’ve published a post that pretends to speak for me as an app developer, and once again I don’t recognize myself in your description of what “app developers” think. (First time: https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-at-scale/#comment-216) I’m also a desktop developer and the same applies to what you say in this post that “desktop developers” want.
Please stop doing that. This is your opinion, not mine. No doubt some app developers and desktop developers agree with you, but I don’t appreciate being presented as part of a united front when I’m not.
This is my personal blog, obviously what I write here is my personal opinion. I don’t think I claim anywhere to speak for you personally, do I?
In a community as large and diverse as ours there are likely very few things every single one of us agree with. That said, the topic is far from new (see e.g. https://www.bassi.io/articles/2017/08/10/dev-v-ops), and the points made here are informed by many discussions with people from all over the community.
An overview of the many occurrences of the here discussed topic in the last 20 years can be found in this reddit thread https://old.reddit.com/r/linux/comments/2f4oe7/revisiting_how_we_put_together_linux_systems/ (first comment there)
For instance, in 2005 Mike Hearn with “Autopackage – What’s a desktop Linux platform? Why do we need one?” or Ian Murdock in 2006, and so on – yet the Linux ecosystem resisted any change…*sigh*
Just a not about Elementary: their app store refuses to host any application which uses toolkits other than Gtk, so it’s also quite irrelevant to third party developers.
Interesting article and clearly defined about SDK and layers of Linux.
Interesting article. I agree with a lot of what is being said. That said, I think we can narrow down the discussion to a couple of important players, i.e. on the desktop side: GNOME, and on the distro side: Ubuntu first and foremost (and Fedora, OpenSUSE, Pop!_OS).
Fragmentation and downstream hacks will always exist, but it’s important that there is at least a good understanding and common goals between GNOME and Canonical/Fedora. I, for one, was glad that Ubuntu went back to GNOME, hoping that both GNOME and Canonical would start advancing this desktop again.
Around 2018 things were looking up, because it felt like, at least on the design front, Adwaita en Yaru (both theming and icons) were converging. Ubuntu 20.04 seems to go in the wrong direction again, with an own ‘Snap-store’, and a different icon for Nautilus. Anyway, convergence and co-operation between the major distros and GNOME are pivotal, IMHO.
I think probably the most important things that needs to happen imply concessions and hard decisions on both ends: Canonical is going to have to decide what it wants to do with Snap vs Flatpak. On the other hand, I think it is long overdue that GNOME developers start listening to the real problems that users keep having with GNOME Shell and certain decisions that are being made. If Canonical patches things to alleviate these concerns, they should, in my view, at least ‘do something’ with it. Making headerbars more compact, for instance. Making the Dash-to-dock (with keyboard quick launch) extension part of the core settings. And finally: make it possible for distros to not theme, but at least add colour branding in the default theme.
I, for one, would like for the major distros and GNOME to work closely together to converge. This impies concessions on both ends.