The following is the story of a developer who published a library to NPM some years ago, which is downloaded weekly for more than one million times. Platforms classify him as an open-source maintainer, but he does not agree with that, because the library is rarely updated and maintained by him.
https://dev.to/tigt/how-to-succeed-in-open-source-without-really-trying-really-55pj
≥8 years ago, I wrote about an extremely niche improvement to a very specific use of SVGs. It got enough positive feedback that I turned that knowledge into an NPM package: mini-svg-data-uri.
Today, it’s both one of the most and least important web dev things I’ve ever done.
Somehow, it’s important
- As of this writing, NPM says it gets ≈1.7 million downloads/week. That also means NPM foisted 2FA onto my account that I almost never use. (If you compare the dates when the repo accepted a PR to the NPM updates, you’ll probably see exactly when they did that.)
- Snyk rates it “Influential”, which means it’s in the top 5% of all NPM packages actually added to a
package.json, not just a transitive dependency. - I know with some certainty that lots of people use
mini-svg-data-urisolely on RunKit, so both Snyk and NPM don’t see a huge chunk of users. (Never underestimate how meaningful a “try online” feature is.)
Normally, I’d be super smug about this and start being insufferable in developer conversations, but…
It’s also unimportant and ridiculous
Snyk and NPM both have algorithms to rate packages for quality and maintenance, but in this case they should consider letting me submit a rating of “lol i dunno”.
It’s not that effective.
The README points out it optimizes by as much as, uh, 20%. And unlike the README’s example, most websites don’t consist entirely of SVG data: URIs.
Unless you’re using mini-svg-data-uri in an offline build tool, it’s almost certainly not worth the download of its JS. (So all of you importing it to use on the client-side… are you sure you want to do that?)
It has no tests.
I don’t remember where its index.test-d.ts came from, but it’s certainly not clear what it accomplishes.
It rarely updates.
Snyk penalizes this, but honestly it’s kind of a feature. It rarely needs to update.
It’s written in like, ES3½.
Folks wanted to use it untranspiled, or something? In principle that’s terrible and Alex Russell will appear in your mirrors at night chanting “who made this mess”, but in practice it’s ≈3.5kB unminified.
I am objectively kind of a bad maintainer.
I automated nothing, which means I must relearn how to npm publish each update, which means folks’ contributions can get needlessly delayed.
If you look through the issues, you’ll see me say “I don’t know” a lot. Humility’s one thing, but I wouldn’t begrudge anyone not trusting me to do things right.
There’s no code of conduct or contributing guidelines, and it still defaults to master. (Somehow I’ve innovated the cognitive dissonance of believing those things are important, and yet also too important for my rinkydink package.)
The features it accrued are niche.
Its “types”: a function that accepts a string and returns a string. I assume the TypeScript was for autocomplete or purism or something, because it sure doesn’t constrain much.
Its CLI is from a dev who whipped it up for themselves then contributed back on a whim. Sure, without a real shell arguments parser, it might break or be needlessly slow. But if you can identify those problems, you probably already know how to fix them with your own #!/usr/bin/env node.
It sprouted a .toSrcset() method because srcset uses spaces as part of its syntax, so you need %20 escapes. It accomplishes this with zero cleverness whatsoever, so I suspect most of the feature’s worth is from how it emphasizes the srcset pitfall in the README.
To be clear, I appreciate that those devs took the time to add features that scratched their own itch. I know there’s something to be said for refusing features to keep software lean and mean. But even though I don’t use those contributed features myself, it takes up a whopping 10kB uncompressed on disk. So, like, refusing those features would have ruined a lot of peoples’ days for no real reason.
Nobody really gives that much of a shit about it
- The code is handy, but if it became even slightly annoying to use — say if I added whatever makes
npm funddo its thing — people would just fork or vendor it. - It’s in a sweet spot of usefulness with almost no leverage, so it chugs along without any temptation for me to do anything spicy and/or money-related with it.
- Putting its stats on my résumé would be impressive, until anyone looked closer.
- It’s somehow avoided getting slapped with the “regular expression denial of service” bullshit that everyone loves, despite having regular expressions I authored in 3 minutes.
- I haven’t even had people try to grift me over it, which I assume is automated based on package stats nowadays.
And yet, it’s undeniably popular. I guess it ticks all the boxes for “is this worth using?” — it handles enough annoying details that you’d rather not yourself, it has no dependencies, and you can read the entire source code almost by accident. The UNIX philosophy is a scam, but it’s a nice racket if you can get it.
It’s dying, but not how’d you think
svg-mini-data-uri will probably become obsolete as evergreen browsers completely take over, since their parsing is loose enough that "data:image/svg+xml," + str.replace(/#/g, '%23') gets you 80% there.
Honestly, it’s kind of nice that it’ll die with the problem it helped solve. It was there when needed, but not a moment longer.
So what?
Maybe the system worked this time? I wrote code for me, then shared it, and now tons of people benefit without me suffering the usual problems of being a popular open-source maintainer. The software does what it says, boringly, and is small enough that it doesn’t make developers or users suffer even when it’s not used “right”.
And it happened without me writing tests, doing any outreach, being good at code, or even using this correctly.
When I put it that way, it sounds like a pretty good trick.