Core.js: Open Source is not Broken

I originally planned to write this article a few weeks ago, but back then I didn’t feel that I had too much of an argument to make. By now, however, I think I have a point to make. To be sure, I am convinced of this point for years already, but I didn’t have the arguments required to make it properly, to convince other people who may think otherwise of its validity.

The point I wish to make today is that the infamous “Core.js incident” does not at all prove that “Open Source is broken”, as many have claimed. Rather, it serves as just another example that it is not Open Source that is broken, but the economic system in which it operates.

What is Core.js?

First, let me introduce the backstory of this incident for those readers of this website who come from my academic side of life and who may have never heard of the news in this regard. Core.js is a JavaScript library that developers of websites and online applications use to ensure their website works well on all browsers – and not just a few. It is a library that is not of much interest to most people, because it operates somewhere in the background. But if it weren’t there, many websites would probably look or behave broken on some browsers. Suffice it to say: Core.js is utterly important.

It is developed by a single person, however, and that person has had a troubled history, to say the least. Personally, I think that he’s just had tons of bad luck and I honestly feel bad for him, but many observers have not taken his message well, in which he outlines his dire straits and calls for help. Instead, many have argued that his situation is dangerous – not for him or his family, but for themselves; for the people who simply use Core.js.

A History of Vulnerabilities and Lack of Funding

Now, one might think, “What does it matter?” And in fact, I can understand this sentiment, especially if you’re not part of the web developer community and have never interacted with Core.js directly. However, it is not the first instance which has prompted observers to claim that Open Source is broken. Just a few years back you may have heard of “Log4shell”, or “Heartbleed”. In both instances, which actually broke international news (unlike the situation around Core.js), severe vulnerabilities have been detected in the software packages log4j and OpenSSL respectively that left billions of devices defenseless against hacking attacks. In a single weekend, in both instances, the bugs have been fixed and within the next week, there were patches available for most systems that fixed these vulnerabilities.

Observers back then concluded that, while we were all very lucky that nothing worse happened, Open Source is broken. The reason is that in both instances, it turned out that the affected software was Open Source and maintained by teams of volunteers. And these volunteers complained, during the aftermath of both incidents, about a lack of recognition and funding, and that these types of problems were bound to happen again if nothing substantive changed in the funding structure of Open Source.

There are quite a few differences between the context of Core.js and Log4j and OpenSSL. Core.js is being maintained by a single person, Log4j and OpenSSL by several people. Core.js is not security-critical, whereas the others are. And, Core.js is mostly of no interest to the general public, whereas Log4j and OpenSSL very much are. Nevertheless, I stress the point that there is a commonality.

When people claim that Open Source is broken, they often lack a proposal for how to do it better. It is true that Open Source software in general has a problem in attracting funding. Many companies earn tons of money on the back of unpaid volunteer programmers who provide the backbone of pretty much the entire software market (relevant XKCD), without ever giving anything back. It is also true that this inevitably leads to frustrated developers who, due to burn out and the issue that they have to follow a regular nine-to-five job, cannot properly maintain those libraries. Every Open Source program is basically an assemblage of makeshift hacks that work until they don’t.

But, despite this mounting evidence to the contrary, I still maintain that it is not Open Source that is broken, but the economic system in which it operates. Please allow me to elaborate.

Open Source is Striving Behind the Public Curtains

Open Source is possibly the modus operandi of software development. And in fact it was Open Source how software was first created in a reusable, shareable manner. The most common license in software, for example, is the so-called MIT license, named after the Massachusetts Institute of Technology. The MIT-license was the attempt by the university to provide some legal safeguards to the many researchers who worked there. It was to ensure that all the software they wrote as part of their research could be safely disseminated without MIT being sued due to bugs or other inconveniences.

To this day, the large majority of Open Source software does not consist of some JavaScript libraries. No, it is thousands of LaTeX packages, R packages, Python and Julia libraries, written by statisticians, computer scientists, and other researchers at universities that make up for the majority of Open Source software. And we rarely hear any devastating news about security vulnerabilities from these. To be fair, most of these software packages never make it to the average user. But my point stands that these libraries oftentimes are much more stable, and much better maintained than some of the Open Source packages programmers in industry work with.

In fact, there are resilient, sustainable approaches to writing Open Source software. And when Open Source software is being written in this way, it does prove mostly stable and reliable.

Three come to mind: You can write relatively high-quality Open Source software without completely burning out, if you …

• … are a researcher
• … are employed at a company in order to write Open Source software
• … are paid within the context of a project that is backed by institutional donors

Sustainable Open Source Development Requires Institutional Backing

This listing is – at least for me – striking. It turns out that to write good Open Source software, you need an institutional setting that allows you to. If you are being employed in order to write Open Source software, then it’s a relative no-brainer: You are getting paid, and your entire job consists of doing what the volunteer teams in the case of OpenSSL or Log4j have to do on the weekend.

The dream-situation for many programmers outside of academia is the third option: When you are part of a project that is backed by an institution either directly or, say, via Open Collective, you are effectively equal with the person being employed to write Open Source software. But without any more direct coercive powers of said institution.

The third category is what I personally fall into, and many of my colleagues. As a researcher at a university, you have one decisive benefit vis-à-vis our counterparts in industry: We are getting paid no matter what, and we can more or less do with our time whatever we please — as long as we finish our research projects. This means that maintaining Open Source software is either a direct result from our research or, in the case of John McFarlane (maintainer of pandoc and professor of philosophy) and me (a poor PhD student), a result of needing to do our research more efficiently. Researchers have mostly power over their time and can work on these projects in a more structured manner than industry employees who cannot fix a quick bug during a writer’s block at the office.

Ways Out of the Crisis

I hope the final argument I am going to make is already emerging from what I have been writing until now. What is broken is not the fact that there is Open Source software, and that vulnerabilities could be prevented solely by completely locking away all free software behind some form of paywall. It is corporate greed and short-term profit goals that make companies earn record profits by using free software without ever paying for its maintenance, and afterward complaining that the software suddenly had a security vulnerability.¹

That would be the likely impossible long-term solution to ensure the prosperity of Open Source software: to exchange the current economic system with one that is aimed towards a common good. There are two other things we can do, however, that are easier to implement and can offer at least some remedy to developers.

The first and possibly the easiest solution would be for programmers to finally stop using the MIT license. It was a great and quick fix in a time when software first was disseminated widely, but it is inadequate in a time that sees more and more monetization of the internet. MIT effectively grants anyone to take the software and make money with it, with no obligations attached.

Other licenses such as GPL or AGPL would force companies who want to benefit off of free software to make their own software equally free. This would quickly disincentivise companies from free-loading off overworked developers and probably lead directly to the one solution I have already seen being proposed here and there: That companies would begin to negotiate with developers to actually pay them money if they want to use the software in their own, proprietary products.

The second, somewhat more difficult – but nevertheless much more sustainable – solution would be to “bring the state back in”, as Charles Tilly and Theda Skocpol have so aptly termed it decades ago. The state with its sovereign power could, via the means of regulation, force companies to pay their proper deeds to overworked Open Source developers. This would decrease the likelihood of severe vulnerabilities while at the same time improving the quality of life for the developers with no drawback for everyday users of those software programs.

In fact, the European Union has surprisingly developed teeth in these issues. With its GDPR, the overturning of the Safe Haven Agreement, and, more recently, the AI framework that is currently under discussion as well as forcing Apple to switch to USB-C, it has proven that proper regulation is still possible. Continuing in this line of thinking, I can certainly see that more regulations can help Open Source in many respects. And, to those who at this point will inevitably argue that regulations will stifle innovation and bring the market to a grinding halt: When was the last time a regulation has completely stopped innovation? Is it not the case that in light of regulations companies can get quite creative…?

Coda

Where does this leave us? A few years ago, I argued in a lengthy video essay that Developing Open Source is a Political Act, and I stand by this statement. When a developer goes out of their way to make something for the common good in spite of all the hardships that they face, it cannot be explained with some form of rational economic behavior. It is the aim of doing good, without remuneration. And given the mounting cries for help from the Open Source community, this seems more valid than ever. It is apparent that developers continue to create Open Source software even though we must assume everybody by now knows how it goes.

Open Source is here to stay. And instead of continuously arguing that it was in any way broken, it is time to stop being a bystander and face the reality that we are not going to fix Open Source by simply abolishing it. Instead, we must seek to improve the circumstances which make Open Source seem as if it was broken. This is not something a single individual could achieve, but if we just stopped for a moment, and rejected the thought that Open Source is broken, this would already be a first, big step towards a solution.