3 ms·

I wonder if this was good intentions by some developers getting subverted by an unaligned leadership ethos? (panicked? too $ focused? not enough user advocacy?

I wonder if this was good intentions by some developers getting subverted by an unaligned leadership ethos? (panicked? too $ focused? not enough user advocacy? no idea!) I can easily imagine a few meetings that went something like this: 1. Security engineer meetings: "Flipping to default-on for automatic updates has been a major win for ~billions of people to help them mitigate the steady stream of 0-days exploiting gnarly web browser internals. Docker adoption isn't at that level but still big, and the individuals are pretty important. We should try it for our community too!" 2. Sales & CEO: "A ha, amazing! We can turn this into a $ win too. We've been needing more $ and conversion triggers for our install base now that we sold the enterprise business. Anyone with docker desktop on for > 2w is effectively a qualified leading with this, and this might finally tip them over to paid! $5/mo is nothing and this is just annoying enough that it might do it! (And if a developer won't pay for that, they're a freeloader / 1% / ... who'd never pay anyways...)" 3. PMs + designers + marketing + other user advocates responsible for trialing & trust: "Wait a minute! For their core workflows, developers need to easily control the versions of their tools in their environment. Messing with that willy-nilly for system version #'s breaks brand trust for our paid conversions!" 4. Sales & CEO: "Maybe. Let's try it and see. Overruled in the name of business experiments, and we can reverse course if it's too damaging!"

t0mas88 6y ago
That's the majority Hacker News kind of opinion "Sales or the CEO fucked it up for the engineers" but another likely explanation is that the main source of frustration (forced updates for everyone) came from the engineering side because most developers hate maintaining older versions. Then someone said "you can't do that to enterprise customers, they demand to pick their own versions" which resulted in this button for the paid version.
- lmeyerov 6y ago
  I'm agreeing with you here for the first part: that's another great well-meaning dev explanation. The ball-dropping is sales/product/leadership not being aligned on user advocacy. "Our velocity & sales > breaking user environments" means either the former is overly prioritized, or the people making decisions are too far from users (developers) to understand their daily needs. Managing docker versions for dev/prod drift isn't "1% of devs 99% of the time" but "99% of devs 1% of the time", so it's a real miss. In an alternate org where the user advocates lead might look more like: * <reject early on the current feature plan proposal as user hostile and instead...> * free: default to auto-update (or not) * free: flip * pay ("Pro"): one-click to switch to another version, both forwards & backwards * pay ("Enterprise"): centrally managed update schedule, version tracking, audit logs, etc. for all devs in your org Folks there are some of the best, so I'm sure most of this was considered, and thus it's an org/process problem
- ratww 6y ago
  This is a desktop app, so there's no need for engineering to maintain older versions. They can just ask users to upgrade to the latest before opening support inquiries. They can even deprecate old web endpoints if they want, and again ask users to upgrade to continue using.

t0mas88 6y ago

That's the majority Hacker News kind of opinion "Sales or the CEO fucked it up for the engineers" but another likely explanation is that the main source of frustration (forced updates for everyone) came from the engineering side because most developers hate maintaining older versions. Then someone said "you can't do that to enterprise customers, they demand to pick their own versions" which resulted in this button for the paid version.

lmeyerov 6y ago
I'm agreeing with you here for the first part: that's another great well-meaning dev explanation. The ball-dropping is sales/product/leadership not being aligned on user advocacy. "Our velocity & sales > breaking user environments" means either the former is overly prioritized, or the people making decisions are too far from users (developers) to understand their daily needs. Managing docker versions for dev/prod drift isn't "1% of devs 99% of the time" but "99% of devs 1% of the time", so it's a real miss. In an alternate org where the user advocates lead might look more like: * <reject early on the current feature plan proposal as user hostile and instead...> * free: default to auto-update (or not) * free: flip * pay ("Pro"): one-click to switch to another version, both forwards & backwards * pay ("Enterprise"): centrally managed update schedule, version tracking, audit logs, etc. for all devs in your org Folks there are some of the best, so I'm sure most of this was considered, and thus it's an org/process problem
ratww 6y ago
This is a desktop app, so there's no need for engineering to maintain older versions. They can just ask users to upgrade to the latest before opening support inquiries. They can even deprecate old web endpoints if they want, and again ask users to upgrade to continue using.