Hacker News new | past | comments | ask | show | jobs | submit login

One thing I've learned about software in general is that I never want to be outside of the primary use case. If you're not using it the same way that the people building it do, it's going to be a pain to use, and your requests will be ignored.

For me, 1Password wifi syncing (with local vaults) never worked quite right, and I don't think that feature has been touched by its developers in all the years since I first bought a 1Password license. It's never going to be. They're all in on their own cloud service and subscriptions.

I don't hate 1Password for using subscriptions -- that's their prerogative -- but I wish I'd known they were going to bail on the Mac-as-digital-hub architecture. That was 100% why I bought it.

I'd describe that pivot, too, as a communications breakdown.




> One thing I've learned about software in general is that I never want to be outside of the primary use case. If you're not using it the same way that the people building it do, it's going to be a pain to use, and your requests will be ignored.

While this might be true in general, one of the main advantages in choosing FOSS is that features used by a small subset of users are more likely to be kept than for proprietary software.

When a software package starts out, early-adopting power users build its popularity and help shape its growth ... until the package becomes so useful that it is now marketable to the masses. Then, for proprietary software at least, there's a strong incentive to streamline and remove anything the masses don't care about...which can alienate the same people who helped make their package great.

For FOSS, there's powerful motiviation to retain features that even only a handful of power users rely on -- lest that project be forked.

I can't remember the last time I've been feature-burned by a FOSS project. My feature-burn scars for proprietary software, however, are many -- and at least a few are quite deep.


> I can't remember the last time I've been feature-burned by a FOSS project.

The GNOME project comes to mind as free software which regularly feature-burns their users, arguing that people who really needed the feature can monkey-patch their DE's javascript to add it back in.

You're right though, most FOSS seems way less likely to remove features people actually depend on that most proprietary software.


It has been over a decade, and I don’t even use GNOME anymore, and I am still pissed at the way GNOME did their great purge in the 2.x release.


You don't need a subscription though. You can still sync through iCloud (i use iOS & macOS), without a subscription.


To be honest, if they're going to do stuff like that they shouldn't be offering those features at all.

Developers should stick to implementing features they're likely to maintain.


Local vault syncing over Wi-Fi was one of the core supported workflows back in the day.


> One thing I've learned about software in general is that I never want to be outside of the primary use case. If you're not using it the same way that the people building it do, it's going to be a pain to use, and your requests will be ignored.

If there is an obscure setting somewhere which makes something work well for you while you become a minority of users in the process, you would not use it?


GP said:

>I never want to be outside of the primary use case.

You've extrapolated too far from their statement. Most people have probably been in this kind of situation and most of us have probably been burned by it at some point: Use a product for an edge case of its intended function and you risk losing that functionality at some point.

Vendors will generally cater for the masses. Where possible, avoid building your usage model around niche features. Assume that free products/features are a loss leader and will disappear at some point. Have a contingency plan if the at-risk feature is particularly important to you.


Such setting is pretty much guaranteed to be disabled in some future update. See: Mozilla Firefox.


> Mozilla Firefox

Depending on what you mean by "in some future update" and "pretty much guaranteed" (given an infinite timespan everything will disappear) I don't think that's true. I've kept my Firefox user.js (my manual about:config changes) under git over the past 3 years[0], and of the 44 options that I customised, 36 are still present and (seem[1] to be) active.

6 of the about:config user_prefs customised add-ons, so they no longer work due to the shift to Webextensions (but I can still make 5 of the customisations via another interface).

1 customised the GCLI, which was removed, and 1 customised Panorama, which was also removed. (However, most of what GCLI did, can be done some other way, and there are a couple of Webextensions faithfully emulating Panorama.)

[0] The file is older, but I added it to git only three years ago. Hence, many of the about:config changes have been "alive" for longer, but I have no record of those that were removed earlier than 3 years ago.

[1] Cursorily glancing through my comments above each entry to make sure that it still does what it was supposed to.




Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: