Hey Chris, What about the following alternative suggestion to alleviate some of the underlying issues you point out. I agree we are signaling badly which packages are interesting to newcomers and outsiders and which packages aren't. In part we've already done the damage with the packages in the "zope.*" namespace. I think we shouldn't try to put humpty-dumpty back together again marketing-wise by removing those packages a few years after their release, and whether this is worth the effort (and I see negative drawbacks to doing so). What we can do is start to clearly indicate on top of a package's documentation whether it's intended to be independently reusable outside of a Zope context or not. We should do this on pypi, but we should also back this up by writing narrative documentation for those packages we *do* think are independently reusable by a wide audience. I think this should be done by starting 'doc' directories in those packages and putting in sphinx-based documentation. The next step would be to go to our "non-reusable" packages and start writing narrative docs for that, ideally with example projects. If we pick a few likely candidates and do some more refactoring we may be able to salvage them into reusable packages and we can declare them as such. As indications I propose: "This package is intended to be independently reusable in any Python project. It is maintained by the Zope Toolkit project." (with hopefully appended: "For more documentation on this see <narrative docs>.") "This package is at present not reusable without depending on a large chunk of the Zope Toolkit and its assumptions. It is maintained by the Zope Toolkit project." We can also add 'reusable' to the metadata tags in PyPI in addition to this. Regards, Martijn