Thoughts on open source

Waaaay back when (yes, it was eight years ago, an eternity in software development), I wrote a post on my old blog about using “Code from the Internet”. In those days, for me and my readers that meant finding some C# code from some blog post somewhere out there written by some Joe Blow and using it in your own app. These days however, if you’re doing any kind of web development, you’re going to be pretty well using a whole bunch of code from the internet, and in general from that internet outpost called GitHub.

Back then, my recommendation was to read and understand the code you were about to, er, recycle, and to sanitize it, if you felt that was needed. This is exactly what I did with the server code behind the URL shortener I use for jmbk.nl: read it to understand it, clean it up, remove the bits I didn’t want, add new stuff I did, rename the API identifiers, make it work on Azure, add authentication, and so on. After all, it was first written in 2009.

These days, with jQuery, Angular, Knockout, React, etc, etc, you just do not have the time, resources, or inclination to do a deep dive. Instead you rely on what might be called a crowd effect: if lots of developers are discussing and using and maintaining some library you’re about to consider, then you’re more likely to view that code as a black box that can be used as is without too much worry.

This attitude came back to bite me last weekend as I updated that old blog to use a modern responsive theme instead of the wickedly awful theme I’d concocted for myself some ten years ago (“to make the website look good in both Firefox and IE6”). Like all modern themes, the look and feel is pretty much all generated from the CSS but there’s also some tweaks to improve the experience via some JavaScript. The theme ships with about a dozen open-source libraries, some of which I’d never seen before (and that I might use elsewhere). To cut a long story short: the theme couldn’t find images that were definitely available. The culprit was one of the JavaScript libraries that was also being loaded (and whose purpose was something completely different).

So what to do? Especially given the reality properly exposed by the now old joke “If you don’t like the JavaScript library you’re using today, there’ll be another along in a minute”.

I’d espouse a few tactics:

• If the open-source library is maintained by a company, I’d say just use it. (Examples: Angular (from Google), React (from FaceBook), Bootstrap (from Twitter), even the AJAX Control Toolkit that DevExpress maintains.) However, please read the license: for example, there are stirrings about a clause in the React license at the moment.
• Talking of licenses, check it. Really. Just because the source code is readily available doesn’t mean you can download/use/distribute as part of an app. If you can’t find a license, leave that open source library well alone. You have better things to do than be embroiled in some legal imbroglio. And be careful of a GPL or LGPL license; aim for an MIT license.
• Check out the history of the library: how many releases? How many issues? How many pull requests? How many commits? In other words, how current and contemporary is the library? In the case that prompted this post, the library had one release, has four issues, and the last commit was eleven months ago. A well-supported library this is not. Also, the most commented-on unsolved issue was exactly the problem I ran into, and it was opened four years ago. As another example, let’s look at Knockout: 37 releases, last commit in January 2016, 61 contributors, well-frequented, pull requests galore, and an up-to-date Issues page. In other words: people use this library, maintain it, and want to make it better. That gives you confidence.
• That last point also applies to the theme I bought: even as a purchased “library”, how up-to-date was it? Well, it used jQuery 1.8.3, which is enough to make me worried for a start. Even when paid for their product, the developers don’t want to update it to keep it up-to-date?
• Documentation? Even better, does the library come with a test suite? Both will help you in how to use the library and the tests may point to where the library is deficient.
• Personally speaking, I also read some/all of the code. If it seems well-written (to some approximation of my own style, perhaps), then I’d trust it more, because I feel more confident about being able to fix bugs, and issue pull requests for them.

Above all, remember that most open source libraries are, well, ahem, crap. They’re uploaded once and never touched again. And note I count some of my own open source libraries among that illustrious set.

Open source libraries (or to use my old term, code from the internet) are a great way to expand the capabilities of your apps, especially client-side. But be aware that just because they’re “free” doesn’t mean that the cost to use them is zero.

Now playing:
Thievery Corporation - Doors of Perception
(from The Cosmic Game)

  Loading links to posts on similar topics...