Free open source comes with a cost

In my blog post “Thoughts on open source” I ended cryptically with But be aware that just because they’re “free” doesn’t mean that the cost to use them is zero. Let me expand a little on this with especial regard to JavaScript libraries.

What exactly is a cost associated with an open source library? When is it not free? I’ll compare this with buying a library from a component vendor, such as DevExpress, the company I work for.

For a kick-off, an open source library certainly does seem to be free: you go to the library’s page on GitHub, and you clone it onto your machine. Done. No cash changes hands.

Now the issue is that you can’t just leave it as a set of files in some folder, you have to use it. You have to read its documentation (if there is any), learn its API and quirks. You have to incorporate it into your web page or application. You might have to change the HTML and CSS (the blog theme that kicked all these musings off cost $20, so essentially free, and yes I had to change markup to use it). All of this takes time and resources, and – hidden somewhat – money. Your time is not free, by any means. However, I’ll agree that, if you bought an equivalent product – with proper documentation, demos, updates, support, and what have you – you’d have to do this anyway. So let’s call it quits on that score.

At this point, something goes wrong. You encounter a bug. After making sure you are properly using the library and doing some debugging, you ascertain that it’s within the library, much as I did with jQuery Widow Fix. I had valid markup but the library was modifying it to make it invalid.

In my case, I could fix my immediate problem relatively easily: just change the markup in some hundred blog posts where the bug appeared. Gee thanks, the cost of using this library – and hence the theme – just went up drastically. I would have to spend quite a bit of time – therefore, money – to do this. How much is your time worth? Alternately, since the bug was easily reproducible in a test case (five minutes work, tops), I could have notified the owner of the library.

In fact, whether you are using a commercial library or an open source library, that is my recommendation. Create a simple test case – in my experience having worked for two component vendors, bugs can pretty much always be reproduced in a simple test case: the bug is due to some oversight in how the library might be used, or the library is being used in a way not foreseen by the developers – and send it off. This is when the difference between paid-for versus open source really comes into play. The commercial player has a big incentive to fix the issue as soon as possible; after all, you have just provided a simple test case for a visible issue. And, unless the fix is going to result in some major refactoring of the product’s code, that is what will happen. Indeed, that is your expectation having paid for the product. You will get a hot fix or a workaround pretty quickly and will be able to continue your development. As a bonus, if the vendor team has any nous at all, they will put your test case in their test suite, so your issue will never be seen again.

In the open source case, good luck. It all depends on the owner and (possible) contributors. If the open source project is funded by one or more commercial entities, you’ll probably get a fix reasonably quickly. If not, you will be relying on the owner’s work ethic and time/resource availability and just plain inclination to maintain their project. The older the project, the less likely a fix will be coming. You therefore have a choice at this point: live with the issue and devise some kind of work-around (fork the library!), or drop the library for another (for JavaScript, there’s always a new library around the corner!), or just live without the functionality completely. All of these choices involve an evaluation of the resulting hidden costs, of course.

For my particular case, there was no contest: the Widow library was so clumsily written that there were several distinct ways it could break your markup. The bug was first reported four years ago and is still not fixed. Reading the replies on the issue page, I see the owner basically has no idea how to proceed. Looking at the way the code was written, it’s my opinion it’s going to involve refactoring it to use some kind of semi-intelligent parser or (worse?) regex. And that will blow the current couple of dozen lines in the library to a hundred or more. Sure, parsing is something I have some knowledge of, but I’m not that enamored of the library’s functionality that I have to have it at all costs. So, I’ll take option three: discard it.

If however, you really need the functionality and there’s no similar library around, it’s time to expend effort in fixing it yourself. Read the code, work out a possible fix, test it with your test case. If everything’s good, issue a pull request and continue using your fix until the library owner merges your PR. But it still requires effort and time and money to do, all for an ostensibly free product.

In summary then, although open source software is supposedly free, there are costs associated with that library: learning, debugging issues, devising workarounds, writing pull requests, and so on. Agreed that some of those might never occur – I’ve never hit a problem with jQuery in my work, for example – but they could. And that’s where the inevitable costs come in.

[It’s at this point that I finished my draft of this post, but on rereading it, it struck me that I could be a little more forceful. Let me put it like this: the software you and I write depends for its success on code that other people like ourselves write for us. Sometimes we pay for that software in cold hard cash, but sometimes we pay for it in other ways. And I’d say using open source means paying for it in those less visible ways: if you are going to use an open source library in your code, assume “ownership” of it; debug issues and come up with workarounds or fixes; publish pull requests. If the owner is unresponsive, fork it and make it yours. Even better, support those open source libraries by answering questions on StackOverflow (I regularly answer questions on SO on the open source charting library Flot, even given that DevExpress provides a competitive one in DevExtreme). In short, invest in the open source library by investing time in using and fixing it.

  Loading links to posts on similar topics...