There are a few really good things about the way software works on the Internet. For a start, there is a huge unofficial network of millions of people contributing to a huge repository of code fragments that help to power many more millions of applications.
Every time you see a little link at the bottom of a webpage that says “Powered by So-And-So”, you’re witnessing this collaborative effect in action.
And of course the main reason people like this third party sharing and collaboration is that it can save you many hours in development time, because you’re not re-inventing something that already exists. But even with these great benefits of the third party code sharing system, there are plenty of reasons why you might want to avoid making use of those code fragments, as we’re about to see…
1.Potential security risks
Because nearly all code that drives anything on the Web is open source, it’s a fair bet that if there is any malicious payload in a given application, it will be quickly discovered by the developer community and rapidly corrected.
But many of these code fragments are downloaded hundreds or even thousands of times per day, and not every administrative team is doing a good job of maintaining a secure code sharing system.
The larger and more complex an application is, the easier it is to infect it by adding a few lines of code in some obscure place. Almost nobody takes the time to scrutinize every line of code in an application, because they generally assume the code can be trusted.
A highly skilled programmer can usually do a good job of obfuscating the malicious nature of the code, and only another highly skilled programmer will figure out what its purpose is… if the malicious code fragment is detected.
2. You don’t own it
This is actually a combination of problems. The first is that you may be subject to various licensing terms. When you have multiple code fragments used in a single web page or application, you may actually be subject to multiple different licensing terms and conditions, and some of these may actually be in conflict with one another.
Of course hardly anyone bothers to read these tedious lists of terms and conditions, but that can potentially be a mistake. In particular it would be a mistake if some condition in the license agreement caused you to be in violation of some law in your home country or in the country where your server is located.
The other issue is that if you don’t own code, you have no control over it, and you may not necessarily understand everything it does or how it works. That means if somebody makes some change to the code, you may be stuck with that change, especially if you faithfully install updates, patches, upgrades and new versions as soon as they’re released as stable, or if you rely entirely on content delivery networks for your third party solutions.
3. You often get much more than you need
Third party code usually works to do the job you want, but sometimes it contains all kinds of extra features that you don’t need and will probably never use. In some cases you can’t remove those extra features easily or even at all. You may also have to compromise. The feature may do something very close to what you intend, but not exactly what you intend. You’re trading awesomeness for the sake of having less work to do, and that’s not always a good trade.
4. Multiple levels of third party dependency can lead to real trouble
Many open source projects use the same third party code fragments in different ways to produce their software. Most of the time that’s not a bad thing, but it can lead to trouble. These days, many developers don’t even install the fragments they are using, but pull them at run time from content delivery networks on demand. The danger of this was illustrated spectacularly by the Left-Pad Incident of 2016.
Every chain is only as strong as its weakest link. This chaining of dependencies means that if any link anywhere along the chain is broken or compromised, the entire chain is at risk of malfunction. In some situations that could be quite costly. Nobody would have suspected the power contained in the 11 lines of code contained in that benign little function called Left-Pad, but when that particular chain link failed, it brought many big websites screeching to a halt. The major part of it was that most people who were using Left-Pad had no idea they were using it, what it did, or how to fix the problem. As stated at item 2, if you don’t own it, you may not necessarily understand it.
Left-Pad was a very simple function that just adds a few spaces to the left side of a line to make sure the line is the correct length. Now the issue here is that any competent programmer could replicate that functionality easily. There is absolutely no need for any application to be depending on this third party function, and yet thousands of websites were using software that included it, including Netflix, Facebook, and Reddit. It was just a stroke of good luck that in this case it was a very simple function that broke the chain, and not some really complicated function that had its own chain of dependencies.
The bottom line is if you can build it yourself, you probably should!
Ultimately the decision on whether to use third party code blocks in your project comes down to a series of complicated decisions that should never be taken lightly. The factors you need to consider are security, legality, cost, time and stability.
To make the decision process simpler, the following test condition will probably help.
IF any of these factors are true:
- the function you want is simple
- you (or your team) have the ability to create the function
- there is plenty of time to create the function
- your application needs good security
- you have concerns about potential legal problems associated with third party licensing
- it is important that your application should never fail
THEN you should build it yourself,
ELSE it may be more efficient to use the third party functions, provided that you are aware of the potential problems and you have a strategy in place for what you will do if those problems arise.
header image courtesy of Stephanie Tucker