Hacker News Reader

Comment by ascar | Hacker News Reader

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.

View on HN

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.

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.

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.

or upstream your fixes

That only works if upstream wants your fixes.

Then you have the proprietary problem again, only worse as then you can't make the fixes.

I did say "worst-case". And as another commenter suggested, upstream your fixes.

“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.

Reply on news.ycombinator.com