In July, I opened Bug 413169 to start a discussion regarding the creation of a “call home” policy for Eclipse projects. The work-in-progress document for the policy is on the Eclipsepedia wiki.
A phone with a cord. How quaint. 2006 called, they want their… uh… phone back.
The policy is intended to cover projects that need to call home; that is, any project that needs to send a heartbeat, gather usage statistics, harvest data from a user’s workstation, or otherwise collect information from user installations. Privacy is a big concern for everybody, so I feel that it’s important that we get this right.
There are some issues here that I think are critical.
Users need to know what we’re doing. Any user, with reasonable effort, must be able to understand–regardless of the sorts of information being sent–what the call home service is doing. The mechanism used and the nature of any data being transported needs to be well documented. Any call home should be initiated by the user themselves or by an authorized automated process. Further, users must opt-in to participate in any automated process. There is some debate on the bug regarding whether this option is opt-in or opt-out (at this point-in-time, I am firmly of the opinion that it must be opt-in).
The Eclipse Privacy policy must be honoured. I think that this is obvious.
Any solution must be vendor-neutral. The requirement for vendor neutrality is baked into the Eclipse Bylaws and culture. Essentially, any implementation of a call home mechanism must operate along the same “level playing field” rules as everything else at Eclipse. In practical terms, this means that only Eclipse Foundation servers can be contacted by any call home service running in code shipped by an Eclipse Foundation project. A call home mechanism can, of course, be designed to be extended by adopters to contact whatever server they desire as part of a product based on project code.
We mustn’t look goofy. My nightmare scenario is that we have a dozen projects all implementing different call home services that all pop up dialog boxes at random times to ask the user if it’s okay to contact an Eclipse Foundation server with some bit of data. This is just an example of what I mean by “goofy”. The user experience needs to be carefully managed, but we also need to gracefully handle, for example, cases where use has limited bandwidth or no Internet access.
In my mind, it falls within the responsibility of each project’s Project Management Committee (PMC) to review and approve the implementation of any call home services. Some involvement and approval from the Eclipse Webmaster is also a pretty natural requirement, as the Webmaster team will be the responsible for keeping the target server(s) running.
We already have a pretty good group of people discussing the evolving policy, but it’d be nice to have a few more people sanity check what we’re doing. I’m pretty steadfast about the opt-in requirement, for example, but only because that’s my perception of what the community wants and expects. It’d sure be nice to know if I’m wrong.
