The Early Days of GitHub – Interview with Tom Preston-Werner

> How would you ship/deploy GitHub Enterprise (or FI) if you made the decision today

A few years ago I met the founders of Replicated, who were just starting to build tools to make it much easier to ship an existing SaaS product to Enterprise customers. I thought it was an amazing idea, having felt that pain so closely myself, and I became an early investor and advised them extensively about all the tooling we built to make GitHub Enterprise a reality. They have now built all of that and a lot more. It works quite simply for containerized apps and I would absolutely use Replicated to ship an Enterprise app today. I’m biased, of course, but I tend to invest in companies because they have awesome people and product, so read that however you like. :)

This is covered quite extensively in the podcast, but the quick version is that we went to a PHP conference very early on to exhibit and found something like half the people that stopped by our booth thought GitHub sounded cool and would be interested in evaluating it, but it being a SaaS only product was a non-starter. We decided we wanted to serve all the developers inside Enterprise companies too and started down the long road of figuring out how to make that work. We had no idea how hard it was going to be, but our goal of helping ALL developers work better together meant it was something we needed to figure out.

Give the podcast a listen for more context around that and your other questions!

> Tom: what tools did you use to build the OVF Enterprise image?

Early on it was a mostly manual process too inefficient to even discuss (shudder). Then we moved to a Vagrant-based solution to make upgrades from any version to the latest version more streamlined. Since then a lot has changed, and I’m not sure what the toolchain GH uses today is.

> How would you approach it today?

See another answer here for thoughts on Replicated and how their tooling can do all this and way more for you.

> One piece of advice I got when porting my SaaS to Enterprise (on-prem) was NOT to create an "enterprise" branch in the source code, but instead just use one big GIANT flag such as an environment variable "ENTERPRISE".

Yes! YES! Amazing advice! You’ll save yourself a lot of horror by doing this from the start. Listen to the podcast for a big discussion on this topic.

> Second, did shipping all source code in plain text to enterprise clients concern you?

In the early days we ran the Ruby code through an obfuscator (which came along with its own set of problems), since we offered a downloadable free trial and didn't know how paranoid we needed to be. Still, much of the codebase remained unobfuscated (CSS, scripts, etc). The hardest part was trying to discourage legit customers not to mess directly with the code, as it made upgrades nearly impossible to manage. To avoid this, we focused on building extensibility APIs into the product that would be useful for all customers. Our licenses, of course, also stipulated the things you mentioned, but hackers will be hackers, so we had to deal with some interesting circumstances from time to time.

I would probably start with a React frontend and GraphQL backend and then optimize from there. Rails is awesome and I owe a lot to it, but the world has changed a lot in the last decade and the modularization and data binding that React/GraphQL offers is too compelling to ignore.

Given today's tooling, I would probably have started later, but at the time it took us long enough to get a good Enterprise product put together that having started quite early gave us a reasonable timeline to enter the Enterprise market with a competent offering. I don't regret our timing at all.

The biggest problem with getting into Enterprise too early is that it will slow you down. With today's great tooling (e.g. Replicated) you can accelerate your technical solution, but you'll still be faced with the overall added complexity of an expanded deployment base, differing customer requirements, more complex (and demanding) support requests, long sales cycles requiring dedicated sales people, and a lot more. All of this to say, sometimes its better to keep velocity up so you can accomplish more with the goal of getting Enterprises to come to YOU.

Our growth was always pretty linear. Surprisingly, steadfastly, linear. But we had the luxury of time from being bootstrapped and staying within profitability for years. We just waited for the market to shift as people realized Git was awesome and GitHub was the best place to collaborate on Git repos. Then we kept our customers happy and worked on building a community. We did almost none of what people today would label “growth work”. Just focused on product and making superfans.

I don't know that there's anything that feels quite the same at the moment. React has some of the feeling, except that it's enjoyed much faster adoption because of the Facebook backing. Vue seems to be more the underdog. GraphQL is another technology that's early but picking up a lot of steam (also thanks to FB).

Today I might do GitHub with a Rails/GraphQL backend and React frontend. Or I might try to stay with JS for most of the GraphQL backend but still do the heavy Git work in Ruby or C. I'd have to think about it a bit more, but the React/GraphQL/Apollo stack is pretty enticing to me today.