Closed source on Linux is hard
Update: Please read the article carefully before commenting. If you notice, most of the problems being described here is part of Eclipse, which is open source. So, usability issues are faced by open source programs as well, and not just proprietary programs on Linux. The reason I wrote that title was because this pain is usually felt by people who are making closed source packages that works on different Linux distributions. The real issue is about unneeded incompatibilities between different Linux distributions.
After working on the porting project to make Flex Builder run on
I am starting to see why closed source software on Linux is
There are just a handful of closed source products on Linux (counting
only the famous ones) – Opera, Skype, Nero, Acrobat Reader, and Flash
Player. Hmmm, I can think of just 5.
Why is that important at all? Because software developers who are not
initiated to the FOSS philosophy will be scared off the platform
because of its inherent complexities. For example, in this project,
getting the software to run on the various Linux distros was, to put
it lightly, troublesome.
There are a number of issues that we faced, which I’m certain is the
reason others don’t want to get into this as well.
Let’s start with Eclipse. Eclipse runs fairly well on different
platforms (let’s ignore the memory-hogging issue here), but on Linux,
it’s a different ballgame. Somehow, the polishing of the UI is
markedly lacking. Yes, we’ve filed
bugs, but turns
out it’s not really Eclipse’s fault, it’s simply because different
window managers work differently on Linux, and handling all of this is
Oh, and this gets better when it comes to distros. For example, the
latest released Eclipse 3.3 won’t run on the latest released Fedora
version. You have to wait till Fedora
8! Because of this,
we had to drop support for Fedora, and instead concentrated on
such as Suse, Red Hat and Ubuntu.
That brings up another problem – the number of distros. The QA effort
required for the Flex Builder (FB) on Linux project was huge indeed.
And yes, we found problems that occurred only on Red Hat but not on
Ubuntu, and so on. For example, clicking on help links in Eclipse on
Red Hat opens a new window every time whereas it properly displays in
the same window on Ubuntu. Again, it’s not really Eclipse’s
Then, there’s the issue of running Firefox. There’s nothing wrong with
Firefox itself, but what’s with each distro trying to customize the
Firefox startup script?! FB on Linux has to check whether the correct
version of the Flash Player plugin is installed in the browser, and
checking this is a long
– do we check in
~/.firefox/plugins/ directory or
$MOZ_PLUGIN_PATH or some
Suse-distro-specific directory such as
Life is simply too
compared to other operating systems.
Isn’t it a wonder that nobody wants to develop a closed source product
for Linux? Even Microsoft is just handing over the audio video codecs
to Novell and
letting them to do the hard work of creating Moonlight on Linux.
Microsoft is smart enough not to try to maintain a Linux version
of Silverlight on its own (I’m considering only technical issues,
let’s set aside philosophical issues on this one).
If we really want to make Linux a good platform, then we need to stop
messing around with the basics – at least please don’t muck up the
basic shell scripts and paths.
The way to get more people, in large numbers, to understand the open
source and free software philosophies is by making their first steps
easy. It cannot be an all-or-nothing approach. Closed source software
on Linux is not practical. And that’s a bad thing because if we can’t
convert software developers to use a different platform, how can we
expect mom and pop to switch
In spite of all this, I think we’ve done a good job of FB on Linux,
and happy to see all the great
we’ve seen so far, including reports of success on various distros
that we’ve never even heard before. So please keep the
Standard disclaimer: The opinions expressed here are my own, not