GitHub is Doing Much Better Than Bloomberg Thinks - Here is Why
GitHub, like Amazon Webservices, is a corner stone of modern day software development. Even if you are not a developer, it is likely that you are using software built with their products. More than 18M users created nearly 50M repositories to store source code, including one for the original source code of the Apollo 11 guidance computer, and did more than 80M pull requests. GitHub is the de-facto standard for working on and storing open source software. It is actively used by 6M people to collaborate on OSS. On top of that, half of the Fortune 10 companies and 44% of the Fortune 50 use their commercial offerings.
Leaked Financials: The Bloomberg article
For as much as we know about GitHub’s adoption by developers, we know very little about how they are doing as a business. At the end of the day, GitHub is still a private company and doesn’t need to disclose any information they don’t want to disclose. When I saw a story by Bloomberg’s Eric Newcomer popping up on Hacker News a few days ago, my excitement sparked.
GitHub Is Building a Coder’s Paradise. It’s Not Coming Cheap
A paradise? Nice! Not cheap? Well, building a company is hard. Unfortunately, the whole article was very much focused on several mistakes GitHub made, only discussing the financial information Bloomberg received on a surface level and didn’t really analyze how GitHub is doing as a whole.
Despite all the adoption and great numbers that I mentioned, GitHub is seeing more competition recently. GitLab is doing a wonderful job in challenging them on a product level. For many years, GitHub didn’t have any competition which naturally led to less pressure and a slower pace for releasing product improvements. This development combined with some troubling cultural issues, multiple changes in the leadership team, and an influx of cash from huge financing rounds caused a lot of employee turnover. Changing your company culture from bootstrapping, no managers, and “Optimizing for Happiness” to being a VC-backed startup with a lot of money, directly translating into more employees, is hard - very hard.
That all being said, Bloomberg’s article caught my eye and I started to dig a bit deeper to figure out how well GitHub is actually doing. All metrics and numbers are from Eric Newcomer’s Bloomberg article and his subsequent tweets.
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.
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 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.
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.
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.
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.
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.
SaaS Playbook: GitHub Invests in Growth
It’s hard to analyze GitHub’s financials and metrics without having direct access to the data. With what we know from Bloomberg, GitHub is to be doing very well financially. $140M in ARR with roughly 62% YoY growth makes them an IPO candidate. GitHub historically generated the majority of their revenue without Sales and outside of the enterprise market. Their ability to move up-market, close large deals and generating more than 50% of their revenue with their enterprise product is very promising and will allow them to maintain a high revenue growth rate.
GitHub is not the only player in the market. Other companies like GitLab are doing a good job but GitHub has a huge head start and the advantage of the network effect around public repositories. Although GitHub’s network effect is weaker compared to the likes of Facebook/Twitter or Lyft/Uber, they are the default choice right now. There’s no network effect in place for their enterprise product which makes investing in that part of the business even more important. Spending money aggressively to acquire more enterprise customers and fend of their competitors is necessary for GitHub to be successful in the long run.
Last but not least, GitHub didn’t raise $350M to let it sit in their bank account. There’s a huge market opportunity and no other company in their vertical is in a better position to win that market than GitHub. If costs get out of control, GitHub can always dial back and decrease the Marketing/Sales spend again which would result in profitability.
Disclaimer: I’m the founder/CEO of Codeship, a continuous integration and continuous delivery company that sits on top of GitHub (and other source code management platforms like Bitbucket or GitLab). Codeship is an integration partner of GitHub but I/we don’t have any insights into their business metrics.