The one-repo-for-old-projects solution works in some cases, but not really for mine. As a contract developer I often have projects that are under active development for a few months and then go into "maintenance mode". In this case I want separate repos for when maintenance needs to happen. Otherwise that one repo is a mess.

I believe this is the kind of problem that CodePlane solves. And I agree with you that its great to see projects like this present competition and make GitHub better in the long run.

It's a hack of course, but if the changes are really that occasional, the pain is negligible: all you need to do is to commit twice for every project change (once for a sub-directory containing the project repo, once for the root repo).

If a project becomes active again, simply take it out of the master repo and push it as a new repo.

It's really not that bad. But then again, things change if you have collaborators...

Can't you just use branches for this? Sugar code (git.sugarlabs.org) generally gets a new branch for each major release, which can be maintained separately from master.

I like this business model better. You pay for what you use, not how you use it. Its moving away from the Microsoft plan of "to use this for business you must pay me double".

Its like a ford salesman asking you about how you plan on using your ford focus, oh you will be driving to work? Highway driving costs you 50% extra. Sorry. You can take our back-alley car for cheap though.

as arturadib mentioned, you can make the "old-projects" repo. But that's just a hack/workaround for a wrong business model. Though I am sure this business model is much more profitable.

I wanted to solve both problems. I have 40+ repos, but about 50% are archives only. So, with 2GB I can store them and I also work on my current projects.