That’s assuming some kind soul in engineering management has the patience and leverage to guide this through 10 layers of purchasing, procurement, finance, legal etc…
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
I've been fortunate enough to work at companies where engineers were trusted to make small purchasing decisions. It works well for a while, but eventually everyone accumulates a lot of random recurring charges and the company cracks down.
$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.
> requires some juggling of licenses with associated turn-around times
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.
I’ve had this very conversation with work colleagues. We can go through the inordinate-pain of acquiring a licence, and all that entails, or we can choose open-source solution and be making progress by the end of the day.
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.”
What would have happened if Microsoft had put some clause in volume licenses that said "you can use a system unlicensed for up to 30 days before paying for a license".
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.
For non-prod/qa/testing/dev stuff Microsoft provides MSDN/Visual Studio Subscriptions which provide specially licensed versions of their operating systems and software. Everyone who uses the MSDN software must have their own subscription and it can’t be used by real users/customers except in a limited dev/test capacity (e.g. UAT).
One other big factor: certain other vendors have very aggressive sales tactics which essentially boil down to “buy a bunch of stuff you don’t need or we’ll audit every computer in your company and charge a penalty for anything we can find to quibble with”.
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.
The big thing for me is the question of the future: they say they currently won't be predatory about it[1] and I have no reason to doubt that the people saying that are being completely honest, but we don't know who will be working there in the future or where the next acquisition/merger will take them.
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.
Some years back I tried to pay the $50 for the VBox extensions - small company and I was the only user. They were very confused, almost like they couldn’t understand that I really wanted to pay for something that I judged good value for the money.
They ended up telling me to forget about it.
I guess that perhaps they only want to target large businesses.
Our company has a lot of processes that could be streamlined via containerization of build and development environments, across Windows, Mac, and Linux.
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.
Someone making $250k/year shouldn't think twice dropping $21/month on a tool that truly makes them more productive.
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.
Because it establishes an exploitative precedent that shouldn't be followed. Because it hides the true cost of a project, which may result in poor decisions later on. Because the cost of a decision/process should fall on the person or company who has the ability to change it. Because using wages to pay for business expenses wasn't part of the employment agreement. Any one of these would suffice.
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.
> Because it establishes an exploitative precedent that shouldn't be followed.
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.
Except that's not the issue being discussed here. Expecting to pay for software development isn't a bad thing. Expecting the employee to pay out of pocket for business expenses is the exploitative behavior.
The problem is that there's simply no easy fix for these bureaucratic frictions and sub-optimal equilibriums. It's the nature of large organizations--they trade efficiencies in some areas for inefficiencies in others.
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.
It's not about $x a month, it's about the friction of dropping any money at all. It could be 10c/year and still annoy everyone, because now they have to go through a procurement process, find someone with a company credit card, wrangle with reimbursement forms, etc.
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.
This 1000x developers are lazy and generally don't want go throug bureaucratic hassle. Long run this just going to hurt docker when developers start using podman or some other free alternative.
A couple comments earlier people were talking about where does this stop, 1000$ a month? A 3D CAD license with the ability to do FEA is around 30 grand a year, I’ve seen seats of specialized software cost north of 100k a year per seat, and that’s for people that 100k is probably pretty close to their take home.
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.
So ignoring holidays, $250k/yr works out to $120/hr.
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.
For companies it's not that easy though. Employees will accumulate services and don't cancel them, will leave without leaving any info on which services were bought for what purposes etc.
Companies still need proper invoices and account for all charges. If they cannot accomplish this because employees forgot they bought services or have left without letting anyone know, the company is on the hook for it.
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.
As someone who went from the PA suburbs and small IT shops (where 75k was a premium salary) to the SF startup scene and Facebook, one of the observations that has stuck with me was the incredible cheapness of my wealthy tech peers. It's hard to explain unless you've been around people who do a whole lot more with a whole lot less.
A simple local k8s installation with a simple but effective GUI on top, running containerd instead of docker and with a CLI wrapper for docker commands, would be more than enough for everything I need.
It's almost as if a manager or engineer shouldn't manage the overall finances of a company or department... Gee, I wonder if there's a job title or something like that that could manage finances like this?
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.
This poster has clearly worked at the same kind of companies I have. Plenty of them would gladly burn 10x what it would cost to just buy the damn license on engineering man-hours switching something that's inferior but free. Because it doesn't show up as an expense on the annual budget.
The concept of opportunity cost is completely lost on a lot of business leaders.
A lot of the driver here is not in the moment short-sightedness, but rather a byproduct of the procurement or other finance processes (ironically often instituted with intent to prevent waste and fraud or make the company more efficient).
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.)
I suspect that most people running at the kind of scale where purchasing is hugely problematic are also running Artifactory or similar, not using Docker Hub.
If someone suggests a tool that costs $1k/yr over a free tool that costs $5k/year in extra work, I’m going to die on the free tool hill. Because the $1k/yr tool will disappear when the company goes defunct, or it won’t interoperate with something else and there is no way of fixing it. Or it can’t migrate to the next tool. Or we need to upgrade to an enterprise license because we become 21 developers instead of 20. Or they just bump
the cost to
$20k for whatever reason. Or the tool won’t work on CI servers because it only works after entering a key in an attended install (yes this is still a thing).
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.
I think he means free as in open source, rather than free as in freeware. In which the worst case scenario is that you are stuck with the last open-source version, but at least you retain full control over your fork of the code and can add features and bug fixes as you see fit.
Then I'll find the fork and use that. We have already done that a few times. There is a reason we audit all the licenses of open source software we have.
Exactly. I've never understood why capital or cash expense costs are valued so much differently than salary costs. I've had jobs (like any manager) where I have complete leeway on how I "spend" millions of dollars of people's time, but had to to through all kinds of approval to spend even the smallest amount of money.
Another example is if I want a $100 keyboard I need ahead of time VP sign off for the non-standard expense, if I want $10000/mo extra in AWS services I need any other engineer to approve my change
Yeah, that's what we decided when figuring this out at our company. Everyone is spending thousands of dollars a month of the company's money (their time). We either trust them to spend our money wisely, or we don't (and they should work elsewhere). So we don't have all these policies. Having said that, these policies are a result of size. You wouldn't spend money poorly when the company is just you and four friends in a garage. But when you're big enough, hiring problematic people is absolutely going to happen and they just see the company's money as a free money pot. We're in a middle ground right now, but, as we grow, are finding it hard to avoid trending more towards the meme corporate policies.
- 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 path dependency whereby various practices turn into processes, regulations and laws. On top of this narratives form that guide peoples thinking as to what the right financial decisions are, then people can start to believe these narratives over time without questioning them. Eventually companies can create certain processes or habits on the basis that those narratives need to be true: https://www.epsilontheory.com/what-do-we-need-to-be-true/
A big advantage of using free open source software is that the licensing prices will never increase because the company needs a new revenue stream to support its business model.
Docker Desktop was free, now it's $21/month, what will it cost next year when Docker needs more money?
Licensing prices might not increase, but paid technical support costs could theoretically be unlimited. Especially if you're at the mercy of an open-source software that isn't well-maintained.
The 4 hours I spent learning the basics of d3 and then couple hours a night for a few weeks working through examples (of others and of my own design) really gave me a powerful new tool for charting applications. Rolling your own is difficult to justify, but "learn and use d3 (BSD licensed)" seems an entirely reasonable alternative to a high-priced commercial offering.
> The concept of opportunity cost is completely lost on a lot of business leaders.
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.
Heh heh... so true it hurts. Why spend 3 years pushing it past risks reviews and oversight committees when you could just write a crappy version that does what you need?
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.
> trying to negotiate absurd concessions from vendors in situations where they clearly have no bargaining power
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.
Yep, I’ve been there, I was a consultant in London charging 700 pounds a day, and my hands were tied because of a silly 50 USD license expense and couldn’t work for a month.
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.
Perhaps you're not understanding corporate bureaucracy. Nobody wants to be the manager who gets fired for trying to save $25k by switching from Docker Desktop to {insert random open source project here}. Not only is it not worth the time or the risk, but the engineering manager's exact purpose is to traverse the corporate bureaucracy. It gives them job security. Plus the engineering manager can negotiate big discounts with the vendor and can brag about that on their own performance reviews.
That is not the point he was making. It's about wanting to get the licenses procured but the process being unreasonably laborious so people just don't bother. The problem isn't cost, it's the mess of corporate wastelands.
It's not the manager, it's some department somewhere else that'll take weeks to respond and then you'll have to chat with them about it and they'll be like "i don't see why this is necessary"
It's very impactful though, it'll probably be people seeing it as highly visible and career-advancing who manage to muster the 'patience and leverage'.
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.
Easier method to deal with monthly payment...Create a purchase order with 12 lines. One line for each month with dollar amounts defined. The purchase order serves as the "approval" so Accounts Payable can process without asking for coding information.
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.
You can drill through layers of that crap if you can sell something through aws marketplace or equivalent thing that your company is already set up to spend millions a month.
Not sure how would that work for a desktop tool. It's in them to figure that out though
Entirely depends on the organization, I used to think this too but then I encountered some organizations (granted ones with entirely dysfunctional procurement processes) where switching technologies was easier and less risky to schedules than going down the procurement process. The risk of missing deadlines and blowing out schedules is the factor that tends to be on people's minds when procurement is brutally slow.
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.
S/O changed the way that revenue was recognized when a vendor sold product and services to implement. Basically, you had to wait until the implementation services were completed to recognize product revenue. Time to complete services could be multi-year and customer dependent.
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