The question is not "Do I host my source code?" If you're a one-person shop, the answer should be yes. If you're a midsized consulting firm, the answer should be yes. If you're a huge distributed product company, the answer should be yes. You get the picture.
The real question: "With whom do I host my source code?" The answer to that question is not as straightforward as the first and will require more thought and research.
At the company I work for, we hosted our own source code up until a drunk driver ran into our office building, and shortly thereafter we faced the same question. We did some preliminary research that narrowed our choices down to GitHub and Bitbucket, but there wasn't a clear winner between the two. Here are some points to consider when picking the right source code hosting solution. The points are listed roughly in order of importance. The first points are critical, while the last points are icing.
Which RCS (revision control system) you use could end the search for you right off the bat. Bitbucket officially supports Git and Mercurial. There's been a rickety solution for Subversion users on Bitbucket, but it's too flaky and will be removed on Oct. 1.
GitHub supports Git, end of story. If you've been using Subversion and you want to change, GitHub posts instructions for making the transition.
We had been using Subversion, so we were out of luck for both GitHub and Bitbucket. We had been considering a switch to Git but had no logical reason to undergo that sort of transition. Our cloud exodus was going to be a migration project in any case, so we chose to make the switch to Git as a part of it.
Public vs. private
Both GitHub and Bitbucket support public and private repositories, so you can't rule out one or the other based simply on feature set. Your needs here, however, will determine which of the next two factors will be more important to you. If you have mostly public projects, then community involvement will have more weight in your decision. On the other hand, if you're dealing with more than just a few private projects, then the pricing model will be a more important detail.
It can be hard to quantify community involvement, but if you dumb it down to number of users, GitHub blows Bitbucket out of the water. Number of users is definitely not the only factor in community involvement, but it is a quick and easy way to get a rough gauge on what sort of exposure is possible.
Another way to gauge the community is to take a look at other projects that have chosen one or the other. GitHub is the favorite of a considerable number of open source projects including the Linux kernel, a handful of your favorite NoSQL databases, and even Subversion. (To be accurate, Subversion is mirrored from Apache's self-hosted Git, but it's in GitHub nonetheless.)
Although both GitHub and Bitbucket allow for public repos, GitHub is the clear winner based on its community and notable projects.
If you have more than a few private repositories, the pricing model will be an important consideration. It's not straightforward to compare the two, because they charge for different aspects of the service. With GitHub you pay per private repository; with Bitbucket you pay by contributor.
The decision should be pretty straightforward. Here's a little calculator to figure out which one is right for you.
Project tracking integration
This is less a feature of Bitbucket or GitHub than of the project tracking software you use. It's worth mentioning, though, because good integration is fantastic and timesaving. First look to see if your project management software integrates with either. If it does, check out the features and weigh them against one another.
A basic integration would simply be linking changes to bugs or development tasks. Many project trackers go beyond that, providing luxury features (and after using these features, they do feel luxurious), like the ability to change the status of an issue or to log time to an issue from within a commit message.
We use Jira, which has support for both GitHub and Bitbucket, so that didn't narrow our search. If you use a different project tracking solution, do some research and see if it narrows yours.
Nobody wants another set of login credentials, right? In the current climate, many apps will let you authenticate via your OAuth2 provider of choice. Unfortunately, GitHub doesn't allow for external authentication. Each member of your team will have to set up a new account at GitHub. Bitbucket, on the other hand, allows you to log in with Twitter, Google, Facebook, OpenID, and GitHub (oh my!) credentials. This point isn't critical, but it's definitely worth considering.
When we migrated to the cloud, one of our decision points for services was how you log in. In our case, we were adopting many new services and didn't want to deal with having to manage a ton of new credentials. Since we had already decided on Google for mail and other apps, we chose a set of services that met all of our needs and would allow for authentication via Google. This wasn't possible for every service we have, but I can log into most of them with a single account.
It's not a make-or-break feature, but single sign-on means fewer headaches for your developers, less time spent on lost password requests, and more productive hours.
This really comes down to two things: how aesthetically minded your developers are, and how often they will actually use the Web interface. There are some tasks, like creating a remote repository, that are much easier to do in the Web GUI. Once that's done, however, how much time will your developers spend in it? After you consider powerful CLI tools and IDE integration, the Web UI looks more like a required convenience than anything else.
We didn't weigh the Web GUI differences much, if at all, into our decision. As for aesthetics, I can't decide for you. Luckily, it's both easy and free to try out the GitHub and Bitbucket GUIs and see which you prefer. When it comes down to it, however, the friendliness of the Web front end shouldn't be weighed very heavily unless your use case involves a great deal of point-and-clickiness.
While it doesn't have anything to do with source code management, GitHub does have a nice feature that Bitbucket does not. GitHub Pages lets you easily set up a website that GitHub will host for you. When it comes to working on open source projects, this is a great little feature. This shouldn't guide your decision, but if you've already chosen GitHub it will be a nice bow on top.
A last suggestion
GitHub and Bitbucket both have their strengths, and you may be at a decision already. Before you pull the trigger, though, consider that you don't have to choose one over the other. You could choose both.
We ended up using both GitHub and Bitbucket to get the best of both worlds. For our private repositories, we use Bitbucket because the pricing model is so much smarter for us. With Bitbucket we pay about $30 a month as opposed to the $200 we'd be paying at GitHub. When we have some code we want to share with the community, we'll send the repository over to GitHub for wider exposure.
Making use of both Bitbucket and GitHub certainly won't work in every case, but it's a solid catch-all compromise that could save you a headache and make your decision go away.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.