I’m always uneasy when using open source, especially in a professional context.

I don’t mind using open source when I’m developing on my own time and my own projects. It saves a lot of time and work to use code for a problem that’s already been solved by someone far more knowledgeable than me.

But when you put any open source code into production, you’re putting your trust in a third party.

And maybe that trust is misplaced.

Let’s talk about three instances of open source gone wrong.

Ant Design

Ant Design is a UI design framework for React web applications. On September 18, 2018, one of the main project contributors committed a “Christmas easter egg” into the project.

If you do not know Chinese, the top comment from the main project contributor reads “changelog 里无须体现”, or “No need to add this to the changelog.” The contributor was deliberately attempting to hide this easter egg from the consumers of their package.

The change itself was rather harmless, as the only thing it did was to convert all buttons into snow-covered buttons on Christmas Day and added a popup tooltip reading “Ho Ho Ho!” However, I have no doubt that there were a lot of developers pulled into work on Christmas because of this.

Most companies have a non-existent sense of humor about these sorts of things, especially for things they can see with their own eyes. I am not particularly surprised hearing about one or two developers losing their job due to this “joke”.

EventStream

On September 16, 2018, a bad actor was granted access to the event-stream repository, who then proceeded to add code that would steal private keys to cryptocurrency wallets. The malicious code would wait until certain conditions were met before activating, so the problem wasn’t caught until November 20, 2018, by which time the package had been downloaded several hundred times, as the library itself was used in a number of packages across the npm ecosystem.

There’s a question of what a project maintainer owes to the community at large. Maintaining an open source project is a thankless task, especially if it’s a package that is used widely in the broader ecosystem. You have a lot of demands on your time, but aren’t really compensated for your work either.

I’m a big proponent of programmers being paid for the code they write. However, it’s not great when a bad actor is able to cause so much damage due to your own actions and negligence.

Actix Web

Actix Web is a web framework written in Rust. On January 17, 2020, the package was removed from its original repository and moved to the project maintainer’s personal repository. I can’t really know how much damage this caused, as I’m not really familiar with the Rust community, but I imagine it was not a good day for quite a number of programmers.

The reverse of the above question is what does the community at large owe to its project maintainers? So many people become burnt out by the project they once loved. I’ve seen it happen many times.

However, to go and destroy any good will generated from your original work seems a bit of an extreme escalation.

I don’t have a great answer, but I know that if I was depending on this code for my own systems I’d be reevaluating that decision.

What to do?

I’m not saying that open source developers aren’t doing valuable work. They certainly are, and without open source, a lot of technologies would be left in the hands of huge companies and out of reach to everyone else.

But when you’re developing in a professional context, you need to evaluate every line of code that goes into your system. You need to know how it works and how it may interact with other parts of your system, even if that code was written by the open source community, especially if it was written by the open source community.

People like to use packaging systems like Rubygems or npm when pulling in third party code, especially in continuous deployment pipelines. But as we’ve seen above, those systems would not have prevented a bad actor at the individual contributor level from causing a mess in your own systems.

What I like to do instead is to directly pull in the portions of the code that I need. Most open source projects cater to as many different use cases as they can, which means there’s a lot of code you might not even need for your own particular use case. Open a new file, copy in the code you do need, and use that in lieu of downloading the package.

Make sure that the project’s license supports what you’re doing, including the licenses of any upstream dependencies, as there are some projects that specifically restrict that sort of activity.

And of course it’s imperative that you keep up to date with the project you’re copying from, to make sure there aren’t any bugs in the originating code that you might need to fix in your own fork. But at least you can rest assured that every subsequent deployment to production will not be potentially harmed by people outside your own organization.