Aye, It's a bit like saying you can't sell your code, because you wrote it in someone elses software.

Writing a decent Dockerfile isn't hard, and keeping it maintained and working with new versions is still work and it's past the wheelhouse of very many people. It's entirely reasonable to want paid for that effort.

That said, it's not work I personally value enough to put my hand in my pocket, and that's a fair take too.

I think it's perfectly fair for them to say "we're not doing this any more". The sketchy part is deleting the public registry at docker.io/bitnami rather than just no longer updating it. Why can't docker.io/bitnami become the 'legacy' registry, receive no future updates, so at least folks who don't hear this news won't have pulls suddenly fail?

edit: like if I have a package on NPM and I want to stop offering it, I think it's shitty to just delete it. That breaks builds.

When a project is abandoned, when updates are slow, when features people want are not being released, when tracking upstream dependency updates are delayed, sure, you are not entitled to anything and I’ll be the first one to say get off your butt and contribute. In the other hand when you engage with the community for years under an OSS/free context then once the community has invested in your project, learning it, creating learning resources for it, integrating it into their own projects, and you never communicated your intention to “wait until it gets big then then pull the rug” it feels like a disingenuous bait and switch. The reason it feels that way is because it is a disingenuous bait and switch. This is even more so the case when you built your project on top of other projects.

I have no problem using a paid product or service or paying for support on a OSS product, but will never pay one of these bait and switch scams a dime, no matter how much engineering effort it takes.

Vendor lock-in is a thing. Switching costs are a thing. They know this. That's the whole business model. They're expecting that the cost of switching to outweigh the cost of the subscription.

I get that this business model is fashionable amongst wannabe rent-seekers, but it's still antisocial and should be shunned.

Reminds me of a joke, where there was a beggar sitting on a street next to a certain office, and one man has been giving him a coin every time he went to work or was going home. That continued for a while, until one day the man says to the beggar - "you know, I've been giving you a coin twice a day for a while now, but now I am getting married, it's an expensive thing so I can't give as much anymore, I only will be giving you a coin once a day from now on". And the beggar cries out: "Look at this putz, he's getting married and now I have to feed his whole family!"

What do you mean, that's the business model more than half the VC-funded startups now. Provide something for free or near free, wait until your customer is dependent on you and/or consolidate into at least an oligopoly and then put the thumbscrews on.

I find that to be a pretty dishonest business model. I don't have any Bitnami images to replace, but I know a lot of people who do without ever having made that choice - and their bosses aren't going to pay Broadcom for the most part either. So you end up with overworked developers that now hate Broadcom and/or a whole lot of deployments that just break or never get updated. The number of people going "I can just switch over to the archive image, whatever" on the K8s subreddit alone is concerning.

> Previously, you would prioritize traction among developers over focusing on revenue.

A.k.a. using open source as a marketing tactic to lure in customers, only to do a rug pull once the business gains enough momentum.

> But that does not work in 2025.

Good. It is an insidious practice. There are very few projects that actually do this properly without turning their backs on the users who made their products popular in the first place.

> You are expected to make money from the get-go and are left with only enterprise customers and boy, that category is hard, as everyone is competing for that slice.

The strategy of delivering valuable products that benefit users without exploiting them has always existed. The thing is that many companies choose the greedy and user hostile path, instead of running a sustainable business that delivers value to humanity and not just to shareholders, which is much more difficult. So I have no sympathy towards these companies.

The problem I think is that all the easy infrastructure problems have been solved and the market is crowded with those solutions. Solving the hard problems is probably where you could have a viable business but I don't really see that many companies trying to solve those:

* Making mono-repos work for large companies.

* Mixed language builds are still a ci/cd unsolved problems for most companies.

* Testing strategies for Iac deployments.

And more that I won't bother to list here.

So, you're saying in 2025 businesses are expected to actually make money? What a novel concept. Will the wonders ever cease? I mean, you could expect that thing where you borrow incessantly to "gain traction" and "produce growth" but never produce any returns on it to run for a bit, especially in a new field where becoming #1 is at premium. But it has to stop somewhere. So it looks like somewhere is here.

The outcomes of this behavior will be devastating and the problems will last for generations.

I have an infrastructure company and I'm focused 100% on developers. It definitely isn't easy, but I see it as the best path for the business.

You can't have it both ways.

If their value-add was miniscule then they should be trivial to replace.

If it's a struggle to replace them then that's the value they were adding.

Packaging is not miniscule value, it's valuable gruntwork.

it doesn't say anything nice that "moderate inconvenience" is a "struggle"

Naive take.

That's like saying, "Honda isn't a car company, they're an assembly company because they don't mine the minerals to make the parts and rely instead on supply chains"