The Canary in the Coal Mine of Open Source Code Re-use
Don’t reinvent the wheel. Like all advice it’s much easier to say then it is to do, particularly when it comes to programming. Programmers suffer from a horrible mental disease called Not Invented Here Syndrome (it’s in the DSM — check if you don’t believe me). We will happily rewrite a perfectly good tool because someone else wrote it and it’s easier to rewrite than it is to understand. Sure, we might not handle all the bells and whistles of the original tool (unicode is for sissies) — but at least we got to DIY.
Rewriting from scratch is particularly a bad idea when it comes to open source software. If there’s an open source library or plugin available that does the trick then there’s no reason at all for you not to pick it up and use it. It’s free. If it doesn’t work the way you want it to then you can rewrite that small part or add functionality. There’s no reason to reinvent the open source wheel…
… as long as you can find it. One problem with leveraging open source is finding out if it exists at all. After enough cursing at Google you’ll eventually get a knack for it and know the good code sharing repositories and announcement lists for your languages of choice. The wheel exists! Someone else is having the same problem and came up with a solution, so now you don’t have to! Thank you, lazyweb.
Or that’s what you think, until you try to take the wheel for a test drive. The install instructions are outdated and don’t work quite the way you’d expect. You have slightly different versions of some common components and that causes things to break in mysterious ways. Or you’ve come across a wheel that the wheelmaker gave up on after he got to where he had to go. The wheel looks like it might do what you want it to, but it’s missing the voodoo required to hook it up to anything.
The single biggest problem I have when trying to leverage open source code with my projects is how long does it take me to get it up and running to demo it? If I can see right away that it works and it will solve my needs, then I’m willing to slog through migrating versions of different libraries, sacrificing some chickens and swilling too much coffee to get it integrated with my code on my machine. But the problem is all the installation headaches seem to happen before you reach that nirvana of running a working demo and seeing what it really does (as opposed to what the hastily written release notes ambiguously imply that it does).
I know what you’re thinking fearless reader: this looks like yet another rant about a wasted afternoon trying to be “productive” through code reuse but instead spent glaring at compiling warnings. But there is a light at the end of the tunnel! I have a solution that will keep you from the Poorly Thought Out Install Process Hell that prevents you from making the most out of open source software:
Ok, that was a bit anticlimactic; and it isn’t even Valentine’s Day yet. But stick with me, I have a point lying around here somewhere. If no one other than the author is talking about that tool/plugin/library on blogs then that means no one else is using it. Or, at the very least, that it hasn’t been sufficiently hardened that you should make any assumptions about how smoothly that wheel will run.
At the very least you should be able to find someone writing about what the tool/plugin/library does and any issues they had in getting it running. If no one has bothered taking the time to do that, then that is a huge canary in the mineshaft, dear friend. A huge canary wearing a bright orange tank top with the words “waste of time” written across it.
Photo by tenerife