Free team being sunset, no way to convert to a regular account

[josegonzalez]

Problem description

I got an email saying that I'll need to convert from a free team to something paid. I use Docker hub solely for images related to the Dokku organization. I don't see a way to convert the namespaces - dokku and gliderlabs - to regular accounts. Both use public repositories exclusively, and are only used for supporting the OSS organizations.

Ideally we can convert them to regular accounts that I can log into, as I don't see anything either org benefits from. A second useful change might be to allow OSS orgs to continue to access docker hub teams for free, but I'm sure thats not where docker hub wants to go, pricing wise.

EDIT: I looked at the Docker Sponsored Open Source program and applied. It seems there is going to be a long wait (I applied this morning, and got that message then too). It's not super clear why I'm being asked for work-related information for an OSS project (Dokku is in no way related to my day job). What will happen if I'm not verified in time for the deadline in question, especially if I haven't even been notified I'm in review?

Debug Information

Browser name and version:

All

URL:

N/A

Timetamp or time range:

N/A

Public IP:

N/A

Hub Username:

dokku and gliderlabs

Error messages (on screen or in browser console)

N/A

Screenshots of the issue (if applicable)

N/A

Task List

• [x] This is NOT a security issue
• [x] I do NOT have a Docker subscription
• [x] I have looked through other issues and they do NOT apply to me

[supaspoida]

This is speculation but I would think that the cost of hosting images in the registry is dwarfed by the cost of egress. I would also guess that egress generated by for-profit usage vastly outstrips the egress generated by the people using the registry to publish images.

Seems to me like the obvious thing would be to ask for money from the people actually consuming the expensive resources and not the ones who have been adding value to the ecosystem on their own dime. Or am I missing something with the cost dynamics here? Are most for-profits mirroring their images these days?

[bagder]

The @curl project provides images that have been pulled 5 billion times in just a few more days. It is right now being pulled at a rate of over 2 million pulls /day. It is labelled sponsored oss on the docker site, but we still got the you will be erased emails.

Removing curl as a team does not really hurt the curl project. It hurts users in the docker ecosystem who (naively?) decided to rely on docker for infrastructure. We don't provide this image for our own sake.

This is docker breaking the setup for what is probably more than a handful of docker users out there.

[LefterisJP]

Hi folks, than you for your feedback!

Docker has a specific DSOS program for open-source projects, and it is not affected by the sunsetting of Free Team plans. We are listening to feedback and may offer additional programs in the future.

We will defer any organization suspension or deletion while DSOS application is under review, and give organizations at least 30 days before we suspend the organization if the application is ultimately rejected.

Any organizations suspended or deleted will not release the namespace, so squatting previous namespaces will not be possible.

Thank you and please keep the open feedback coming!

Hey @yavorg thanks for chiming in.

I come in here representing rotki: https://github.com/rotki/rotki And opensource tool for which we provide docker images through dockerhub.

Just like everyone else chimed in here, this is too sudden a change and asking for so much money just to publish an image is impossible for most small opensource projects like ours. Please reconsider.

[guice]

@douglascamata

The reason for this change is simple: Docker, as a company, has to make money. This means reducing costs (bye free teams tier

I entirely get what you're saying about needing to make money. My point is [for many] free teams tier is just an organizational setup and doesn't cost Docker any more money to host than it does for a normal free user account. Meaning: if I [had some way to] convert my org. [hostname] to user [hostname], it wouldn't cost any different. But, now I'll have multiple user accounts/logins to contend with.

Free Teams did have limitations enticing people to upgrade to their paid teams package. They could adjust these. However, I'm very much despise companies that remove free functionality just to put them into a subscription tier. I thought Docker (the company) was mature enough they didn't have to do a bait-n-switch on their long-long-time user base.

[144mb]

This will mass break dependencies. Really really bad. Please don't play Oracle and ruin everyone's 2023.

[Mecki-Messer]

oh wow, just started using docker, i guess ill search for an alternative now

[BretFisher]

A blog post and updated FAQ: https://www.docker.com/blog/we-apologize-we-did-a-terrible-job-announcing-the-end-of-docker-free-teams/ An attempt to put it all in a twitter thread: https://twitter.com/BretFisher/status/1636407810610151433

[nwalters512]

Will open source images I rely on get deleted?

Not by Docker. Public images will only disappear if the maintainer of the image decides to proactively delete it from Docker Hub. If the maintainer takes no action, we will continue to distribute their public images.

I think this needs some clarification. My interpretation is that suspended/deactivated accounts (accounts that don't pay) will still have their existing images available to pull, but that we won't be able to push new images/tags or otherwise mutate data in our organizations. Docker staff, is that correct?

[MrNaif2018]

Hi! Are there any differences between personal account and organization account if we just need to push our images (one account, pushed by our CI, no other features used other than storage basically) I wonder what is better: sponsored OSS program or converting to personal account, because my project is opensource but I want to use SaaS model in the future to accelerate it's development?

[DaspawnW]

Will open source images I rely on get deleted?

Not by Docker. Public images will only disappear if the maintainer of the image decides to proactively delete it from Docker Hub. If the maintainer takes no action, we will continue to distribute their public images.

and with this we are back to the same level of clarity as before the text, thanks for nothing

[yavorg]

An update from Docker https://www.docker.com/blog/we-apologize-we-did-a-terrible-job-announcing-the-end-of-docker-free-teams.

Thank you all for your candid feedback here.

[xsolid]

Will open source images I rely on get deleted? Not by Docker. Public images will only disappear if the maintainer of the image decides to proactively delete it from Docker Hub. If the maintainer takes no action, we will continue to distribute their public images.

I think this needs some clarification. My interpretation is that suspended/deactivated accounts (accounts that don't pay) will still have their existing images available to pull, but that we won't be able to push new images/tags or otherwise mutate data in our organizations. Docker staff, is that correct?

That's correct.

[bagder]

This new blog post says

1. this doesn't affect "sponsored open source" projects (which I read then means that @curl is not affected since it is tagged as "sponsored oss")
2. then says affected users are listed as "Docker Free Team" - which is how I am listed.

So, both not affected and affected. Clear as mud. Or does it mean that the project survives but no users in the org that maintains the images? Or does it mean that one of those conditions trumps the other? If so, which one wins?

[verdverm]

@yavorg The parentheses statement here injects ambiguity into the previous statement

Will open source images I rely on get deleted?

Not by Docker. Public images will only disappear if the maintainer of the image decides to proactively delete it from Docker Hub. If the maintainer takes no action, we will continue to distribute their public images. (Of course, if the maintainer migrates to the Docker-Sponsored Open Source program or to a paid Docker subscription, we will also continue to serve their public images.)

---

How do distribute and serve differ here? If an org does not sign up, will you stop serving their public images?

[yavorg]

@verdverm in both cases the images will remain available, so serve == distribute in this context

[everflux]

@yavorg could you also clarify how you are going to act on the forgotten open source program applications? Up until now I always assumed that it was just me, but as is clearly visible here there a multiple affected users/organizations.

[BretFisher]

could you also clarify how you are going to act on the forgotten open source program applications?

@everflux Docker management told us everyone should reapply, the program policies have been broadened and they are adding people to the review process to catch up. Once you reapply, the org in question will avoid the 30-day clock until they've processed the application and communicated the decision.

[robert-scheck]

I applied again for the Rocky Linux project yesterday and did not receive even a confirmation email that my application was received.

Is there some way to know for sure if our application went through?

Others I spoke with received a new ticket confirmation email, along with acceptance within 15 minutes. As near as I can tell, I am not missing any emails nor have issues with deliverability.

I'm experiencing exactly the same issue here for 4 projects.

[michaelherger]

An update from Docker docker.com/blog/we-apologize-we-did-a-terrible-job-announcing-the-end-of-docker-free-teams.

What I'm still missing is a clear statement like "If you're a small team of one or two devs, providing a public image or two: nothing will change". Or "You'll still be able to pull all public images. But you will no longer be able to push new ones".

I'm missing a clear statement as to what the "paid features" which will no longer be available are.

Basically a before and after comparison if I decide not to pay the 300USD/y.

[guice]

"You'll still be able to pull all public images. But you will no longer be able to push new ones".

@michaelherger This one ^. The org itself will be suspected / locked. You can still pull the images, but you won't be able to push new ones. If you wish to maintain the org name, you have one of two options: upgrade to paid teams or contact support to have the org name converted to a personal account.

[jamgregory]

[...] the org in question will avoid the 30-day clock until they've processed the application and communicated the decision.

@BretFisher - I'm confused what this "30 day clock" now refers to. The blog post explicitly says...

We’d also like to clarify that public images will only be removed from Docker Hub if their maintainer decides to delete them.

That contradicts what the original email says (that there's been no follow up to - I only know about it from following this issue)

If you don’t upgrade to a paid subscription, Docker will retain your organization data for 30 days, after which it will be subject to deletion.

So what are you actually losing after 30 days? The ability to push to images in that organisation? Presumably to manage it in some fashion? Or is everything going?

Presumably if we lose the ability to manage the organisation but you keep the public images... how do we delete them in future?!

[j616]

@yavorg Thank you for your update. But I'm still concerned about the implications of this change. Docker Hub is the default registry in the docker tooling. This change will result in a proportion of images on that registry no longer receiving updates through no fault of the developers.

How will Docker communicate to users that the images they are using will no longer receive updates via Docker Hub? Or will the responsibility fall to developers who choose not to/can't afford to switch to the paid plan to delete their images from Docker Hub to avoid users un-knowingly using images that aren't receiving feature/security updates?

I hope you can understand that while the communication of this change wasn't great, this is not the primary concern of the community. And this updated FAQ has not fixed the majority of the communities concerns. Teams will still be deactivated. Images will still go without updates. Images that use affected images as a base will also be affected, potentially in a hard to see manner. Some teams are now being forced into extra monetary burden. Anyone who uses Docker Hub will now have to put effort to analysing and mitigating the effects of this on their code/workflows. Some will have to communicate their plans as to weather they will stay with docker hub or move. And the community still has less than 30 days notice to work around all of this.

[n1ngu]

As part of a small company, our private applications have always been published to our private registry. But so as to give back as much as possible to the Docker community I vouched to release most of our tooling in the open.

Now that decision is causing my organization additional cost for no revenue. We understood Docker Hub was the right place for OSS images. How confused was I?

As we are already paying a registry I'd rather move public images there as well, but a redirection mechanism should be a must after your ransom notice. Without this, confusion will only spread https://github.com/Project-OSRM/osrm-backend/issues/6325#issuecomment-1224931339

[pimterry]

a redirection mechanism should be a must

For others interested in registry redirection, I've done some digging into docker pull, and written up a guide for making images accessible via your own hostname, without having to self-host your own registry: https://httptoolkit.com/blog/docker-image-registry-facade/.

It doesn't let you redirect existing names on Docker Hub, but if you set this up yourself now (fairly easy, and deployable entirely for free on many services) then you can make docker pull your-org.example.com/org/image work as an address for your existing images on Docker Hub, start telling everybody to use that URL today, and then migrate your images across to different registries in future without the address changing. Lets you change address now and migrate the images themselves independently, and removes any risk of subsequent address changes later on if you need to migrate again.

[yavorg]

@bagder I suspect your account may be part of multiple organizations, and one of them is on the "Free Team". Other organizations on your account are unaffected. Please try the steps under "How can I see if I’m affected?" here.

[NeilHanlon]

I applied again for the Rocky Linux project yesterday and did not receive even a confirmation email that my application was received. Is there some way to know for sure if our application went through? Others I spoke with received a new ticket confirmation email, along with acceptance within 15 minutes. As near as I can tell, I am not missing any emails nor have issues with deliverability.

I'm experiencing exactly the same issue here for 4 projects.

I received a confirmation email yesterday as well as an acceptance one this morning.. It does appear they come, just with delay?

[DaspawnW]

Based on some analysis we have identified the following 4 types of users / organizations and use this right now for action items on a migration strategy:

• Verified Publisher ✅
• Sponsored OSS ✅
• Community User ✅
• Community Organization ❌

For the first 3 it seems quiet easy to identify if a user / organization is affected while for the "Community Organization" it's quiet hard. One example is getsentry, this is a Community Organization but the authors of it commented in a GitHub Issue that the Org is a Docker Team so should not be affected.

I as a user am pretty much left out in the cold by Docker right now and I have the feeling that security vulnerabilities that may appear after the deadline especially with public repositories are just taken for granted. Let's say I have a repository like bitnami/nginx with version 1.23 (let's assume bitnami/nginx is not Verified Publisher) then according to their strategy so far I would expect to always get the latest patch level on a docker pull of 1.23. But if the repository is now frozen I can't be aware of that anymore. The issue of security is completely left out of the equation and thus the trust in Docker is completely gone. Especially with the question of what happens in a year? Will there be another announcement out of nowhere and again only 30 days and all OSS projects are dead?

[guice]

NGL here, it doesn't appear Docker (org) had really thought through the impact of this change. They say it's only "2%" of users - if it's only 2%, of their environment, then why even bother with it? It's very clear from this thread that this "only 2%" is hosting some extremely large clients who hadn't been converted to official DSOSS repos.

I got word back about the namespace conversion to personal: I'm going to be forced to maintain an separate email if I want to hold my username account and my hostname namespace.

[mutech]

For me, this is the tipping point to go away from Docker. The way how Docker manages firewalls on Linux which effectively sabotages other products was already a close call. I assume this effect was not intended, but if it is achieved through persistent negligence, that's not much better. There are many other things that bother me about Dockers behavior.

All of these items show a mind set that I personally perceive as corrosive if not malicious.

I read in a blog post that Dockers CTO commented on the effects of policy changes with the phrase "sucks to be you". I don't perceive that as a thoughtless comment that might have to be read in context, this seems to be a mind set that I see more and more often in recent times. It goes along with a spiteful view of freeloaders on the net. This might be a wild accusation on my part, but hear me out, I think I have a point here.

Docker - the software - is in reality not much more than a shell around features that the Linux kernel provides. The substantial work is done by the kernel, Docker mostly orchestrates these features. That is a valuable contribution, especially considering the impact Docker had on the industry. But it's basically the nice card board box around the actual product, the iPhone.

Docker not only requires Linux to implement its core features, it also requires it to run its content, the images. The very images that will soon be unavailable and users who relied on their availability will coerce OSS projects to save them the effort to migrate to a new repository - indirectly. As I see it, it's not real OSS projects who are the freeloaders, it's Docker getting a free ride here. The Linux kernel never harassed me with an annoying button begging for money much like street kids do where i live.

When we as users get to enjoy free services, the provider usually gets more than just a fair compensation. I have the impression that we should get paid for most of the services that are offered to us for free. My kids were surprised to learn that when they put their money on a bank account for safe-keeping, that the bank pays them for it. I could explain to them that their money is not actually safe and that banks don't actually keep their money, but I will wait until they get a bit older. But this is a very similar situation.

Guys, your users are not freeloaders. You exist because other people do the hard work allowing you to easily make an awesome product with a couple of lines of code. You exist because you did the right thing at the right time and were lucky enough that people realized that. So many projects do what you did and much better and failed silently. People care for your repository because you were the first to have one and your software defines the default setting for the image repository. Not because this repository is a valuable or irreplaceable service. Podman is right there. So is Github or Gitlab. We need you less than you need friendly open source projects. Someone might tell you "sucks to be you" soon enough.

There are many ways to capitalize on previous achievements. Treating your customers like milking cows and your benefactors (the fellow open source projects on which the whole industry relies) like freeloaders is probably the best way to self-destruct.

[mutech]

We apologize. We did a terrible job...

I just read that now and I cannot agree more. But I should have stopped right there if I wanted to stay with Docker, because what followed just makes it worse.

[..] Free Team [..] was deprecated [..] in particular (because) it didn't serve the open source audience as well as [..] Docker-Sponsored Open Source program

Docker is insulting our intelligence here. We know that the program was deprecated to coerce non-paying users to pay up. That in itself is perfectly okay. Your business, your service, your pricing. But doing it in a way that makes it incredibly hard to chose an alternative is not quite as okay. Pretending that this is about "serving the open source audience" is deceptive and also a plain lie.

This is especially obvious if people trying to join the very program that is here declared as superior service apparently does not even exist. Users keep trying to register and never get a reaction. If serving the audience is why you are disrupting your user bases confidence, then you should plan ahead before you make announcements and ensure that your back office can handle the load of registrations. You are the company that defined much of what IT infrastructure became in the last decade and you not only ask for 30 days time to process a registration, you also fail to process them for years (see comments above).

We'd also like to clarify that public images will only be removed from Docker Hub if their maintainer decides to delete them.

That's great! Are you also informing all users who are relying on these images being updated that they will no longer receive updates? That is a clarification that actually is valuable, because it would prevent people from making false assumptions.

The open source community is not alarmed because of how you communicated, but because of what you communicated and how you implemented the transition.

Do these three letter jobs include a CCO? Chief Communications Officer? There is some room for improvements.

For example. The installation instructions for Docker Desktop for Linux read:

1. Set up Docker’s package repository
2. Download latest DEB package

Yes, that's right. Docker has an APT repository that Docker Desktop requires to install dependencies. But Docker Desktop is not in this repository. Why? Why should anybody need to separately download that package? There will be a reason, but it can only be a very bad reason for which the documentation does not apologize, but it says:

Note

At the end of the installation process, apt displays an error due to installing a downloaded package. You can ignore > this error message.

Instead of doing the obvious and right thing - put that .deb file in the repo, some engineer and a guy writing the documentation decided it's better to warn the user that they will receive an error message from their operating system. And then they tell this user that they can ignore this error message. Because they guys providing the OS are stupid and the user should trust Docker to know better.

The error message is:

N: Download is performed unsandboxed as root, as file '/home/user/Downloads/docker-desktop.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

I would never want users of my software see such an error message. I would never ever tell my users to ignore an error message including terms such as "root", "unsandboxed", "permission denied". I would tell them be careful when they see that stuff. I would tell them to make sure they understand what they are doing.

I would not even try to explain or apologize for such a catastrophic communication.

When you run Docker on Linux and at the same time use LXC or other software that depends on firewall settings, you will see that Docker works fine and everything else stops working.

The fix proposed by Docker is this:

It is possible to set the iptables key to false in the Docker engine’s configuration file at /etc/docker/daemon.json, but > this option is not appropriate for most users. It is not possible to completely prevent Docker from creating iptables rules, and creating them after-the-fact is extremely involved and beyond the scope of these instructions. Setting iptables to false will more than likely break container networking for the Docker engine.

"Not apropriate for most users" - That sounds a lot like you think most of your users are not qualified to engage in "extremely involved" stuff like iptables rules. I take that as an insult.

"It is not possible to completely prevent Docker from" - Is it now? What is the purpose of that option then?

"beyond the scope of these instructions" - What is the scope of these instructions if not exactly that? The title is "Docker and iptables". This is all the information we get about the way you fuddle with our firewalls. And this is in the section "Advanced Concepts", meaning that the majority of your under-qualified users is already the subset of all your users who are advanced. We are in the ivory league here.

You are messing around with my firewall. That's what I use to keep MY systems safe. This is not YOUR firewall. YOU provide a secondary technology that I am not going to use because I cannot trust you. You obviously do not understand the concept of roles and responsibilities.

Whoa. I should not have read this apology. That really did me in. But it feels good to vent. Okay, podman...

[xquery]

To add to @bagder comments about curl images.

We appreciate docker hosting of the official curl images and to date it seemed that their efforts had the best interests of the community at heart and together with lots of other open source images added enormous value to docker's offering ... it might be that those previous good efforts were the result of individuals working for the company that have since moved on and now a 'new broom' has come in to see what can be commoditised ... unfortunately damage has been done and words said cannot be easily 'unsaid'.

I am glad that hosting of curl images will continue but still confused if we have to 'do something' on our end - overall I do not get a warm and fuzzy feeling that this kind of thing will not happen in the future. Perhaps it is too much to expect those kind of guarantees in life.

Perhaps docker would consider a larger vision ... and help the community/industry build a planet wide distributed, decentralised registry ... which frankly is exactly what all of us are thinking about right now..

Barring that they can always consider donating directly to the curl project at https://opencollective.com/curl ... which would materially improve our little part of the open source community.

It amazes us how many of the largest companies in the world directly and indirectly depend on open source projects for their critical path but give precious little back to improve the public good ... which btw is what most of your community really wants to do - rather then maximise your shareholders profit - which often are two opposing forces ... maybe it might help in thinking that the open source community is one of your biggest shareholders ?

[boldandbusted]

Honestly, in light of all this, I hope that the CNCF or the Linux Foundation curate a non-corporate, community-blessed container registry that is solely for F/OSS projects.

[BretFisher]

@jamgregory

@BretFisher - I'm confused what this "30 day clock" now refers to. The blog post explicitly says...

So what are you actually losing after 30 days? The ability to push to images in that organisation?

Yes. If you do nothing with the org on the free plan, on April 15th you'd loose access to private images and the ability to push any new images. Public images will still be pullable.

Presumably if we lose the ability to manage the organisation but you keep the public images... how do we delete them in future?!

I don't know what this experience will look like on April 15th. Let's hope we see a new post or FAQ update on that. In the worst case, though, users/consumers of a pre-15th image can still get it and build from it.

---

Just a friendly reminder, you still have options beyond a paid upgrade:

1. Submit a support request on Hub (log in first) to convert the free org to a free user.
2. Submit a request to the Docker-Sponsored Open Source, which I know they have/are ramping up staffing on and have already reviewed and responded to a majority of the requests received in the last three days.

Another friendly reminder, if you ever submitted a DSOS request before Wednesday, they are encouraging us to re-apply. I've never done it, but I too have multiple free organizations that I'm considering it for.

[BretFisher]

Based on multiple conversations we had with Docker management, CEO, and staff, I made a 14-minute podcast on the facts and timeline as I see them. Any corrections in the coming days/weeks will get added to the show notes or a full re-edit of the audio to keep it current.

If you saw my live show on Thursday, this podcast includes multiple corrections to things I said on that show, including learning hours later that free org public images will still be pullable after April 14th.

https://podcast.bretfisher.com/episodes/docker-hub-oops

[xquery]

Still unclear - images are still pullable but what good is that if they just atrophy and collect CVEs for unsuspecting users to pull months, or years later ?

[mutech]

Analysis of the motivations behind this move

This is such a catastrophic situation, for Docker, the images providers affected by the policy change as well as users of Docker images, both paying and non-paying, that I cannot let it go.

So Docker provided a free service to us and that service is apparently expensive. Expensive enough, that Docker does not want or cannot to sustain it. It's expensive because images are high volume downloads.

Users don't see Docker Hub as a distinct service. A user wants to run an image, Docker is the most prominent technology, so they install Docker, search for an image that does the job and then they run the image. There is a concept of "the best image". That means something different for each user, but there are some qualities everybody appreciates. The "official" image is the one that carries an air of competency. You can expect to get the most recent updates. Professionals creating official images will also think of upgrade paths, because that's a problem each software vendor has to tackle routinely.

In the absence of an official image or where such images don't meet the particular requirements of a user, they search for alternatives. Most users will search for keywords and then sort by number of downloads, user ratings or other most often community defined attributes.

This is what Docker Hub does for users, besides providing the network bandwidth for downloads. What is it to Docker?

To Docker, Hub is the last mile. It's what decided the browser wars for Microsoft. They had the opportunity to provide users with a default choice. You chose Internet Explorer unless you explicitly installed another browser. Their operating system, their default settings. Chrome uses Google search as default search engine. The last mile provides quite some value if choice is relevant. It's always nice to provide a default.

Docker is under pressure from two sides. It started out as the only or the most popular containerization solution. Then came kubernetes, cutting services out of the cake, leaving application containers. Kubernetes started out as pure cloud technology, leaving on premise and devtop to Docker where it still shines. Then comes LXD cutting a small piece of dockers cake, containers as cheap (in terms of resources) virtual machines and Podman as direct competitor, taking over production app containers because of a better migration path to kubernetes and rootless containers as a tech to fix security problems with Docker.

Docker is still at the top. It's still the most popular container technology and it is overall awesome technology. But competition makes it increasingly a niche product. It's not getting better or easier for Docker. Docker already changed from the container thing to the developer tool and the software demo platform.

Here is the thing. The sustainable thing to do is to innovate if you want to win competitions. The alternative is to use leverage while you are on top and try to suffocate competition. Microsoft succeeded with the latter strategy, but they ultimately still lost the browser war, despite the total dominance that Microsoft still has on the Desktop. MS failed to innovate on the mobile train though and together with complete negligence in the innovation department they had to come up with a complete redesign of MS. This platform is part of it. SCO tried to use leverage when they lost the PC UNIX market. They bet on licensing as leverage. Most of you guys are too young to remember that. An epic failure.

This answers the question why Docker is not transforming Docker Hub into a registry, leaving the hosting of images to image authors. That would be cheap, it would preserve all functions that current Docker Hub has. But it would be giving up on the last mile. Hub would only be the default in Docker engines, not (necessarily) for all the other competitors who could easily provide their own registry, if image providers already take charge of the expensive hosting task.

So what Docker really does here is to charge image providers to finance their status as last mile provider or leverage to have some unique quality that their product can no longer provide.

Not only that, the motivation for providers to pay is their reputation, their users. If they don't pay up, their users will suffer the consequences, because they will otherwise no longer receive updated images at best. Their users would have to change their registry settings, many of which won't even know what that is and how to do it. They are just as likely to choose an "official" or "better" image before they edit some daemon.json file that Docker marks at something like use at your own risk.

This of course also effects paying users, because they are just as likely to use images from OSS projects. So paying up to Docker does not really mean that Docker is respecting your interests.

What I perceive as incredibly short sighted if not stupid, is that whenever a company decides that using leverage is better or easier than to innovate, they forget that leverage always works both ways. The lever pushes harder on the other end, but the smaller force requires a longer way and that usually means that innovation will become that much more difficult. A long way to get where others already are. And that does not even account for the devastating damage to the reputation of the brand.

I loved SCO Unix at a time when Linux did not yet exist. It was a way to have a real UNIX on my PC. It was ridiculously expensive, but it was worth it. Until Linux and the BSD's came out. It was tough on SCO, but that's business. They had a long period where they were on the top, where they could have innovated and instead rather felt omnipotent and so much better than the rest of the bunch. This feels so very similar to what we see here.

[robert-scheck]

I'm experiencing exactly the same issue here for 4 projects.

I received a confirmation email yesterday as well as an acceptance one this morning.. It does appear they come, just with delay?

Yes, it looks like there is some delay for the initial (automated?) response. Meanwhile I received responses like this:

Thank you for applying to the Docker-Sponsored Open Source program! We appreciate the time you took to fill out the application, and it’s now being reviewed.

You’ll receive an update within 30 days. […]

[schmunk42]

What's the worst from a user point-of-view is that you can't really see if the image you're using might be affected.

You need to go to DockerHub and look up if the namespace is from a Personal Account or Community Organization. And even if you do that, a Community Organization could still be "in application"-state.

Not to mention, that even Sponsored OSS might be revoked at anytime, if the management makes that decision.

[mutech]

What's the worst from a user point-of-view is that you can't really see if the image you're using might be affected.

I think the only end users who are immediately impacted are those who use docker to deploy productive services and rely on image updates. They will have to evaluate if the images they are using are affected or alternatively if other registries provide the same or similar images and just migrate there which probably provides a more reliable long term solution. They will probably migrate to Podman in the long run anyway, because that also provides easier migration paths to Kubernetes and become less reliable on Dockerhub through that path.

Depending on how OSS projects react to this policy change, Quai, Github or other alternatives might just take over the role that Dockerhub has now. If that happens, other user categories will increasingly find outdated images on Hub and also migrate away from Hub or Docker or both.

I think the sustainable solution is not to replace Dockerhub with another vendor service but to move to purely community run solutions that are less prone to such blackmailing campaigns. That will of course require some financing. If the big vendors don't contribute that, we are going to have to pay for some services, which I find perfectly acceptable if we know what we actually pay for. It's probably better to spend money on smaller to mid sized storage providers than to concentrate the whole business on 1-3 global companies who control everything.

The core of the problem really is that whenever a commercial entity gains a unique selling point in cooperation with open source projects, the temptation to capitalize on that by milking OSS projects or users is just to great. The concept of minimal trust does not only work well in security. We are going to have to give up on trust-based cooperation.

[ckadner]

This just came into my email inbox — From Docker:

On March 14, 2023, we emailed you about your Free Team subscription, outlining our intention to sunset that plan. After listening to the concerns of the community, we’ve decided to reverse course, and are no longer sunsetting the Free Team plan. If you’re currently on the Free Team plan, you no longer have to migrate to another plan by April 14. All customers who upgraded to a paid subscription will automatically receive a full refund for the transaction in the next 30 days, allowing them to use their new paid subscription for free for the duration of the term they purchased. We apologize for the alarm our decision caused. For more details, please visit our FAQ.

[yavorg]

As announced, Docker is no longer sunsetting the Free Team plan. We value your passion and engagement, and thank you for all the feedback that made this decision possible. We are closing this issue, but please open a new one or contact support if you have further feedback.

[mutech]

It takes guts to not only correct a "mistake" but also admit that it was one. Deeply appreciated!

[guice]

Now, Docker should just bring back Docker Free Teams. According to your post, these are the main differences:

The main advantages of (paid) Docker Team vs. Docker Free Team are:

• Unlimited number of teams (vs. 1 team in Free Team)
• Up to 100 seats total (vs. 3 seats max in Free Team)
• Unlimited private repositories (vs. no private repositories included in Free Team)
• 5,000 pulls/day/user (vs. 200 pulls/6 hours/user in Free Team)
• The Free Team plan does not include a license for commercial use of Docker Desktop at a company of more than 250 employees OR more than $10 million in annual revenue.

Honestly, Free Teams sounds like a perfect steppingstone to upsell paid Teams. Why was the free tier removed, anyway? It sounds like Free Teams is just a User account with an org name and 2 additional contributes.

The Free Team plan does not include a license for commercial use of Docker Desktop at a company of more than 250 employees OR more than $10 million in annual revenue.

Since Docker Desktop is free for these orgs (under 250), why isn't Teams as well? I complete understand how paid Teams would include paid Docker Docker license -- upsell!