"don't expect" or "for certain"? Can't really plan ahead without some kind of certainty.

There is no real distinction between those two phrases here, because the person using those phrases isn't ultimately in control.

Indeed. While I do maintain two of them, that maintenance is effectively equivalent to being an open source maintainer or open source contributor. I do not have any non-public knowledge about the Docker Official Images program. My interaction with the Docker Official Images program can be summed up as “my PRs to docker-library/official-images” (https://github.com/docker-library/official-images/pulls/TimW...) and the #docker-library IRC channel on Libera.Chat.

Even if they were fully in control, there still would not be a distinction because whoever is controller this decision could change their mind at a later date.

My analysis of this:

After Kubernetes became the de-facto container orchestration platform, Docker sold a bunch of their business to Mirantis. They shifted their marketing and positioning from enterprise to developers. From public sources, it sounds like their strategy is doing pretty well.

The question then is, does Docker look like they are committed to open-source and the open-source ecosystem?

1. You would think that a developer-focused strategy would involve open-source, and that doing things to decrease their influence on the open-source world would reduce their influence, branding, and narrow their funnel. (But maybe not. Are the people paying for Docker Desktop also big open-source users and advocates?).

2. It sounds like Docker has full-time internal teams that maintain the official Docker images and accept PRs from upstream.

3. Docker rate-limited metadata access for public repositories. Is that a signal for weakening support for open-source?

4. According to the article, the Docker Open Source program is out-of-touch ...

5. ... But they may still be paying attention to the big foundations like CNCF and Apache. So the images people depend upon for those may not be going away anytime soon

So I would look for other signals for diminishing commitment to open-source:

- If several of the larger projects pulls out of hosting on Docker Hub

- If the internal Docker teams are getting let go

- If the rate at which PRs are accepted for the official images are reduced

- If the official images are getting increasingly out of sync with upstream

- Some other signals that matches

From my understanding, Docker is moving to become an open to (proprietary) enterprise packager for closed source, or paid for software development.

- Keep access to big, permissively licensed open source software.

- Charge for higher pulling limits and tools.

- Keep source open, but infra closed, hence converting whole infra to "source available".

- Keep "small open source fish" out of the pond, by charging for what's available on the hub/platform.

As a result, they are kinda becoming "Snap Store" of containers. Premium feel, high fees for higher bar for entry, etc.

At the end of the day, Docker is just a hungry whale chasing money. I can't blame them, but they are not motivated by the value they provide anymore. They are motivated by the money they can make.

Sad, but understandable (to a degree). This makes them very easy to disrupt in free software arena. I'm a paying Docker Pro customer, but I might look somewhere else in the long run.

Interesting, "snap store of containers" sounds plausible. Seems like a decent business model, but also, one that is not really committed to the open source ecosystem.

To go back to the question that started this out -- should we be worried about having image dependencies pulled out all of the sudden? It sounds like, if it is a large open source project, probably not so soon. That includes the `library` repos.

Any smaller project should be vendored if they are still sticking to Docker Hub.

I don't think that Docker has an interest to be committed to the open source ecosystem anymore.

They're playing the long game. They standardized container format, completed the reference implementation, gave it as open source and implicitly told everyone "they have done their part, the infra is not under their monopoly, so they're free of the burden".

Due to experience, I'm wary of the infrastructure which I can't build/rebuild. So, anything above Linux distribution + the package repositories needs to be buildable from scratch. As a result, I don't use ready-made app containers unless I have to.

I pull a distribution container and configure it to my liking, and build my own containers. Moreover, if I use the container more than two times, I publish its Dockerfile publicly, so anyone can build it from scratch if they want to. This allows me to get my hands dirty and pivot and rebuild pretty quickly if companies pull things like that.

Containers are great, but not knowing how to work without them, or not knowing how to make one is taking great toll as companies pivot to proprietary/money first models more and more.

Maybe being open and being closed just a cycle, and we're moving to other half of the period?

Did Docker standardise the container format?

I always was under the impression that they had great marketing but were mostly capitalising on tech built by other (mostly Google to be honest) which failed to properly market them.

Sage insight, definitely looking forward to disrupting them in the near future :)

> You would think that a developer-focused strategy would involve open-source, and that doing things to decrease their influence on the open-source world would reduce their influence

The influence you are talking about is negative: increasing control means increasing arbitrary behaviour, which means increasing your risks as a platform user, which means masses of pessimists fleeing to saner competitors who don't seem willing to take away your toys.

One could argue that only the person who is in control could say “for certain”, and as such, that is the implicit differentiator between those two phrases.

I mean yeah okay fine the phrase is then "according to your understanding of the rules set forth by Docker, as of today's edit of the linked PDF (2023-03-15), and in accordance with the current (2023-03-15) configuration of the three images, `alpine`, `node`, and `golang`; are those three images covered by the open source program and will continue to be accessible or will those images cease to be accessible by non-paying members of the general public in thirty (30) days?"

It's just that I'd thought we'd moved past the need for that level of pedantry here, but apparently not.

That's probably a good thing, because that makes clear you missed the point about the Docker Official Images program. Docker's support for open-source organizations has nothing to do with the Official Images program; they are generated by Docker themselves, rather than being generated by an open source project and merely hosted by Docker.

I may sound pedantic, but in all honesty, Docker has been quite hostile over the past few years in terms of monetizing / saving costs, so nothing would surprise me at this point. I would definitely not feel comfortable saying "for certain". Phrased differently, if the person who is in control says "for certain", vs. some random HN user, I would attach a lot more value to the statement made by the personal in control.

There's no need to post a combative reply. The parent is just pointing out the dictionary meaning of 'certain'.

You could instead set the bar at a 'high likelihood' instead of 'certain'.

Unless you're hosting the infrastructure yourself, you can't ever be certain. No one can know for sure what Docker will decide to do in the future. The entire company could shut down tomorrow.

But it seems to me that Docker official images are no more at risk of deletion today than they were a week ago.

> Unless you're hosting the infrastructure yourself, you can't ever be certain.

I can't be certain I won't be hit by a car, or a storm won't rip up the fibre to my house, or a raft of other things, either.

You relatively can.

> Can't really plan ahead without some kind of certainty.

If you are relying on images hosted by a third party, you have already committed to relying on something without certainty.

Useful information, bad look for Docker - "Oh, no slash as the namespace separator. Good and easy way to tell, that's how I would've done it!".

I mean, it's not a terrible convention. On the website they have a badge ("docker official image"), but devs aren't usually looking at the website, they're looking at their Dockerfile in vim or whatever. This is a straightforward way to communicate that semantically through namespacing.

Still, shame on docker for the rug-pull.

It's better than none, but explicit over implicit. If it were namespaced like PULL docker.org/offical/alpine:latest that would be better, imo.

They are also available at docker.io/library/alpine and equivalent, and I'd advise anyone to start using this format as more distros might break the default registry[1].

[1]: https://man.archlinux.org/man/containers-registries.conf.5.e...

One should get in the habit of prefixing them with docker.io/library through, simply because docker's claim on being the default namespace is unacceptable (and also not true on RHEL-adjacent distros)