And I definitely don't like the business incentives subscription models generally create when it comes to standalone software development (as opposed to a server-based service), and so far the major moves to them I have experienced (such as Adobe's) have reinforced my concerns. While in the short term individual personalities can of course do whatever, I think in the medium to long term it's very hard for development direction to stay divorced from whatever the direct economic incentives of the business model are. In turn thinking about that is one of the more important factors in thinking about to what degree a company can be depended on over the years. Because:
1. Humans have a strong tendency to favor the status quo unless there is a disruption (HN crowd likely deals with this frequently, such as with the immense power of defaults in UI design).
2. Low constant noise triggers less consideration then occasional larger spikes, even if the former adds up to more in the same time period.
3. There is direct loss associated with stopping.
4. Lock-in increases.
subscriptions are well known to be a lot stickier and less sensitive to stagnating software, pricing changes, etc., then per-version purchases are. Companies can put out "being able to focus on the longer term!" but fundamentally subscriptions remove a significant form of customer-oriented hard discipline and incentives. Some devs might be able to continue the same without it, but many clearly cannot. And I want to emphasize that this isn't at all necessarily because of any maliciousness or even greed, no "haha now we have them where we want them". It's just that a lot of humans will lose focus without some sort of hard-to-subvert, reasonably fast outside feedback loop. Subscriptions also encourage feature development and testing towards a single vertical ecosystem, even if other approaches would be perfectly viable.
AgileBits says they're keeping standalone licenses, but I see nothing about reasonable feature parity. I also agree that one of the best ways to assuage concerns is full honesty, including acknowledging obvious conflicts of interest, and in that light I agree it would have been valuable to see at least something about how this boosts their revenue, and how they're aware of the risk of making standalone licenses second class citizens and will watch for it. They've been a solid company and made a solid product overall however, so I'm willing to give them the benefit of the doubt here for now. It'd be a shame if they ultimately do go sub-only at some point, even if data can be trivially dumped to other programs.
Maybe by that time though progress will be made on finally getting websites away from password authentication entirely and in turn PMs can be rendered mostly a historical artifact.
As as an aside, though I think this blog is aimed at a general audience there are a few misunderstandings that are significant, since they're not that complex but feed misunderstandings. For example:
>In the 1Password app's sync model, however, one assumes they use the pretty-secure HTTPS-based APIs for each of these products, machine to machine, no JavaScript in the loop.
The author himself correct states that in 1Password's (or KeePass or any other client based encrypted database setup) case they're using purely offline-app endpoint encryption, and part of the entire point of that is that the transport mechanism is irrelevant. There is no need to trust anything beyond what exists on the endpoint. This matters because it relates to some of the other concern points he raises, not just cloud storage location but for example "backdoor code in a future 1Password app release that sends the goodies to the enemies". An endpoint password manager that allows abstracting sync from the application itself, at least optionally, in turn can be isolated from any net access (and/or any attempts monitored) which reduces that threat profile as well.
----
1. Effectively a mediocre reimplementation of public key auth on top of 90s-era website authentication practices that have proved sticky.