I certainly see the value of telemetry in being able to produce a higher
quality product through understanding user behavior. However, I am not
sure it is realistic. My clients are very conscious of intellectual
property and data privacy concerns, and for some of them, even discussing
the possibility of allowing telemetry in any part of the technology stack
would damage their trust in me. Even if there were an easy opt-out
feature, I would be very concerned that I or someone on my team would
accidentally build client code without opting out, and I would have to take
serious steps to ensure that this could never occur.
I would be thrilled, of course, if such analyses could be easily performed
against publicly available code on Hackage, as many tests have done in the
past. This would also provide an additional small incentive for people to
open source code that they do not have a strategic need to keep secret.
MarLinn's idea sounds like a good approach to me, although I agree that it
has difficulties. I think the key would be to make the report produced
brief, human-readable, and clear enough that a CTO or other executive could
easily sign off on "declassifying" it. We could then ask that companies
voluntarily submit this report if they wish to have an impact on
prioritizing the future of the language. I suppose this is a very strict
version of "opt-in", and generally I think that opt-in would be fine, as
long as we're very confident that we'll never have a bug that makes it
opt-out instead.
Ryan
On Fri, Dec 9, 2016 at 12:13 PM, MarLinn via ghc-devs
Pretty random idea: What if ghc exposed measurement points for performance and telemetry, but a separate tool would handle the read-out, configuration, upload etc. That would keep the telemetry from being built-in, while still being a way to get *some* information.
Such a support tool might be interesting for other projects, too, or even for slightly different use cases like monitoring servers. The question is if such a tool would bring enough benefit to enough projects for buy-in and to attract contributors. And just separating it doesn't solve the underlying issues of course, so attracting contributors and buy-in might be even harder than it already is for "normal" projects. Close ties to ghc might improve that, but I doubt how big such an effect would be.
Additionally, this approach would just shift many of the questions over to Haskell-platform and/or Stack instead of addressing them – or even further, on that volatile front-line space where inner-community conflict roared recently. It wouldn't be the worst place to address them, but I would hesitate to throw yet another potential point of contention onto that burned field.
Basically: I like that idea, but I might just have proven it fruitless anyway.
Cheers, MarLinn _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs