4 ms·

Hey - in general, yes, we do talk to our Users on a regular about the product (in fact, I first participated in the research session, and only after that decide

Hey - in general, yes, we do talk to our Users on a regular about the product (in fact, I first participated in the research session, and only after that decided to join the company). I assume you're asking specifically about discussing telemetry and open source, not only the features. We try to be super open about collecting the data, and published an extensive list of things we report. Most of our users don't mind. Those that did, messaged us directly about it and shared their feedback. Some even decided to trust us after exchanging emails, talking to the team and seeing us improving the messaging based on their feedback. Regarding open source - it is not just a vague promise. We do have plans on doing it, many team members joined the company because they want to contribute to the community. We actively discuss this topic with our community on Discord and Github. I'm personally super excited about our UI framework, and can't wait until we open it up to other people (we recently added some a11y support, which is super cool and not as common among the Rust frameworks). Here's the github discussion for more context: https://github.com/warpdotdev/Warp/discussions/400 https://github.com/warpdotdev/Warp/discussions/400 However, we understand that our current mode of operation won't (and honestly, can't) please everyone, so it's not surprising that there are people who don't agree with this approach.

nlh 5y ago
Thank you for answering! So it really just sounds like an impedance mismatch between Warp and the HN crowd.
maxloh 5y ago
Will Wrap licensed under a FOSS license (any of those approved by OSI or FSF) after being open sourced?
sitkack 5y ago
> Some even decided to trust us You could also be that special someone to trust us. Let's trust each other.
xenadu02 5y ago
Why did you not just make telemetry and logins opt-in? That avoids the entire issue from day one. I think that's what is giving people a strange feeling about this. You prioritized your own desires (not needs mind you) rather than your users. And if your thinking is so off that you really think these are needs during the beta then that is even more worrying. If I were in your shoes I'd crunch immediately to make telemetry, crash reporting, and logging in three separate opt-in features then get a build out ASAP. Prompt people to enable or disable each with clear language in a single screen (no EULAs or lawyer weasel words) and no dark patterns (like double-negative checkboxes or flipping cancel and accept button colors). For crash reports and logins there is an even better way to handle this that is respectful of your users without being obtrusive and shows you are working hard to earn trust. Then you only need one post-install prompt to ask permission to share data which is much simpler. 1. Ask the user each time you find a crash report and let them inspect it if they want to do so, then ONLY send the content the user inspected (no hidden payloads, extra HTTP headers, etc). Include a checkbox/dropdown "Always send" or "Never send". The default is to ask the user to help you out. It gives transparency by letting them inspect the entire payload. And if/when you've earned their trust they will click Always on their own. It also covers you just in case the payload accidentally picks up something sensitive. 2. When the user invokes a feature that actually needs a login then prompt them at that time. Or if the context doesn't allow that, show an unobtrusive icon, link, or banner in a context-appropriate way that lets them create an account or login. 3. For sharing let users share things anonymously with links, no account required. Once they've started using the feature let them know they can create an account to "claim" the things they've shared. This can be a good way to show people the benefits rather than just claiming benefits exist. It makes a nice on-ramp without pestering or annoying people who never create an account. And the people they share things with may end up becoming your users.
- jasonlotito 5y ago
  > Why did you not just make telemetry and logins opt-in? While I'm not them, I can answer this. Users did ask for this as much as they asked for other things. > You prioritized your own desires (not needs mind you) rather than your users. That's an awfully big assumption to make, and one that does not conform to reality.

nlh 5y ago

Thank you for answering! So it really just sounds like an impedance mismatch between Warp and the HN crowd.

maxloh 5y ago

Will Wrap licensed under a FOSS license (any of those approved by OSI or FSF) after being open sourced?

sitkack 5y ago

> Some even decided to trust us You could also be that special someone to trust us. Let's trust each other.

xenadu02 5y ago

Why did you not just make telemetry and logins opt-in? That avoids the entire issue from day one. I think that's what is giving people a strange feeling about this. You prioritized your own desires (not needs mind you) rather than your users. And if your thinking is so off that you really think these are needs during the beta then that is even more worrying. If I were in your shoes I'd crunch immediately to make telemetry, crash reporting, and logging in three separate opt-in features then get a build out ASAP. Prompt people to enable or disable each with clear language in a single screen (no EULAs or lawyer weasel words) and no dark patterns (like double-negative checkboxes or flipping cancel and accept button colors). For crash reports and logins there is an even better way to handle this that is respectful of your users without being obtrusive and shows you are working hard to earn trust. Then you only need one post-install prompt to ask permission to share data which is much simpler. 1. Ask the user each time you find a crash report and let them inspect it if they want to do so, then ONLY send the content the user inspected (no hidden payloads, extra HTTP headers, etc). Include a checkbox/dropdown "Always send" or "Never send". The default is to ask the user to help you out. It gives transparency by letting them inspect the entire payload. And if/when you've earned their trust they will click Always on their own. It also covers you just in case the payload accidentally picks up something sensitive. 2. When the user invokes a feature that actually needs a login then prompt them at that time. Or if the context doesn't allow that, show an unobtrusive icon, link, or banner in a context-appropriate way that lets them create an account or login. 3. For sharing let users share things anonymously with links, no account required. Once they've started using the feature let them know they can create an account to "claim" the things they've shared. This can be a good way to show people the benefits rather than just claiming benefits exist. It makes a nice on-ramp without pestering or annoying people who never create an account. And the people they share things with may end up becoming your users.

jasonlotito 5y ago
> Why did you not just make telemetry and logins opt-in? While I'm not them, I can answer this. Users did ask for this as much as they asked for other things. > You prioritized your own desires (not needs mind you) rather than your users. That's an awfully big assumption to make, and one that does not conform to reality.