Providing Context: What Do the GitHub Numbers Mean?

Bloomberg got access to a set of financials of GitHub and the article refers to some of the numbers in the documents but it’s not always entirely clear what the definition of the different revenue numbers (ARR/MRR vs. Recognized Revenue) or revenue streams (github.com vs. GitHub Enterprise; Personal Plans vs. Organizational Plans) is. I’ll try my best to paint a clearer picture and put the numbers into context.

Overall Revenue

Eric Newcomer, the Bloomberg journalist who received the financials and wrote the article stated that GitHub’s ARR (Annual Recurring Revenue) back in September 2014 was around $70M.

$70M in ARR is certainly amazing; but for a technology startup, at the end of the day, all that matters is how fast you can grow on top of that. GitHub was the darling of the developer community but 2014 (harassment scandal, Tom Preston-Werner resigning) and 2015 (slower progress, increased competition) were challenging and it suddenly wasn’t set in stone anymore that GitHub will dominate and own their vertical in the same way as for example Amazon Webservices owns theirs.

The September 2015 ARR number of $90M seems to reflect that. But, if they were struggling in 2015, they blew it out of the water in 2016 and went from $90M in September 2015 to $140M in August 2016.

GitHub grew from $90M to $140 in 11 months — data source: Bloomberg & Eric Newcomer

Enterprise Revenue

GitHub offers three different products as of December 2016:

github.com personal plan

github.com organizational plan

GitHub Enterprise (on-premise/VPC product)

All of the growth in the last two years came from GitHub’s organization plans or GitHub Enterprise. The revenue from their organization plans roughly doubled and the revenue of GitHub Enterprise tripled over the course of 23 months (Sep’14 — Aug’16) while the revenue of their personal plans stagnated according to the numbers Bloomberg published.

50% of GitHub’s ARR came from GitHub Enterprise as of August 2016 compared to 35% back in September 2014. Their efforts to get into larger organizations and become more of a traditional enterprise software vendor also explains the higher burn rate. Historically, most of GitHub’s revenue came from their github.com offering which was completely self-serve while their GitHub Enterprise customers require more handholding and a more traditional enterprise sales process.

GitHub is marching into the enterprise market — data source: Bloomberg / Eric Newcomer

Those numbers seem to be in line with the other numbers mentioned in the article which probably refer to “Recognized Revenue”, an accounting/financial metric. GitHub’s fiscal year goes from February to January and they ended January 2016 with $95M in recognized revenue (compared to $90M in ARR in September 2015).

For the 9 months from Feb’16 to Oct’16, GitHub recognized $98M in revenue which would, for the sake of simplicity, assuming a linear growth rate, result in $131M in recognized revenue by January 2017 (the end of their fiscal year). That compared to $140M in ARR in August 2016 seems reasonable because recognized revenue often lags ARR in high growth subscription software businesses.

Burn Rate

The headline and a big portion of the article is focused on GitHub’s high burn rate. Similar to the revenue metrics, it’s hard to conclude whether a burn rate is low or high solely based on the absolute numbers.

GitHub’s burn rate for the 12 months between February 2015 and January 2016 was $27M. That means that GitHub lost $27M while generating $95M in revenue. During the 9 months of 2016, from February until October 2016, GitHub burned $66M and generated $98M in recognized revenue. On the surface, it looks as if GitHub burned significantly more money ($66M instead of $27M) but only generated $3M more in revenue. It could be an issue, especially because GitHub lost $66M in just 9 months and the burn rate for the whole fiscal year will likely increase.

But it is important to look at the ARR as well. Today’s ARR results in higher recognized revenue down the road.

Example: Your SaaS product creates $10 in MRR in January and adds $10 every month. You end the year $120 in MRR. For your investors, you annualize the MRR to be able to share an ARR metric. You report a $10 x 12 = $120 ARR for January and $120 x 12 = $1,440 in ARR by the end of December.

Recognized Revenue lags behind ARR/MRR

Although you are at an ARR of $1,440, you can only recognize $780 in revenue. Assuming GitHub calculates their ARR in a healthy and responsible manner, there is no issue with their burn rate since it will result in higher revenue. The beauty of Software-as-a-Service is recurring revenues and predictability but it comes with a cashflow disadvantage if you can’t get your ARR up-front.

Cash Balance

Keep in mind that GitHub raised a total of $350M and probably has access (or could get access any time) to a credit line/debt facility. There should be plenty of money left of the latest $250M investment from July 2014 (plus whatever was left of the $100M investment from Jul’12).

Jul’14: $250M in venture capital

Feb’15-Jan’16: Burn of $27M

Feb’16-Oct’16: Burn of $66M

Let’s assume that GitHub lost a similar amount between Aug’14 and end of Jan’15 (6 months) as in the months afterward; so 1/2 of $27M = ~$14M. $250M - $14M - $27M - $66M = $143M.

Based on those numbers, GitHub still had more than half of their $250M investment in the bank by Oct’16.

Even if GitHub stops growing and doesn’t reduce the Marketing/Sales costs, it would still have enough money in the bank (solely from their $250M investment) for another 20 months. On top of that, GitHub is probably able to close multi-year deals with their enterprise customers and could get some of that revenue up-front if they choose to pursue that road. That additional revenue would not be recognized upfront, but over the course of the lifetime of the contract. In that case, the burn rate in the P&L (“loss according to the income statement”) would be higher than the actual cash burn rate.