3 ms·

If you mean with "you" the operator of the tool, then yes I agree partially. But in this context it's more like "you" the user and then using open source altern

by ascar 7y ago

If you mean with "you" the operator of the tool, then yes I agree partially. But in this context it's more like "you" the user and then using open source alternatives doesn't make a big difference. Updates (which you generally want for security/good features/fixes/x) will still break your workflow regularly. It's about how the service handles change (e.g. options to use the old interface etc.) that make the difference and not open source or proprietary. There are many examples in FOSS that made user interfaces arguably worse and you have a hard time dealing with it, if you still need/want to run the newer version for other reasons.

joepie91_ 7y ago
It being open-source (under your control) or not does make a difference here. In an open-source thing, with this sort of productivity-harming breakage, you could worst-case just pay a random freelancer to fix it for you. You don't have that option with Slack.
- acdha 7y ago
  That’s how you end up with critical apps which are full of known security issues because now upgrading requires reverse-engineering and migrating a bunch of one-off customizations. This approach only works if you’re committed to paying regularly to maintain your fork.
  - woodrowbarlow 7y ago
    or upstream your fixes
    - gizmo686 7y ago
      That only works if upstream wants your fixes.
      - eythian 7y ago
        Then you have the proprietary problem again, only worse as then you can't make the fixes.
  - joepie91_ 7y ago
    I did say "worst-case". And as another commenter suggested, upstream your fixes.
    - acdha 7y ago
      “upstream your fixes” only works if the upstream wants them. If you charge in saying “you're all dummies (per OP); here's a patch which goes against your project direction which I want you to maintain in the future”, that's probably not going to be very successful.
xenorplxx 7y ago
Exactly that. There was an interview with Basecamp founder here a few days ago and he highlighted that even now when the current version is Basecamp 3 they still maintain Basecamp 1 for clients who don't want to make the change.

by ascar 7y ago

joepie91_ 7y ago

It being open-source (under your control) or not does make a difference here. In an open-source thing, with this sort of productivity-harming breakage, you could worst-case just pay a random freelancer to fix it for you. You don't have that option with Slack.

acdha 7y ago
That’s how you end up with critical apps which are full of known security issues because now upgrading requires reverse-engineering and migrating a bunch of one-off customizations. This approach only works if you’re committed to paying regularly to maintain your fork.
- woodrowbarlow 7y ago
  or upstream your fixes
  - gizmo686 7y ago
    That only works if upstream wants your fixes.
    - eythian 7y ago
      Then you have the proprietary problem again, only worse as then you can't make the fixes.
- joepie91_ 7y ago
  I did say "worst-case". And as another commenter suggested, upstream your fixes.
  - acdha 7y ago
    “upstream your fixes” only works if the upstream wants them. If you charge in saying “you're all dummies (per OP); here's a patch which goes against your project direction which I want you to maintain in the future”, that's probably not going to be very successful.

xenorplxx 7y ago

Exactly that. There was an interview with Basecamp founder here a few days ago and he highlighted that even now when the current version is Basecamp 3 they still maintain Basecamp 1 for clients who don't want to make the change.