Open source software: modify, extend, or leave it alone?

When I first started using WordPress for blogging, it didn’t have support for standards-level Atom feeds. Being open source, though, a colleague had looked at how RSS feeds were processed and had written some code for Atom. I took this code and plugged it into my installation, right along side all the code that came as an official part of WordPress.

This worked great until I installed the next release of WordPress. First, I forgot to stick the Atom code into the code directory. Later I realized that something had changed and things were not working correctly. I was able to tweak it and everything was fine … until it happened again. This might still be a problem except that WordPress eventually provided proper support for Atom and I could delete and forget the custom code.

To be fair, WordPress has a very good extension architecture and hundreds of plugins have been written that support this. There is virtually no reason for the average WordPress user to look at the source code of the main application.

And this is good, because if you start tweaking the main application you can run into the same sort of problem that I had above. If you start making modifications to the primary source, you have created a recurring commitment to keeping the patch current until it is no longer needed. There might be great advantages to you for having the patch, but keeping it up to date through changes of the main application can be quite a bit of work.

One way of ending the need for you to maintain the patch is to get the application committers to accept your “fixes” and put them in subsequent versions. Depending on the project and the quality of your work, this can be easy or next to impossible. In the closed source world, the analog would be for you to get the software vendor to implement a change request immediately as a fix or long term as a feature addition.

As I mentioned above, if there is a good extension architecture, there may be no need to modify the core application. WordPress, Drupal, and FireFox are all hugely popular open source projects that allow extensions by virtue of software hooks or programming interfaces (APIs). I think most people know about APIs, but an example of a hook is something like “apply a set of user actions right before sending the content to the browser.” An example might be “every time the content is to be sent to a browser, first search for all occurrences of words in a given list, and then replace them with links to relevant websites.”

This allows the architects and developers of the main application to focus on the core functionality and the extension mechanisms. They themselves can provide higher level, non-core features via hooks or APIs, and it is not uncommon to see software shipped with standard extensions.

Extensions are not immune to bugs or problem when the main application changes. Anyone who uses Firefox and extensions knows that it takes a fair amount of time after a major new release is available for extensions to get updated, if they ever do. I used several extensions years ago that never supported later versions of Firefox. It is frustrating when this happens, but I either move on to new extensions or learn to live without the old ones.

Drupal seems to require massive changes in extension modules between its major version changes. WordPress sometimes requires plugin updates, but since WordPress is updated more frequently, this has become standard operating procedure and is generally pretty smooth.

To be clear, extensions and plugins are wonderful things and maintaining compatibility with new software releases is an old problem not restricted by any means to open source. Proprietary software also can have version-to-version compatibility problems with extensions, APIs, and data formats.

If you don’t want to deal with any of these problems, consider avoiding patching code and using extensions. I think for most people the first is a reasonable option, but the second will probably cause you to miss some really nice features that come in extensions, often by developers outside the core development community.

There can be innovation in the core application, but that same application can become a platform for innovation if it has a good extension mechanism. Choose good applications that can be improved or configured outside the core software, and you’ll save a lot of trouble and gain some real advantages. This is true for open or closed source software.

2 Comments

If you’ve got to the point where you’ve studied the code enough to realise you need to write a patch, you should probably get an anonymous VCS checkout of the project rather than download a source tarball.

Nearly all VCSs system let you pin your checkout to a particular tag or branch, so you can do your development against “stable” release or set of releases.

The advantages of this are:

1) You can always see the local changes you’ve made to the code with a “$VCS diff” invocation, without having to keep a whole separate “orig” tree around yourself.

2) Updating to the next release is normally lower-bandwidth if the VCS is sending you patches against last version, compared to downloading the entire source tarball again.

3) Updating to the next release should automatically apply/merge your local changes to the new tree, for free.

4) Sending patches upstream, on the off-chance they’ll be merged, gets easier, as many VCSs will automatically add extra information to the patch which the upstream maintainers will find useful/necessary (e.g. add the author’s name/email address to the patch itself, so that that information never gets lost if the patch is forwarded on).

Oh, how much easier “core patching” would have been if everyone used Git! (or any other distributed VCS :). When everyone has their own branch securely checked in to the VCS, merging in the latest version of “master” is usually a walk in the park.

Anyway, I agree on the extension recommendation. If a system requires you to write code in the core, it’s a badly designed system without enough extension points.

PS: “Atom” isn’t an abbreviation for anything, so there’s really no reason to write it in uppercase letters. :)