This is the follow-up to the previous
episode.
So, is free software always better than the other kind? Jonne claimed
that the “freedom” aspect of free software isn't an advantage for him,
because free software is hard to change, and it takes a long time to implement
the new feature you would like to add to it. The alternative would be to send
a bug report or feature request to the developers. But both in free project
and proprietary ones you may reach grumpy developers, who will consider your
request as low priority.
Now the real difference between free and proprietary is that in the case of
free software, you have the right to do it yourself. It may be difficult and
take an enourmous amount of time (such as integrating CMYK in GIMP, which was
not designed orginally to handle anything else than RGB), but it is possible
if you are willing to devote resources (time and/or money) to it. With a
proprietary software, if the developers don't want to implement your feature,
there is no appeal. Jonne's argument was that you can always find a software
(free or not) that does what you want. I claim that this is not always true.
The first example is that when I built my leffakone five years ago, there was
no software running on Linux that supported DVB subtitles and automatic TV
commercial removal. Actually, there was no software that was supporting these
two features at all. So I took the time to implement them myself (and yes,
MPlayer's subtitle code is an horrible mess). The second example is a recent
problem with Python's X11::Protocol module. It had a bug that I managed to
identify thanks to the source code, and I found a way to go around it. I
submitted a bug report, but to this day (over a month later) it has still not
been answered. X11::Protocol was exactly what I needed, but had it been
proprietary, I wouldn't have been able to find a workaround, and would have
needed to settle with a sub-optimal solution, which would not have been doing
exactly what I want.
Jonne also claimed that developers don't need the source code of a software,
but the software should be designed so that it can be extended. Firefox is a
good example: a lot of features can be added as “extensions” and the
developers don't need to access Firefox's source code. But not all software is
designed to be extensible, especially if it is in the (financial) interest of the
publisher to prevent anyone to develop an extension without its blessing. This
means that if the extension you want to develop doesn't follow the publisher's
commercial strategy, you won't be allowed to do it. And again there will be no
appeal. An no, you don't always find another software that does the same
thing and would allow you to develop your extension.
And guess what? Most of the software available nowadays is not extensible.
That is, it's not meant to be easy to extend. If you want to change its
behavior or fix a bug, you have no choice but to dig into the source code. And
even if the software has been designed with extensibility in mind, it doesn't
mean that the data it exports through its extension API contains all the
information you need for your purposes. A good example of this if my blog
engine, Bloxsom. It was designed to be extensible, most of the work is done
by extensions rather than by the software's core. But for implementing
features such as multiple languages and multiple categories, I had to change
the core, because the extension API was not enough. And I don't know any other
blog engine that fits my requirements. But hey, I don't know all the blog
engines in the world, so I may be wrong.
To be continued.