Track who installed what ports on what OS and on what

[Ryan Schmidt]

On May 13, 2007, at 22:06, Norman MacIntyre wrote:

> That is a bad idea. What purpose would it serve other
> than collecting statistics and curiosity?
>
> Let me know when you do this so I can immediately use
> only fink.

I see! Well, that's two people vehemently opposed so far. :)  
Interesting.

For comparison, it's far from unprecedented for programs to send  
statistical information to their developers when they check for  
updates. The popular text editors BBEdit and TextWrangler from Bare  
Bones Software do this, for example, as does the venerable dock  
utility DragThing. As I recall, they all ask for the user's  
permission before doing so, and explain exactly what data is sent; we  
could do that too. Even Software Update sends Apple a list of the  
Apple software you have installed, so that it can deliver to you a  
list of applicable updates. And it does that without your permission,  
and it's on by default, too.

The purpose for collecting this data is obvious: it allows the  
developers to learn what kinds of machines and OS versions their  
users are using, which can help the developers decide where to focus  
their resources. In the case of MacPorts, it's fairly obvious that we  
will have PowerPC users running 10.3.x and 10.4.x and Intel users on  
10.4.x. Maybe some 10.5.x testers too. What's less obvious is what  
ports people are using. And by collecting that information, we would  
not only help the port authors learn which of their ports are  
actually getting used, but also help users gauge a port's  
reliability. If a user is interested in a port and sees that hundreds  
of others have successfully installed it, there's a good chance it  
works. If nobody has installed it, or nobody with the user's  
processor architecture or OS version has installed it, there may be  
problems.

If I wasn't clear before, I should also clarify that no personal  
information about the user would be stored -- username, email  
address, IP address: none of that. And it is not the intention to  
display a list of any individual user's active ports, only to sum up  
totals of active ports. However, I have to admit the system would  
need to store the lists of the users' active ports in order to  
compute the totals. And maybe that's a concern, since the information  
could be obtained by determined individuals with access.

Perhaps I should explain what led to my initial email. In working on  
a redesign for the MacPorts web site, I thought it would be nice to  
include a box of popular ports in a sidebar, like so:

-------------- next part --------------
Skipped content of type multipart/appledouble-------------- next part --------------

My data here is clearly made up, but it illustrates the idea. If we  
tracked who installed what ports and on what processor, we could  
generate an accurate graph of the above, and similarly for OS versions.

What I didn't do in the example above, but what I would want to do,  
is show only "interesting" ports. I would say ports like pkg-config  
and apr-util aren't "interesting" because they're merely dependencies  
of other ports. You wouldn't install apr-util just by itself; apr- 
util isn't the end goal. Other larger ports like apache2 are the end  
goal, and that's the kind of port I would show in the graph. If I  
could find a good way to identify the "interesting" ports.

But perhaps this entire graph isn't so interesting, ultimately.  
Presumably if you're looking at MacPorts, you have a specific  
software package in mind that you're wanting to install, and don't  
need a graph of what everyone else is installing. I guess I was  
thinking of something like Apple's Dashboard widget download site,  
where they show you a list of today's top widget downloads. Same idea.

If we don't do this graph, I would still like some extra info on the  
MacPorts home page, something to show new users what they can do with  
MacPorts. Something to draw them in. Maybe just a list of the most  
recently updated ports and their versions would do. That would be  
easier, too, since I can already pull that information from the  
repository.