Open source software is alive and well in 2017. Any application you could think of or imagine probably has already been created and released as open-source software. The rise of package manager’s like Node’s NPM, Python’s pip, and .NET’s Nuget allows this software to be delivered into developer’s hands with a simple command entered in a terminal window. I am convinced that there’s never been a better time to be a software developer, and it’s easier than it ever was to learn how to code. And yet, I often find myself wondering if the previous barrier to entry into software development was better for the quality of software. There are plenty of open-source libraries now, and plenty of fast and easy ways to get them into your application. That being said, do we really know what these libraries do and how can we trust the quality of software built by strangers on the internet?
In an increasingly connected world, authentication becomes the largest challenge for those trying to conduct business on the internet. Otherwise, you become liable for cost incurred by fraud, neglect, or user inexperience. I would say that the same applies to those trying to release open-source software on the internet as well. Not many people are going to use your software if they cannot be assured of it’s quality, and then your github stars, forks and, watches become a litmus for software quality. But such a method of social proof doesn’t actually let people know how easy to use and reliable the software is. Consider one of the most widespread vulnerabilities in recent memory, Heartbleed, was caused by a flaw in an OpenSSL standard library. Sure, the fact that it was open source allowed it to be caught in a seemingly proactive manner, but the ubiquity of the library made the breach that much more worrying. Popular software isn’t necessarily good software but making sure your software can be trusted is hard to do when you offer it without warranty.
This is easier said than done since package managers have made using external libraries super easy. I made a notification program in C# for my team at work that uses an SVN package from Nuget. I only used one or two methods from the package and I don’t know anything about it beyond the usage of those one or two methods. This certainly qualifies me to speak about and document the one or two methods that I used, but it doesn’t qualify me to make sure it is bug free, secure, or a good piece of software. I’m not saying I did no research about it before using it, and I am confident that I have not introduced any security risks by installing and using the package. However, because the library is open source it is subject to change, and change is not something many organizations are prepared to deal with when the inner workings of the library are abstracted away by API calls.