Why do we want "distributions" (whether 'sumo' or domain specific) in the first place? Obviously because we have some pains to alleviate, but I think Linux distributions, particularly Ubuntu, have been coping with similar pains for a while now with good results. I used to be rather informed on the state of Linux distributions circa the end of the 90's. Should I use this distribution or that one? Now I don't care, the answer is always 'Ubuntu, and apt-get it to fit your needs'.

The pain list, as I see it:

(a) Make it easy to find functionality that you'd typically be tempted to implement alone

(b) Make it trivial, mind boggling easy, to add this functionality to your interpreter once you know of it

(b.1) Make it easy to package a Python 'distribution' so end users don't need to muck around with (b)

(c) Make it easy for software to specify its requirements in code and get them mostly automagically

(d) Make it *legally* least painful to acquire and use endorsed functionality sets

 ... (pipe in if I missed something important)

I'm wondering if expanding the efforts in Python packaging ("easy_install" and PEP376 comes to mind, only on steroids) isn't the correct solution for alleviating these pains in a much better fashion. I'm not saying it's easy, but I think that superb packaging technologies are a very well proven technology, that they're well within the community's capabilities/needs and that maximizing flexibility is a move in a better direction than creating one or two or seven 'distributions'.

I hope you would intuitively grasp what I mean, even if I fail to articulate it well, if you ever used dpkg and apt-get (or equivalents), along with the ability to add sources and the simple distinctions between sources (core vs. universe vs. multiverse), along with eco systems like launchpad and PPAs, etc. To my 1999 self these features of Ubuntu seem like miracles, not so much because Debian and dpkg/apt-get weren't there back then (they were life saving back then too), but because of the whole system's huge support base and centrally-designed decentrally-implemented nature. 'apt-cache search' is usually how I find new software these days, and the same could be true for Python when I need futures or multiprocessing or whatever. I could write lots about what I think we should have in such a system, but maybe it's more befitting for python-ideas or a blog post than here; for this argument, 'mirror Ubuntu's winnage' is a good enough description. I think a good and lively packaging system beats 'distributions' any day. 

This leaves us only with the legal pain, which I felt harshly on my flesh following some acquisition by a corporation and it's painful and frustrating and mostly unreasonable. I suspect, though I'm a legal n00b (and proud of it), that packaging in multiple repositories like Ubuntu does could help a lot, along with taking some responsibility over the most recommended repo (candidates are the 'almost made it into stdlib' packages, maybe even the giants like Django, NumPy, TurboGears, Twisted, etc). This is not about development responsibility and surely not about taking legal liability, it's about actively helping facilitate these packages' use in hostile legal environments. While the hackers in the trenches working on trunk and py3k may not care much (and probably needn't care much), I humbly think the PSF may care more and is best equipped to help. Maybe by requiring certain licenses for 'recommended' repo inclusion, maybe by working with the likes of Google or IBM on publishing legal reviews of select Python distributions, I don't know, depends what would help a corporate lawyer make speedy approval.

 - Yaniv