@radekmieBy Radosław Miernik · Published on · Comment on Reddit
Over the years, I was in a way forced to change the software (of all kinds) way too many times. The news of Tupperware almost closing down in last year and iRobot actually filing for bankruptcy this year are, to some extent, results of a rather similar process. Obviously, the scale is much bigger, and I won’t cry about a mega corporation losing money, so let’s stick to the software.
Here’s a short story I see way too often: you’re using an “enterprise” solution1 that costs a lot and start looking out for alternatives. Some time later, you make a decision and migrate to the new-and-shiny product2. Then, a few years later, their quality goes down, prices go up, and the whole cycle repeats.
Enshittification is a thing, nothing new on that front. But as someone working on open source projects for years (also professionally; see On Getting Paid for Open Source), I believe it can be done better.
All it takes is a tad less corporate human greed.
Becoming the Next Big Thing™ is nothing but the main goal for most, if not all, startups out there. Sure, the understanding of what it means will be different for a social media platform and a frontend animation library, but it’s out there. Sometimes, it’s unrelated to their vertical, e.g., “Make the world a better place.” is a valid, though crazily vague, target.
Once you get some traction (revenue, users; however you measure it), people will start considering you as an alternative. That will drive you even further. All you have to do is rinse and repeat. (I know it’s not that simple, but you get the idea: at some point, you will be a viable choice.)
Finally, you’ll become an interesting bite for an acquisition. (Because every single startup always does, right?) Up to this moment, except for these few valuation-increasing decisions that cost you a few customers, your users were treated surprisingly well! Their requests were (often) acted on straight away, problems (usually) addressed, and the price remained reasonable.
However, an acquisition is just an investment, and these are meant to pay off at some point. (Again, there are exceptions, but I ignore them on purpose today.) The same goes if you’re going for an IPO or an investment round. I’m so sorry, your only goal now is to make it happen.
And you’re not the one who will pay for it.
Looker, a promising business intelligence platform, got acquired by Google in 2019 (1, 2). What happened to the existing users? Extreme price hike, virtually no support, and halted development (1, 2, 3). Oh, they copied some parts of it into Google Data Studio, and followed up with renaming it to Looker Studio, because we love reusing the same product names, right? (Ironically, the same happened to Tableau when Salesforce bought it; the name stayed, though.)
Nx, a… Well, it started as a monorepo management tool (task orchestration); now it does a lot of things in the same area. AI is also there, duh. Anyway, Nrwl, the company behind Nx, raised $8.6M in late 20223. Later, in mid-2024, they announced Nx Powerpack, a “suite of paid extensions for Nx”. While they said it won’t impact the existing users in any way, it removed an important feature at the same time.
There are whole stories around Reddit charging for API access, Unity charging for game installations, or Bitnami licensing their Docker images. Depending on your reliance on these, you either had an alternative, were forced to pay for it, or decided to look for alternatives.
After enough backlash, Nx backpedaled on it in early 2025, and so did Unity. That’s why calling out such behaviors is important! In Bitnami’s case, you can still use some of it, but at a cost of continuous maintenance; that’s kind of similar to Minio switching to “source only distribution”.
In general, it pays off to be vigilant about what exactly you’re outsourcing. Is it a “fixed amount of value”4, like when you’re installing an open source library? Is it something that will scale with your application, like a specialized database? Or is it something your entire organization will heavily rely on, like an internal knowledge base?
My rule of thumb is that the more isolated a tool is, the better. Bonus points for not relying on existing dependencies, as that leads to coupled versions. I try to follow it also when developing software – that’s why changestream-to-redis, ranges-set and even uniforms are “focused” by design.
My salary for the first 10 years was mostly coming out of investors’ pockets, so I also benefited from it. However, my point is that not every single thing has to conquer the market. Do you have to scale further, add more and more features, and inflate the prices while at it?
At some point, you have to, as otherwise your competition will eat you alive. I’d like you to mind the difference between making a living out of it and breaking the bank. We all need the former; the latter is a dream for many of us. But that’s a dream that often comes at a price of others’.
It’s on us not to harm others.
If you want to read more about why such “enterprise” solutions cost extra, go ahead and check out On Enterprise Paywalls.
This decision process is a cost, too. I worked with some smart people ignoring it, because “We’ll let our developers try it out.” A hundred hours later (or more, depending on the problem), they are either surprised and learn a lesson or fire the poor researcher due to a drop in performance.
At that time, one of the teams I was working with was migrating from Lerna (another monorepo tool) to Nx, as they took the stewardship of it earlier in 2022. Such a funding round was both good and bad news – good, because the tool is here to stay; bad, because we knew the price would change.
Here, by fixed I mean “I can do it in X hours and be done with it”. Of course, there will be some maintenance needed, but the same goes for updating your dependencies. It all depends on the level of vendored complexity.