In the last blog post, I described how to export a Plone site using collective.
Historically the Plone Collective has been a collaboration spaces for open-source projects in the field of Plone. The Collective was hosted for a long time on the SVN infrastructure of the Plone Foundation. For long time this model worked sufficiently good because free source code hosting options beside Sourceforge have been rare.
With the rise of Github and Bitbucket and the growing popularity of GIT the Plone Collective switched to Github last year or so.
The question that arises nowadays: do we need the Collective as shared repository anymore?
- Everyone can have free repositories on Github or Bitbucket.
- Everyone can contribute to existing packages and projects by forking and sending pull requests - this is actually the same development model used in the collective.
- The package maintainers keep full control over its own packages and sources.
- No more unwanted or uncontrolled checkins by other persons.
- No more arbitrary removal of packages based on constructed or pretended offense (see here for the discussion on the removal of collective.milf).
- Your code and your repository is in the end under the control (or perhaps better: under the supervision) of the Plone Foundation.
- A common shared repository for most(?) Plone add-ons gives an better overview about what packages are available.
- Repository limits: I assume that the Plone Foundation has some agreement with Github for hosting this amount of repositories under a free plan or under special conditions. As standard Github member you are usually constrained by their free plan (which has not been a problem for me in reality - even with a larger number of repositories)
Every package maintainer must decide for itself which level of control over your code is better for you: I either you comply with the Plone Foundation and their views or risk the arbitrary removal of packages or just keep the code in your hand.