5 ms·

>Yet another reason not to put telemetry in your software. Can you explain a bit more your way of though? How should you decide what to support if not having t

by dwild 7y ago

>Yet another reason not to put telemetry in your software. Can you explain a bit more your way of though? How should you decide what to support if not having the information from your user? The only other alternative is to ask, and then only the one that answer will get supported, which sure is great for the one that answer, but that may means a much bigger audience that you won't support even though they need to be supported.

yellowapple 7y ago
> The only other alternative is to ask I see nothing wrong with that.
- dwild 7y ago
  ... nothing wrong with what followed? Why did you just quote the beginning when I cite a pretty good argument afterward and you don't even argue with it? We are on Hacker News please, be more thorough and defends your point.
  - yellowapple 7y ago
    > .. nothing wrong with what followed? Nope. > Why did you just quote the beginning Because the rest can be extrapolated from it. > We are on Hacker News please So? Just because we happen to be on Y Combinator's corporate propaganda machine doesn't mean I'm any more compelled to respond to things about which I care not.
JohnFen 7y ago
> How should you decide what to support if not having the information from your user? There are many well-known and largely perfected methods of getting that information without the use of telemetry. The thing that general telemetry really brings is cost savings and convenience. But it also brings a peculiar kind of blindness as well, since companies largely stopped doing product research that isn't telemetry.
- simion314 7y ago
  >There are many well-known and largely perfected methods of getting that information without the use of telemetry. Can you link to a few of this many known methods? I am interested in ones that would fit open source projects that have no budgets for research. Thanks
  - JohnFen 7y ago
    Just look at how product development worked before telemetry was a thing that was possible, and how its done in other industries. This isn't hidden information.
    - simion314 7y ago
      OK, so you have no idea but you speak like you have plenty solutions. What I know of are things like Debian - https://popcon.debian.org https://popcon.debian.org , Ubuntu's https://wiki.ubuntu.com/Apport https://wiki.ubuntu.com/Apport , Fedora's https://docs.fedoraproject.org/en-US/Fedora/13/html/Deployment_Guide/ch-abrt.html https://docs.fedoraproject.org/en-US/Fedora/13/html/Deployme...
  - gdfasfklshg4 7y ago
    Telemetry is 100% not a viable fit for an open source project. A very significant proportion of your potential users will either keep it disabled or if that is not possible (which would be illegal in the EU anyway) not use your software. Just ask your users.
    - dwild 7y ago
      > A very significant proportion of your potential users will either keep it disabled Then they made the conscious choice that their usage won't get known and thus be aware that another way of communication will have to be used. > Just ask your users. "A very significant proportion of your potential users" won't tell what they want, or won't even know what they want. The one that will be the most vocal won't necessarily be the voice of reasons either.

by dwild 7y ago

yellowapple 7y ago

> The only other alternative is to ask I see nothing wrong with that.

dwild 7y ago
... nothing wrong with what followed? Why did you just quote the beginning when I cite a pretty good argument afterward and you don't even argue with it? We are on Hacker News please, be more thorough and defends your point.
- yellowapple 7y ago
  > .. nothing wrong with what followed? Nope. > Why did you just quote the beginning Because the rest can be extrapolated from it. > We are on Hacker News please So? Just because we happen to be on Y Combinator's corporate propaganda machine doesn't mean I'm any more compelled to respond to things about which I care not.

JohnFen 7y ago

> How should you decide what to support if not having the information from your user? There are many well-known and largely perfected methods of getting that information without the use of telemetry. The thing that general telemetry really brings is cost savings and convenience. But it also brings a peculiar kind of blindness as well, since companies largely stopped doing product research that isn't telemetry.

simion314 7y ago
>There are many well-known and largely perfected methods of getting that information without the use of telemetry. Can you link to a few of this many known methods? I am interested in ones that would fit open source projects that have no budgets for research. Thanks
- JohnFen 7y ago
  Just look at how product development worked before telemetry was a thing that was possible, and how its done in other industries. This isn't hidden information.
  - simion314 7y ago
    OK, so you have no idea but you speak like you have plenty solutions. What I know of are things like Debian - https://popcon.debian.org https://popcon.debian.org , Ubuntu's https://wiki.ubuntu.com/Apport https://wiki.ubuntu.com/Apport , Fedora's https://docs.fedoraproject.org/en-US/Fedora/13/html/Deployment_Guide/ch-abrt.html https://docs.fedoraproject.org/en-US/Fedora/13/html/Deployme...
- gdfasfklshg4 7y ago
  Telemetry is 100% not a viable fit for an open source project. A very significant proportion of your potential users will either keep it disabled or if that is not possible (which would be illegal in the EU anyway) not use your software. Just ask your users.
  - dwild 7y ago
    > A very significant proportion of your potential users will either keep it disabled Then they made the conscious choice that their usage won't get known and thus be aware that another way of communication will have to be used. > Just ask your users. "A very significant proportion of your potential users" won't tell what they want, or won't even know what they want. The one that will be the most vocal won't necessarily be the voice of reasons either.