Free team being sunset, no way to convert to a regular account
josegonzalez opened this issue · 93 comments
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
- This is NOT a security issue
- I do NOT have a Docker subscription
- I have looked through other issues and they do NOT apply to me
Yeah the email is very confusing as it suggests only access to private repos will be suspended while public repos are not, but everything will end up being deleted in May regardless if public or not. The "FAQ" also has the heading "Private Repos FAQ" so is not relevant at all for free teams that only use public repos.
Seems like there's a big assumption in that email that everyone using teams are companies with money and private stuff rather than a group of OSS developers.
The whole thing seems super rushed without much consideration and have just left people confused. The links in the FAQ aren't even clickable.
I want to second the fact that this email raises many more questions than it answers. I have a Free Team organization that's use to distribute public Docker images for an OSS project. If "all data will be deleted", does this include our public images?
It seems like no one knows what is happening: https://news.ycombinator.com/item?id=35154025
I maintain the OSS project for the mambaorg/micromamba image, which is currently using a free Team account.
My reading is that if you are accepted into Docker's open source program, then you get a free Team account (that I'm guessing isn't going to get purged). I just applied to this program and Docker says they try to process applications within 30 days. However, Docker indicates they currently they are receiving a high volume of applications. If my application isn't approved in 30 days, then it will be after the Teams purge date and my images will go away. These images are commonly used in CI pipelines and those pipeline are going to break if the images are removed from Dockerhub. I'd really like to see Docker commit to fully processing all applications to their open source program before purging teams.
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!
@yavorg thanks for the update. Can you clarify exactly what will happen if we don't upgrade to a paid plan and also don't make it into the DSOS program? Will all our public images truly be deleted?
The fact that the DSOS program excludes commercial OSS really stings considering that Docker itself is commercial OSS! Payment for me, not for thee; I guess I'm only allowed to make a living from "tips".
Considering that docker hijacks the top level for docker commands, this change will likely results in a lot of broken images and malicious images. For us, a small company that is not OSS, it's just not worth paying 300$/y just to publish a public image. We might have considered it a smaller price point or used the personal namespace but now we can't "downgrade" so this is just a shit move from Docker.
Hey @yavorg we applied years ago to the DSOS and never received and answer after the first follow-up. I am very concerned about https://hub.docker.com/u/trion where we publish Angular images with >10mio pulls in sum
Similar story here for the Rocky Linux images in the rockylinux namespace. We had applied for the OSS program years ago and heard nothing. We applied again a few months ago after prompting but have similarly not heard anything from that application, either.
Same thing with the OSU Open Source Lab and the Cinc project. I just applied for the OSS program for both but no idea if that will pan out or not based on the comments above.
It sad to see that we're going to loose our namespaces because of this. Converting the existing organisations to a free personal account would fit us best, but we'll just move our images to other container registries I guess.
Docker has a specific DSOS program for open-source projects, and it is not affected by the sunsetting of Free Team plans.
Might be worth adding this to the FAQ as I was unaware this existed, and I seem to not be alone in that.
The timeline of this, the lack of communication, the lack of a stepped migration path, all tell me that Docker is not an organization to be relied upon, and that I need to reduce my exposure to this company for my projects as fast as I possibly can.
I knew this would happen, but didn't prepare for it, my bad.
My main concern is squating. As a kubernetes admin for big orgs, if we don't get strong comitment from docker about this, I think I'll forbid the use of hub.docker.com it would be easier.
I recommend you to take this squating issue seriously if you don't want docker name to be associated with dramatic events. (In my opinion this squating thing can become a serious industrial catastrophe).
@pierreozoux It was mentioned before by @yavorg that squatting wont be possible.
Any organizations suspended or deleted will not release the namespace, so squatting previous namespaces will not be possible.
An additional plan for small developers would be greatly appreciated. Forcing us into a 5 user / $300 minimum spend for a few public images for our own users is excessive. Why can this not be a 1 user minimum at $5/month?
That would keep me, otherwise moving to GHCR
The @racket project submitted our application to the DSOS program in July of 2021 and we have never heard anything back.
The messaging around this is very confusing. At face value, this seems to indicate the free tier will fully disappear, but the FAQ and documentation only talks about private images. We're only using this to publish public images for OSS projects.
Please clarify what's going to happen to public-only images.
Never heard of the DSOS program before, I applied and got a positive answer in less than fifteen minutes so it may be worth a shot.
The lack of communication does not inspire confidence for the future though
Never heard of the DSOS program before, I applied and got a positive answer in less than fifteen minutes so it may be worth a shot.
It's worth mentioning that the DSOS program isn't really fitting many OSS usage cases. The form is not relevant for organization publishing more than one project for instance. It's also demanding information like "company" or "job title", as if the OSS organization is in fact a company employing people, which won't match many OSS organizations out here.
I haven't filed a DSOS request because I have no idea what to fill for most of the fields.
I haven't filed a DSOS request because I have no idea what to fill for most of the fields.
I tried, despite the mismatch you mentioned. However, Docker even fails to count to 30 correctly.
I wonder if it might be time for we the community just host its own registry without these restrictions and problems.
I submitted a DSOS application for rpki-client (portable) on July 7th, 2021, answered all questions (sent by the "Docker Marketing Team" via e-mail) – and never heard back from them after July 12th, 2021 (where a "Marketing Intern Docker, Inc." confirmed that they received my answers and would come back to me with a decision).
I also would like to remark that I'm using Docker Hub only to publish public images (but actually for multiple projects in different Docker Hub organisations), which have been built outside (using GitHub Actions). And this is mainly because Docker Hub itself didn't support enough architectures at the time when I evaluated this somewhen in 2020.
Being able to convert the organization accounts into personal single-user free accounts with the same name and images would be a reasonable solution for most of what I maintain, I think.
I'm also affected by this - like many other projects here, I'm only using Docker hub to publish public images within a org namespace (no private images, no builds, no other team members).
These images are widely used by others, referenced in all sorts of docs & CI builds, and embedded in software running all over the place, so implying that all these images will stop being accessible in 30 days is a massive problem.
I'm running a tiny open-source project but with some income (just enough to make development sustainable with one developer) which means it seems I'm not allowed into the open-source scheme either.
At least keeping existing public images available for more than 30 days would be a huge help for migration here (maybe that's already going to happen regardless, but the current messaging is very unclear on this).
Being able to convert my organization account into a personal single-user free account with the same name & images would be a reasonable solution imo (if these were the rules in the past, that's probably what I'd set up now).
Alternatively, allowing closed organizations to set up automated redirects to hosting elsewhere would help, so that references to all the existing images don't break. I could very easily host these images on GHCR for free, or run my own public hosting indefinitely for far less than $300, but doing that now doesn't solve my problem because the existing Docker hub URLs are widely used all over the place already.
Also similar to others, I have a couple of single-user orgs used only to publish public images from public, open source github projects, and would love to be able to just switch them to single-user free accounts. At this point my plan is to migrate new versions to be published on ghcr but I'd rather not lose the historical images.
It would be nice if there were some way to have a redirect from our old orgs/repos to their new locations, and similarly provide a helpful error message for CLI pulls, to aid downstream migrations.
Hey folks,
Our use of Dockerhub is to host a "test image" which doesn't do anything beyond store some files in a couple of layers. We haven't updated it in years and we mostly use the image to test the open source project.
According to DSOS, we can only make use of Dockerhub if the image is in "active development". We are planning to move it to GHCR but I'd like to ask here if there is some alternative place within Dockerhub we could move it to.
cc: @rnjudge
Not every open source project can be or will be onboarded to docker open source thing. Why don't you at least "downgrade" these account into personal account or even free public only "org" tier? I can't imagine what kind of horror it would create.
Speaking for the Zeek project, we also applied for DSOS a long time ago and never heard back. We're on the Free Team tier. We started dual-pushing to Docker Hub and AWS ECR a while back, out of concern over Docker Hub's long-term viability.
Docker has a specific DSOS program for open-source projects and it is not affected by the sunsetting of Free Team plans.
The program is extremely discouraging. Besides being a long and confusing form for its purpose, the prospect of any compensation (such as consulting) immediately rules you out. Most OSS projects take years to profit (if ever) and such a black and white criteria contradicts open source support.
We are listening to feedback and may offer additional programs in the future.
When in the future? After our accounts have been terminated and containers deleted? Please understand that part of the issue is vague communication, and this does not help us confused or discouraged by the current messaging.
Finally, I would speculate many of the OSS maintainers have Docker organizations because our communities asked us to. As soon as those images are removed, there will be a wave of users and companies with broken deployments, leaving the OSS teams and Docker to deal with the upcoming fall out.
One of my projects was rejected by this program late 2020. As part of the rejection, Docker staff told me by email:
Data egress is a large operational expense for Docker, which we can not continue absorbing. We are asking our users to share in some of this cost. We are making an exception for 'science experiment' open source projects, because we are committed to growing development communities.
Any Open Source which is created/funded by employees of a company would likely have this same result:
Since X is funded by a commercial entity, we can not include it into the Open Source program, and provide these images with the namespace whitelisting included with this program.
I haven't looked recently but at the time, the program included some "marketing" requirements which I think would make many feel uneasy.
We are faced with a similar situation as Testcontainers, which is a pure OSS project, but has AtomicJar as a commercial entity building products related to the OSS project.
One of our main components currently hosted at Docker Hub (ryuk) has 100M+ pulls. We were given the Sponsored OSS badge when Docker started to introduce pull rate limiting, but since I received this email as well, I expect us to loose this badge now. When applying for the new OSS program, we got a rejection similar to what @rarkins has shared.
While paying for a team plan would be totally fine for us, this would still leave Testcontainers users potentially facing the pull-rate limits, which might (especially on CI), lead to failing builds for our users. This means we are now faced with looking into alternative hosting solutions, that mitigates this situation.
I can understand Docker wanting to cover the egress costs, but I find the messaging and pricing around this very unclear.
We face the same problem as the FreeIPA project. We were offered to join DSOS program when it was announced in December 2020. However, that communication was a black hole: apart from the original automated response from applying to the program, no communication has happened until November 2022 when Docker proposed to re-apply as the application form was streamlined.
We are not using private repositories for builds and don't even use much of Docker hub ourselves. Our users do rely on those images, though. 5M pulls are probably not much compared to other projects but this is still a sizable amount of use.
We're facing the same issue with the LocalStack project. We were also offered to join the DSOS program in the past, and have submitted our application in the meantime (hoping for a timely review and approval 🤞).
We've also participated in some co-branding together with the Docker team (e.g., a recent blog post about our Docker Desktop Extension).
Losing access to Docker Hub for our open source community would be a huge bummer, 😕 and would certainly affect thousands of users in their day-to-day work using the LocalStack Community image. Any support would be highly appreciated! 🙌
Affected here too, it feels like a mob move to be honest...
But the main problem is that it will affect negatively the whole community as a bunch of images will just stop working which will lessen the value of dockerhub (and docker TBH) as a reliable way to distribute and execute software.
At the very very least you need to support redirects for repositories that get closed.
We relaunched the Docker-Sponsored Open Source program in September 2022 (blog post here). Since we made significant changes to the qualification criteria (we removed the limitation of not being able to have commercial funding for your project), we emailed all projects who applied the to Docker-Sponsored Open Source program prior to September to invite them to reapply with our new review process. If you did not receive that communication, there may have been gaps in email deliverability. I encourage everyone to apply to the Docker-Sponsored Open Source program using the updated application form and criteria.
Additionally, thank you for the feedback on the submission form. We are using your suggestions to inform how we can bring more clarity to the Docker-Sponsored Open Source program and ultimately serve the open-source community as best we can.
@Bkblodget As far as I can tell, the prohibition of commercial funding is still in place:
Not have a pathway to commercialization. Your organization must not seek to make a profit through services or by charging for higher tiers. Accepting donations to sustain your efforts is permissible.
Perhaps there's a distinction between "pathway to commercialization" and "commercial funding" that I'm missing?
We relaunched the Docker-Sponsored Open Source program in September 2022 (blog post here). Since we made significant changes to the qualification criteria (we removed the limitation of not being able to have commercial funding for your project), we emailed all projects who applied the to Docker-Sponsored Open Source program prior to September to invite them to reapply with our new review process. If you did not receive that communication, there may have been gaps in email deliverability. I encourage everyone to apply to the Docker-Sponsored Open Source program using the updated application form and criteria.
Additionally, thank you for the feedback on the submission form. We are using your suggestions to inform how we can bring more clarity to the Docker-Sponsored Open Source program and ultimately serve the open-source community as best we can.
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 think it's pretty clear people, if you are an OSS project use another alternative like Quay, ECR, GHCR or any of the many others. Docker has been lining itself up to be friendly to corporations only for quite sometime. You must pay to use Docker Desktop, you must pay to have a Org and you must pay to have reduced rate limits. Please stop feeding them if you are an OSS project, just let them wither out and die as the dinosaur they are committed to being. They haven't innovated in years and yet want to charge people for features that used to be free. This should be a warning for anyone thinking of ever using anything created by Docker.
@yavorg, thanks for the response so far. I want to touch upon what you wrote here:
Any organizations suspended or deleted will not release the namespace, so squatting previous namespaces will not be possible.
How long will namespaces not be released? 1 year? 3 years? Indefinitely? If a team deletes their own namespace within the next ~30-60 days, will those namespaces be protected in the future from squatting, also meaning that other legitimate organizations cannot re-use those namespaces in the future?
It's crucial that Docker Hub has plans in place to prevent bad actors from hijacking namespaces that have been "lost" due to teams not converting permanently. Failing to do so could have severe consequences for environment security, as it clearly creates a prime opportunity for bad actors to serve compromised containers to consumers. This could result in thousands of organizations falling victim to cyber-attacks, leading to data breaches, financial losses, damages to reputation.
Given the gravity of the situation, it's imperative that Docker Hub makes clear what actions will be taken to prevent such scenarios. As other folks have stated, the risk and threat vectors makes me believe that blocking hub.docker.com and docker.io is the right choice for my organization/team. The security of the entire ecosystem Docker has built is at risk, and any delay or inaction could have disastrous consequences.
How do I identify if an image, such as https://hub.docker.com/r/bitnami/kafka, is at risk of disappearing?
Edit: FWIW, I'm also looking for the answer over in the Docker forum
I don't see any comments from solo, indie, hobbyist developers who are also going to be affected by this.
I have a team with a single user (me) for organizational purposes. I don't use any of the team features. I'm simply using it as an organizational namespace in a manner similar to many of the other comments here. In fact, I haven't pushed any images to it. I use a self-hosted registry, but I want the option of using Docker Hub to publish public facing images using the namespace since I have the matching namespace everywhere else.
I can't (pragmatically) pay $300 per year for a 5 user team to keep my namespace, but this tweet makes me worried that if I don't pay there's a risk I'll lose it permanently.
when we remove accounts we do not free up the namespace so squatting is not possible.
That's better than having it squatted on, but it's still detrimental to me. I deleted an old team I don't use to test and the namespace did not become available (within 30m). I'd be very disappointed if the Docker Hub namespace that matches every other service I use ended up becoming unusable.
Please consider offering some more palatable alternatives for people with light usage (like me) who are primarily trying to maintain a consistent namespace across services. If every service I use starts asking for $300 per year for an organizational namespace the reality for me is that I'll lose control of the brand / identity I use for development.
Any organizations suspended or deleted will not release the namespace, so squatting previous namespaces will not be possible.
Not to be harsh: this just makes it sound like this move is nothing more than a push for $, to remove a previous useful feature used for organization for public users. I have a user account and I have an org account under my user because I push my images under my org, my hostname, not my username, i.e. it's [hostname]/imageName not [username]/imageName.
I do not understand the reason for this change. What's the logic behind it? All I can see is this will make Dockerhub less useful for those who are simple hobbyists that want to maintain images under our hostnames. As a developer, a db architect, I cannot understand why you would need to do this.
As the previous comment right above me: I have a single org with a single user - me. It's my hostname, and my hobby images. That's it. I have this on all my code sites: Github, Gitlab, Bitbucket, Dockerhub. So far, Dockerhub is now the only one that's going to .... well .... force me to leave since I won't pay a team price just for me.
This feels like a blatant attempt to push users into a subscription tier.
Another thing I don't think brought up is what if you are squatting on a name and Docker takes it away because you didn't pony-up and pay them. Now what if you want to start using it again? Will Docker be competent enough to release the name back to you?
What's the logic behind it? All I can see is this will make Dockerhub less useful for those who are simple hobbyists that want to maintain images under our hostnames.
That is the exact reason why they are doing this, Dockerhub is no longer friendly to small-mid FOSS projects. They have been trending this way for years. Unless you are a big organization (but really, even if you are), stay clear of anything Docker related including Mirantis.
@guice @onedr0p: The reason for this change is simple: Docker, as a company, has to make money. This means reducing costs (bye free teams tier) and generating income (now you gotta pay for it). If they don't make money, they can't maintain a free service for anyone at all. We must want Docker to succeed if we want to keep using their services for free.
From a different perspective, on top of improving a lot the open source sponsoring program, they could have planned and communicated this much better to avoid the current situation. My suggestions are to implement the following, among many other possibilities:
- Permanent org/image name squandering protection.
- Possibility of a "verified redirect" to another repo for those who won't stay.
- Downgrade of free team accounts into personal accounts.
@onedr0p Docker has underwritten the network and storage costs for many FOSS projects for many years. It is fair for them to want cover their costs. If you aren't following the changes to buildkit, it is understandable you don't see the innovation.
What most of us are upset about are:
- the unclear and inconsistent messaging
- having only 30 days to understand and sort things out
- the complete lack of a middle ground, $300 is a lot of money for what most projects would get in return
There are certainly FOSS projects out there taking advantage of the free tier and costing Docker big money. There are far more hobbyist and small projects caught in the blast radius. The OSS option from Docker is also unclear and makes it seem that most early stage projects will not qualify.
Docker: Please be clear in your communications and clarify what is happening with the miscommunication that caused this issue to be risen. Comments here and on twitter are not sufficient to reach most people impacted by this. SEND ANOTHER EMAIL
For anyone planning on migrating away from Docker Hub and deleting/abandoning their free-tier teams, I've (quickly) put together a script to help anyone shuffle containers from docker.io to a new target registry in bulk. Tested it in a couple of my environments, worked fine so far.
crane copy is probably better for most people: https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane_copy.md
goharbor.io mirroring is better for more complicated or bulk requirements: https://goharbor.io/docs/2.1.0/administration/configuring-replication/create-replication-endpoints/
edit: This page helped me work through multi-arch image migration
crane copyis probably better for most people: https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane_copy.mdgoharbor.io mirroring is better for more complicated or bulk requirements: https://goharbor.io/docs/2.1.0/administration/configuring-replication/create-replication-endpoints/
@verdverm Almost definitely. Had some weird performance issues with Crane before, and skopeo seems to work just fine, but I don't disagree 🙂
From what I gather from this is as follows, there is no downgrade path from free team to personal account, ultimately with single person teams, there isn't any real difference between a personal account and a team that only uses public images. The main difference is being able to manage multiple namespaces under 1 account (which can be achieved currently with multiple personal accounts). So essentially what Docker is doing is holding users with Free Teams hostage, until they pay up. If that was not the case, then you wouldn't also offer free personal accounts, right? Or offer a downgrade path
@yavorg, I appreciate the opportunity to address the recent announcement regarding the discontinuation of free company teams on Docker. While I understand that businesses need to adapt and evolve, I am concerned about the potential impact this decision may have on the open source community and the trust placed in Docker.
To clarify, I am not opposed to change or the introduction of reasonable limitations and pricing. However, I believe that abruptly discontinuing free namespaces for company teams may adversely affect smaller open source projects that have relied on these services.
The open source community thrives on trust and collaboration. Trust is essential, and once it's compromised, it can be challenging to regain. There have been instances where companies altered their terms or pricing structures, which led to a decline in trust and, ultimately, a loss of users.
To foster a closer relationship with open source projects, I would like to propose some alternative solutions:
- Introduce reasonable limitations on free accounts, such as restricting the number of private repositories or the amount of storage used.
- Offer tiered pricing with affordable plans specifically tailored for small open source projects or startups that are not yet generating significant revenue.
- Implement a grace period to allow users time to adjust and make informed decisions about their continued use of Docker services.
In conclusion, I understand that Docker must make decisions for its growth and sustainability, but I hope you will consider the implications for the open source community. By working together, we can find a solution that benefits everyone and maintains the trust that has been built over the years.
Thank you for your attention to this matter, and I look forward to seeing how Docker continues to support and engage with the open source community.
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?
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.
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.
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.
This will mass break dependencies. Really really bad. Please don't play Oracle and ruin everyone's 2023.
oh wow, just started using docker, i guess ill search for an alternative now
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
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?
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?
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
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.
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.
This new blog post says
- 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")
- 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?
@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?
@verdverm in both cases the images will remain available, so serve == distribute in this context
@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.
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.
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.
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.
"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.
[...] 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?!
@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.
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 Project-OSRM/osrm-backend#6325 (comment)
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.
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?
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?
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.
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.
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:
- Set up Docker’s package repository
- 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...
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 ?
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 - 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:
- Submit a support request on Hub (log in first) to convert the free org to a free user.
- 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.
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.
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 ?
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.
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. […]
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.
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.
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.
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.
It takes guts to not only correct a "mistake" but also admit that it was one. Deeply appreciated!
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!