I’m reposting my comment from the PR in case folks haven’t read it, then I want to address some of the points in this thread so far.
—
I wanted to add some clarity around why we plan to include the census package. Recently, we were looking at Meteor usage statistics and realized that given our existing telemetry we can only identify about 20% of apps using Meteor. That means a large fraction of our usage comes from apps that we know absolutely nothing about.
This is less than ideal as knowing who our users are and how they’re using our platform helps us make informed decisions towards creating a great Meteor roadmap. The insight gained from better telemetry results in a roadmap that increases worldwide Meteor adoption (which helps everyone in the community - more contributors, more add-ons/services, more talent, more jobs). For instance, knowing what breakdown of apps are built by enterprises vs startups vs individuals allows us to tailor our learning materials, tutorials, features and commercial offerings accordingly. Knowing what scale folks use Meteor at (by collecting the maxSessions stat - https://github.com/meteor/meteor/pull/6469/files#diff-a7c6c405e95f7fbaeac0c4645b12c77eR27) informs us on how much engineering resources to allocate towards scaling/performance.
Ultimately, we’re doing this to benefit everyone in the community by gathering objective data that informs where to spend our resources in the most impactful way. The difficult decision lies in where to strike the balance between the package being too intrusive but useful vs being friendly but useless.
@laosb I like your suggestion of explicitly notifying users that we’ve added the package.
—
First off, I want to say I think we put the cart before the horse here by writing the code and opening the PR before engaging the community first. We’re an engineering driven company and sometimes code is easier to write than prose. We won’t make that mistake again. The immediate point of this package is perfectly summed up by @rozzzly when they said “The sense I get is MDG want’s to know who is using meteor and for what kinds of apps. That way they can gauge their audience.” . To that end, the most important pieces of data we’d like to gather are rootUrl, maxSessions and version (Meteor’s).
The challenge that I alluded to in my comment on the PR is to have enough people be comfortable with providing this data for it to be useful. If 80% of apps remain in the shadows we haven’t really achieved anything.
Having said that, we absolutely do not want users to be unaware that we’re collecting this data. Further, it should be trivial for users who do not want to give us the data to opt-out. It’s the users in the middle who don’t much care either way whom we would really want to encourage to opt-in - any ideas on the best way to do this would be appreciated.
Now to specific questions/concerns:
You should make the package opt-in via a prompted Y/N
We figured providing a clear message when running meteor create that the package had been added and where to read more about it as well as instructions for removing it (meteor remove census) would suffice. The reasons we thought this was better was:
a) It’s less friction than having to pause, think and press a key everytime you create an app.
b) meteor create can still be run from scripts without the need to add further complexity by introducing additional command line flags.
c) This way those users who are indifferent towards providing the census data are less likely to opt-out as it would mean typing another command.
What information is being sent?
The data we’re proposing to send is here. We’ll add more documentation on exactly what this stuff means and why we’re sending it.
You shouldn’t be sending my server’s ip.
This data was included unintentionally, we’re going to remove it.
You should open-source the data.
Actually, this was our intention all along. We plan on building infographics and writing about the findings we glean from the data. We hadn’t intended to open-up public access to the database - this is in interesting idea though. Would people be comfortable with it? It’s kind of like the actual census data. We’re all comfortable with providing it, the results are public and in fact very useful to everyone - but it might be not be a great idea if people could look up the data based on street address.
Where is the source code?
The source code currently lives in this PR. Once merged it will live in the mainline Meteor repository.
Thanks to everyone for participating in this thread. I appreciate your feedback and want to stress that we’re not out to ship something that’s going to alienate the community.
but I digress.
Those mediums, the community members are great, but that doesn’t mean MDG can’t aim to do better.