How to Succeed in Open Source Without Really Trying (Really)
Tags: webdev, svg, javascript, npm
Published: 2023-05-10 01:29:00

---
title: How to Succeed in Open Source Without Really Trying (Really)
published: true
description: It is code written by an idiot, full of downloads and regex, signifying nothing.
tags: webdev, svg, js, npm
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xkg9nzcxkdzxhj1l7rxw.png
# published_at: 2023-05-09 19:08 +0000
---

≥8 years ago, I wrote about [an extremely niche improvement to a very specific use of SVGs.](https://codepen.io/tigt/post/optimizing-svgs-in-data-uris) It got enough positive feedback that I turned that knowledge into an NPM package: [`mini-svg-data-uri`](https://www.npmjs.com/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”](https://snyk.io/advisor/npm-package/mini-svg-data-uri), 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-uri` solely on RunKit](https://npm.runkit.com/mini-svg-data-uri), 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”.

<dl>
<dt>It’s not <em>that</em> effective.
<dd>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 <code>data:</code> URIs.
<dd>Unless you’re using <code>mini-svg-data-uri</code> in an offline build tool, it’s almost certainly not worth the download of its JS. (So <a href="https://www.npmjs.com/browse/depended/mini-svg-data-uri">all of you <code>import</code>ing it</a> to use on the client-side… are you sure you want to do that?)

<dt>It has no tests.
<dd>I don’t remember where <a href="https://github.com/tigt/mini-svg-data-uri/blob/master/index.test-d.ts">its <code>index.test-d.ts</code></a> came from, but it’s certainly not clear what it accomplishes.

<dt>It rarely updates.
<dd>Snyk penalizes this, but honestly it’s kind of a feature. It rarely <em>needs</em> to update.

<dt>It’s written in like, ES3½.
<dd><a href="https://github.com/tigt/mini-svg-data-uri/pull/5">Folks wanted to use it untranspiled</a>, or something? In principle <strong>that’s terrible</strong> and Alex Russell will appear in your mirrors at night chanting “who made this mess”, but <a href="https://unpkg.com/browse/mini-svg-data-uri@1.4.4/">in practice it’s ≈3.5kB unminified</a>.

<dt>I am objectively kind of a bad maintainer.
<dd>I automated nothing, which means I must relearn how to <code>npm publish</code> each update, which means folks’ contributions can get needlessly delayed.
<dd>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.
<dd>There’s no code of conduct or contributing guidelines, and it still defaults to <code>master</code>. (Somehow I’ve innovated the cognitive dissonance of believing those things are important, and yet also <em>too</em> important for my rinkydink package.)

<dt>The features it accrued are niche.
<dd>Its “types”: a function that accepts a string and returns a string. <a href="https://github.com/tigt/mini-svg-data-uri/pull/15#issuecomment-624412182">I assume the TypeScript was for autocomplete or purism or something</a>, because it sure doesn’t constrain much.

<dd><a href="https://simonewebdesign.it/1req/#the-favicon">Its CLI is from a dev who whipped it up for themselves then contributed back on a whim.</a> 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 <code>#!/usr/bin/env node</code>.

<dd><a href="https://github.com/tigt/mini-svg-data-uri/issues/9">It sprouted a <code>.toSrcset()</code> method</a> because <code>srcset</code> uses spaces as part of its syntax, so you need <code>%20</code> escapes. <a href="https://github.com/tigt/mini-svg-data-uri/blob/00dc78c8f77eb7b47299a9e3d564749105810c9c/index.js#L51-L53">It accomplishes this with zero cleverness whatsoever</a>, so I suspect most of the feature’s worth is from how it emphasizes the <code>srcset</code> pitfall in the README.

</dl>

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 fund` do 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](https://overreacted.io/npm-audit-broken-by-design/), 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](https://www.johndcook.com/blog/2012/05/25/unix-doesnt-follow-the-unix-philosophy/), 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](https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-an-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](https://github.com/tigt/mini-svg-data-uri/issues/9#issuecomment-503397923).

When I put it that way, it sounds like a pretty good trick.