Slugging It Out In Open Source

This is a transcript of the audio at https://soundcloud.com/rich-trott/slugging-it-out-in-open-source.

I want to talk about open source but before I do, let’s talk about slugs.

Not the slimy invertebrates, although those are totally awesome.

I’m talking about URL slugs.

Way back in 2011, someone using the moniker dodo published an npm module for making slugs. The module itself was called slug and it became popular. But in 2015, dodo stopped working on the module. In 2017, a denial of service vulnerability in the module was disclosed publicly. Then, after 2018, dodo seemed to have vanished from the internet completely.

OK, I know I’ve set this up like it’s a murder mystery or some investigative journalism uncovering international espionage or something like that, and it’s not that but stick with me here anyway.

My involvement in the story starts in 2018. dodo has stopped working on slug and has either disappeared or is poised to disappear from the internet, and there is a publicly-disclosed vulnerability in slug.

Meanwhile, I was frustrated about a different bug in some other module. The bug was breaking a build for me and I had submitted a pull request to fix it. But my pull request didn’t get a response. The package had apparently been abandoned by its maintainer.

I explained the situation to someone at npm, Inc. “No problem,” they said. “We have a documented process for this situation.” They told me to email the module maintainer and cc npm support. In the email, I was to explain what was up to the maintainer, and ask if they could either merge my change or give me access to the package so I could do the maintenance myself. If the maintainer fixes the bug or gives me access to the package, great. If the maintainer doesn’t respond to me for a couple weeks and also doesn’t respond to a follow up or two from npm support, then npm support will transfer the package ownership to me.

In the current world of increasing supply-chain attacks, npm probably doesn’t do things this way anymore. But in 2018, the thinking was that if someone has stopped maintaining a package, it is in the community’s best interest for the package to be maintained by someone else.

I started emailing maintainers of packages that seemed abandoned and had unfixed bugs, especially security issues. Responses were positive. It probably helped that I was among the most prolific contributors to Node.js core, a fact which I always mentioned.

Some maintainers were grateful to turn over their package because they didn’t want to maintain it themselves anymore anyway. Every single maintainer I emailed replied to me — with one exception. That exception was dodo.

My first email to dodo bounced. I found another email address for dodo, which did not bounce. But dodo did not respond. After a month and two follow-up emails from npm support to dodo, npm support transfered the package to me. I was now the maintainer of slug.

I published a fix for the DoS bug quickly. But now I was stuck. I wasn’t interested in slugs or the package. This package wasn’t the most popular thing on npm but it was far more popular than anything I had ever published to that point. Now people wanted features and help.

To top it off, the DoS vulnerability wasn’t really a big deal. I don’t know how everyone was using the module, but it seems unlikely to have been commonly exploitable.

But OK, I fixed the package. Now what?

I didn’t want to abandon the package and put it right back where it was. So instead, I dove in. I was going to pay down technical debt, fix bugs, add features. There’s a joke that “free software” is free as in puppy, and I now owned a puppy.

I spent time learning different methods for Romanizing various languages, considered the pros and cons of adding various alphabets, and so on. I didn’t have time in my life for this, but somehow, I made time. From the outside, it didn’t look like I was doing much. Each new feature required a ton of research and experimentation, just to show up as a single commit adding a handful of non-ASCII characters. There are still lots of things that would ideally be done. There’s always more to do. But I just can’t prioritize doing them over other things in my life. I still don’t care about slugs. Someone out there does, probably, and that’s great. But I’m faking it. And so it’s all not even that rewarding. This can’t be good for my mental health.

There is another slug package on npm that is more popular than slug. It is called slugify. It is a fork of slug, so it shares a lot of the same API. I made some changes to slug to bring it even more into alignment with slugify. My unspoken hope was that slug and slugify would become so similar that they could merge and I could effectively hand off slug to the maintainer of slugify. Turned out there’s one catch. The maintainer of slugify wanted to do the same thing, and hand off slugify to the maintainer of slug.

After some mutually supportive interactions in the slugify issue tracker, the slugify maintainer emailed me in April 2021 telling me that they added me as a collaborator in GitHub. They told me to feel free to make any decisions and that they trusted me 100%.

In another email, they explained that they never thought about maintaining slugify much, but then it was on a slide for a Google I/O talk and became popular.

The slug and slugify modules are minor examples of a larger issue: So much critical open source code is maintained by people who can not invest the time to properly maintain it. And a lot of these people suffer guilt and anxiety over it.

I’m far from the first person to point this out. And there’s a lot to say about how sponsorships and foundations are only partial solutions. But other people have already explained that better than I could. If you want more information on this, I recommend Nadia Eghbal’s book Working in Public.

I should mention, though, that I have every reason to believe this problem is just as endemic in proprietary software. As with open source, if a proprietary package is big and popular enough, it will be maintained. But everything else faces the risk of burned-out, disinterested, under-compensated developers, and under-resourced teams.

To this day, I do not know what happened to dodo. Maybe they retired. Maybe they won the lottery and have moved to a private island. Maybe they decided to leave tech for another career. Or maybe they just got tired of maintaining slug and simply stopped.