Last week, GitHub announced its all-new Free plan, making GitHub free for all developers and teams with unlimited collaborators and unlimited private repositories. The announcement came as a big surprise for many. GitHub’s business model always has been charging teams for private repositories — while remaining free to use for open-source repositories. With this change, GitHub turned off a significant chunk of its revenue coming from organizations on the Team plan.

Until you take an in-depth look — which is when you see how this change was a long time coming and shouldn’t have surprised a keen observer, I’ve been watching developer tools closely for quite some time. Pricing changes of platforms like GitHub are of particular interest to me since the company I run is a complementing service used by developers.

To understand how the pricing change was a long time coming, and how it probably doesn’t really impact GitHub’s revenue in the long run, let’s take a few steps back and see how we arrived here.

GitHub’s approach to product and pricing

GitHub’s business model has always been charging users and teams for private repositories. The product is entirely free to use for open-source code, which brings in massive activity from developers. Once you’re hooked to using GitHub, there’s a high chance that you’ll pay for storing your private code too. Neat.

Historically, GitHub has never had feature gating of any kind — the free and paid plans get almost identical capabilities. Therefore, the value addition to customers has always been the ability to use GitHub for private code. Since the launch in 2008, the pricing was based on the number of private repositories and had multiple tiers for different brackets of repositories allowed.

That changed in 2016 with the announcement of unlimited repositories — switching the pricing model to the number of users. The value, still, was using GitHub for storing private code.

This product strategy (of having no feature gates) and pricing model (free for open-source, paid for private code) proved to be very useful in acquiring users fast — who could quickly get to see the value on open-source code and then swipe a card to use private repositories. The simplicity of the product and a singular focus on no-frills source code hosting and better collaboration tools further accelerated the growth.

Comparison with Bitbucket and GitLab

Quite the opposite to GitHub, Bitbucket and GitLab have always had feature gates headlining their pricing strategy. Both these platforms have had, unlike GitHub, a free tier for private code. But their pricing has been, in general, complex. For instance, Bitbucket still offers enforced merged checks in their most expensive plan; and GitLab offers the merge approvals only in the paid tier, and multi-group user boards in a higher paid tier. GitHub had been the first mover in providing most of these features and kept all these features available to all tiers.

A shift in the user’s perception of value

GitLab’s meteoric success in the past couple of years brought into light a new trend, however. GitLab went full ballistics with feature gating, with as many as four tiers of pricing — and tried to attack the entire DevOps category with different product features aimed at various verticals and under different plans. This strategy was new, utterly opposite as compared to what the largest incumbent GitHub was doing, and would have seemed foolish to any observer at that time. And why not? After all, GitHub has been the reigning leader of the category, kept its product simple and focussed, and built an extensive API to play well with complementing services like CIs, issue tracking, code verification, automated deployments, monitoring, release management, etc. GitLab just attempted to do everything, all at once.

But it turns out, GitLab has been a visionary. Their experiments with embracing feature gating uncovered something very unconventional: hosting private repositories alone is no longer the core value for the customer.

The world has changed a lot since GitHub’s founding in 2008, and organizations are now embracing workflow automation more and more. The success of CI / CD platforms like Circle CI and Travis CI, the more recent roaring success of dependency vulnerability detection platforms like Snyk, and growing adoption of automated code quality and verification tools clearly meant that engineering teams from companies of all sizes are looking at automating everything in the software development that can be automated — and they’re looking for 3rd party services to do that, as compared to building things internally.

Enter, $MSFT

It’s mid-2018, and Microsoft announced that it’d acquire GitHub for a whopping $7.5B in stock. Things had not been exactly rosy at GitHub before that, and the company had struggled to make money despite having built the most influential platform for developers and engineering teams in the world. This story is something every investor dabbling in developer tools loves to quote (in addition to Docker), but that’s a tale for another day.

With a new leadership under Nat Friedman, GitHub quickly figured out what it had been missing. GitLab had just crossed the $100M ARR mark, and Atlassian’s ~1B ARR saw some decent growth coming from Bitbucket. GitHub had the largest and fastest-growing, user-base of developers from across the world — what would it take to convert that into massive revenue growth?

The Big Switch

It’s almost like GitHub had this epiphany after the acquisition. It realized the shift in the value chain of software development tooling. It realized that it already had the most massive distribution platform for developers — with 40M+ developers and 2.9M+ organizations — and they no longer needed just private repositories and collaboration tools.

So GitHub switched the gears to build everything else, just like GitLab — almost. Soon after the acquisition, it went on an acquisition spree, gobbling up Pull Panda, Semmle, Dependabot, and the latest, npm. It also added CI / CD capabilities after refreshing GitHub actions — which, as you’ll see later, will go on to become a significant part of its strategy.

In a matter of fewer than two years, GitHub switched from being the best code hosting and collaboration platform for developers to trying to be the single platform where software development happens. I’m tempted to use the term OS for Software Development here, but I think the analogy has already been overused.

GitHub Free: embracing the inevitable

Given the detour we took so far, making it free for all teams and developers seems the natural progression for GitHub. It realized that much more value could be created by selling value-add services on top of source-code hosting, backed by a massive distribution base it has already built. If you look at the latest pricing, this becomes as plain as day.

GitHub has realized what features add the most commercial value for its customers and also has been pushing for more adoption of GitHub actions — for CI / CD and ad-hoc pipeline integrations.

Embracing feature gating, it moved all essential features to the free tier except for those that teams can’t possibly live without now — like required reviewers (which is something that GitLab did from the very beginning).

Another evidence is decreasing the free action minutes from 10,000 to 3,000 in the team plan. This signifies that GitHub has seen growth in people adopting GitHub Actions as their primary CI / CD if they’re on GitHub already (bad news for Circle CI) — so the change in pricing based on minutes makes total sense.

Soon, we’ll see GitHub adding or moving more additional features only in the paid plan. This is a double whammy — GitHub gets to say it’s free for anyone doing software development in the world, but it’s making sure people who can pay, would pay.

So yes, GitHub Free has had GitHub lose a lot of revenue in the short-term, but my educated guess is, it’s not a lot. And all that loss would be offset by new teams jumping on board from other platforms like GitLab and Bitbucket and eventually converting to paid in the mid-term future anyway. In the long-term, GitHub Free makes GitHub more revenue.

The math for GitHub Free

Let’s talk about a team of 10 developers who are on the Team plan. The team also uses GitHub Actions for CI / CD on all their projects, stores built packages using GitHub Packages and also generates a lot of artifacts through GitHub Action runs. It is common for a team of this size and decent activity to use at least 5,000–7,000 build minutes every month.

What were they paying before

$25/mo (for the first 5 users) + $9/user/mo ⨉⁢ 5 users = $70/mo 
$0 * 7,000 minutes (free build minutes) = $0
Total: $70/mo

What they’d be paying after GitHub Free⁢

$4/user/mo ⨉ 10 users = $40/mo
$0 * 3,000 mins (free build minutes) + $0.008/min * 4,000 mins = $32/mo
Total: $72/mo

For small teams that are deeply integrated with GitHub, which is something GitHub is betting on anyway, they’d be paying more now. As the team grows in size, yes, the total cost would see some decrease as compared to previously — but there are high chances that more features could go behind more pricing tier, just like GitLab.

What GitHub Free means for other developer tools

I’ll be honest here — this is not particularly good news for complementing services that engineering teams use in their workflow. Since GitHub has become so ubiquitous amongst tools bought by engineering teams, it has also become a reference point when it comes to pricing. When purchasing a tool that works on top of GitHub (like a CI tool, or code review automation tools), it is prevalent for customers to compare the pricing with GitHub — “Why should I pay $30/user/mo for this tool when I’m just paying $9/user/mo for GitHub?”. Well, this pricing change is just going to make it worse for everyone. The pricing change by GitHub is the last nail in commoditizing source-code hosting in the industry, and like other players, it has now stepped into the value addition game with features on top of the core workflows.

Embrace the Free tier

Here’s the silver lining. The fact that GitHub is betting on primarily selling value-added services proves business value validation for every developer tooling company out there. If the biggest player in the market is moving towards them, they’re already sitting on a gold mine. Which makes sense — since we’ve seen increasing adoption of tools that automate parts of software development and save developer time

From a pricing perspective, it makes sense for developer tools who’ve been pricing per user to embrace the free tier, and give at least some user seats for free — if not all. They’ll also need to identify which of their features add the most value, and ruthlessly put everything in the free plan. This will not only help improve adoption but also help focus on the features that add the most commercial value.

GitHub just validated the larger trend in the developer tooling market, which GitLab and others had already foreseen. Others will need to catch up now for better or for worse quickly.