Some Questions in Relation to the Latest JavaScript Open Source Scandal
If you followed the r/javascript or r/programming subreddits in the past few days you probably already read about the latest Open Source scandal to hit the JavaScript community:
About a year ago, Marak — a prolific open-source author, wrote in the repository of his highly popular library faker.js that he is tired of providing value to fortune 500 companies while being broke himself. They should either pay him or fork his work and maintain it on their own dime or else… This was apparently related to a fire at his apartment (see below), and a subsequent financial crisis he suffered from, as this tweet indicates. While the original issue was deleted, you can see this Reddit thread, which remains.
On January 4th, 2022 he followed through on his threat and basically deleted the faker.js codebase. While he didn’t delete the repository itself, he deleted the actual library code, rebased the repository so there is only a single commit in it, and rewrote the readme to read:
What really happened with Aaron Swartz?
You can see the repository here, and the Reddit thread discussing this here.
Marak’s shenanigans didn’t stop here. It seems that he also intentionally introduced a bug to another popular library he created: colors.js. In this case, he added an infinite loop that console logs a test message and then released it. This bug affects thousands of users, including several very popular packages such as live-server and jest.
He then created an issue in the color.js repository and claimed this issue is due to an unforeseen regression, requiring a huge amount of work to fix, subsequently posting several times reports on a sleepless night he is spending fixing it. This was subsequently proven to be false in the same GitHub issue, and you can also see the Reddit this Reddit post concerning it as well as this one.
As a result, and according to a tweet by Marak, GitHub froze his access and NPM reverted faker.js to a previous release. In my opinion, these are correct interventions on behalf of these platforms (both Microsoft-owned companies) — ensuring that Marak cannot cause any more damage for the time being, and at least temporarily ensuring the open-source component of this saga is finished.
Now, it seems that Marak has a history of unhinged behaviour: in September 2020, following a fire in his apartment (the same fire as mentioned at the beginning of this article), bomb-making materials were discovered, and as multiple people in Reddit noted — he is probably having some sort of psychotic break. While this is sad on an individual basis — and I do not belittle the suffering and struggle mental health issues cause, it does highlight some of the problems underlying open-source, both from the side of the creator and the side of the user.
Setting aside the apparent malice (or at least mischief) in some of Marak’s actions, it’s a worthwhile question to ask whether an OS author has the right to delete the codebase they created? Or even for that matter to modify the Git history in a way that eliminates the contributions of others?
Of course, if the project is not used by anyone and there are no contributors, then these questions are simple — the author has full control of the codebase and its history, and he or she can do as they please. But these questions are not so simple if the situation is different.
By accepting code contributions, the author in effect agrees to “share” the ownership of the project to some extent. True, this doesn’t translate into actual access control in GitHub or other similar platforms, but I am talking about ethics here, which is after all the realm in which “rights” exist. In this regard, to delete a repository, or modify its git history in a way that hides contributions, is an affront to all the different contributors who contributed code, triaged issues, made suggestions, reported bugs, and so forth. All of these people dedicated some of their time, talent, and goodwill to the given project. This dedication comes with an expectation of receiving credit, even minuscule, for their respective contribution. And this is in effect a pact between the author, or maintainers, and the contributors.
Then there is the side of the user. When I create a piece of software and publish it under an open-source license, I wish for it to be used. How can I expect my code to be used if it can’t be trusted? When using an open-source package, users extent trust to the authors of the package. Obviously, this is not always a good idea — otherwise, we wouldn’t need to worry about malicious code, and the booming toolchain security space wouldn’t be a thing (you can also see the Snyk blog post regarding this). Yet, aside from the fraudsters, scammers, and thieves who are among us, open source is built on trust on both ends of the equation- we trust the authors of packages to write code in good faith, to be competent coders, to follow best practices etc. And the authors of open source code trust we will use their libraries in good faith, give credit where it’s due, and support them as programmers and creators.
When an open-source author goes and deletes his or her work, for a project that is in use, he or she acts against the foundation of what makes open source possible.
In this case, the correct solution is to find maintainers who are willing to take ownership of the project and transfer ownership. If no one is willing to take ownership, then deprecating the package while converting the repository to read-only mode and archiving it is a viable option.
Another thing that is highlighted here is the problem of trusting large, popular projects run by a single owner/maintainer. True there are many trustworthy open-source authors, like me (if I may say so myself), who take this responsibility seriously.
Yet I would be apprehensive of using a project that has sole maintainers. It’s simply a fact that maintainers burn out — the more popular the package is, the more a maintainer is pressured to fix issues, attend to PRs and spend his or her free time on this project, usually with meagre compensation.
For example, consider this pinned issue in TypeORM — one of the most popular ORMs in the JS/TS space. The author of the package did not receive the kind of financial support he was expecting. He tried to transition into a project following the example of Vue.js and others but this move failed. As a result, TypeORM moved from being a vigorously maintained project into an almost deprecated package. It’s still maintained but not very actively — as the piling of issues shows.
While I sympathize with the author of the above package and do think large companies should support open source developers way more generously. I also recognize that the reason people create open-source projects, to begin with, is not in search of financial compensation — rather, it's because the problem is interesting, or they like to create something new, or maybe they want to showcase their skills and create a reputation for themselves. All viable reasons, and in a way these serve as a form of compensation.
The correct solution in the above case would have been to add more maintainers to the project and to let go of some degree of control. This is indeed hard, but if you really care about something you created then sometimes letting go of some degree of control and letting others join in is the right choice to ensure continuity and growth.
So the final question really is how to mitigate this situation? That is, how to create long-lasting and trustworthy open-source projects?
One interesting option is collective maintenance. For example, in the Python open-source ecosystem, there is an active organization called Jazzband, which as their website declares:
…is a collaborative community to share the responsibility of maintaining Python-based projects.
It gives maintainers and contributors the ability to “play in the same band” instead of being forced into “artist” and “audience” roles.…
Once you are a member you can transfer an existing repo to the Jazzband organization…. There are also many existing Jazzband projects which you can start contributing directly.
This is a great approach and one that would benefit the JavaScript/TypeScript ecosystem in particular.
For example, as a result of Marak’s actions, a new Faker.js repository was created copying the history of the old project, under the namespace whitesheperd, which is apparently some sort of insurance company. It would have been much better if either fakerJS became a separate GitHub organization with multiple owners and transparent maintainers, or if it came under the purview of an organization such as the above-mentioned Jazzband.
Another thing is the recognition of contributions. The actions of Marak are only possible when the author really doesn’t consider the various contributions to his or her project as significant. In other words, it’s a narcissistic act. A good countermeasure to this, and one that signals that a project owner considers all contributions important is all-contributors. This project, stemming from the talented hands of Kent C. Dodds and his multitude of collaborators, allows you to show all the contributors to a project, not only the code contributors. This is very important in giving credit, and it would be great to see this JavaScript/TypeScript tool being adopted by other languages — or even by platforms such as GitHub and GitLab.
More content at plainenglish.io. Sign up for our free weekly newsletter. Get exclusive access to writing opportunities and advice in our community Discord.
