Summary: I raise some follow-up points to yesterday's post on community-governed packaging efforts.
The problem with conda-forge today
As discussed in my blog post yesterday, conda-forge may offer the way forward to create a community-governed package repository that meets the standards already established in the Linux, R, and other open source communities.
The single biggest problem with conda-forge right now is that its hosting of
build artifacts depends on closed source software and a proprietary hosting
service, anaconda.org (formerly binstar.org). To continue the Linux
analogy, it would be as if software for creating
yum package repos
were closed source. It's much better than not having any hosting service
available, but it would be better to have a option available that is open
source and under community governance. You can see how this works in the
Debian / Ubuntu ecosystem, for example.
The same type of software used to create anaconda.org and the on-premises product analogue (which Continuum sells to enterprises to run on their own servers -- so their own closed-source software can be conda-installed behind firewalls) is also needed to create a network of publicly available package mirrors. See R's CRAN mirror network for an example of what this might look like.
Solving the community-governed binary packaging problem completely requires the non-trivial task of creating an open source conda build artifact server in addition to the problem of operating shared build and test infrastructure.