Sunday, November 9 2008, 19:33
Open-Sorcery: the default answer to a feature request is "no, do it yourself"
Open-source is often acclaimed by its supporters for empowering the users using the products rather than big corporations only out for the money and leaving users with closed and static software. My point here is not to start another holy war about Open-Source vs Proprietary Software but to debunk some myths about open-source and how many of the advantages promoted by the open-source movement simply do not work as smoothly in the real world. In this article, we will see how getting a little and insignificant feature (like adding a command-line switch for an already existing feature available through the GUI) implemented in an open-source software often feels like an assault course, especially if your feature request happens to be rejected for a more or less acceptable reason: priorities, not useful to most people, laziness, or just because you can do it yourself, so doing so should you!
While it is true that anyone
(with the technical skills required, that is) can get the source code and make modifications to it, it isn’t exactly as easy as, say, opening
a Word document and adding a paragraph and printing it again. There are
several obstacles in the way, which make this journey a far more
adventurous and time-consuming matter than the open-source zealots told
Open-source movements tend to be quite Linux-oriented, which is natural since GNU and Linux did so much for it. This means that a lot of tools for the development of the product may be quite Unix-cultured, which is obviously an obstacle if you are a Windows user. For example, getting the source code from Sourceforge often requires the use of CVS, which is a tool you need to learn before even beginning the long journey to adding your feature.
This one is a bit similar to the culture: let’s assume that the open-source project you intend to recompile uses external libraries. These may not be included in the project’s source code package. For example, an open-source project I recently wanted to modify made use of the Boost C++ Library, which wasn’t delivered with the source code. Obviously, it means spending yet more time looking for the required components (and possibly even needing to compile them, which may themselves have their own dependencies, getting you in some sort of infernal cycle…) before even starting to work on implementing your feature.
Understanding the source code internals
Depending on how complex the program is, it can use something between in the tenths or hundreds of source code units. Understanding how the program’s source code is structured isn’t something that comes immediately. You need to read the source code and figure out the functions and objects it uses and their purposes. At first, you’re not really sure in which part of the source code the feature you want to add or modify may be. All of this requires programming experience and time, especially if the documentation and code-commenting is poor.
Once you’ve implemented your feature… what happens?
Congratulations! You’ve spent a whole morning, getting the source code off the repository, sought the dependencies all over the whole Internet, and understood the source code structure and the objects it used to properly implement your feature (what was it already... oh yeah, adding a command-line switch to activate an already existing feature in the GUI). You have compiled your binary and it works fine, but what’s going to happen in the future? Sooner or later, a new version of the software is going to be released, which won’t include your cherished feature you wasted so much time to implement.
A solution would be to make a patch and go through the procedure of grabbing the source code from the repository, getting the latest version of the dependencies, modifying the source code again (either manually or through a patch file, provided this part of the source code doesn’t change so dramatically that the feature needs to be rewritten) and recompiling. Obviously, all of this isn’t really convenient and you probably don’t want to skip new versions as they fix bugs and add new features (alas, minus yours), so what can you do? Do you go through this time-consuming routine every time a version is released? You can of course decide to be pragmatic and forget about your self-esteem and go back to the people who told you to go away and implement the feature you requested by yourself to ask them as politely as possible to add your now implemented feature/patch to the main source code repository. Of course, if it happened that the reason wasn’t laziness or just the fun to have you waste a morning on something an active coder on the project could have done in a matter of minutes, but that it doesn’t match with what they want to do with the software, you’re going to be on your own and have to implement this feature again, every little time a version is released. Once more: simply not as convenient and easy as advertised.
I certainly realize I’ve been a bit cynical here, but that’s also because I’m quite bored to see any suggestion I propose in open-source applications return with basically the same answer. It is boring, especially when you hear the same sugarcoated arguments about how much open-source empowers users to make the application fit their goals rather than them fitting in the mold of a static application. Of course I understand that the point of open-source is to have people participate to help the development but it isn’t like the project leaders would accept any code as is anyway: it would need to match certain code guidelines and standards and as such is likely to be partly or fully rewritten. While having the source code, and as such the opportunity to modify the program, is certainly better than having no alternatives, it also serves as an easy excuse for people managing this area of the project (which may not even be the developers themselves: sometimes I’ve seen this delegated to mere forum-bunnies) to reject any suggestion a bit too quickly. It also reveals one of the biggest flaws of the open-source movement: support, where you are basically on your own if things go wrong or if you need something, using the excuse that thanks to the source code you can debug anything and add anything by yourself. No wonder many businesses quickly came back from the open-source hype and tend to turn to more predictable products for their business-critical applications.
Granted, to have a feature added to a proprietary software, you need to convince the author about it, which may be quite difficult if it is a big corporation like Adobe, for example. The smaller software companies releasing their software as shareware or freeware need to be convinced as well, but they will at least do their best to please the customer and help him with a particular shortcoming of the software if the feature can’t be added immediately.
I’m not telling that open-source is bad or that it doesn’t have its strong points, but just that having the source code isn’t a good enough solution for many when you need features for the reason I’ve listed above: even for developers, it is just too time-consuming and spending several hours or days making ephemeral changes to an open-source application that are not going to be preserved in the long run makes you drift away from your current project. Time is money: and because of that, even if open-source software tends to usually be free, the cost of using them when you need support or new features turns out to be expensive, sometimes even more than a commercial product whose developers may be a bit more helpful… since, after all, you’re the one paying their salaries…