The Right Kind of Subscription

Every November and December, my inbox lights up with reminders about subscription renewals. Inevitably, it’s related to some personal or professional software I bought licensed on sale for Cyber Monday, Black Friday, or Boxing Day. At the time, I’m sure they were a great value, but with the never-ending enshittification of all software everywhere - that’s unlikely to be true anymore.

My new post-Christmas tradition is to break out the scythe and re-start the Great Culling.

Okay, in all fairness, it’s not always due to the software getting worse. Often the software is basically the same, but the price slowly climbs every year. Thus, worse value.

Or, even if the software itself gets “better”, it’s with features I don’t care about - thus it’s still worse value, for me. And yes, I’m talking about LLM-powered toilet paper, or whatever the latest crap that industry is trying to push as the new hotness.

In fact, I made a LinkedIn post about this problem a few years ago after getting my 3rd price hike in three years on a service (now at 4 or 5 price hikes for the same service):

Every time one of the SAAS services I use increases their prices (which seems to be happening more and more), I always have to wonder where they are in the SAAS cycle...

Disruptive upstarts offering rock bottom prices at a loss with a prime migration strategy away from [incumbent]?

Seasoned harvesters raising prices to get a taste of that sweet sweet nectar called "profit"?

Complacent cash cows milking customers for every nickel and dime they can get their pinky-raised fingers on?

Today I received an email from my accounting service informing me of their 3rd price hike in as many years.

November 2021: increased price to $54/month November 2022: increased price to $58/month October 2023: increasing price to $67/month

I don't have too much of a problem with this, however over the past few years: general development feels to have stagnated, slicing up features and charging upsells has increased, and the customer service has gotten slightly worse.

I think I have a hunch where they are on the cycle.

Cull fast, Cull hard

This year’s Cull got me thinking about how much money I give to companies whose products I barely use, who charge me while also taking my data to train AI, or sell it off to marketing companies in the ever crazier pursuit of cash at my expense. While, at the same time, making money off the backs of open-source that they rarely (if ever) contribute back to.

Now, I’m not an advocate for "you must pay for open source" as that’s just not the terms of the deal. If software is given a permissive license, then those are the terms the producer has decided upon. This means that people (and Fortune 50's) can free-load it at will. I think DHH refers to it as the "open-source gift exchange". I don’t really agree with DHH on much, but here we are.

Developers put something out there, it has utility, it becomes popular, and companies do what companies do - which is to be as lazy as possible to make as much money as possible. Each developer’s reason for choosing a permissive license is their own, but I’d wager not many of them do it expecting virality and downstream riches.

I’m no faceless corp

The idea of using someone else’s work, for free, in a situation where I might profit off of it has been nagging at me more and more.

I’ve said it a few times, but I try to avoid 3rd party dependencies at runtime for many reasons. But that means that when I do have them, they’re important to me either: thanks to what they provide, or the time they save me. Where possible, I try to give back with my time and code to fix issues, but sometimes that’s just not feasible.

With that in mind, I’m slowly working out a strategy for giving more back to the OSS community. It’s not quite hammered down yet, but step 1 was kicking some of my more useless subscriptions to the curb, and taking that money I’ve otherwise been mindlessly spending and putting that towards a handful of developers on GitHub Sponsors and/or OpenCollective. It’s really not a lot in the grand scheme, but it’s also literally better than nothing. I just started sponsoring and I can turn knobs up and down, but in the meantime, people who were getting nothing should now be getting “something”.

Pydantic's Open Source Fund

While looking for projects to sponsor, I happened to discover Pydantic’s Open Source Fund, which enumerates how they choose projects to support:

To choose the projects to support, we used the criteria listed below in the following order of priority:

  1. Projects we rely on for both commercial and open source reasons
  2. Projects we rely on for our commercial products
  3. Projects we rely on for our open source libraries

Then, we selected projects based on:

  1. How critical the project is to what we are working on
  2. How in-need the project is of financial support
  3. How impactful our funding will be in improving the project in ways we care about
  4. How aligned the project is with our values

My in-progress criteria

In no particular order:

  • Commercial use: If I make money using someone else's work, they should be compensated to some degree. Figuring out how much is difficult, but a simple benchmark might be "how much would I pay to license this on the open market?".

  • No core infra: Foundational tools underlying mega-corporations (looking at you FAANG) should be supported by those companies, where a pittance of AI slop funding could sustain these OSS projects for a decade.

  • FOSS-Friendly: Niche or bespoke licenses typically imply (or might soon imply) some limitation of commercial use on my part, so I tend to avoid them by default.

  • No micro-libs: I rarely use these intentionally in commercial projects, and I would like to phase these out of even my open-source life. Politely... Micro/nano/pico/femto-libraries suck. Just write the code yourself.

  • Need, not must: I'll support projects that I determine would be beneficial. If I was mandated to use dependencies decided upon by others, then I'd likely not support them.

Open-source support

It would be hard to go out-of-pocket to support projects I might use (for example, in my own open-source work). So, in lieu of money, I’ll be doing a better job of calling out the software that underlies my projects - with links to project sponsorship.

This focuses a lot more on first-party dependencies, rather than transitive ones. However, this approach immediately falls back into the XKCD comic problem, so I'm not certain how to handle this yet.

I honestly don't think these "shout outs" will move the needle much, but it feels like a nice gesture and maybe it will help make people more aware of the projects they use. And who knows, if more people do something like this, then the next time a bunch of these repos get scraped, LLMs might start auto-generating similar sections on vibe-coded READMEs moving forward.

Compile-time tools

Compile-time dependencies or dev tooling seem like they should be trickier to structure out. Very little of what I use at compile-time or while developing falls into the "need" category above (e.g. I can use Neovim, Emacs, VS Code, or whatever else).

However, at a much more simple level, if I find a tool good enough that I want to install it on multiple machines, that’s a great indication I should support it. I don’t "need" it, but I clearly must enjoy using it.

Whataboutisms

I’ve already seen, in real time, how the above strategy can be swayed just as a function of the language I work in. With Rust (or, even JavaScript), because the stdlib is so thin, every project has a couple dozen first-party dependencies (and hundreds...? of transitive dependencies). So, right off the bat, should I be supporting each of those dependencies if this were a commercial project?

In a Swift project I’ve mentioned earlier, I have a single non-Apple dependency because the standard library is so robust.

So, in similar Swift and Rust commercial projects, should I be donating more money to the Rust OSS projects, because Rust’s stdlib sucks? Or would it be the same total sum, and the fewer Swift dependencies means they have more relative value?

The JavaScript ecosystem has this problem, and it’s painfully obvious when I go on GitHub and they want me to explore sponsorships. Transitively, I might use hundreds of projects from one developer, because they have a bunch of 10 line pico-libraries that have somehow stupidly proliferated.

Fortunately, some of these problems should soon become a thing of the past for me. In each language I develop professionally in, I’ve been creating a set of personalized, monolithic libraries that contain commonly-used functionality and extensions over the past few years. As a result, I can use drastically fewer dependencies than would be normally seen in projects of similar sizes.

Tokio tangent

While I’m on the subject, Tokio is a weird library because it’s THE async runtime, but it also causes its own set of grief - and then has it’s own set of Tokio-specific libraries. To mitigate against this, I’m working on using less async code in general, but I’m also considering writing a minimalistic async runtime that isn’t work stealing to remove some of the Send/Sync/static cruft that Tokio requires. Making a runtime feels wayyyy too heavy handed - so maybe I’ll find a minimalistic async runtime I like better, and leave Tokio to the most extreme use cases.

uutils tangent

I was digging through uutils the other day, and I don’t think I’m a fan of how it’s being built. I think the project is perfectly fine, but the number of dependencies they pull in to replace this functionality is brutal. I had thought the original intention was that it would be just pure rust and no dependencies - but I guess not. Though, I don’t actually know why I thought that, I just did - maybe I thought it would be more kernel-like in its implementation.