I’m hosting my Python stuff at Bitbucket since early 2009
(with the oldest repo created on 2009-02-20).

Bitbucket is a great alternative to Github: it provides unlimited free
private repositories (including sanely defined conditions for teams);
it supports both Mercurial and Git. Pull requests and many other features
popular on Github are also present. Why would one want to move from
this excellent SaaS to another one, equally non-free?

Two things: Community and CI.

Community

Github is no doubt more popular, even being inferiour to Bitbucket is some
aspects. Maybe because it was the first Google Code killer; or maybe because
Bitbucket was a “github for Mercurial” until it became clear that Git was the
choice of the majority and the niche was occupied. I don’t think features or
usability matter that much.

A popular code hosting service means a huge community.

There were cases (definitely more than one) when people would register on
Bitbucket only to file an issue; who knows how many times they simply wouldn’t
bother to register. Also, their contributions were of lower quality because
they were unfamiliar with the site and the VCS. They could add a pull request
but they failed to figure out how to do it and simply posted an issue
(hopefully with a patch).

Bitbucket is by no means a marginal service. Nevertheless, by hosting
my active projects there I prevented them from receiving a certain amount
of care from the community. It is also possible that some developers simply
missed them while searching on GH.

Continuous Integration

This was actually the migration trigger for me. I was waiting and waiting
for an adequate CI solution available for Bitbucket. A simple solution that
just works, you know. And that’s free because I’m not going to pay for such a
service if its sole purpose is to test software that I support without any
monetary profit (haven’t got not a single cent, actually — and never tried).

The only thing that I could find recently for BB was drone.io. It’s fine
but makes little sense for me because the Python version can be specified in
project settings, period. You can test against py26 OR py27 OR py32, etc.
But what I need — and why I need a CI in the first place — is something
that would ensure that my commit passes all tests in all environments that
I’m willing to support. For example, Argh must be continuously tested
against py26, py27, py32, py33 and pypy. I could run tox locally but it’s
very slow and still allows a certain degree of machine-dependent floating bugs.

So, having Travis CI freely available for any repo at Github was enough
to finally convince me to move.

Mercurial vs. Git

I’ve been using Mercurial for five years. Yes, I did try Git. And again.
And then again. And all the time Mercurial was flat out better: easier
and more intuitive, or at least good enough. This was my major point
re I-dont-wanna-even-touch-that-github.

My new job, however, required me to use Git. At some point I tried HgGit
but it was a disaster. So, okay, let’s play this Git game. Why not.
Aaand, well, I like it. Mercurial has indeed a much better UI: more concise,
more intuitive (this doesn’t really depend on experience), better thought-out.
But Git’s staging area and light branches are very practical, and when you come
back to Mercurial, you miss them much more than Hg’s CLI in Git. By the way,
Git’s enigmatic and cumbersome interface can be partially “fixed” by aliases:

unstage = reset HEAD --
last = log -1 HEAD

To sum up:

Git is quite OK, just like Hg.

Github is quite OK, just like Bitbucket.

Conclusion

There’s probably no need to move my rather popular and stable projects
like django-autoslug: the community has already helped to polish the library
and has it in bookmarks. By moving the code to another site I would only
break people’s bookmarks and confuse them. There would be not much profit
from CI either as the code has stabilized and it is highly doubtful that
any significant changes are to be expected any soon. So old stuff stays
where it is regardless on how popular it is.

Most private projects won’t profit from public interest and don’t need testing
anywhere but on my own machine(s). So they stay, too.

However, my actively developed projects that can be useful to the community
and can profit from public interest are to be moved. The first two are
Argh and Monk. You can subscribe if interested. :-)