I recently came across an interesting article about the integrity and security of a major source code repository of the world’s most active and popular programming languages on the planet, in serious danger of being compromised by malicious viruses and malware.
No fewer than 39 packages were found in NPM (Node Package Manager), which contained malicious and dangerous code.
NPM is an open source online registry of javascript libraries that anyone can freely download for your own use in your own software application.
By last count, there are well over 350,000 source code package libraries that have been uploaded into NPM, making it the world’s largest online software library repository in the world, hands down.
Need a software library to let you connect to an Oracle database? How about a library to let you work with JSON files on the command line? Or what about a library to help you parse Microsoft Excel files?
All possible with libraries in NPM.
It’s no surprise NPM has become so popular. It’s a true testament to the power of open source and collaboration, and an invaluable tool for software developers.
If there’s one thing software developers HATE doing, is reinvent the wheel. It’s why we create reusable software libraries.
If we have to write code to parse an Excel file, it stands to reason we will need to parse a different Excel file in the future.
The smart developer will take that code to parse the Excel file and make it into a reusable software library you can incorporate into future projects … reusable code helps a developer save time by only developing functionality that actually solves the unique business problem the application is supposed to address.
And by and large, most developers have a strong sense of collaboration and community. We WANT to help out fellow developers … it’s in our DNA.
Which is why we often upload useful bits of code and software libraries into open source repositories like Github and NPM so that other developers can take advantage of the same libraries.
This spirit of giving and wanting to help out fellow developers has driven the entire open source movement since it’s inception.
History of Open Source
Richard Stallman, an MIT hacker from the 1960s, embraced the idea of openness in computing and sharing useful code with other software developers.
His driving philosophy was that all software should be free. Not “free” as in “free beer”, but the other kind of freedom.
The freedom to run the program as you wish; the freedom to copy the program and give it away to your friends and co-workers; the freedom to change the program as you wish, by having full access to source code; the freedom to distribute an improved version and thus help build the community.
From this philosophy, Stallman wanted to write a free operating system and supporting software. Many of these applications are still widely in use today like the emacs text editor and GCC, a software compiler.
Stallman continues to champion the free software movement with his Free Software Foundation.
The Closed vs. Open Source War for Developers
It kicked off a sort of idealogical war of philosophy within the software development community.
On one side, was the notion that software deserves to be free. The other side was the notion that software can be proprietary and closed, meaning that a software developer is not obligated to share the source code or allow anyone else to modify it.
Microsoft built its empire around this opposing philosophy of open source. Consumers of Microsoft’s flagship operating system and Office productivity software are not allowed to read and examine the internal source code nor be allowed to modify it.
The World Is Built On Open Source and Open Standards
Open source continues to be a powerful influence and driving force in modern computing to this day. Linus Torvalds created a UNIX like operating system kernel, which is the core innards an operating system needs. This kernel, in conjunction with all the free software which Richard Stallman and his software utilities and applications, have created the massively successful GNU/Linux ecosystem.
[bctt tweet=”History has shown that open standards stand the test of time, compared to proprietary technologies.” username=”profocustech”]History has proven that open standards and open source prevail and stand the test of time, compared to proprietary code and technologies.
- TCP/IP, which is the networking protocol behind the internet, is an open standard which has the support of all major institutions and organizations. The TCP/IP protocol is how computers communicate and transmit information to each other over the internet, it’s literally the backbone technology behind the internet.
- HTTP (hyper text transfer protocol) is the layer that sits on top of TCP/IP and makes the concept of clickable links from one web page to another, possible. It is also an open standard.
- HTML (Hypertext Markup Language) is the markup language which websites are built with. It is also an open standard.
In fact, many of the other supporting technologies that drive the internet, are either open source, or conform to open standards as well…Cascading stylesheets, javascript, file transfer protocol, PGP encryption, and tons of other protocols, languages and technologies all are based on open standards.
The technologies that usually die on the vine, are the ones that DON’T conform to open standards or are closed and proprietary so you can’t examine the raw source code.
When’s the last time anyone willingly uses the Flash plug-in technology inside a web browser? Flash is proprietary and closed source, and rapidly being dropped by many users and organizations.
Silverlight, which was Microsoft’s attempt to compete with Flash, has also died on the vine, due to being closed and proprietary technology.
There’s a great read by Eric Raymond titled “The Cathedral and the Bazaar”, which explains why the open source movement has caught on so successfully. History is proving open source and open standards are the wave of the future.
The Fallacy of Open Source
Yet as wildly popular as the open source movement has become, there is a bit of a dark lining developers need to be aware of.
THE DANGER OF TRUST.
Open source has a bit of an Achilles heel … it’s very strength, it’s openness, is also a potential weakness.
What would happen to someone who wanted to make something open source and deliver it to the software community at large?
What if that certain someone had nefarious intentions?
The fact that NPM was infected by a good number of malicious software packages, is positive proof that not everybody uses open source with good intentions.
It’s not just intentional maliciousness we need to be careful of.
There is also the danger of thinking open source code is naturally “better” in quality than closed and proprietary source code.
That kind of dangerous thinking led to the famous “heart bleed” security vulnerability found in the open source implementation of the SSL (Secure Sockets Layer) protocol to encrypt data communications.
It’s estimated that close to a million websites still have the heart bleed vulnerability.
It’s not that this bug was intentionally created. It’s just that the vulnerability wasn’t discovered until recently.
But you may wonder why this happened if this code was completely open source and free for anyone to examine and modify?
The simplest reason I can think of is simply because there is so much open source code out in the wild.
Not everybody knows how to read, let alone modify, source code. And those that do, need to willingly want to do so.
Trust But Verify
There’s something to be said for the closed ecosystem, walled garden approach to software repositories.
Apple is probably the most famous example of a company that embraces a closed software ecosystem that is subject to tight control.
In order for a software developer to release software for Apple’s iOS mobile platform, a developer must submit their code to Apple, which scrutinizes and reviews the code, and makes sure the code meets their standards and is not maliciousness or contains any harmful viruses or malware.
It essentially goes through a rigorous vetting process, before it can be approved to appear in Apple’s app store.
It doesn’t absolutely guarantee that malicious software doesn’t make it into the app store, but the extreme vetting process goes a long way to help prevent it.
Open source repositories like Github and NPM don’t really have a vetting process.
A developer needs to be well aware of this when they consider using something from an open source code or library repository.
I’m only speculating here, but I imagine sooner or later, there will be a tighter vetting process for open source repositories like Github and NPM. In what form, is anybody’s guess.
The saying “Trust but verify” isn’t bad advice for we software developers to follow.
