Six steps to avoiding evil open source
If you’re like me – generally operating at the business end of the applications spectrum – then chances are you don’t care about code. And why should you when all that’s needed are tools to get the job done. Right? Wrong.
A significant portion of what we use today has its roots in open source code. Heck, the Internet as we know it would not exist without the open source LAMP stack. Open source is important for many reasons but to me the biggest benefit comes in being able to attract hundreds and thousands to code commit and improve solutions over time, often at no or fractional cost to me as the consumer of that code. Diginomica for example benefits tremendously from the efforts of many coders who have contributed to the WordPress codebase.
But open source has its evil side and it is this I will discuss.
Earlier today and along with a colleague, we rounded out a small content assessment and advisory project. As part of the exercise I’d asked to take a look at the backend components since the object of our review is built upon a widely used open source solution. I was particularly interested to see how the customer will be managing content additions going forward since there was some question about sustainability and self maintenance which didn’t quite make sense given the technology in question.
What I saw horrified me.
The designers had basically taken a perfectly good solution and then butchered it, hacking lumps out of the code to refactor into custom components. In a lot of cases there was no need to do this and I came away baffled as to why they had developed so many custom pieces when there is pre-existing functionality that has been augmented by widely available commercial code. To make matters worse, I had to learn how they were constructing the code along with the dependencies they had created. I gave up pretty quickly.
When we questioned them about it, I was equally horrified to find that none of the answers I heard made any real sense. To my jaundiced eye, this was a classic case of a supplier taking advantage of customer ignorance to do things that were un-necessary but which could be pointed to as fulfilling the quoted work order.
One of the things that worried me concerned the manner in which they had reconstructed the code. Apart from somehow making it SEO unfriendly, they were potentially contributing to giving a false understanding around site activity without clearly explaining what counts for measuring activity.
I am not privy to the contractual terms involved between the supplier and our mutual customer but I am betting that wording like: ‘develop where supplier considers necessary,’ is somewhere in the statement of work underpinning the purchase order. It’s an apparently inconsequential set of wording that can have important ramifications further down the track.
One of the consequences of this particular form of development is that the resultant code could only ever be satisfactorily maintained by one supplier. Its lockin by another name. In most commercial situations, you want to be sure that if the wheels fall off a relationship then whomever picks it up has a good shot at making the next version work just as well as the old. In this case, it is far from clear whether that will be possible.
You can argue that the customer has benefited from a solution that absolutely fulfills their needs but I’d equally argue that in doing so, the customer has unwittingly acquired the technical debt created by its supplier. It doesn’t matter in the short term but has important long term consequences for both performance and improvement as the base technology changes.
We often see this at much larger scale inside business solutions where the customer has asked for and been given ‘xyz’ functionality only to find that the cost of maintenance and regression testing outweigh the long term benefit. It is why business users are often told that an upgrade will take much longer than people expect. As a side issue, it is why cloud based solutions are often favored ahead of on premise. In the cloud, you get what you’re given. Period.
Whether they know it or not, I doubt there is a user of internet technology that has not benefited from open source. It’s represented a fantastic contribution to making the internet what it is today. Many of today’s open source solutions are amazing works of creation that while freely available, represent the collective work of many thousands of programming hours. We should all respect that effort.
The fact that open source licensing allows you to tinker with code is a net good. Heck, I tinker with code pretty much every week but that’s it – tinkering. Augmenting for very specific and narrow use cases, not hacking where I can make sensible compromises. So what’s to do in an open source environment?
- I encourage customers who want open source to carefully think through what they’re trying to achieve and determine whether around 80 percent of requirements can be met from using commercially supported open source code. If that’s the case (and it mostly is, subject to some wrangling around the definition of ‘need’ and ‘nice to have’) then we’re good to go.
- I recommend avoiding open source in situations where the desired outcome is going to require significant code hacking. If that’s the case then you’re probably looking at the wrong solution. There will be alternatives, some of which might be open source.
- Recognize that open source code doesn’t stand still and that any additional functionality that is not handled by functions that are configurable as compared to customized will require maintenance in one form or another.
- Where an open source solution has a plugin architecture, then be careful about selecting commercially supported functional plugins. You’ll need throats to choke and nothing concentrates the mind more than the renewal check. Without that safety net you’re on your own. Also remember that code built for many people is likely to be far more robust than code built for one customer.
- This is a catch all but is just as valid for open source decisions as others. Don’t let requirements get in the way of practical outcomes. Every company I’ve ever advised claims they want this or that functionality because their business depends upon it. I call BS on that. The balance of probabilities in 95 percent plus of cases I’ve seen claiming uniqueness as a differentiator is just plain wrong. Where that has been the case then the customer should develop their own solution.
- Be aware that the economics of open source can be compelling but you will be making tradeoffs and especially in the area of support and maintenance. You might be several steps removed from the original coders which is fine where there is a large base of code committers but of dubious value when the code has both limited distribution and/or limited support. Consider what happens in these circumstances for each open source component in your landscape.
Featured image credit: © momius – Fotolia.com