7 ms·

I'm astonished by the pushback from the Docker devs on this. rflay, ThomasNegeli, and Nuru did heroic work by gently and thoroughly explaining why mandatory, au

I'm astonished by the pushback from the Docker devs on this. rflay, ThomasNegeli, and Nuru did heroic work by gently and thoroughly explaining why mandatory, automatic updates are unacceptable for a dev tool. I would not have been so patient. The fact that they had to hold the maintainers hands through this is disappointing. "it's a feature request not a bug" shows Stephen did not even understand the problem he introduced. Either that, or he didn't read all the comments before him.

phendrenad2 6y ago
This is how you get forked. They're risking the business on some dumb dark pattern here.
- nvllsvm 6y ago
  Unfortunately not straight-forward with Docker Desktop as it's closed-source. Sure, underlying components are open source, but I've seen no other effort to glue them together in a cohesive, single-purpose package like Docker Desktop.
  - eyelidlessness 6y ago
    This is also the kind of thing that drives people to create the alternative.
- kelnos 6y ago
  How is that a dark pattern? Are you going to say that Chrome and Firefox auto-updates are a dark pattern too? Keeping people on the latest version of your software has very clear benefits to both you and your users. Unfortunately, as we see here, it can also have downsides. Ultimately it's up to the developer to decide what trade off works best for them. Input from users is important, but it's not the users' decision.
MattGaiser 6y ago
I wonder if that discussion already occurred in Docker and now they are simply messengers executing something already decided. I've had the position of saying that something desired will not be done with the only thing I could honestly say without airing private disagreements being "reasons", as the person I was talking to knew I also didn't think it made sense. Deflecting with vague statements has also been a tactic I have used, hoping that they would not persist.
- kenniskrag 6y ago
  it is planned to let the user decide according to the issue.
- NullPrefix 6y ago
  Can't you just give a straight answer saying that the suggested idea will not be considered further due to company policy?
  - dmatech 6y ago
    No, because that puts company management in the crosshairs. You don't let some developer do that without first getting the spin machine time to come up with a reason why it's good for the users. Otherwise people question the vendor's ability to provide the product they want.
    - edoceo 6y ago
      This whole page is full of folks who are currently questioning the vendors ability (or am I misreading something?). That does seem like a problem that should put focus on the management.
      - MattGaiser 6y ago
        > That does seem like a problem that should put focus on the management. That's what all of us who have ever had to go out and work around annoying decisions want you to realize.
chias 6y ago
> "it's a feature request not a bug" shows Stephen did not even understand the problem he introduced. He clarifies a little bit further down the thread: > It's not a bug because it's working exactly as designed. We're very aware that you regard it as a misdesign. If a project / community has adopted specific definitions for given words such as "bug", "feature request", etc., then IMO you should not get mad at people for using them as defined. You may feel strongly that the auto-updating feature is a terrible idea in application, and you may even disagree with this project's decision to define a "bug" as "something that isn't working as designed", and that's fine. But I don't think it suggests that Stephen does not understand the issue, or did not read the thread.
- p1necone 6y ago
  I think that's a silly definition of a bug. If it breaks the product, it's a bug. It doesn't matter if it was created at dev time or design time. Hell, a huge chunk of dev work is rethinking design decisions that are misguided/under specified/break things because you only see these issues once you start having to implement details.
- lopatin 6y ago
  "bug" vs "feature" is a silly debate about semantics until someone uses it as a justification to push back releasing a fix. Bugs get fixed immediately, but feature requests can wait. And also, who says that mis-designed features aren't bugs? In this case, they designed a bug, and shipped it.
  - jameshart 6y ago
    Introducing an entirely new user-facing dialog option into the upgrade install flow doesn't sound like a 'bug fix' to me in any system. That's completely new UX, localization, security concerns, documentation... Autoupgrading might totally be a misfeature for your usecase, but it's how this program works. If you don't want it to do that, then uninstall it.
    - lopatin 6y ago
danaliv 6y ago
Seriously. Before I made it to the part where they agreed to stop auto-updating, I was on the third revision/toning-down of the comment I was writing in my head. I get that having multiple versions in the wild makes support more difficult, but what's more important in a dev tool: your support workload, or your users' control over their configuration management?
- kelnos 6y ago
  As someone who maintains an open source development tool that I work on in my spare time and don't get paid for, reducing my support workload is absolutely more important to me. You'd be surprised at the amount of time I waste asking people to try to reproduce an issue on the latest version, and when they do, their issue goes away. Unfortunately an auto-update feature for my tool isn't feasible, but if it were, I'd add it in a heartbeat. If that would turn some people off on it, I'm fine with that. On a side note, I see plenty of developers click the "Remind Me Later" button over and over and over on the update dialog for their dev tools (and even OS). As a pathological example, I noticed one of my coworkers running a 3-year-old version of IntelliJ IDEA recently when he shared his screen on a Zoom call. But people who don't even install patch updates for months is common as well.
  - utborin 6y ago
    That's fine for something a person is working on in their spare time, but when it's a multi-million dollar company whose mission statement is "we simplify the lives of developers who are making world-changing apps," I think it's fair to have different expectations.
  - dragonwriter 6y ago
    > As someone who maintains an open source development tool that I work on in my spare time and don't get paid for, reducing my support workload is absolutely more important to me. Docker Desktop is produced by a for-profit company, and while it is free of charge itself, it is a key customer-facing part of an ecosystem Docker monetizes by selling subscriptions to services which it leverages. It's not some solo developer’s spare time project, and if Docker wants to be a viable business, it won't be treated like one.
kelnos 6y ago
On the flip side, supporting old versions is often very difficult and time-consuming. For an open-source project I maintain, sometimes I feel like I spend more time asking people to upgrade to the latest version (which often fixes the issue someone has) than I do helping people with legitimate issues. (I exaggerate, but it's a not-insignificant drain on my time.) If these people are paying for Docker Desktop, then, sure, maybe they're entitled to upgrades and support on their terms. But if they're not, I'm completely sympathetic toward developers trying to reduce their (unpaid) support burden. Yes, this might turn people off and hinder adoption, but that's their choice to make.
karlshea 6y ago
I’ve gotten/gave help and lurked on the ddev Slack—Randy Fay has the patience and helpfulness of a saint.
inshadows 6y ago
Yep. There's a growing desire of even open source projects to shove updates down your throat without any recourse for you as user. I see such software as trojan horse. Developers argue that you need much needed updates with security fixes, etc. Which is of course true. But there's no justification for denying user the freedom of controlling when to update. EDIT: But seeing this in Docker doesn't surprise me at all. It's this kind of project that knows better than you. Compare this with general purpose tools such as SSH, Git, gcc. There's nothing special about projects like Docker and Snap and they will get eventually replaced by projects that expose more knobs to fit (private) use cases of other users.

phendrenad2 6y ago

This is how you get forked. They're risking the business on some dumb dark pattern here.

nvllsvm 6y ago
Unfortunately not straight-forward with Docker Desktop as it's closed-source. Sure, underlying components are open source, but I've seen no other effort to glue them together in a cohesive, single-purpose package like Docker Desktop.
- eyelidlessness 6y ago
  This is also the kind of thing that drives people to create the alternative.
kelnos 6y ago
How is that a dark pattern? Are you going to say that Chrome and Firefox auto-updates are a dark pattern too? Keeping people on the latest version of your software has very clear benefits to both you and your users. Unfortunately, as we see here, it can also have downsides. Ultimately it's up to the developer to decide what trade off works best for them. Input from users is important, but it's not the users' decision.

MattGaiser 6y ago

I wonder if that discussion already occurred in Docker and now they are simply messengers executing something already decided. I've had the position of saying that something desired will not be done with the only thing I could honestly say without airing private disagreements being "reasons", as the person I was talking to knew I also didn't think it made sense. Deflecting with vague statements has also been a tactic I have used, hoping that they would not persist.

kenniskrag 6y ago
it is planned to let the user decide according to the issue.
NullPrefix 6y ago
Can't you just give a straight answer saying that the suggested idea will not be considered further due to company policy?
- dmatech 6y ago
  No, because that puts company management in the crosshairs. You don't let some developer do that without first getting the spin machine time to come up with a reason why it's good for the users. Otherwise people question the vendor's ability to provide the product they want.
  - edoceo 6y ago
    This whole page is full of folks who are currently questioning the vendors ability (or am I misreading something?). That does seem like a problem that should put focus on the management.
    - MattGaiser 6y ago
      > That does seem like a problem that should put focus on the management. That's what all of us who have ever had to go out and work around annoying decisions want you to realize.

chias 6y ago

> "it's a feature request not a bug" shows Stephen did not even understand the problem he introduced. He clarifies a little bit further down the thread: > It's not a bug because it's working exactly as designed. We're very aware that you regard it as a misdesign. If a project / community has adopted specific definitions for given words such as "bug", "feature request", etc., then IMO you should not get mad at people for using them as defined. You may feel strongly that the auto-updating feature is a terrible idea in application, and you may even disagree with this project's decision to define a "bug" as "something that isn't working as designed", and that's fine. But I don't think it suggests that Stephen does not understand the issue, or did not read the thread.

p1necone 6y ago
I think that's a silly definition of a bug. If it breaks the product, it's a bug. It doesn't matter if it was created at dev time or design time. Hell, a huge chunk of dev work is rethinking design decisions that are misguided/under specified/break things because you only see these issues once you start having to implement details.
lopatin 6y ago
"bug" vs "feature" is a silly debate about semantics until someone uses it as a justification to push back releasing a fix. Bugs get fixed immediately, but feature requests can wait. And also, who says that mis-designed features aren't bugs? In this case, they designed a bug, and shipped it.
- jameshart 6y ago
  Introducing an entirely new user-facing dialog option into the upgrade install flow doesn't sound like a 'bug fix' to me in any system. That's completely new UX, localization, security concerns, documentation... Autoupgrading might totally be a misfeature for your usecase, but it's how this program works. If you don't want it to do that, then uninstall it.
  - lopatin 6y ago

danaliv 6y ago

Seriously. Before I made it to the part where they agreed to stop auto-updating, I was on the third revision/toning-down of the comment I was writing in my head. I get that having multiple versions in the wild makes support more difficult, but what's more important in a dev tool: your support workload, or your users' control over their configuration management?

kelnos 6y ago
As someone who maintains an open source development tool that I work on in my spare time and don't get paid for, reducing my support workload is absolutely more important to me. You'd be surprised at the amount of time I waste asking people to try to reproduce an issue on the latest version, and when they do, their issue goes away. Unfortunately an auto-update feature for my tool isn't feasible, but if it were, I'd add it in a heartbeat. If that would turn some people off on it, I'm fine with that. On a side note, I see plenty of developers click the "Remind Me Later" button over and over and over on the update dialog for their dev tools (and even OS). As a pathological example, I noticed one of my coworkers running a 3-year-old version of IntelliJ IDEA recently when he shared his screen on a Zoom call. But people who don't even install patch updates for months is common as well.
- utborin 6y ago
  That's fine for something a person is working on in their spare time, but when it's a multi-million dollar company whose mission statement is "we simplify the lives of developers who are making world-changing apps," I think it's fair to have different expectations.
- dragonwriter 6y ago
  > As someone who maintains an open source development tool that I work on in my spare time and don't get paid for, reducing my support workload is absolutely more important to me. Docker Desktop is produced by a for-profit company, and while it is free of charge itself, it is a key customer-facing part of an ecosystem Docker monetizes by selling subscriptions to services which it leverages. It's not some solo developer’s spare time project, and if Docker wants to be a viable business, it won't be treated like one.

kelnos 6y ago

On the flip side, supporting old versions is often very difficult and time-consuming. For an open-source project I maintain, sometimes I feel like I spend more time asking people to upgrade to the latest version (which often fixes the issue someone has) than I do helping people with legitimate issues. (I exaggerate, but it's a not-insignificant drain on my time.) If these people are paying for Docker Desktop, then, sure, maybe they're entitled to upgrades and support on their terms. But if they're not, I'm completely sympathetic toward developers trying to reduce their (unpaid) support burden. Yes, this might turn people off and hinder adoption, but that's their choice to make.

karlshea 6y ago

I’ve gotten/gave help and lurked on the ddev Slack—Randy Fay has the patience and helpfulness of a saint.

inshadows 6y ago

Yep. There's a growing desire of even open source projects to shove updates down your throat without any recourse for you as user. I see such software as trojan horse. Developers argue that you need much needed updates with security fixes, etc. Which is of course true. But there's no justification for denying user the freedom of controlling when to update. EDIT: But seeing this in Docker doesn't surprise me at all. It's this kind of project that knows better than you. Compare this with general purpose tools such as SSH, Git, gcc. There's nothing special about projects like Docker and Snap and they will get eventually replaced by projects that expose more knobs to fit (private) use cases of other users.