6 ms·

Personally I find this unacceptable. It’s ok to do it within your own company environment, but not for a public open-source project. This is a slippery slope f

Personally I find this unacceptable. It’s ok to do it within your own company environment, but not for a public open-source project. This is a slippery slope for “understanding more about our users” and I challenge anyone to show a meaningful improvement that derived from telemetry of this kind. There are better ways to figure out how a project is used without harming privacy (ex: analyzers like BuiltWith). Projects doing this should get a red mark to discourage it.

JohnFen 4y ago
I actually think it would be OK if the telemetry were opt-in. At this point, I'd even settle for just having the software actually warn you about the data collection on first use.
- ikiris 4y ago
  you opt in by using the product. especially if its open source.
  - teej 4y ago
    Tracking my usage was never part of the social contract of OSS. This post is a reminder of that.
    - martypitt 4y ago
      What social contract is that? As far as I'm aware, the contract of OSS is "you can fork this to change it, if you don't like it" (license permitting). A big part of the reason people advocate for OSS is so they can read the source code to understand what's going on, and change the parts they don't like. Telemtry sits squarely under that usecase. I agree that it's good manners for projects made users aware of telemetry, but there's no "contract" that implies they have to.
      - JohnFen 4y ago
        He was talking about the social contract, not the license. OSS is a community that has mores, expectations, and social contracts like any other community. Spying is very much in opposition to that social contract.
  - JohnFen 4y ago
    If you haven't provided informed consent, you haven't opted in.
    - ikiris 4y ago
      Ahh fair, I was under the impression this was disclosed telemetry.
- barnabee 4y ago
  I agree opt in telemetry (with no dark patterns, nagging, etc.) is fine. We do this (even then, strictly for non personaly identifiable crash/error reporting only), and I would encourage everyone who isn't a friend/family of the team, close community member, investor, etc. not to opt in. It isn't necessary. (Though having a small number of tens of people from those groups who do opt in is reasonably useful.)
mark242 4y ago
> I challenge anyone to show a meaningful improvement that derived from telemetry of this kind Which features of our software are people using, and where do we need to concentrate the most with our limited resources and bandwidth to provide our users the best possible experience. What are the biggest build- and run-time errors, and are they a result of the developer experience, and can we fix this through either better documentation or better error messaging. What are the paths to successful adoption of our software, and can we nudge potential users (through documentation or developer outreach) to get on one of those paths. We polled our users and they said that they want feature A, but our usage data shows that a vast majority of our users need feature B to be more successful faster. Our software is used most often with other-tool-A. Can we strike up an agreement with the team that makes A, in order to give our users a better experience when integrating both tools through documentation, tighter API integrations, etc.
- wootland 4y ago
  > Which features of our software are people using, and where do we need to concentrate the most with our limited resources and bandwidth to provide our users the best possible experience. The best possible experience starts with not being spied on, especially against my consent. No feature is worth that. > What are the biggest build- and run-time errors, and are they a result of the developer experience, and can we fix this through either better documentation or better error messaging. Make it easy to report bugs. This is a solved problem (c.f. any popular open source application). > What are the paths to successful adoption of our software, and can we nudge potential users (through documentation or developer outreach) to get on one of those paths. As a user, I never want to be "nudged". Ever. Do not "outreach" to me especially if you've made the decision to contact me by spying on my data. > We polled our users and they said that they want feature A, but our usage data shows that a vast majority of our users need feature B to be more successful faster. So your users told you what they wanted and you didn't give it to them and justified the decision based on analytics. This is where people say that analytics are good for the product manager's job in helping justify its existence but at the expense of the users. > Our software is used most often with other-tool-A. Can we strike up an agreement with the team that makes A, in order to give our users a better experience when integrating both tools through documentation, tighter API integrations, etc. Create great solutions. If that means doing biz dev or integrations to make that happen, go for it. You do not need to spy on your users to build meaningful partnerships.
ikiris 4y ago
As long as its disclosed I have a hard time with the pearl clutching going on over this. If you don't like something the maintainer of an OSS product is doing, fork it or don't use it.

JohnFen 4y ago

I actually think it would be OK if the telemetry were opt-in. At this point, I'd even settle for just having the software actually warn you about the data collection on first use.

ikiris 4y ago
you opt in by using the product. especially if its open source.
- teej 4y ago
  Tracking my usage was never part of the social contract of OSS. This post is a reminder of that.
  - martypitt 4y ago
    What social contract is that? As far as I'm aware, the contract of OSS is "you can fork this to change it, if you don't like it" (license permitting). A big part of the reason people advocate for OSS is so they can read the source code to understand what's going on, and change the parts they don't like. Telemtry sits squarely under that usecase. I agree that it's good manners for projects made users aware of telemetry, but there's no "contract" that implies they have to.
    - JohnFen 4y ago
      He was talking about the social contract, not the license. OSS is a community that has mores, expectations, and social contracts like any other community. Spying is very much in opposition to that social contract.
- JohnFen 4y ago
  If you haven't provided informed consent, you haven't opted in.
  - ikiris 4y ago
    Ahh fair, I was under the impression this was disclosed telemetry.
barnabee 4y ago
I agree opt in telemetry (with no dark patterns, nagging, etc.) is fine. We do this (even then, strictly for non personaly identifiable crash/error reporting only), and I would encourage everyone who isn't a friend/family of the team, close community member, investor, etc. not to opt in. It isn't necessary. (Though having a small number of tens of people from those groups who do opt in is reasonably useful.)

mark242 4y ago

> I challenge anyone to show a meaningful improvement that derived from telemetry of this kind Which features of our software are people using, and where do we need to concentrate the most with our limited resources and bandwidth to provide our users the best possible experience. What are the biggest build- and run-time errors, and are they a result of the developer experience, and can we fix this through either better documentation or better error messaging. What are the paths to successful adoption of our software, and can we nudge potential users (through documentation or developer outreach) to get on one of those paths. We polled our users and they said that they want feature A, but our usage data shows that a vast majority of our users need feature B to be more successful faster. Our software is used most often with other-tool-A. Can we strike up an agreement with the team that makes A, in order to give our users a better experience when integrating both tools through documentation, tighter API integrations, etc.

wootland 4y ago
> Which features of our software are people using, and where do we need to concentrate the most with our limited resources and bandwidth to provide our users the best possible experience. The best possible experience starts with not being spied on, especially against my consent. No feature is worth that. > What are the biggest build- and run-time errors, and are they a result of the developer experience, and can we fix this through either better documentation or better error messaging. Make it easy to report bugs. This is a solved problem (c.f. any popular open source application). > What are the paths to successful adoption of our software, and can we nudge potential users (through documentation or developer outreach) to get on one of those paths. As a user, I never want to be "nudged". Ever. Do not "outreach" to me especially if you've made the decision to contact me by spying on my data. > We polled our users and they said that they want feature A, but our usage data shows that a vast majority of our users need feature B to be more successful faster. So your users told you what they wanted and you didn't give it to them and justified the decision based on analytics. This is where people say that analytics are good for the product manager's job in helping justify its existence but at the expense of the users. > Our software is used most often with other-tool-A. Can we strike up an agreement with the team that makes A, in order to give our users a better experience when integrating both tools through documentation, tighter API integrations, etc. Create great solutions. If that means doing biz dev or integrations to make that happen, go for it. You do not need to spy on your users to build meaningful partnerships.

ikiris 4y ago

As long as its disclosed I have a hard time with the pearl clutching going on over this. If you don't like something the maintainer of an OSS product is doing, fork it or don't use it.