Broadcom has always been about pure evil (cough capitalism cough), you just haven't been affected by it before. Ask anyone who's worked with their hardware...
So
They're still technically Avago Technologies, just wearing the name of Broadcom after the acquisition in 2015-2016. Not sure if there's much of Broadcom left, beyond the name and what IP they had at the time which was not sold off, like they did with the IoT related IPs.
Good to see they decided to delay a bit and do some brownouts first. I took a quick look at the Docker hub stats (https://raesene.github.io/blog/2025/08/21/bitnami-deprecatio...) and it looks like some of those images are still getting hundreds of thousands or even millions of pulls a week.
The way I see it, a software project has only (1) code you maintain or pay someone to maintain for you, and/or (2) throwaway code that you will eventually need to replace with an incompatible version.
Nothing wrong with a project that is just gluing throwaway code because it's a gamble that usually pays off. But if that code is from third-party dependencies, just don't believe for a second that those dependencies (or any compatible forks) will outlive your project, or that their developers have any incentive at all to help you maintain your project alive.
24 hours? Wouldn’t it be better to do shorter bouts of scheduled unavailability so unknowing people’s systems will boot up without manual intervention, but still generate lots of nasty logs / alerts?
There was actually a really terrible brown-out by Poetry (a Python dependency management and packaging tool) where they introduced sporadic failures to people's CI/CD systems: https://github.com/python-poetry/poetry/pull/6297
It is sad to see how Broadcom cannot do padding right for mobile…
But on topic: why not create docker.io/bsi and let /bitnami as is without new updates? Then nothing breaks; it just won’t be possible to do upgrades. You’ll then figure out why and possibly seamlessly switch to your own build or BSI.
> But on topic: why not create docker.io/bsi and let /bitnami as is without new updates?
If people are relying on you for automatic security updates, and you've decided to no longer provide these updates [for free], users should opt in to accept the risk.
This would normally require user action (after a period of warnings/information), and having the fix look 'obviously' unsafe (`/bitnami ` ->`/bitnamilegacy`) feels reasonable.
I don't want to discount the work they are doing, and that it has no value, but a little bit shocking that they expect to go all commercial with this, in the Oracle way, while just "packaging" and so relying on open source software that they will not contribute to.
Also, I'm a little bit wondering at how much all of this is really copyrightable in the end.
Because if you keep it private I understand, but here it is basically for each package just a few lines, recipes to build the components that they don't own. Like trying to copyright the line "make build".
And it might be each the single and obvious way to package the thing anyway.
And speaking at the built artefacts, usually a binary distribution of third party open source software with common license should preserve the same rights to the user to access the source code, the instructions to build, and the right to redistribute...
I understand the vision behind trying to monetize these images for enterprise use, and can get down with the idea of maintaining both a “less secure but free” and “more secure but paid” model. But it appears that Broadcom’s intent is to over time force everything on to their enterprise offerings, which seems like a short sighted thing to do.
Over time it will limit adoption and ultimately just make everyone go back to the native open source offering, cutting bitnami/Broadcom out of the loop.
Broadcom really took the open source community backwards with this move IMO.
I was never a fan of images from Bitnami. They always used complicated entrypoint and setup scripts, and introduced weird quirks to the software. More than once have I experienced issues or ran into configuration limitations with Bitnami images that didn't exist in official ones.
So good riddance, as far as I'm concerned. I recommend anyone to avoid using them, and switch to official images or to build them yourself if they're not provided. That's the more secure approach, anyway.
Sometimes, over engineered approaches are necessary to make older software work with environment variables and configmaps, because said software is still designed for traditional VM deployments.
> However, in order to sustain and support the dedicated team of engineers who maintain and build new charts and images, a subscription will be required if an organization needs the images and charts built and hosted in an OCI registry for them.
This is such a naive take. Bitnami images were a sign of goodwill, a foot in the door at places were the hardened images were actually needed. They just couldn't compete with the better options on the market. This isn't a way to fix it, it's extortion. This is the same thing Terraform Cloud did, and I don't think that product is doing so hot.
> Essentially, Bitnami has been the Jenkins of the internet for many years, but this has become unsustainable.
It's other people's software, so it's very rich of Bitnami to accuse anyone of freeloading when their only contribution is adding config options to software that maybe corresponds to a level 2 on the OperatorFramework capability scale[1] - usually more of a 1.
>This is such a naive take. Bitnami images were a sign of goodwill, a foot in the door at places were the hardened images were actually needed. They just couldn't compete with the better options on the market. This isn't a way to fix it, it's extortion. This is the same thing Terraform Cloud did, and I don't think that product is doing so hot.
You seem to be confused about who Broadcom is and how they operate. "Long term health" isn't a thing for them. They buy products that are embedded deeply in the fortune 500, cut 90% of the staff, and increase licensing and support 2-100x. They do not care if you are upset. They do not care if you're going to "find something else". They don't care if you build an entire campaign to decry what they're doing.
They know the F500 cannot easily remove them, and that they will have at minimum 5 years to print cash on their service contracts. Sure, some of those F500s will sue them and try to stop the extortion via legal means, but they know that they'll either win, or at worst still be allowed to jack up prices even if a court rules it's not their original egregious asking price.
In the end, they have to do it because of the CSR, and they can do it because of the CSR.
The European Union Cyber Residence Act has the potential to drastically change the open source ecosystem.
The new regulation pushes the due diligence for security according to the Act towards any entity making a commercial offer based on open source software.
Caveat emptor!
For any enterprise, that means that they either do extensive documentation and security on open source components they use or they use foundation or enterprise-backed products.
Note that pure uncommercial open source projects are exempt from the Act.
I see this as a chance; we can still create open and free software, and those of us who desire financial compensation from those who make money with their work can offer as a necessary compliance framework as a service via a different entity.
I advocated an enterprise to migrate away almost two years ago now. In enterprise time that means the project to do so is just about complete, so I am feeling pretty vindicated just now.
Meanwhile if anyone wants images with dramatically higher supply chain security than anything Bitnami ever offered, and free to the public forever, check out stagex.
As the only multisigned, full source bootstrapped, reproducible, and container native distro that exists, it does not matter what registry you pull from because the digest is the same everywhere.
We publish all images to both dockerhub and quay and signature checks pass either way so mirror anywhere you want.
Anyone claiming they need to host in a particular registry for security is gaslighting you.
I never understood the point of Bitnami. Every time I tried one of their image / package, it's a complicated mess full of custom and strange stuff, really hard to work with.
Instead of a simple package of the software based on some familiar base, you get some weird enterprise garbage that follows strange conventions and a nightmare when you need to customize anything.
Back in the day, Bitnami was a way to run Wordpress on Windows. They packaged it nicely so that you could install it on Windows Server. Nowdays that could get you fired, but back then Linux was not so widespread.
I've used them as a quick way to get rootless configured base images. Not sure if official repos provide those now, but it used to be a big hassle to get things like postgres images running without root in their containers. Although I often had to read through their dockerfiles to figure out the uid setup, where configs live, etc because they were not consistent between the various bitnami images.
> The Photon images provide many other benefits not previously available to users of Debian images, including:
Drastically reduced CVE count (e.g., 100+ CVEs to in some cases 0)
This implies that they are deliberately offering Debian images with known unfixed security vulnerabilities. Sounds evil.
65 comments
[ 2.7 ms ] story [ 80.2 ms ] threadIt's a shame that competition for this position has been ramping up lately.
The way I see it, a software project has only (1) code you maintain or pay someone to maintain for you, and/or (2) throwaway code that you will eventually need to replace with an incompatible version.
Nothing wrong with a project that is just gluing throwaway code because it's a gamble that usually pays off. But if that code is from third-party dependencies, just don't believe for a second that those dependencies (or any compatible forks) will outlive your project, or that their developers have any incentive at all to help you maintain your project alive.
But on topic: why not create docker.io/bsi and let /bitnami as is without new updates? Then nothing breaks; it just won’t be possible to do upgrades. You’ll then figure out why and possibly seamlessly switch to your own build or BSI.
It's on brand when you consider how badly the styling in Rally needs an update.
If people are relying on you for automatic security updates, and you've decided to no longer provide these updates [for free], users should opt in to accept the risk.
This would normally require user action (after a period of warnings/information), and having the fix look 'obviously' unsafe (`/bitnami ` ->`/bitnamilegacy`) feels reasonable.
Also, I'm a little bit wondering at how much all of this is really copyrightable in the end. Because if you keep it private I understand, but here it is basically for each package just a few lines, recipes to build the components that they don't own. Like trying to copyright the line "make build".
And it might be each the single and obvious way to package the thing anyway.
And speaking at the built artefacts, usually a binary distribution of third party open source software with common license should preserve the same rights to the user to access the source code, the instructions to build, and the right to redistribute...
Over time it will limit adoption and ultimately just make everyone go back to the native open source offering, cutting bitnami/Broadcom out of the loop.
Broadcom really took the open source community backwards with this move IMO.
So good riddance, as far as I'm concerned. I recommend anyone to avoid using them, and switch to official images or to build them yourself if they're not provided. That's the more secure approach, anyway.
This is such a naive take. Bitnami images were a sign of goodwill, a foot in the door at places were the hardened images were actually needed. They just couldn't compete with the better options on the market. This isn't a way to fix it, it's extortion. This is the same thing Terraform Cloud did, and I don't think that product is doing so hot.
> Essentially, Bitnami has been the Jenkins of the internet for many years, but this has become unsustainable.
It's other people's software, so it's very rich of Bitnami to accuse anyone of freeloading when their only contribution is adding config options to software that maybe corresponds to a level 2 on the OperatorFramework capability scale[1] - usually more of a 1.
[1]: https://operatorframework.io/operator-capabilities/
You seem to be confused about who Broadcom is and how they operate. "Long term health" isn't a thing for them. They buy products that are embedded deeply in the fortune 500, cut 90% of the staff, and increase licensing and support 2-100x. They do not care if you are upset. They do not care if you're going to "find something else". They don't care if you build an entire campaign to decry what they're doing.
They know the F500 cannot easily remove them, and that they will have at minimum 5 years to print cash on their service contracts. Sure, some of those F500s will sue them and try to stop the extortion via legal means, but they know that they'll either win, or at worst still be allowed to jack up prices even if a court rules it's not their original egregious asking price.
The European Union Cyber Residence Act has the potential to drastically change the open source ecosystem.
The new regulation pushes the due diligence for security according to the Act towards any entity making a commercial offer based on open source software.
Caveat emptor!
For any enterprise, that means that they either do extensive documentation and security on open source components they use or they use foundation or enterprise-backed products.
Note that pure uncommercial open source projects are exempt from the Act.
I see this as a chance; we can still create open and free software, and those of us who desire financial compensation from those who make money with their work can offer as a necessary compliance framework as a service via a different entity.
https://stagex.tools
As the only multisigned, full source bootstrapped, reproducible, and container native distro that exists, it does not matter what registry you pull from because the digest is the same everywhere.
We publish all images to both dockerhub and quay and signature checks pass either way so mirror anywhere you want.
Anyone claiming they need to host in a particular registry for security is gaslighting you.
[1] https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...
[2] https://www.gnu.org/software/mes/
[3] https://bootstrapping.miraheze.org/wiki/Stage0
[4] https://savannah.nongnu.org/projects/stage0/
[5] https://github.com/oriansj/bootstrap-seeds
Instead of a simple package of the software based on some familiar base, you get some weird enterprise garbage that follows strange conventions and a nightmare when you need to customize anything.