[zhengt]

In addition to crashes, we also want to know things like: which features people are using so we can invest more in them, how much people are using the app so we know if we're doing in a good job.

Totally understand if you're not comfortable with that though! It will be removed when Warp is out of the beta test.

[db48x]

I know it sounds logical to you, but the further down that road you go the worse your software will be in the end. Make software with a coherent vision and you can pick and choose features based on how will they fit that vision without needing to spy on your users, or turn it into a popularity contest.

Incidentally, you might be interested to know that in the last 8 hours my comment has gotten 25 upvotes; that’s a lot of lost customers.

[NateEag]

> Incidentally, you might be interested to know that in the last 8 hours my comment has gotten 25 upvotes; that’s a lot of lost customers.

No, that's a lot of people who upvoted your comment.

I'd wager anyone who agrees with your perspective is unlikely to have been a Warp customer in the first place.

(Speaking as one who tends towards your side of this discussion.)

[db48x]

I don’t mean that my comment cost them customers, only that the upvotes on my comment measures the customers they had already lost by using pervasive telemetry.

[NateEag]

I doubt that even a plurality of the people who upvoted you would have installed Warp and wound up paying for it.

[chillfox]

I hate telemetry driven development.

It just results in loosing infrequently used but important features. First it gets moved from a button to a menu, then to a sub-menu and eventually removed.

[db48x]

Exactly. I prefer Emacs–style programs where the number of features grows without end, and everyone customizes the UI and keybindings to make the features they like best easiest to use. Every time someone thinks of a new way that Emacs can make their life easier they can add it to Emacs immediately, without asking for permission or even sending in a pull request. Later, if they think the feature is polished enough and others might find it useful, they can send a pull request either to Emacs or to the Emacs Lisp Package Archive (ELPA), or to MELPA (should they not like the minor licensing restrictions on ELPA), or just post it on EmacsWiki or their blog or Facebook page or whatever for others to copy from.

But for that to work you have to start with something that is both very extensible, and yet is also coherently designed. The extensibility has to be a strong part of that initial design, so that the software is designed to be malleable.