3 ms·

You can either monetize the thing that brings you business directly, adversarially impacting users. Or you can monetize something else that's correlated to tho

You can either monetize the thing that brings you business directly, adversarially impacting users. Or you can monetize something else that's correlated to those costs to subsidize the main use case and keep new user acquisition frictionless. Like NPM charging large businesses with special needs with NPM Enterprise, or GitHub with teams and CI/CD features and GitHub Enterprise, and so on. Docker sold off Docker Enterprise. Now they're trying to extract rents from people who are just trying to "docker build", a command whose ease of use is what drove people to use Docker in the first place. Foot, meet gun. Docker is breaking their main selling point. "docker build" and "docker run" should _just work_. By breaking that expectation in subtle ways they risk alienating users. By advertising that they're willing to break their main use case, they're going to alienate businesses and early adopter developers like myself. Now I'm looking for alternative registries and making sure that devops code I manage doesn't depend on Docker. That's surely not what they wanted, right?

michaelmrose 6y ago
Forgive my unfamiliarity. From the article >We’ve been getting questions from customers and the community regarding container image layers. We are not counting image layers as part of the pull rate limits. Because we are limiting on manifest requests, > For example, roughly 30% of all downloads on Hub come from only 1% of our anonymous users. The limits appear to be 100 pulls per 6 hour time frame per ip address for anon users and twice as much for authenticated users. The least favorable reading of this is to assume a rolling period so lets roll with that. Pun intended. According to docker whom I imagine is in a better position to evaluate the situation this will impact almost no users. Logically properly caching downloads seems like it would improve local performance. Do you really need, given the possibility to cache downloads, to pull a new image every 1.8 minutes in environments where paying $5 a month for individuals or $25 a month for a team would be prohibitive? I'm going to assume that orgs manage a variety of one off and recurring expenses. I don't see how this is any different. What I think is the most salient point is that docker is not a new endeavor. They already have many users. Acquiring new people who consume resources and pay nothing isn't a valuable proposition for them. Why would it be? Do you wish you had more roommates living with you eating your food and paying nothing towards the rent?
- AaronFriel 6y ago
  > Do you really need, given the possibility to cache downloads, to pull a new image every 1.8 minutes in environments where paying $5 a month for individuals or $25 a month for a team would be prohibitive? Given that even a "docker build" does a manifest pull, it's not just "new images", but existing ones as well. Now expand that to a team that say, builds 10 images in parallel using Docker Compose. Now it's a build every ~18 minutes will hit the limit. Larger builds, like say a CI system building every time there's a push to a branch? Yikes. I've expressed my thoughts in detail here about why I think they should find another avenue to monetize Docker: https://twitter.com/AaronFriel/status/1297988737981247488 https://twitter.com/AaronFriel/status/1297988737981247488

michaelmrose 6y ago

Forgive my unfamiliarity. From the article >We’ve been getting questions from customers and the community regarding container image layers. We are not counting image layers as part of the pull rate limits. Because we are limiting on manifest requests, > For example, roughly 30% of all downloads on Hub come from only 1% of our anonymous users. The limits appear to be 100 pulls per 6 hour time frame per ip address for anon users and twice as much for authenticated users. The least favorable reading of this is to assume a rolling period so lets roll with that. Pun intended. According to docker whom I imagine is in a better position to evaluate the situation this will impact almost no users. Logically properly caching downloads seems like it would improve local performance. Do you really need, given the possibility to cache downloads, to pull a new image every 1.8 minutes in environments where paying $5 a month for individuals or $25 a month for a team would be prohibitive? I'm going to assume that orgs manage a variety of one off and recurring expenses. I don't see how this is any different. What I think is the most salient point is that docker is not a new endeavor. They already have many users. Acquiring new people who consume resources and pay nothing isn't a valuable proposition for them. Why would it be? Do you wish you had more roommates living with you eating your food and paying nothing towards the rent?

AaronFriel 6y ago
> Do you really need, given the possibility to cache downloads, to pull a new image every 1.8 minutes in environments where paying $5 a month for individuals or $25 a month for a team would be prohibitive? Given that even a "docker build" does a manifest pull, it's not just "new images", but existing ones as well. Now expand that to a team that say, builds 10 images in parallel using Docker Compose. Now it's a build every ~18 minutes will hit the limit. Larger builds, like say a CI system building every time there's a push to a branch? Yikes. I've expressed my thoughts in detail here about why I think they should find another avenue to monetize Docker: https://twitter.com/AaronFriel/status/1297988737981247488 https://twitter.com/AaronFriel/status/1297988737981247488