Docker Desktop no longer free for large companies
theregister.com
theregister.com
The business license costs $21/month, probably less in reality.
Do you really think that businesses are going to jeopardize the workflows of their $250k/year assets over a very core piece of software for $250/year?
Any alternative has switching costs and risks. Companies will just pay this. I see so many people saying “just do these 10 steps and it’s basically the same”. It just ain’t worth it for $250
USD 21 per user/month + bulk discount is nothing.
If companies want to roll their own they can, but most won't. Docker Desktop adds a lot of value if only by removing the hassle for quick os-agnostic development.
In a world where podman exists, what's the point of docker on dev machines anyway?
Pretty sure they're used for more than that.
The biggest showstopper for podman is that it runs entirely in userspace on Linux. Having said that, I use it as a drop-in replacement for Docker and it's only become better in the past year. This is somewhat irrelevant to the Docker Desktop product, as podman doesn't provide a nice packaged up solution, but you can use podman on Windows and Mac as long as you have a Linux host available, either as a guest VM or as a machine _elsewhere_ on the network, see [1]. I only use Linux if I can, and the ability to run images without having to run a daemon with root privileges is a very big bonus for me, but it might not be for you. Now I do wonder, how hard would it be to declare a minimal nixOS VM for running as one's podman host :)
As I see it, that's the whole selling point. Need to have something with limited rights or build a container without root? Podman is the way to go.
Just `brew install podman`.
For Windows, Podman is available on many distributions in WSL2.
Why do you believe that? Docker's "root by default" design decision is the bane of Docker. Podman is even described as Docker done right in that regard.
Even for myself flying solo I can use my old desktop as a Podman server, conserving RAM/CPU in my development env. Sounds good to me.
It needs to have parity in all other pseudo-layers (3rd party tool support, support plans, OS support, someone to sign a contract with, compliance tools, etc.) We know most of these go unused or have no real meaning to devs, but they unlock enterprise procurement.
I believe podman has a linkage to RedHat which may actually bring all of the things that procurement want to hear, but the question is whether the door is open to RedHat, or not. Procurement departments can be fickle, preferring Oracle for everything or the other way round trying to eradicate Oracle while permitting a combination of others. It's all politics based on previous experiences and opinions in the end.
https://docs.podman.io/en/latest/markdown/podman-build.1.htm...
> --cache-from
> Images to utilize as potential cache sources. Podman does not currently support caching so this is a NOOP.
Not sure the bare docker daemon VM wrapper has a defensible moat though. Maybe this does more in Windows?
I did not know that running basic Linux VMs was something you could do without downloading VMware or Virtual Box - which isn't as easy as just running a few scripts (especially in corporate environments where Brew and other tools might not be so readily available to all employees).
> downloading VMware or Virtual Box - which isn't as easy as just running a few scripts (especially in corporate environments where Brew and other tools might not be so readily available to all employees).
Docker Desktop needs the same level of access, because it runs virtual machines. If you could install it on your own, can't you install those on your own? If it was centrally managed, then IT can switch to one of those programs instead.
> Does Mac have any sort of built-in VM framework like Hyper-V?
Yosemite added Hypervisor.framework, I guess?
Two, actually. Hypervisor.framework [0] to build virtualization solutions on top of a lightweight hypervisor, without third-party kernel extensions, and Virtualization.framework, to create virtual machines and run Linux-based operating systems.
[0] https://developer.apple.com/documentation/hypervisor?languag...
[1] https://developer.apple.com/documentation/virtualization?lan...
Literally the first non-title element in your link. Just because the client is cross-platform doesn't mean the entire solution is turn-key cross-platform.
I was going to say that installing Podman on macOS/Windows leaves the VM as an exercise to the user, but per another comment, there's podman-machine[1], a new-ish built in to setup a VM. However, it's apparently already deprecated (?) and recommends simply 'Vagrant' as an alternative, so seemingly setting up the VM is back to being a user exercise for Podman?
Most of the problems that devs are facing with docker are not actually docker but this layer that tries to abstract the VM. So in the end, it's quite common that you have fix things in the VM or get rid of it. I don't know if docker on WSL2 makes the matter better, none of the devs in my team using Windows can use it because of the memory usage bug.
I don’t think that thinking like an engineer will help you understand the value add here.
Of course, that fortune 500 is going to pick up the phone and demand to pay 1/4 of that (and they'll probably get it). Enterprise sales is fun
So it's less about 10$ and more about: "I understand what a wireless mouse is and it doesn't look mission critical to me."
"No idea what those items on that AWS bill mean, but I'll probably be better off not asking"
You have three rational choices: 1. Play the game, 2. Keep your head down, 3. Quit and move to a company that doesn't play those games.
Sitting around complaining that a big company has crappy inefficient processes is like complaining that water is wet. A complete waste of time and makes you look incompetent to other people in the company who are playing the game. These inefficient processes end up optimizing for people who know how to talk the code and cultivate the right relationships. Take advantage of that.
First you need something core to start a bill around. Let's make a law that makes it easier to buy guns.
But no one is going to vote for that, so let's give it a name you CAN'T say no to. It will henceforth be known as "The Child and Family Home Protection Act".
Great we have a cool name and we have a law significant enough to send to the floor of congress. Now let's get enough people to promise to vote for it so we don't waste our time. Oh, Congressman X says that he would vote for it as long as we add another law about funding polar bear research. Sure, whatever just add it in, we need the votes. Congresswoman Y says she will vote for it if we add a law about requiring masks at church. We need the votes, tack it on. Congressman Z has been trying to get more tanks sent to Afghanistan for nearly a decade, if we add that in I bet he will vote for out law too.
Then these things get bundled up and sent to the floor where people vote on laws with fun marketing names added to them.
The same thing happens in business. You start off with a core project like a new ERP system. Give it a complex sounding name that no one in accounts payable will say no to. Then we add in a bunch of computers into the budget that we have been trying to get for 2 years. Add a new printer. Throw in some docker desktop licenses for our developers, and then bundle it up and send it to Accounts Payable. Bam, now you have docker desktop licenses and new computers. You're welcome.
Another likely outcome is that it’s “easier” for teams to switch to another tool (easier in that at least they’re not waiting on a third party for approval) and everyone loses a lot of time
Big corporations are not the most efficient beasts for this kind of situation
The concept of opportunity cost is completely lost on a lot of business leaders.
It’s not just the $250/yr/dev, but rather the requirements to create a new vendor in the ERP morass, to get approvals for an exception to the standards for payment terms (and/or methods), any requirements for vetting vendors, etc.
If you’re selling to an enterprise, don’t charge just above whatever the “employees can put it on their card without approval”. If you’re going to exceed that, you might as well exceed it by a lot. (If you’re going to make every developer file an expense report every month, I can readily prefer to do a lot of command line typing rather than filing an expense report… If I automate that for a lot of my fellow devs, I get to do something fun and be a minor folk hero.)
https://www.joelonsoftware.com/2004/12/15/camels-and-rubber-...
Oh some JavaScript graphing library is expensive. Let’s roll our own!
Heroku meets our needs 100% let’s spend millions to switch to K8 and have a much worse experience.
Free tools have a predictable and stable cost.
I have probably been burned more times from free tools over the years, but the scars aren’t as deep. It’s just a shrug and hoping the other project works when the first doesn’t.
Unless they suddenly turn from free into a $21/month per person fee.
Docker Desktop was free, now it's $21/month, what will it cost next year when Docker needs more money?
- Reviewing purchases should put some reasonable controls around how much software you can accumulate. Adding to the tech stack has maintenance costs, and you don't really want to do it without some sort of review. In this case, it's not the dollars as much as the fit.
- With SaaS tools in particular, there are often privacy or security concerns. Those teams should review. Probably want legal's eyes on it to get the right terms in place as well. Again, less about the dollars here, and more about the agreement, risk, required disclosures (subprocessor, etc), and those kinds of factors.
- On the spend itself, you'd be surprised how this adds up, especially if folks are signing multi-year deals and not bothering to negotiate licensing. Remember, if it's easy for you and me to buy, it's easy for everyone else to buy too, and it multiplies quickly.
Now, on one-off hardware purchases and such, I agree it should be a lot easier. At least at the startup I work at, anything under $500 is just an expense report, so just make sure your manager is cool with it and go for it. But there are considerations here also around stuff coming in that IT or facilities then needs to support - obligating their time with your purchase is something you need to agree on or avoid.
EDIT: Also as someone else pointed out, grift on purchase orders is easy without any oversight.
A lot of it is that opportunity cost really isn't the problem of many business units. I spent a week building a crappy version of codecov for our few repos.
Dev won't get in trouble for that because opportunity cost isn't a thing for us as a cost centre.
Buying anything on my organization costs something around $10k. Add your price to this to discover the total we are spending.
That's on financial cost. The opportunity cost of stopping technical people to handle the technical details of an acquisition is just huge, and larger the most differentiation there is on the market.
$21 is nothing for a one-time spend.
$21 per month per employee is now $252/year per employee, but now you also need someone managing all of these licenses and accounting. Every new employee or team change requires some juggling of licenses with associated turn-around times before that person can get started.
It's not bad when it's just a couple key pieces of software, but it doesn't take long before every engineer has some mix of 20 different subscription tools and platforms and licenses and you're on the phone with a different vendor every week doing the annual subscription renewal pricing negotiation dance. The sales people know how this works and would prefer to wear you down with endless conference calls until you get tired of negotiating and just pay the new, higher price they're asking.
Soon, all of those "cheap" tools have added up to $1000/month or more per employee with a couple people dedicated to managing these licenses and negotiating with vendors all of the time. And it's terrible.
When the tool isn't easily replaceable, you deal with it. I'm not sure I see that with Docker Desktop, though. When you get a new hire, do you tell them to submit a ticket with licensing and wait until they can get their Docker Desktop license? Or do you simply write some documentation about how to accomplish tasks without using Docker Desktop so you can remove another external dependency? Teams generally gravitate toward the latter.
This! I've always said that a bit reason for FLOSS to win over the internet server-side is because scaling fast and juggling livenses is just too hard. Especially with the prying eyes of Oracle/MSFT/etc's powerful legal teams and hidden "phone home" code.
Going with a LAMP stack was just to simplest way to keep moving at speed.
Then engineering can spin up loads of instances to test stuff and scale fast with minimal hassle, and it'll be the purchasing team playing catchup later, no longer in the decisionmaking path.
There’s a dozen services I could buy for work that would probably improve things dramatically, for very little cost, but almost nothing is worth the pain of “get sign off. Get sign off again. Fill in paperwork. Wait n weeks. Get more sign off. Wait even longer for finance to do their thing.”
Docker doesn’t need to actually do that to run afoul of policies based on the scar tissue from those other vendors. Simply going from “you can use it without being sued” to “we have to pay people to make sure we’ll win” will increase the perceived cost at many large shops.
Without a contract, it's hard to disagree with the policy types who are going to ask what protects the organization if that happens. Once you go down this path even a little, the barriers to entry at large organizations go up since you have to look at it from the perspective of both the upfront cost and possible future cost / off-ramps.
1. https://twitter.com/scottcjohnston/status/143272649295845376...
When they are merged into some other big company, that company will look to milk the cow by going after license compliance. It happens every time.
They ended up telling me to forget about it.
I guess that perhaps they only want to target large businesses.
But arguing for $252/yr times a thousand developers (in the office I work in, at least; we have others elsewhere) is just untenable. If the value was there for us, then we could get it signed off on, but there's no way to build that value because now it's too expensive to get started.
A year or two ago I bought a personal license to Ubuntu FIPS after being urgently asked to debug an issue w/ Python's OpenSSL bindings. Unsurprisingly it turned out that my company had an enterprise license, and had I known whom to contact (which I didn't), I could have gotten a license key in a couple of days. But why waits days and potentially many thousands of dollars of time when I could buy a license now and get started immediately?
Frankly, it's weird how Silicon Valley employees making obscene amounts of money balk at personal expenses as if they're some minimum wage employee being victimized by their employer nickel-and-diming them. But that's just me. In fact, except at startups, Silicon Valley corporations neither expect this nor even give you credit for taking such initiative.
For personal expenses (meaning expenses for my own hobby projects, not "personal expenses" to mean business expenses paid by an employee as you have used it), $21 would be a quick decision. But using that same $21 to shore up a faulty requisition process? Nope, not at all.
I decided long ago not to worry about such expenses because 1) the engineer in me hates this inefficiency and urges me to fix or work around it (depending on your perspective), 2) navigating bureaucratic red tape takes a personal toll, and as someone who is paid well I don't mind at all spending a trivial amount of money for my own wellbeing, even if its for work, and 3) as someone who has worked in startups and even founded one, I've both been in a position where I was expected to take on such expenses and expected others to do the same (at least as an initial matter[1]).
[1] The dilemma is that unless the purchaser faces some risk of incurring the expense themself, they're not as incentivized to consider the reasonableness of the purchase. The solution is either 1) requiring permission beforehand, or 2) hiring more mature employees who understand the nature of the dilemma and who have already factored this responsibility and risk into their negotiated compensation. The latter doesn't scale, though, which is why large organizations invariably regress to the former.
You’re making life harder for everyone else!
It also allows small creators to survive.
I'm working on hybrid mobile apps again after a long break. The number of essential packages in both the Ionic/Capacitor/Cordova and React Native ecosystems that are "looking for maintainers" (think: camera functionality) and have long lists of issues is frankly astounding, given the number of users of said packages.
An expectation to pay so the maintainers can maintain is a good thing in my book.
So where does it stop? Is 250$ ok but 1000 isn’t?
I think we’ve set the line just fine, if you want to cover opex out of pocket, cool. But don’t try to put that on people who can’t afford it.
Docker arguably should be charging more for it. The friction between $0 and $21/month is higher than the friction between $21/month and $60/month in a lot of ways.
Having worked with procurement departments I can understand very well why employees should never be able to make purchasing decisions without someone from procurement in the loop.
How long does it really take to set up the VM and port forwarding to have most of what people care for from docker desktop locally. A couple of hours. Let's say 3. So cost $360.
How long does it take to go through your average large company requisition process? Probably 2 hours over multiple weeks. So that's $84 for the license at the $7 tier, and $240 for the time spent dealing with the corporations self inflicted tedium. But hey, $324, still technically cheaper.
But then there's the opportunity cost of waiting two weeks to install fucking docker. I think we can all agree that's worth more than $36.
So I'll be looking at alternative solutions rather than deal with the corporate purchasing bureaucracy. Even if the purchasing manager was reacting in real time I'd probably consider it worth $36 not to deal with the process.
that's how it's worked for me - in my last job spent 3 weeks waiting for a Qt License, Intel compiler license, MSVC license...
Real talk: Just hire people. The US especially has a huge amount of college educated people who struggle to find a job that matches their chosen education. If you can't find someone that matches the exact profile, pay for an education and training. As a company, don't accept just winging it - especially not if you have enough money.
What situation, being trapped? I'm not sure what size has to do with it. Are small corporations maybe more ... agile?
If the org's been thoughtful to in advance, it's at the level of being almost an operational risk - all of engineering uses this tool, tool's licence or pricing might change, retooling has an associated cost and down-time.
Not sure how would that work for a desktop tool. It's in them to figure that out though
Not where I work at. IT opex are a recurring cost item with no visible benefits, so are squeezed dry at every annual budget review. Capex are seen as investments into something new and good and their impact on the bottom line is amortized over several years.
Legal alone will spend months looking at run-of-the-mill software contacts trying to negotiate absurd concessions from vendors in situations where they clearly have no bargaining power.
We can spend a lot of money on Oracle for their profoundly obtuse products though.
I got front-line seats at a company with tens of millions in revenue try to get payment processor to remove escrow terms from the contract.
Said company got blocked at tier 2 support. They refused to escalate for a company who wasn’t a customer, especially when legal stuff was involved. Tier 2 had a script specifically for people like us.
I regret not bringing popcorn to that phone call.
In short: “Those aren’t our terms; those are the terms of a billion-dollar bank. Sign it or leave.”
They were very much not impressed with our claim to being the second-largest widget maker in the world.
Example: I only have to revisit licensing once a year, to create a new 12 line purchase order. It's still a pain but I prefer purchase orders vs dealing with credit cards. In addition, querying expense history for purchase order lines provides far more detail vs querying a credit card platform. Credit card history tends to go into a black hole.
One possible hitch...Some companies might restrict Accounts Payable from receiving purchase orders for separation-of-duties reasons.
I asked if I could just pay it myself, but was told that would violate the IT department guidelines and possibly an SLA too, so I just sat there for a month, reminding everyone at the daily stand ups I was blocked. I couldn’t believe it.
I was not the only one who was tied in red tape there, it was indeed normal.
This company was making 600 million a year in profit.
If it's a core part of my job and the best option available, it'd be worth it, but if there's any reasonable alternative, I'll go download that today instead of wading through all of the lawyers and approvals and compliance to use something slightly better.
If you already have a live deployment then the company's bigger fear is the a risk of switching to a completely new infrastructure and they'll all of a sudden push the paperwork quickly to stay on their existing codebase.
I’d rather investigate an alternative like running it on a VM than deal with that. Actually I’d rather shave my face with some mace in the dark than deal with that.
If you know more than other people, that's great, but then please share some of what you know so the rest of us can learn. If you can't do that or don't want to, that's fine, but then please don't post.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
It’s ok. Just keep telling yourself you’re smarter than everyone else.
Rule of thumb TCO for headcount is 1.5-2x salary to account for taxes, Medicare, health insurance, equipment cost, licenses, office square footage, stock options, travel, etc.
So a $250k asset from a business perspective is typically someone that makes $125k-$165k.
Salary + Taxes (Payroll, etc) + Fringe (Healthcare, etc) + Dev licenses + Training/conferences = paycheck * (n > 1.5)
I see $160K salary ceilings for general "senior engineers" for vast majority of non-FAANG companies in high COL East Coast city, so I'd imagine midwest is $25K less since housing is so much cheaper.
But maybe salaries are really exploding, and I just haven't been paying attention.
However, this will have a massive change on the competitive landscape. For companies that haven't yet adopted Docker, this is a huge red checkmark. This change is going to spur development on open source alternatives like nothing else could.
This is such a good problem to have. I would love to cut Docker Inc. a check.
And we've basically moved over to garden (a k8s dev env) anyway. But we still use docker plenty.
If docker and containerization is not yet widely used in the company, a lot of decisionmakers will not buy it, because they did fine without it for decades ;)
Being so cheap actually complicates the matters even more, since the finance people don't really want to mess with purchases less than $5,000, even though it is their own rule that requires all software to go through them regardless of cost. It just means they won't be willing to help very much.
Tech companies? No, they will probably cough up until they have another solution.
IT departments in non-tech companies? Yes. I fully expect a circus there. Many won't have known it was being used, purchasing will have their ego bruised by a company "hijacking" them and won't want to pay, and so on.
Management may want some badge of honor for saving a budget line item. Or developers may want to embark on a new and interesting project and successfully convince management it's a good idea, who will agree for a wide range of reasons (not pissing off developers might be one of them).
Both will ignore the risk and considerable downsides. Happens all the time.
Still should be doable for most businesses that size but licensing costs can blow up when you start to have a lot of seats. An annoying thing about the company I work for is that they have a limited number of licenses for things like IDEs, so they ration them. And so I'll boot up an IDE for a language I work in less - like say, PyCharm - and it will stop working because my license got taken away and given to someone else. I'll have to request another one be given back to get working again, which is pretty annoying when I'm trying to get something done. I work mostly with Docker / Kubernetes so if I'm in a situation where my core tools are being constantly taken away, I'll be pretty miffed.
I agree that Docker has every right to charge big companies for this software. Just wanted to point out that the costs can be more than you'd expect.
VCs are shooting themselves in the foot here: it is very obvious that we should never adopt any technical tool backed by VC, because they will eventually try to make us an offer we can't refuse and then go out of business shortly thereafter when their extortion attempt doesn't work.
Lol yes, I know. My point was the cost of meatware is 3 orders of magnitude greater than the software, and likely less at scale.
$100k/mo would mean 5,000 devs. I highly doubt a company with overheads near/in excess of a billion dollars/year is going to sweat a $1m expense for core infra like Docker.
Not just "think" - I know for a fact.
Finance refuses to spend money if there is a "free" alternative, and Architecture rejects all software that isn't OSS licensed without a lengthy review process. It would take us at least 3 months to get approvals and POs for all the devs, if it even got approved, but more likely it would be in "batches" of licenses, further delaying roll-out. So instead the devs are beginning to install Linux VMs to run Docker from, or looking at podman.
People forget that just because there's a "rational" decision, doesn't mean people (or businesses) will choose it. Businesses are run by humans, and humans are irrational and dumb. Path of least resistance wins.
No, it costs $21/user/month.
> Do you really think that businesses are going to jeopardize the workflows of their $250k/year assets over a very core piece of software for $250/year?
I work for a big enterprise that is currently going through a transition that is simultaneously a cloud transition and a transition to more critically consider tooling with license management overhead (which for a $21/seat license, is probably a significantly larger cost in a big, bureaucratic enterprise than the license cost itself.)
That said, there's a good argument that the things that you get for that $21/seat are things many enterprises will find are still worth the license cost + license management overhead. On the other hand, most of that is stuff that doesn't scale with number of developer seats, so a subscription model that doesn't work on that basis and therefore doesn't impose the kind of license management overhead that per-seat licensing does would probably net Docker more revenue while imposing less total costs on enterprises.
Do you guys not realize that I know that? I did the maths standardized to one seat.
I’m not also suggesting that the entire engineering spend for 100+ person companies is $250k/year.
Do the analysis on a per unit cost because that’s how life works: per unit cost of human capital and per unit cost of software vs. per unit value creation.
Did you not read the rest of the post? I think you knew the license fee was per seat, I think you just think you failed (and fail, still) to understand the significance of that on the actual cost to the business imposed, of which the license fee itself is only a fraction.
When you've spent enough time in the IT Department, you'll see companies demand that you "cut laptop costs" or similar. Because when you're buying 250 laptops a year, the people with the budgets go "OMG we're spending half a million a year on laptops". So changes are made to the configuration, maybe small SSD but often times it'll be something like less RAM, or slower CPU - because purchasing controls aren't that fine. Great, you've now cut $200 per laptop and the money people are excited to see you've saved $50,000/year.
Do they understand that now there are 250 people, which probably all cost more than $100,000/year, whom aren't quite as efficient as they could be? Nope. And they don't care. The budget says you get X. The personnel cost is attributed in some other category not to be touched.
Almost no one at a higher level looks at the puzzle and goes "Well we should spend $250/year to get this $250,000 asset productive". They look at the situation and go "We've got 100 developers, ain't no way we're spending $25k/year on this product. It's not in budget."
Lastly the per-employee cost adds up. It's $11/mo for SSO. $18/mo for email suite. $19/mo for Gitlab. $14/mo for Jira. $5/mo for Confluence. $3/mo just to put SAML on Jira & Confluence. $8/mo for Password vault. $12/mo for Slack. $17/mo fro Zoom. $17/mo for Lucidchart. $12/mo for Laptop MDM. That's not everything an employee needs, heck it doesn't even cover HR products (Workday? 15Five? Applicant Tracking?), Training (probably a couple of those), EDR/AV for laptops, and dozens of other smaller services. Sure adding another $21/mo isn't going to change the number a lot on an individual basis, but it adds up really fast when you multiply it out across all your Developers.
And don't forget. How do you rationalize that your container software costs more than your source code control solution? One of those two things you can very easily live without... and it's Docker.
Let me add something useful here and say that it even has a name:
"subscription fatigue"
I was fine paying Netflix for an all-I-can-watch even if I ended up watching less than a DVDs worth of content just for the convenience of not keeping a stack of DVDs around.
I'm not fine with paying Netflix, HBO, Disney, my cable provider, NRK (state owned broadcastee,mandatory) etc etc a monthly or yearly fee.
So I just drop it: it is not like I need to watch it.
Same with tools: I'm happy to bug my company to pay for IntelliJ as long as NetBeans is stuck in its current spot, we already pay for Jira and Confluence but I am always seeking out the open source solutions, - partially because I'm old enough to realize that $n in subscription means $n x 12 x m devs a year, partially no cost open source (contrary to popular belief here) is less hassle and partially because going proprietary feels like paying Dane geld.
Edit:
> Almost no one at a higher level looks at the puzzle and goes "Well we should spend $250/year to get this $250,000 asset productive". They look at the situation and go "We've got 100 developers, ain't no way we're spending $25k/year on this product. It's not in budget."
Probably true in most places and it is sometimes a problem.
But that institutional hesitation is also a powerful defense against every vendor who wants to inject themselves somewhere and then start jacking up the prices.
Would love to know how you arrived at this number.
The list price for 100 engineers on the most expensive plan would be $25k/year and I guarantee Docker will do volume discounts.
Additionally, the terms just say you need a paid plan, which presumably could be the cheapo $5/mo plan which would be $6k/year for 100 engineers.
But maybe my company is too large; large enough companies can have smaller teams, other teams will probably go the licensing route
My company was already somewhat interested in checking out hosted IDEs, and today this pushed us to start some proof of concepts to move some teams over to github's codespaces.
So, yes, businesses will adjust their workflows to avoid the cost since many were already interested in improving their workflows and relieving some of the burden on their developer environment tooling teams.
YES! I've seen it. Stinginess at my shop regularly causes hours and hours of pricey engineering resources to address problems caused by underallocating cloud resources to the point things fail - or refusal to allow some cloud service because it will cost $100/month (despite saving 10s of thousands in eng resources)
It's crazy but I bet it happens many places.
The pricing model for this is really stupid. A $21/mo subscription is a pain in the ass — they would be better off just selling it perpetual for $1000.
I ran a big enterprise shop for years. Nuisance licensing like this costs a fortune - I’d need to go do legal review, have it tracked for renewals and compliance, etc. Freemium product like this is always coupled with a stupid license enforcement audit that appears and tries to extort you. For a small quantity, overhead may be more than the product.
As an enterprise consumer, it makes me question the viability of the company. $250 a year is priced to allow unit managers to use P-Cards to avoid procurement processes. It’s too cheap to make meaningful amounts of money, so unless it’s a way to shift me to a more intelligent model, I’d have folks assigned to investigate alternatives.
1) Internship at a well known tech corporation. I was on a project that would accelerate the debugging and diagnostic of a machine the whole factory depended on; tl;dr I was making an app to replace an overgrown Excel sheet. To do that we used an opensource library but the catch was that the maintainer made its money by placing the documentation under a paywall. At some point the project was going well but the leftovers from Google Code could not do anymore. So it took two months (TWO MONTHS!) to do a $15 USD one time payment with the company's credit card. Apparently the process took longer due to the fact we had to go through PayPal.
2) Another multi billion corporation, less big but still multinational. They spent hours and lots of money on internal propaganda to promote their "core values"; which of course included "agility". We wanted to buy a commercial code analysis tool to save time during code reviews and increase code quality of a code base where ~30 devs worked. No brainier right? We had the R&D department's VP's OK to buy the damn thing and ask for forgiveness to the mother ship later. After 6 months our team leader was still receiving calls and and form to fill. "Do you really need this? Did you think about other products? Did you have the OK from this person thousand of miles away and this other person who speaks in a very broken English?" Using the company's internal organism and salary tables we estimated that during those six months they have wasted about 5 years of licensing in salary.
Hahahahaha, yes, absolutely. Because if the wrong VP gets this in his head, it's not $250/year, it's "almost half a million dollars over 3 years" for the 500 employees or whatever. I've seen it happen.
fuck..i need to find a new job
That's not how corporations work.
I work remotely for large corporation (over 100k employees) and it wastes on average an hour of my productivity every day on stupid stuff. For example my office PC becomes unavailable every time it gets an update, at least once a week. They force restart during working hours. If there is somebody in the office I can call them to reboot it, if not I have to drive there. Everybody has the same problem. Meetings are disrupted, plans are thrown in disarray, people are loosing sometimes entire day of work.
The problem has been known before covid and has not been solved.
Any normal logical person would throw resources into solving the problem, but the people responsible just say they are busy and why is that a big problem if you can just press reboot?
This was email provided and owned by the very company I worked for, and it was costing enough for management to care.
Maybe enterprises have changed since then, but I wouldn’t be surprised if stuff like this does start asking questions as it’s a new cost on a budget.
I have, and let me tell you, they will spend dozens of hours and thousands of dollars to fight a purchase of $21. I'm really not joking.
As soon as there is a viable alternative (and I’d be happy to contribute to the effort), I’ll be moving away from Docker for Mac.
podman stop -a
or you can mount the current directory
podman run -v .:/mnt
or you can mount while you build
podman build -v /dir:/dir
or you can work entirely without root and have the same user on the host also in the container:
podman run --userns=keep-id
(useful when a directory is mounted into container but the application refuses to run as root)
For Windows, use WSL2 and do the same.
Both can mount “local” folders, although the setup is obviously different.
You now have a better way to manage containers than ever before.
You could use anything to manage the Docker VM... VSCode is just one option.
Docker Engine looks problematic since the license isn't clear at all. For instance, Microsoft didn't include Docker into GitHub Actions, they also forked Moby and packaged it on their own, since they can't comply with the End User Agreement of Docker Engine.
Multipass, Qemu, and Parallels can all provide a solid VM on Mac host. All you need after that is your dev environment VM guest image to deploy to the team.
$ docker pull hello-world@sha256:7d91b69e04a9029b99f3585aaaccae2baa80bcf318f4a5d2165a9898cd2dc0a1There are also better caching properties when using content addressable identifiers. For example with kubernetes pull policies, using IfNotPresent and deploying by digest means you don't even have to check with the registry to initialize a pod if the image is already cached, which can improve startup latency.
While agree on the unquoted part, this is true also for human-readable (aka mutable-that-should-be-immutable) tags, when that pull policy is set (which is by default for everything that is not `latest`)
Docker can still be run in the VM just fine, for cases where you want a reproducible build environment.
I do this at any company that lets me (and by lets, I mean doesn't explicitly forbid) - They all give me a Mac, and the first (and sometimes only) thing I install is usually vmware fusion, followed by the linux distro of my choice (Arch).
Or just create your reproducible build environment as a QEMU VM image instead of a docker file. That way you only have to install a VM image, instead of install VM image/OS + install Docker + install your Docker file.
Containers solve a different problem than vms. The biggest issues (at least for me) are
1. The second a dev starts using that VM, it's no longer reproducible. The goal of docker is that a developer can create reproducible images as a part of normal development.
2. I won't be running that QEMU vm in production, but I might very well be running the exact same container image in both development and production.
I just SSH into my server. The biggest pain about macOS is that it can't easily mount SFTP.
Pulling the same projects to my (admittedly quite fast) linux box in the cloud is night and day for speed in docker with volume mounts. Browserfy runs 5x faster, at least. Yarn install is 10x faster.
And it's reliable. Docker's filesharing on the mac has about a 25% failure rate that any given save will be properly picked up by watch, with a complete, uncorrupted, updated file.
It seems to me you would be the one cutting off your nose to spite your face in this scenario.
How does this affect consultants that want to introduce docker to large corporations but small teams? A lot of scenarios become crappy now.
Which alternatives did they kill? The Podman tool ecosystem is doing fine and is closing in on being a complete replacement, and Docker Swarm hasn't exactly killed k{number}s.
I understand (in some way) the decision Docker made but I am not sure it is the way-to-go. However, it is a very hard question and if I had to pay a monthly fee for each component I‘m using to develop a solution, one or the other project would not even start because it‘s not worth it anymore.
Or put another way, how much time would you need to replicate what Docker offers for a team of 50 people? If it takes more than 25% of the time of a single employee, then Docker is cheaper (assuming your employee costs $5000 a month, which I guess is a lower bound for an engineer).
I think it is a very valid question how to monetize Docker (and all the other libraries we are using for free), but I am personally not sure that subscriptions to everything are the solution.
I am sure that this expense should not get into your way if you have 50+ engineers, however if you think that with all expenses…
Isn't paying their fee also contributing to the effort of what they've put in to it so far, and ideally what they'll do to keep it working and improve over time?
I certainly don't begrudge Docker for trying to create a sustainable business, but as an "open core" model it's really hard to understand what their proprietary extensions are that people will want to pay for. They took a stab at the container orchestration space with Docker Swarm (which you could definitely imagine having an "enterprise version") but that lost out pretty definitively to Kubernetes. So they're left with Docker Hub? That just doesn't seem like it will really be much of a revenue generator. You're either using whatever cloud container registry is available (ECR, GCR etc) or you're using a more general artifact repository like Artifactory, GitHub which can be a container registry as well as a Maven/NPM/etc artifact repository.
Minikube sets up a Linux VM using MacOS Hypervisor.
It even has a convenience command to configure docker-cli/docker-client.
$ minikube docker-env
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.65.11:2376"
export DOCKER_CERT_PATH="/Users/wibble/.minikube/certs"
export MINIKUBE_ACTIVE_DOCKERD="minikube"
$ minikube start --embed-certs
Available options:
--driver='': Driver is one of: virtualbox, parallels, vmwarefusion, hyperkit, vmware, docker, ssh (defaults to auto-detect)Hyperkit is open source software that works on macOS.
https://minikube.sigs.k8s.io/docs/drivers/hyperkit/
Virtualbox is also a free (as in beer, and mostly libre) driver that works on all of windows/linux/macOS
It's arguable if the container is "virtualized linux" as they all share a single linux kernel. In reality there's one virtual machine, one linux kernel, and many linux userspaces (one per container), which is kinda the whole point of containers.
Over docker+linux, the virtual machine is the only additional layer.
fwiw, I personally don't use macOS, so I've only got virtualized linux (containers) run by docker running on linux running on my hardware.
Are you trying to make a point or something here? Like, yes, we've built layers of abstraction that include different types of virtualization (VMs and containers), and they compose. Is that all you're observing?
Nah, just curious/intrigued by how these stack.
OS-level virtualization is very much a thing. I'd be interesting to compare this to the approach taken by Docker Dekstop for Mac. I bet they do something quite similar (hypervisor-based virtualization like Virtualbox) - nothing fancy like WSL1 that I believe runs a sort of "tortured" Linux kernel inside the NT kernel.
Docker on Windows and Mac does the same as what is described above - it runs a Linux VM and runs the docker server inside that, and then does a little magic to expose native OS paths and so on to that VM. On Windows, it uses WSL2 by default now, but WSL2 is also a Hyper-V VM in the end, with some Windows magic to blend it more nicely in Windows workflows.
- MacOS running a hypervisor
- A Linux VM with Docker installed.
- A Linux container running on that VMs kernel.
Containers on Linux aren’t virtualized (normally, you could use runV I suppose if you wanted). The only overhead is the extra disk space to extract the root fs of the container image and the namespacing.
LXC was the first container implementation on Linux and uses full Linux systems similar to a VM.
Even better Oracle tracks the ips that download this extension and after a suitable amount of time they will come knocking on your company's door asking for an insulting amount of money (e.g. more expensive than VMware) or get sued. You need to read the fine print of the additional Eula printed in really small letters on the VirtualBox website to figure out the extension isn't free. It's almost a honeypot tactic. Scummy.
Was free for as long as I've known it existed. Telerik recently bought by 'Progress' (ironic), software re-written in Electron and now charges a subscription to use it.
Glad HTTP Toolkit is now available free for 'hobbyist' tasks - https://httptoolkit.tech/
I should mention here: not only is the core product all free, it's also completely open source, even including the paid bits (https://github.com/httptoolkit). And those Pro features are completely free for all contributors to the project.
I've tried to set it up so I couldn't run off with it and force everybody to start paying even if I wanted to, but any suggestions for further improvements there very welcome.
I was very, very impressed when I opened the Android mode and my Genymotion emulator just opened automatically with the VPN app and connected.
Then everyone panics when a critical build stops working because some apt repository of some decades old distros is unplugged or some shell script piped directly to bash goes dark (or someone with a bit of security common sense rightfully has a panic attack) and we have to salvage it using some ex-employees backup images.
This is also why I just don't say I do devops because it just gets to a point where the "devops guys" are just the people you give the dirty jobs nobody wanna do.
Everything else is handled by other parts of the ecosystem already, image registries both private and public, orchestration, etc.
A lot of macOS developers imo seem to have more knowledge in their specific domain and less in how to wire up a VM to look seamless, they'll need the docker CLI to work with the local filesystem to keep a lot of existing Makefiles functional, I see a bunch of companies caughing up money in the short term just for that.
Docker Desktop on Windows itself proves quite well that WSL2 works fine for this use case.
Good move by Docker, financially speaking. They have little to lose.
A whole bunch of scenarios die now.
Why would I go out of my way to set up Docker differently on my dev machine compared to my servers? That seems like a recipe for failure.
I have been supporting it for 2 years now. Been through all the Docker Desktop upgrades, performance issues everytthing. I have researched docker performance on macs running k3d + k3s + istio and a bunch of microservices. I have had to jump into the internals of Docker daemon and docker cli and networking to solve how docker networks are provisioned for various proxying issues.
1. Docker dragged their feet with native performance for file syncing. We have to selectively enable it and just so that it doesn't bog the machine down.
2. When running it gets the CPU running at 75-80C, causing the fan to run non-stop at 3000 rpm at least. It is definitely impact by bad macbook pro design, which is terrible at airflow and heat sink activities
3. We were on unstable for a bit to test the new file syncing approach. Docker dropped that in stable and said "deal with it"
4. The paid forced upgrade notification means that I can't peg the Docker Desktop version for the whole org at a certain version.
5. Right after we switch from the unstable to stable, the next minor version is a breaking change.
6. Number 4 would be fine it docker would keep to their guarantee of stable being stable. They do a terrible job of being backwards compatible. The current stable we had was 3.3.1. With the constant minor upgrades, and pushing people, some people went to 3.6.0. (the latest as of yesterday, Aug 30) This broke everything inexplicable with just a VM error where k3d would keep crashing. I downgraded everyone back to 3.3.1 to get teams unblocked while waiting for me to find a fix.
7. Finding a fix usually involves waiting for Docker to prioritize something but at this point I don't trust that Docker know what it is doing.
I am currently pushing for Linux laptops, hosted dev environments and reducing the need to run distributed monoliths. We shall see.
The non-desktop docker product on it's own is crazy good, I think it's reasonable to expect docker desktop to improve once docker actually makes money from it and can afford to hire more engineers to work on it.
EDIT: Wow, they actually did this and got back to me - thank you!
If I have to tweet-storm to get someone to look at my support ticket, there is no real support.
Larson, Will. An Elegant Puzzle: Systems of Engineering Management (p. 122). Stripe Press. Kindle Edition.
It was in that era of my career that I came to view management as, at its core, a moral profession. We have the opportunity to create an environment for those around us to be their best, in fair surroundings. For me, that’s both an opportunity and an obligation for managers, and saying no in that room with my manager and CTO was, in part, my decision to hold the line on what’s right.
Larson, Will. An Elegant Puzzle: Systems of Engineering Management (p. 123). Stripe Press. Kindle Edition.
And that's why they are scaling back on free plans.
I've never opened a ticket to Google as paying customer so I don't know for sure but unless someone comes and confirms that same crap is happening even if you pay we can't really compare those two cases and Docker is worse for simple reason that it demands payment yet ignores paying customers.
"Specifically, small businesses (fewer than 250 employees AND less than $10 million in revenue) may continue to use Docker Desktop with Docker Personal for free. The use of Docker Desktop in large businesses, however, requires a Pro, Team, or Business paid subscription, starting at $5 per user per month."
(nmap -O $local_subnet | grep -ci 'Macbook') > 250basically most companies with ~50 people probably has 10 million in revenue (annually). considering wages and buildings and stuff you need for 50 people...
Businesses that would unknowingly risk this because some engineer just went and installed Docker Desktop because they couldn't be bothered chasing this through management and procurement? Well..
As others have stated: I am okay with attempting to monetize your work, but increasing prices like this (especially from free to a pretty pricey per-head subscription model) doesn't sit well with me. There doesn't seem to be much differentiation between the tier besides: "How many employees/revenue you have" and that is not my favorite line of charging.
Does this relate at all to the forced upgrades that were pushed earlier this year?
Disclosure: I work on Rancher Desktop. Feedback welcome.
Where's the Linux version? Give it to me in Snap, AppImage, Flatpak, deb, or rpm, whatever you want. Just offer something. We'll take care of the rest.
I somewhat agree with your viewpoint, but given Windows 10 is generally just Windows 10 , OSX is OSX… But Linux could be anything from Redhat to Alpine to a raspberry pi , I understand why devs wouldn’t support it
Part of this was due to priorities and part of it was technicalities. For example, do we put it in a VM so that way someone can easily blow things away and we don't touch the base system? We had to come to some direction on what we wanted to do there. Now that we have that idea we need to finish up one thing on Mac that will translate over to Linux.
The Linux side will be based on Lima[1] just as the Mac side is.
Earlier today I had a discussion on the packaging format.
If you’re using Linux already, most of this stuff is as useful as nipples on a breastplate. You could theoretically run an emptied out husk of the app on Linux, but there are much better tools for working with the tools directly.
So I’d be greatly surprised if any Linux kernel hackers are miffed about this.
There are even programs like minikube that can get you Kubernetes in a VM on Mac.
There is something else to it that people want and that translates to Linux, I've learned. They want an easy button with an easy UX. There are a lot of people who are like that.
One example from my last job was having one shell.nix in the root of every project folder a developer could nix shell into that contained everything they needed, same version and all, to get going with that project.
1. There's very little "getting started" info here, you seem to assume everyone already runs kube everywhere else and already has workloads ready to go.
2. Not sure if this is feasible, but I'm looking for something that solves the Docker Desktop problem! I want something that can port map to a local port for testing, I want something that I can map a local folder to in order to store job input/output.
3. I tried starting it, and I'm already running Docker Desktop. It didn't seem to start a healthy kube cluster, and actually did nothing for me but just said it was waiting for the cluster. It might have been attempting to connect to old Docker kube clusters that I'm no longer running. Did I just need to wait longer? It wasn't clear.
Docker for Mac absolutely sucks. If they’re going to force everyone to pay they better start fixing bugs.
They recently stopped allowing skipping a release unless you pay, and then promptly shipped a point release with a showstopper bug.
I literally asked IT for a Linux VM/Cloud machine yesterday for development because my Mac is dead in the water due to a bug. It’s time efficient to develop on the Mac if it works, but the overall experience is terrible compared to Linux on the desktop IMO.
Whoa, really? Is this written up somewhere?
My first "WTF" with docker was in Fall 2015 when we dockerized our app and had it nicely set up so we could tell employees "run this command and the app Just Works" ... and then they introduced a breaking change to the format of docker compose files so it just mysteriously stopped working in the middle of the day.
I honestly thought that's a bug. That is so ridiculous if that's intentional. I agree with your post and have similar experiences with Docker for Mac
This is purely a $$$ move (which is fine) but we shouldn't expect an order of magnitude more work going into the product as a result of this move, imo.
The fact that they don't care, and yet you (or if not you, others) still use it, succinctly explains why they do not care.
If they have a shitty, buggy client for Mac/Windows, and people complain about it but still use it, then they have no incentive to care.
You can open up the docker app and configure a smaller amount of ram if it impacts your host OS
So you are wrong. For those of us affected by the bug, it's a big issue.
[1] https://blog.simonpeterdebbarma.com/2020-04-memory-and-wsl/
I've been using it full time since 2018 and it's been nothing but really fast and as stable as you can ask for given how complex of a tool it is. It rarely crashes (maybe once every few months) and I've built thousands of images across many different tech stacks.
I get the problem they are trying to solve is extremely difficult. I don't think I'd do much better trying to seamlessly ship a very Linux-centric API on Mac and Windows. They have my sympathy but that doesn't mean I'll use the product given a choice.
I asked for a P14 AMD Ryzen 7 5850H ThinkPad. Its still en route. But until then I'm using my Dell G5 SE Ryzen 7 4800H laptop with Manjaro. Best dev experience I've ever had at a company. The dev machine adds to the package IMO. If you're not getting the tools you want, you're not being paid enough ever.
I have no idea how this is popular.
> No changes to Docker Engine or any upstream open source Docker or Moby project.
If you develop on Linux, no changes are needed.
Would I be able to install and run Docker inside Ubuntu's WSL distro to avoid paying for Docker for Desktop?
So install the client inside WSL and the engine on a Linux VM.
EDIT: https://raesene.github.io/blog/2018/11/11/Docker-18-09-SSH/ was a blog I wrote when that feature landed, AFAIK it works the same way now :)
I may have had to expose the Docker socket for VS Code containers support to work, but that wasn't any pain, and secured with TLS.
Never needed Docker Desktop, which seemed like a bloated mess.
If you need to use `docker` command under Powershell, maybe exposing docker socket to Windows host would probably work. I didn't try it as I don't need it.
I install `docker.io` via apt and its good to go except that package has on some ubuntu versions been missing the /etc/init.d/ startup script.
I build my WSL2 environments via Dockerfile. You can see everything here:
https://github.com/SeanTAllen/wsl-environments/tree/main/ubu...
Using that dockerfile I can then export the file system as a tar (https://wiki.seantallen.com/notes/docker-export-filesystem/) and import into wsl using the wsl import command.
We've been managing all our infrastructure with docker / compose, and its been great. But one of the key advantages is unifying the dev & prod environments. Now lately we've been outgrowing the docker solution so k8 is on the radar, but one of the things holding me back is losing the unified prod/dev experience.
So the question has been, take the hit and suck up all the bugs, confusion, duplication etc. that come from having these separate, or move everyone over to k8 and have to deal with the complexity on the developer side?
Well, this decision now definitely tips the scales - there's a distinct advantage to going all in on k8s because we can run it up and down the stack and not be constantly hassled by licensing and software restrictions.
From https://docs.docker.com/engine/install/binaries/#install-cli...
> The macOS binary includes the Docker client only. It does not include the dockerd daemon.
Docker for Mac/Windows sets up a Linux VM using macOS/Windows native virtualization via the open-source HyperKit/VPNKit abstractions maintained by Docker-the-Company and the community. That VM runs Docker Enginer (dockerd) and all interaction (docker CLI commands, shared volumes, networking, etc.) are proxied into that VM.
There's probably a fairly simple way to run Docker directly in WSL, but a lot of documentation is going to need to be updated to point to that method.
Docker's CEO is being disingenuous. When you deploy a Docker container, you specify the image ID. The ID looks like a SHA-256 digest and even starts with the string 'sha256' but it is an arbitrary value generated by the docker daemon on the local machine. The ID is not a hash of the image contents [0, 1]. In other words, docker images are not content-addressed.
Since docker images are not content-addressed, your image registry and image transfer tools can subvert the security of your production systems. The fix is straightforward: make an image ID be the SHA-256 digest of the image contents, which is the same everywhere: on your build system, image registry, test system, and production hosts. This fix will increase supply chain security for all Docker users. It is massive low-hanging fruit.
Now Docker will add image signatures without first making images content-addressed. Their decision makes sense only if their goal is to make money and not make a secure product. I cannot trust a company with such priorities.
[0] https://github.com/moby/moby/issues/39247#issuecomment-49697...
[1] https://github.com/distribution/distribution/issues/1662
EDIT: Added another link.
The layers are not tar+gzipped until you attempt to push them, at which point the digest is calculated.
Images have a reference (e.g. "ubuntu:20.04"), they have an ID inside docker (random string), and they have a digest.
All image data is stored by digest. Even when you fetch an image reference it is looking up the digest of that reference and fetching that digest and that digest is verified.
An image manifest contains the digests of the image config and the digest of all the layers, the image config also stores the digest of all the layers. This is how all the data is traversed from the registry.
Once pulled, the content addressed layers are extracted into the storage driver (overlay, btrfs, whatever).
Also, announced on 31.08, effective 31.08 (albeit grace period…)
The page reads as follows:
> These new terms take effect August 31, 2021, and there is a grace period until January 31, 2022 for those who require a paid subscription…
So: announced 31.08, effective 31.08 (albeit grace period).
To add to this, I have received their email with this announcement after after 2pm CEST on 31.08. This must have been an unplanned decision.
Trying to be a poor mans pivotal was a stupid strategy, and developer tools is awkward too.
I’m convinced if they charged $10 per engine per month they would have kept all of the goodwill and momentum and been the next VMWare.
https://www.docker.com/blog/docker-enterprise-edition/
https://web.archive.org/web/20171118161452/https://www.docke...
That being said, since the core docker tech is free, this will surely just cause some free alternative to DD to spring up in the relatively short term, and accelerate the move away from Docker in general, which has been happening for a while.
It seems like the real cost to this change is the goodwill from smaller companies + teams that are now realizing they'll have another expense dropped on them. Except the expense is a previously free product with no real improvements, at least from what I can tell.
The forced updates I HATE. It's my machine, I get to pick the version of software it runs. And I've had enough bad updates from Docker to get jittery when it pushes one on me.
Your company is probably not going to fare well in this thread, but thanks for this! No benchmarking clauses are gross. Glad to see someone with the means to remove one do so.
Or their removal of Docker
Somebody else already did the hard work to get it going with WSL2, why not just cut out the 3rd party you don't need and put it together so the command lines were compatible and your existing tooling works. AWS and Microsoft both have skin in this game and Docker Desktop would be right in their sights.
On something like Debian, you don't even get a desktop gui and you don't miss it either. No reason why WSL2 or a mac shouldn't be exactly the same.
I'd guess a lot of people will just use Docker engine on a Linux VM with the CLI on Windows/Mac as that'll work just fine and is open source.
This was kind of inevitable though, ultimately Docker had to find a revenue stream somewhere. Docker Hub must be massively expensive to run and developing docker's product isn't free either...
This will accelerate those programs
Podman is closest in function to docker engine, which is still open source.
This is why podman, and others are looking to replace the docker engine which while still open source is tainted by the actions of the parent company
They could probably turn this around a bit into a free with Windows, pay for Linux (at the 250 employee level - possibly up the employee count to 500 though).
Isn't Docker Desktop (i.e. the part being sold) just a client that sets up a Linux VM to run the free part?
Maybe this time management will start listening.
Plus, frankly, podman works reliably well in rootless mode, no more messing up with docker in docker, you can be root in you container without needing pretty much any privileged resources.
And since podman 3.x you can use docker-compose just pointing it to the user rootless podman socket.
And podman can start act like a dumb kubernetes and start pods and deployment from the yaml definitions.
Assuming you have docker and ssh running on your remote host:
# point docker on your mac to your remote machine
export DOCKER_HOST=ssh://dude@localhost:5555
# run nginx or whatever you want
docker run -p 8080:80 nginx
# forward the port locally
ssh -L 8080:localhost:8080 -p 5555 jilles@localhost
# open http://localhost:8080 in your browser
Not sure if its still around.
For a ton of small companies (anyone making $10 million or less per year) nothing is going to change and DD is still free to use.
If you're at a big organization with let's say 200 developers chances are your company makes hundreds of millions of dollars a year. Even Docker's most expensive business plan would cost you 200 * $21 = $4,200 month.
Payroll for your 200 developers will likely be over 3 million dollars a month. How can you be upset with paying 4k a month? That's almost nothing relative to other expenses.
Realistically I'm surprised Docker is charging so little for their business plan. Making 4k on 200 developers at a 300 million+ company is not asking a lot.
I want to move out of Docker services because of the "The new terms take effect on August 31, 2021" part of the email I've just received, even if it's followed by a "with a grace period until January 31, 2022".
I'm OK with them trying to get money. I'm not OK with them changing things overnight.
Since it's unclear if / how Docker can enforce their TOS I'm guessing they would be happy to extend it because the other avenues lead to you not using DD or using it without paying.
I think OP's principle is that it will probably just be easier to switch tools than to push the $42k annual spend through the organisational mud to get it approved (depending on how muddy the mud is).
This is particularly true for a single developer that wants to start using docker desktop, if the rest of the org isn't already using it.
This on top of some of the decisions in the past year like removing the ability to opt out of updates, and the issues that pop up when I don't expect it (crashes, file systems, etc) I am more inclined to find other solutions.
There are tiny companies with $10m revenue (remember, revenue isn't margin and certainly isn't profit). A company could easily have non-employment expenses be 90% of its revenue, so we are talking about $1m or 7-8 person company there on decent salaries. A far cry from the 200 devs you give as an example.
However as to "why" - because docker's precise value proposition is its ubiquity and universality. The exact reason people have adopted it is because everyone can run it, no matter who, no matter where. So this compromises the main value proposition of Docker. People will now find alternatives because if I can't distribute my application using docker and know the person at the other end can run it (because now they need a license that they don't have) then it lost virtually its whole point to me.
Can you give a few real world examples where a $10 million / year revenue company with 7 employees would have difficulty paying $147 a month (or $49 if they went for the $7 / month instead)? With the $7 / month plan (if you only care about DD), the entire annual cost for all 7 devs is less than hiring 1 developer for 1 day at a normal US dev salary.
Obviously one payment is not too big but as soon as the policy allows one it allows all such things so its effectively opening the gate to all kinds of micro-payments that quickly build up and become entrenched as "essential".
Here's a similar analogy ... does your company pay for your parking? Why not, its small compared to your salary right? and it definitely helps you get to work, be more efficient etc? Well its not just about the parking its because that represents a class of purchase that if allowed would tilt the scale towards a massive number of similar types of expenses. So in fact most places will have blanked policies disallowing small purchases.
Another question: since the price for Docker Desktop already got arbitrarily changed with no notice, why would you believe that it won't go up in the future? Or get more restrictive in other ways? Once a company executes bad faith one time, continued manifestations of that have to be considered as a risk.
> Another question: since the price for Docker Desktop already got arbitrarily changed with no notice, why would you believe that it won't go up in the future?
Personally, I'll worry about a future notice when it happens. A meteor could wipe out all of humanity tomorrow but I try not to think of "what ifs".
If docker wants to play like this they will need to be willing to partner with a ‘real’ services company who is already on a range of procurement panels to get a foot in the door, at least in my part of the world. If we could pay this as part of our MSA with a vendor we already use, $50k a year wouldn’t be so bad, but adding a new vendor and pushing that uphill? Not likely for us.
"Docker attempting to monetize users of its product who can easily afford the cost." I mean, the terms seems reasonable, and wouldn't you rather support Docker vs IBM (Redhat->Podman)?
Nothing changes for users who aren't making money using Docker, but I suppose you could still spend your time switching to podman on principal.
Solving for the intersection of building and maintaining tools people desire and those building said tools eating and paying rent is hard.
(no affiliation with docker)
> wouldn't you rather support Docker vs IBM (Redhat->Podman)?
Podman is an open source product and Docker is not. I'd much rather support an open source project. And what's wrong with "supporting" IBM anyways? Did they hurt you in some way???
The Docker Engine is Apache License and open source.
They are a dysfunctional consultancy masquerading as a technology firm, running on inertia. They are not to be supported. (Also, my genuine condolences)
https://news.ycombinator.com/item?id=24228972
https://news.ycombinator.com/item?id=26532125
https://news.ycombinator.com/item?id=26869877
https://news.ycombinator.com/item?id=22224782
https://news.ycombinator.com/item?id=23268191
TLDR I want the best experience for my fellow technologists and engineers.
Before Docker Desktop, would need to create VM with Docker and connect to that. Docker Desktop makes that smooth and wraps in nice UI.
Most people like the convenience of that, if not the performance or (now) the cost.
(but, it's possible that what I'm using is also considered Docker Desktop—I just associated that term with their GUI thingy [and I think it includes some kind of sys tray widget?], which I've never used)
[EDIT] oh no you're kinda right, I think I recall having to run one command, post-install, on older versions, to set up the VM, though I don't think you still have to and that was all still handled for you, you just had to tell it to do it. `docker-machine create default` or something like that, was enough for 99% of use cases. Don't have to even do that, now, though, IIRC.
You can install the docker client inside WSL/OSX and connect over SSH to a docker CE instance.
You as a developer won’t be involved with purchasing Docker subscriptions. Instead they’ll have sales teams that approach your IT department who will pay for support reasons and pre install Docker Desktop on all company hardware.
That’s why this is only focused at larger companies. This gives IT departments someone to call when a developer reports a problem.
I’ve been a Mac user for 20 years and do a lot of docker and Kubernetes work. I recently started developing on a Linux machine that was a fourth of the price and a lot less burden for my day-to-day work.
We'll be moving soon given no forthcoming Linux client.
Unfortunately, Docker's most valuable addition, developer environments, is only for two of the three OSes used most commonly by developers in a corporate environment. No company is going to adopt a feature that can only be used by two-thirds of its workforce.
I do have a genuine question though. Can a company just change their pricing structure and make it effective immediately(I understand they have a grace period here)? I guess for free tiers they probably can, because the users have never paid them, but what if I'm a paying customer? Could Docker simply say sorry we have changed our pricing from next billing cycle(or tomorrow) you have to pay 100% more. Could they legally do something like that?
Look at how many complaints there are, and people still use it.
I've been using Docker Desktop for years, and thankfully it's been more stable for the past year or two - before that it was a shitshow.
It works great for me now, but I don't actually need or use any of the GUI features - it's more or less a glorified installer for Docker Engine. Not sure if it has to do any magic for mounting Windows folders to work?
Anyway, curious if it's possible to just run Docker Engine in WSL2 myself, if there are any gotchas, and if mounting Windows folders "just works"?
As someone who uses Docker Hub (the public repos) but not Docker Desktop (their Windows/Mac proprietary apps), it pisses me to have to pay for crap software I don't use nor care about.
Then again, the ecosystem did end up being built to be centralised around on single repository, so we did all kinda buy into this.
If they want to do this, it should have to say in big bold font "this is free for now and we will charge for it later, you will have X months of warning before being required to pay at that time".
In some non-software industries this is already considered illegal behavior: https://en.wikipedia.org/wiki/Dumping_(pricing_policy)
I'd personally even go so far as to say that there should be some legislation around using very cheap loss-inducing prices for extended periods of time to capture the market and then jacking them back up. Like how Ubers used to cost ~30% of what they do now in San Francisco. But that's a lot harder to specify as there are legitimate use cases for sales and loss leaders.
The concerning text written is "Limited image pulls per day". What's the limit here?
We're a small dev team, but it seems like nothing is changing at all for those of us who don't sign in to Docker.
I use docker on linux, mainly executing "docker build", "docker run", etc.
Does it still cost if I do it in a 1k+ company during work?
So if you're on Linux, nothing has changed (yet).
Although that thread was posted earlier, I think we'll merge it into this one, on the principle that corporate press releases tend to make worse HN submissions. This is something of an exception to HN's original source rule.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
No way the company is fronting these costs.
I wonder how sustainable it is for docker to be like other open source entities and rely on consistent donations from major corporations to rely on income.
I also wonder if this will impede on docker adoption in the coming months. I guess time is the only one that can tell
If it isn't already abundantly clear to you: free software isn't sustainable. It's built on the backs of people who provide it for whatever reason they choose.
This be a beggar so I can continue to have free stuff mentality has got to go.
The disappointing part is that a product that was once free and distributed in abundance is now requiring licensing starting immediately for small businesses. There is a transition gap but the policy is effective starting today. There were no added features of value, it was just a random change of price from nothing to something.
I think the new enterprise features that they are boasting about which is probably where they would end up making most of their money could have been suffice as this new policy is going to be difficult for them to enforce.
I'm sure docker desktop originally being free contributed to them being this popular. It made using containers for development super easy on windows and Mac.
Now that they have the huge user base, they're in a good position to dictate terms in their favour whether we like it or not.
Not an installer, and doesn't include docker-compose, but this is what you're talking about, I think.
Only supports Windows containers.
Be warned
The article itself uses "we"
It's plain wrong. You can't refer to yourself as Docker AND as "we"