GitHub: why it is right for open source and wrong for you
For most of the software development projects in the world, GitHub is the wrong choice for their hosting needs. This is because for most of the world, they are not developing open source software, and thus the pricing model for GitHub works against them, as it is designed to charge the daylights out of those who do not develop open source software.
To help me explain this, let’s look at two examples.
An open source example
We will use Git itself as our example for open source. Here is a project that is open source and uses three public repositories. Looking at the Git repository, there have been 702 contributors to it.
When you examine the GitHub pricing model, this could be run on any plan, including the free one, since we are only constrained to have no private repositories on GitHub (you can have unlimited public repositories) and unlimited contributors—which makes it perfect for open source.
When you apply the recommendation I mentioned in yesterday’s post about lightweight repositories to this model (with free, unlimited public repositories), it makes even more sense for open source projects.
A corporate example
The other side of the coin is a company doing consulting or in-house development work that needs storage, and (for whatever reason), that work cannot be open sourced. Thus, you will need private repositories—and a lot of them if you follow lightweight repository principles. Even if you don’t intend to follow those principles, splitting up your repository in an organizational way might still create a lot of repositories.
For example: I worked at a small company (< 30 developers) that deployed and developed on top of Microsoft CRM & SharePoint. There, we split things by customer (so each customer got a repository), and after three years, we had nearly 200 repositories. For them to use GitHub simply by moving over would mean negotiating a custom price with GitHub, as GitHub doesn’t offer standard pricing at that level. If they had restructured to properly follow the lightweight repository principle, they could have easily tripled the repository count!
So if not GitHub, then who?
In a company, you need to view the issue from a different angle—you need many repositories. However, you also have another key difference from open source: you have limits on something open source doesn’t—and doesn’t want to limit—contributors. In a company, you’ll only have staff or project contributors, so limiting the number of people involved is useful. It also makes costing hosting easier, as it boils down to per-head pricing.
So who offers Git hosting with unlimited private repositories and charges per head? There are two main players in this space, and I’ve used both—both are great solutions. BTW, I also use GitHub and think it’s great—just more suited for open source collaboration.
BitBucket
BitBucket, which started as Mercurial hosting to GitHub’s Git hosting, now offers Git as well. Their model is straightforward: unlimited private repositories at $1 per user per month. Simple.
TF Service
Who expected Microsoft to excel at Git hosting? They’ve done it well with their TF Service offering, which provides unlimited private Git repositories. TF Service is currently free, but that won’t last—my gut tells me Microsoft can’t compete with BitBucket’s $1 per user cost.
The reason it can’t compete is that TF Service offers more than code hosting—build servers, work item tracking, and more! Plus, if you have Visual Studio Premium or Ultimate, you likely have an MSDN subscription, which may cover TF Service costs, making it free.
Summary
This post isn’t about criticizing GitHub—it’s an amazing service that has revolutionized how the world interacts with code. What it aims to show is that, despite its popularity, GitHub may not be the best solution for everyone.
The real number one issue to avoid GitHub
While this discussion focuses on pricing (often overlooked when choosing a platform), the top blocker for GitHub—and for TF Service & BitBucket—is my customers. Many won’t allow hosting outside the company or in a foreign country, so we must run our own infrastructure to accommodate them.