Blog & White

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.