Introduction

I don’t know if you’ve seen it, but recently, a person named Marak, who makes faker.js, created some drama around faker.js.

I do not condone a lot of what Marak has allegedly done. This post is not about most of that. It is just about his decisions regarding his Open Source projects.

He is apparently in a tight financial situation, of his own making, and would like to be paid for his work. After getting frustrated at not getting anything back, he tried to monetize his work as a SaaS. Then some company just copied him and created their own and refused to hire him to help.

So he nuked faker.js, which caused NPM to restore it and GitHub to (allegedly) suspend his account. After getting his account back, he updated faker.js to just spin in an infinite loop.

As can be seen from the link I posted above, people are divided in their opinions about whether what he did was ethical or not.

My opinion is that it was a jerk move, but it wasn’t unethical in the sense of this definition of ethical:

ethical
Being in accordance with the accepted principles of right and wrong that govern the conduct of a profession.

I would like to explain my opinion in this post.

Harm

First of all, we have to ask ourselves: did Marak do harm?

Yes and no.

When he first nuked the project, no, he did not cause harm. If people’s code broke because they expected his code to always exist, that is on them.

In other words, there should NEVER be an expectation that a gift of FOSS code will always exist. Sometimes, the gift disappears. If GitHub had suffered a hack that deleted Marak’s repo, it would have done the same thing. If Marak deleted his account, it would have done the same thing.

However, by putting an infinite loop in later, he caused harm by burning compute resources until people noticed.

How much harm? Well, some electricity. Not great.

Except that he really didn’t cause that harm either because he didn’t force anyone to grab his new code. More on that later.

No Warranty

First of all, there was the claim that Marak’s license does not give him the right to do anything he wants.

This is wildly false. faker.js is under the MIT License, which states:

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

(Capitals in original.)

In essence, this says that anyone who receives the software can have no expectations about what the software can and will do.

In fact, it even directly addresses the case where the software might cause harm with “IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY.”

CFAA

Then there was the argument that updating faker.js to burn CPU cycles was like poisoning brownies.

No, it’s not. In fact, as someone else said, turning the software into a virus would be more analogous to poisoning brownies because that is illegal and should be punished.

And besides, even if he did do something like poisoning brownies, he did it out in the open where people could see.

But that’s not what Marak did. He didn’t even cause machines to be “bricked” (i.e., he didn’t destroy any machines). All he did was burn CPU cycles.

Of course, the infinite loop could have destroy machines, but infinite loops happen all of the time in buggy software. If an infinite loop actually destroyed a machine, something else went wrong, and I would argue that Marak was not to blame for that.

Due Diligence

Oh, and another thing about that: Marak didn’t actually do anything to anyone.

What he did was update his code. That’s it.

He didn’t hack into everybody’s computers and surrepticiously change the code on their machines. He didn’t plant a virus or other malware. He changed his code, on his GitHub account.

He did nuke his repo initially, which means that previous versions are gone from his account, but he also did not hack into everybody’s machines and wipe his code from their machines. They still had previous versions.

He owns the code, and he should be able to update it.

What caused the problems is that other people took the update without checking it and tried to use it.

As someone said, what Marak did was more analogous to provide updated schematics for a floor of a building, schematics that would not work, and the contractor built the floor using the updated schematics without consulting the architect. That would be on the contractor.

Likewise, failing to vet dependencies is on the companies using Marak’s code, not on Marak.

In any other engineering field, the “checking” is called “due diligence,” but apparently, in the software world, it is called “unnecessary.”

Companies that depend on Marak’s code, or the code of anyone who is not an employee or contractor, should always do due diligence when updating their dependencies. Doing otherwise is negligence, and in my eyes, it’s criminal if it affects anyone else but the company itself. In any case, it is definitely unethical.

Which is ironic because many of the same peole accusing Marak of unethical behavior are acting unethically themselves by their negligence.

If you would claim that there is no way to figure out what their dependencies are, then you would be indirectly claiming that they are negligent in even knowing what software they use! There is no excuse for not auditing dependencies.

And then once an audit is done for a version of a dependency, it should be pinned to that version, which means that only that version is used, unless manually updated.

That manual update should also be an audit.

“But Gavin! Marak also caused problems for other Open Source maintainers, not just companies!”

First off, no he didn’t, because they also did not need to pull down his new version. See above.

Second, you may be working on a hobby project as a FOSS maintainer, but you are still responsible to yourself for vetting the dependencies of your code so that they don’t harm you.

If Marak introduced a virus, that’s on him. But he also didn’t force you to take his new version. You took that torch blindly and burned yourself.

Warning

“Even if he didn’t force anyone to take the new version, he should have warned everybody!”

He did warn everybody. Here’s the warning:

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Yes, the disclaimer of liability from the MIT License again. It is also a warning.

A disclaimer of liability is that you cannot have any expectations about the software, including past, present, or future versions. It specifically says that it cannot be considered “fit for purpose”. This is a warning.

If any FOSS maintainer assumed it was fit for purpose, then they cannot blame anyone but themselves. And that especially goes for companies.

If, however, a FOSS maintainer updates to a new version of a dependency and does not get burned, and releases the update to his software, which then subsequently burn others, he is also not at fault; his project (probably) also disclaims liability.

There was also a second warning. It now errors with a 404, but Hacker News discussed it at the time. “No More Free Work from Marak: Pay Me or Fork This” is a pretty clear warning.

Responsibility

Then there is the claim that Marak has responsibility toward his users, a “social contract,” if you will.

Social contracts are usually implied. This leads to bad things because people can have different ideas of what a social contract implies.

And I think this is the real crux of the disagreement about Marak’s actions: those who think he did wrong do so because they think he violated a social contract. And those who think he didn’t do anything wrong (even if they think he was a jerk) believe that he did not violate a social contract.

Yes, you can be a jerk without violating a social contract.

Now, I know why people think he violated a social contract: because there is an inbuilt expectation to Open Source to act like you have a responsibility to users.

For the most part, Open Source maintainers have upheld that expectation.

But let me remind you about another expectation about Open Source that people and companies “conveniently” forget: the expectation to give back.

You see, contracts, including implied social contracts, always go both ways.

So why do people try to enforce one side of the Open Source social project (by complaining when bugs happen), but then get upset when Open Source maintainers try to enforce the other side of the social contract by asking for or demanding payment for future services?

It is hypocritical at best and outright exploitative at worst. But no matter what, it is unethical.

And that’s really why I don’t think what Marak did is unethical: because he was not the one that broke the social contract first; his users were.

With one exception: people who contributed actual code to his projects. Marak was unethical in his behavior if he did not inform them of what he was doing and make sure they could keep the code because they did, in fact, keep their end of the social contract.

Compensation

But what if companies and users had kept the oft-ignored part of the Open Source social contract? Then Marak would be in the wrong.

And that’s what should have been done: companies should have paid and/or done their due diligence. Other Open Source projects should have done enough to protect themselves.

That’s really all that Marak was asking for; he was asking for the companies to hold up their side of the social contract. And yet, he is being dragged through the mud for daring to actually enforce the social contract, just like companies try to do in the opposite direction.

In other words, if you don’t want something like this to happen to your dependencies, pay the maintainers what they are worth to you.

Projects Are People

Why is this a problem?

Because projects are not about software; they are about people.

There are always people behind the projects, and those people are chokepoints; that is why “bus factor” is an actual term.

If you want your dependencies to last, make sure they have the resources they need. That’s why people pay for SQLite, which is in the public domain.

In fact, supporting Open Source projects is just another expression of “Take Care of Your People and They’ll Take Care of You”.

The reason that is important is because people have limited time and energy; their time and energy are scarce resources.

Notice that I did not say that people are scarce resources; they are not resources and cannot be treated as such. In fact, that’s the source of so many of the misconceptions about how to help people be productive.

But again, time and energy are resources; however, they are scarce resources, and they are also time-limited in that you cannot use more than a little of them every unit of time.

Conclusion

To summarize the lessons:

  • Open Source is a social contract.
  • Companies and users violate their half of the social contract.
  • But they also try to enforce the opposite side of the social contract.
  • And they get upset when maintainers try to enforce their side of the social contract.
  • Projects are people.
  • As such, they are constrained by time and energy.
  • If companies would take care of project maintainers, they would take care of the companies needs.

And until companies learn those lessons, Open Source maintainers will burn out, and then companies will suffer through disasters like log4j, Heartbleed, and plain old abandonment.

You know what to do to fix it, so the ball’s in your court.