3 ms·

Do you think NPM, Ruby Gems, or others would last long if they were so user hostile? Would Node have grown into the genuinely useful development environment it

Do you think NPM, Ruby Gems, or others would last long if they were so user hostile? Would Node have grown into the genuinely useful development environment it is if free users were limited to 10000 package downloads an hour? It's so unbelievably user hostile that it seems like the result will be people just stop using Docker. The right solution for Docker is probably to spin off or monetize the Hub in a different way. Imagine if GitHub started charging users for git cloning too many packfiles per hour.

michaelmrose 6y ago
All these things cost money to run why would it be surprising if they cost money to utilize their resources beyond a point?
- AaronFriel 6y ago
  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
krferriter 6y ago
I think npm and ruby gems are quite a lot smaller than the average and upper bound size of docker images, which can easily be multiple GiB. Also the use case is different, where a docker build may incur a few manifest retrievals from the registry, while an npm build may incur hundreds. I don't know how quickly the average user would run into a 10000 download/hour limit for NPM, but if they were able to arrive at an equivalently high limit like 200/hr for docker, then maybe it would be fine to start charging for rate limits above that, and not impact most people.

michaelmrose 6y ago

All these things cost money to run why would it be surprising if they cost money to utilize their resources beyond a point?

AaronFriel 6y ago
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

krferriter 6y ago

I think npm and ruby gems are quite a lot smaller than the average and upper bound size of docker images, which can easily be multiple GiB. Also the use case is different, where a docker build may incur a few manifest retrievals from the registry, while an npm build may incur hundreds. I don't know how quickly the average user would run into a 10000 download/hour limit for NPM, but if they were able to arrive at an equivalently high limit like 200/hr for docker, then maybe it would be fine to start charging for rate limits above that, and not impact most people.