A snapshot of the current state of Desktop Linux at the start of
2019—with comparison charts and a roundtable Q&A with the leaders of three top
I’ve never been able to stay in one place for long—at least in terms of which Linux distribution I call home.
In my time as a self-identified “Linux Person”, I’ve bounced around between a
number of truly excellent ones. In my early days, I picked up boxed copies of
S.u.S.E. (back before they made the U uppercase and dropped the dots
entirely) and Red Hat Linux (before Fedora was a thing) from store shelves at
various software outlets.
Side note: remember when we used to buy Operating Systems—and even most
software—in actual boxes, with actual physical media and actual printed
manuals? I still have big printed manuals for a few early Linux versions, which, back then, were necessary for getting just about everything working
(from X11 to networking and sound). Heck, sometimes simply getting
a successful boot required a few trips through those heavy manuals. Ah, those
were the days.
Debian, Ubuntu, Fedora, openSUSE—I spent a good amount of time living in
the biggest distributions around (and many others). All of them were
fantastic. Truly stellar. Yet, each had their own quirks and peculiarities.
As I bounced from distro to distro, I developed a strong attachment to just
about all of them, learning, as I went, to appreciate each for what it
was. Just the same, when asked which distribution I recommend to others,
my brain begins to melt down. Offering any single recommendation feels
Choosing which one to call home, even if simply on a secondary PC, is a
deeply personal choice.
Maybe you have an aging desktop computer with limited RAM and an older, but
still absolutely functional, CPU. You’re going to need something light on
system resources that runs on 32-bit processors.
Or, perhaps you work with a wide variety of hardware architectures and need a
single operating system that works well on all of them—and standardizing
on a single Linux distribution would make it easier for you to administer
and update all of them. But what options even are available?
To help make this process a bit easier, I’ve put together a handy set of
charts and graphs to let you quickly glance and find the one that fits your
needs (Figures 1 and 2).
Figure 1. Distribution Comparison Chart I
Figure 2. Distribution Comparison Chart II
But, let’s be honest, knowing that a particular system meets your hardware
needs (and preferences) simply is not enough. What is the community like?
What’s in store for the future of this new system you are investing in? Do
the ideals of its leadership match up with your own?
In the interests of helping to answer those questions, I sat down with the
leaders of three of the most prominent Linux distros of the day:
- Chris Lamb: Debian Project Leader
- Daniel Fore: elementary Founder
- Matthew Miller: Fedora Project Leader
Each of these systems is unique, respected and brings
something truly valuable to the world.
I asked all three leaders the exact same questions—and gave each the chance to
respond to each other. The topics are all over the place and designed to
help show the similarities and differences between the distributions, both in terms of
goals and culture.
Note that the Fedora project leader, Matthew Miller, was having an unusually
busy time (both for work and personally), but he still made time to answer as
many questions as he could. That, right there, is what I call dedication.
Introduce your Linux distribution (the short, elevator-pitch version—just
a few sentences) and your role within it.
elementary is focused on growing the market for open-source software and
chipping away at the share of our closed-source competitors. We believe in
providing a great user experience for both new users and pro users, and
putting a strong emphasis on security and privacy. We build elementary OS: a
consumer-focused operating system for desktops and notebooks.
My role at elementary is as Founder and CEO. I work with our various teams
(like design, development, web and translation teams) to put together a
cohesive vision, product roadmap and ensure that we’re following an
ethical path to sustainable funding.
Not only does it have stellar reputation for stability and technical
excellence, it has a unwavering philosophical stance on free software (i.e., it
comes with no proprietary software pre-installed and the main repository is
only free software). As it underpins countless derivative distributions,
such as Ubuntu, et al., it is uniquely poised and able to improve the Free
Software world as a whole.
The Debian Project Leader (DPL) is a curious beast. Far from being a BDFL—the
DPL has no authoritative or deciding say in technical matters—the
project leader is elected every year to a heady mix of figurehead, spokesperson
and focus/contact point, but the DPL is also responsible for the quotidian business
of keeping the project moving with respect to reducing bureaucracy and
smoothing any and all roadblocks to Debian Developers’ productivity.
The Fedora distribution brings all of the innovation of thousands of upstream
projects and hundreds of thousands of upstream developers together into a
polished operating system for users, with releases on a six-month cadence.
We’re a community project tied together through the shared project mission
and through the “four Fs” of our foundations: Freedom, Friends, Features
and First. Something like 3,000 people contribute directly to Fedora in any
given year, with a core active group of around 400 people participating in
any given week.
We just celebrated the 15th anniversary of our first release, but our history
goes back even further than that to Red Hat Linux. I’m the Fedora Project
Leader, a role funded by Red Hat—paying people to work on the project is
the largest way Red Hat acts as a sponsor. It’s not a dictatorial role;
mostly, I collect good ideas and write short persuasive essays about them.
Leadership responsibility is shared with the Fedora Council, which includes
both funded roles, members selected by parts of the community and at-large
With introductions out of the way, let’s start with this (perhaps
deceptively) simple question:
How many Linux distributions should there be? And why?
As long as there are a set of users who aren’t getting their needs met by
existing options, there’s a purpose for any number of distros to exist.
Some come and some go, and many are very very niche, but that’s okay. I
think there’s a lot of people who are obsessed with trying to have some
dominant player take a total monopoly, but in every other market category,
it’s immediately apparent how silly that idea is. You wouldn’t want a
single clothing manufacturer or a single restaurant chain or a single
internet provider (wink hint nudge) to have total market dominance. Diversity
and choice in the marketplace is good for customers, and I think it’s no
different when it comes to operating systems.
[Responding to Daniel]
Yes, I agree exactly. That said, creating an entirely from scratch distro is
a lot of work, and a lot of it not very interesting work. If you’ve
got something innovative at the how-we-put-the-OS-together level (like
CoreOS), there’s room for that, but if you’re focused higher up the stack,
like a new desktop environment or something else around user experience, it
makes the most sense to make a derivative of one of the big community-powered
distros. There’s a lot of boring hard work, and it makes sense to reuse
rather than carry those same rocks to the top of a slightly different hill.
In Fedora, we’re aiming to make custom distro creation as easy as possible.
We have “spins”, which are basically mini custom distros. This is stuff like
the Python Classroom Lab or Fedora Jam (which is focused on musicians). We
have a framework for making those within the Fedora project—I’m all
about encouraging bigger, broader sharing and collaboration in Fedora. But if
you want to work outside the project—say, you really have different ideas
on free and open-source vs. proprietary software—we have Fedora Remixes
that let you do that.
The competing choice of distributions is often cited as a reason preventing
Linux from becoming mainstream as it robs the movement of a consistent and focused
However, philosophical objections against monopolistic behaviour granted, the
diversity and freedom that this bazaar of distributions affords is, in my
view, paradoxically exactly why
it has succeeded.
That people are free—but more important, feel free—to create a
new distribution as a means to try experimental or outlandish approaches to
perceived problems is surely sufficient justification
for some degree of proliferation or even duplication of effort.
In this capacity, Debian’s technical excellence, flexibility and deliberate
lack of a top-down direction has resulted in it becoming the base
underpinning countless derivatives, clearly and evidently able to provide the
ingredients to build one’s “own” distribution, often without overt credit.
Matthew wrote: “if you want to work outside the project—say, you really have different
ideas on free and open source vs. proprietary software—we have Fedora
Remixes that let you do that.”
Given that, I would be curious to learn how you protect your reputation if
you encourage, or people otherwise use your infrastructure, tools and possibly
even your name to create and
distribute works that are antithetical to the cause of software and user
Thinking about it from a slightly different angle—how many distros would
be TOO many distros?
More than the market can sustain I guess? The thing about
Linux is that it powers all kinds of stuff. So even for one non-technical
person, they could still end up running a handful of distros for their
notebook, their router, their phone someday, IoT devices, etc. So the number
of distros that could exist sustainably could easily be in the hundreds or
thousands, I think.
If I may be so bold as to interpret this more widely, whilst it might look
like we have “too many” distributions, I fear this might be misunderstanding
the reasons why people are creating these newer offerings in the first place.
Apart from the aforementioned distros created for technical experimentation,
someone spinning up their own distribution might be (subconsciously!) doing
it for the delight and satisfaction in
building something themselves and having their name attached to it—something entirely reasonable and justifiable IMHO.
To then read this creation through a lens of not being ideal for new users or
even some silly “Linux worldwide domination” metric could therefore even be
missing the point and some of the sheer delight of free software to begin
Besides, the “market” for distributions seems to be doing a pretty good job
of correcting itself.
Okay, since you guys brought it up, let’s talk about world domination.
How much of what you do (and what your teams do) is influenced by a desire
to increase marketshare (either of your distribution specifically or
desktop Linux in general)?
When we first started out, elementary OS was something we made for fun out of
a desire to see something exist that we felt didn’t yet. But as the
company, and our user base, has grown, it’s become more clear that our
mission must be about getting open-source software in the hands of more
people. As of now, our estimated userbase is somewhere in the hundreds of
thousands with more than 75% of downloads coming from users of closed-source
operating systems, so I think we’re making good progress toward that
goal. Making the company mission about reaching out to people directly has
shaped the way we monetize, develop products, market and more, by ensuring
we always put users’ needs and experiences first.
I think it would be fair to say that “increasing market share” is not an
overt nor overly explicit priority for Debian.
In our 25-year history, Debian has found that if we just continue to do good
work, then good things will follow.
That is not to say that other approaches can’t work or are harmful, but
chasing potentially chimeric concepts such as “market share” can very easily
lead to negative outcomes in the long run.
A project’s user base is directly tied to its ability to have an effect in
the world. If we were just doing cool stuff but no one used it, it really
wouldn’t matter much. And, no one really comes into working on a distro
without having been a user first. So I guess to answer the question directly
for me at least, it’s pretty much all of it—even things that are not
immediately related are about helping keep our community healthy and growing
in the long term.
The three of you represent distros that are “funded” in very different ways.
Fedora being sponsored (more or less) by Red Hat, elementary being its own
company and Debian being, well, Debian.
I would love to hear your thoughts around funding the work that goes into
building a distribution. Is there a “right” or “ideal” way to fund that work
(either from an ethical perspective or a purely practical one)?
Clearly, melding “corporate interests” with the interests of a community
distribution can be fraught with issues.
I am always interested to hear how other distros separate influence and power
particularly in terms of increasing transparency using tools such as Councils
with community representation, etc. Indeed, this question of “optics” is
often highly under-appreciated; it is simply not enough to be honest, you
must be seen to be honest too.
Unfortunately, whilst I would love to be able to say that Debian is
by-definition free (!) of all such problems by not having a “big sister”
company sitting next to it, we have a long history of conversations regarding
the role of money in funding contributors.
For example, is it appropriate to fund developers to do work that might not
not be done otherwise? And if it is paid for, isn’t this simply a feedback
loop that effectively ensures that this work will cease to within the remit
of volunteers. There are no easy answers and we have no firm consensus, alas.
I’m not sure that there’s a single right way, but I think we have the
opinion that there are some wrong ways. The biggest questions we’re
always trying to ask about funding are where it’s coming from and what
it’s incentivizing. We’ve taken a hard stance that advertising income is
not in the interest of our users. When companies make their income from
advertising, they tend to have to make compromises to display advertising
content instead of the things their users actually want to see, and
oftentimes are they incentivized to invade their users’ privacy in order
to target ads more effectively. We’ve also chosen to avoid big enterprise
markets like server and IoT, because we believe that since companies will
naturally be incentivized to work on products that turn a profit, that making
that our business model would result in things like the recent Red Hat
acquisition or in killing products that users love, like Ubuntu’s Unity.
Instead, we focus on things like individual sales of software directly to our
users, bug bounties, Patreon, etc. We believe that doing business directly
with our users incentivizes the company to focus on features and products
that are in the benefit of those paying customers. Whenever a discussion
comes up about how elementary is funded, we always make a point to evaluate
if that funding incentivizes outcomes that are ethical and in the favor of
Regarding paying developers, I think elementary is a little different here.
We believe that people writing open-source software should be able to make a
living doing it. We owe a lot to our volunteer community, and the current
product could not be possible without their hard work, but we also have to
recognize that there’s a significant portion of work that would never get
done unless someone is being paid to do it. There are important tasks that
are difficult or menial, and expecting someone to volunteer their time to them
after their full work day is a big ask, especially if the people
knowledgeable in these domains would have to take time away from their
families or personal lives to do so. Many tasks are also just more suited to
sustained work and require the dedicated attention of a single person for
several weeks or months instead of some attention from multiple people over
the span of years. So I think we’re pretty firmly in the camp that not
only is it important for some work to be paid, but the eventual goal should
be that anyone writing open-source code should be able to get paid for their
Daniel wrote: “So I think we’re pretty firmly in the camp that not only is it
important for some work to be paid, but the eventual goal should be that anyone
writing open-source code should be able to get paid.”
Do you worry that you could be creating a two-tier community with this
Not only in terms of hard influence (eg. if I’m paid, I’m likely to be able
to simply spend longer on my approach) but moreover in terms of “soft”
influence during discussions or by putting off
so-called “drive-thru” contributions? Do you do anything to prevent the
appearance of this?
“Do you worry that you could be creating a two-tier community with this
Yeah, this is a big challenge for us. We have many people who are paid by Red
Hat to work on Fedora either full time or as part of their job, and that
gives a freedom to just be around a lot more, which pretty much directly
translates to influence. Right now, many of the community-elected positions
in Fedora leadership are filled by Red Hatters, because they’re people the
community knows and trusts. It takes a lot of time and effort to build up
that visibility when you have a different day job. But there’s some important
nuances here too, because many of these Red Hatters aren’t actually paid to
work on Fedora at all—they’re doing it just like anyone else who loves the
“Do you worry that you could be creating a two-tier community with this
It’s possible, but I’m not sure that we’ve measured anything to
this effect. I think you might be right that employees at elementary can have
more influence just as a byproduct of having more time to participate in more
discussions, but I wouldn’t say that volunteers’ opinions are
discounted in any way or that they’re underrepresented when it comes to
major technical decisions. I think it’s more that we can direct labor
after design and architecture decisions have been discussed. As an example,
we recently had decided to make the switch from CMake to Meson. This was a
group discussion primarily led by volunteers, but the actual implementation
was then largely carried out by employees.
“Do you worry that you could be creating a two-tier community with
this approach? … It’s possible, but I’m not sure that we’ve measured anything to
I think it might be another one of those situations where the optics in play
is perhaps as important as the reality. Do you do anything to prevent the
appearance of any bias?
Not sure how best to frame it hypothetically, but if I turned up to your
project tomorrow and learned that some developers were paid for their work
(however fairly integrated in practice), that would perhaps put me off
investing my energy.
What do you see as the single biggest challenge currently facing both your
specific project—and desktop Linux in general?
Third-party apps! Our operating systems are valuable to people only if they can
use them to complete the tasks that they care about. Today, that increasingly
means using proprietary services that tie in to closed-source and non-native
apps that often have major usability and accessibility problems. Even major
open-source apps like Firefox don’t adhere to free desktop standards like
shipping a .desktop file or take advantage of new cross-desktop metadata
standards like AppStream. If we want to stay relevant for desktop users, we
need to encourage the development of native open-source apps and invest in
non-proprietary cloud services and social networks. The next set of
industry-disrupting apps (like DropBox, Sketch, Slack, etc.) need to be open source and
Third-party apps/stores are perhaps the biggest challenge facing all
distributions within the medium- to long-term, but whilst I would concede
there are cultural issues in play here, I believe they have some element of
being technical challenges or at least having some technical ameliorations.
More difficult, however, is that our current paradigms of what constitutes
software freedom are becoming difficult to square with the increased usage of
cloud services. In the years ahead we may need to revise our perspectives,
ideas and possibly even our definitions of what constitutes free software.
There will be a time when the FLOSS community will have to cease the casual
mocking of “cloud” and acknowledge the reality that it is, regardless of
one’s view of it, here to stay.
For desktop Linux, on the technical side, I’m worried about hardware
enablement—not just the work dealing with driver compatibility and
proprietary hardware, but more fundamentally, just being locked out. We’ve
just seen Apple come out with hardware locked so Linux won’t even boot—even with signed kernels. We’re going to see more of that, and more tablets
and tablet-keyboard combos with similar locked, proprietary operating
A bigger worry I have is with bringing the next generation to open
source—a lot of Fedora core contributors have been with the project since it started
15 years ago, which on the one hand is awesome, but also, we need to
make sure that we’re not going to end up with no new energy. When I was a
kid, I got into computers through programming BASIC on an Apple ][. I could
see commercial software and easily imagine myself making the same kind of
thing. Even the fanciest games on offer—I could see the pixels and could
use PEEK and POKE to make those beeps and boops. But now, with kids getting
into computers via Fortnite or whatever, that’s not something one can just
sit down and make an approximation of as a middle-school kid. That’s
discouraging and makes a bigger hill to climb.
This is one reason I’m excited about Fedora IoT—you can use Linux and open
source at a tinkerer’s level to make something that actually has an effect on
the world around you, and actually probably a lot better than a lot of
off-the-shelf IoT stuff.
Where do you see your distribution in five years? What will be its place be in
the broader Linux and computing world?
Debian naturally faces some challenges in the years ahead, but I sincerely
believe that the Project remains as healthy as ever.
We are remarkably cherished and uniquely poised to improve the free software
ecosystem as a whole. Moreover, our stellar reputation for technical
excellence, stability and software freedom remains highly respected where
losing this would surely be the beginning of the end for Debian.
Our short-term goals are mostly about growing our third-party app ecosystem and
improving our platform. We’re investing a lot of time into online
accounts integration and working with other organizations, like GNOME, to
make our libraries and tooling more compelling. Sandboxed packaging and
Wayland will give us the tools to help keep our users’ data private and
to keep their operating system stable and secure. We’re also working with
OEMs to make elementary OS more shippable and to give users a way to get an
open-source operating system when they buy a new computer. Part of that work
is the new installer that we’re collaborating with System76 to develop.
Overall, I’d say that we’re going to continue to make it easier to
switch away from closed-source operating systems, and we’re working on
increasing collaborative efforts to do that.
When you go to a FOSS or Linux conference and see folks using Mac and Windows
PCs, what’s your reaction? Is it a good thing or a bad thing when
developers of Linux software primarily use another platform?
Rushing to label this as a “good” or “bad” thing can make it easy to miss the
underlying and more interesting lessons we can learn here.
Clearly, if everyone was using a Linux-based operating system, that would be a
better state of affairs, but if we are overly quick to dismiss the usage of
Mac systems as “bad”, then we can often fail to understand why people have
chosen to adopt the trade-offs of these platforms in the first place.
By not demonstrating sufficient empathy for such users as well as newcomers
or those without our experience, we alienate potential users and contributors
and tragically fail to communicate our true
message. Basically, we can be our own worst enemy sometimes.
Within elementary, we strongly believe in dogfood, but I think when we see
someone at a conference using a closed-source operating system, it’s a
learning opportunity. Instead of being upset about it or blaming them, we
should be asking why we haven’t been able to make a conversion. We need
to identify if the problem is a missing product, feature, or just with
outreach and then address that.
How often do you interact with the leaders of other distributions? And is
that the right amount?
Whilst there are a few meta-community discussion groups around, they tend to
have a wider focus, so yes, I think we could probably talk a little more, even
just as a support group or a place to rant!
More seriously though, this conversation itself has been fairly insightful,
and I’ve learned a few things that I think I “should” have known already,
hinting that we could be doing a better job here.
With other distros, not too often. I think we’re a bit more active with
our partners, upstreams and downstreams. It’s always interesting to hear
about how someone else tackles a problem, so I would be interested in
interacting more with others, but in a lot of cases, I think there are
philosophical or technical differences that mean our solutions might not be
relevant for other distros.
Is there value in the major distributions standardizing on package management
systems? Should that be done? Can that be done?
I think I would prefer to see effort go toward consistent philosophical
outlooks and messaging on third-party apps and related issues before I saw
energy being invested into having a single package management format.
I mean, is this really the thing that is holding us all back? I would grant
there is some duplication of effort, but I’m not sure it is the most egregious
example and—as you suggest—it is not even really technically
feasible or is at least subject to severe diminishing returns.
For users, there’s a lot of value in being able to sideload
cross-platform, closed-source apps that they rely on. But outside of this use
case, I’m not sure that packaging is much more than an implementation
detail as far as our users are concerned. I do think though that developers
can benefit from having more examples and more documentation available, and
the packaging formats can benefit from having a diverse set of
implementations. Having something like Flatpak or Snap become as well
accepted as SystemD would probably be good in the long run, but our users
probably never noticed when we switched from Upstart, and they probably
won’t notice when we switch from Debian packages.
Big thanks to Daniel, Matthew and Chris for taking time out to answer
questions and engage in this discussion with each other. Seeing the
leadership of such excellent projects talking together about the things they
differ on—and the things they align on completely—warms my little
AddSearch Custom Site Search