The Early Days of GitHub – Interview with Tom Preston-Werner(heavybit.com)
heavybit.com
The Early Days of GitHub – Interview with Tom Preston-Werner
https://www.heavybit.com/library/podcasts/enterpriseready/ep-2-the-early-days-of-github-with-tom-preston-werner/
28 comments
Tom here. Just saw this got posted on HN and wanted to say I’m happy to answer any questions about how we tackled Enterprise at GitHub (the main topic of the podcast) or anything else, really!
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". Two branches SaaS and Enterprise will lead to pain down the road while at the outset it may seem like a good approach.
Tom: what tools did you use to build the OVF Enterprise image? How would you approach it today?
Second, did shipping all source code in plain text to enterprise clients concern you? My application was in PHP, so the source was not compiled. My thinking was, have an Enterprise License Agreement that basically says, "you can't modify, disassemble, or distribute the source code."
Tom: what tools did you use to build the OVF Enterprise image? How would you approach it today?
Second, did shipping all source code in plain text to enterprise clients concern you? My application was in PHP, so the source was not compiled. My thinking was, have an Enterprise License Agreement that basically says, "you can't modify, disassemble, or distribute the source code."
> 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.
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.
> 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.
Could you share two of your favourite stories related to this?
Could you share two of your favourite stories related to this?
> 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.
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.
> 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.
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.
Hey Tom! When I think of GitHub, I think of Rails. If you were building a new SaaS product today, would you still use server-generated HTML (w/ js sprinkles, as DHH likes to say), or would you lean toward heavier clientside javascript?
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.
[deleted]
Thanks!
How would you ship/deploy GitHub Enterprise (or FI) if you made the decision today, with all the new deployment tools available and new kinds of environments in use?
Also, what kinds of trials/freemium did you find necessary to offer for Enterprise? Did everyone already know they needed it and trust that it worked because of GitHub.com? How much custom work and pricing/negotiation did you tolerate?
How would you ship/deploy GitHub Enterprise (or FI) if you made the decision today, with all the new deployment tools available and new kinds of environments in use?
Also, what kinds of trials/freemium did you find necessary to offer for Enterprise? Did everyone already know they needed it and trust that it worked because of GitHub.com? How much custom work and pricing/negotiation did you tolerate?
> 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. :)
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. :)
You talked about how you felt like Ruby was sort of the "hip crowd" so to speak, since enterprises hadn't discovered it yet. Do you feel like that is still true of Ruby? Is there another language that has taken that place in your mind? What would you choose to write Github in today?
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.
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.
Hey Tom, wondering what the initial days of growth at GitHub looked. Was it all hockey stick up and to the right? Or where there plateaus, peeks, and valleys? Did you have to do any growth work?
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 am a superfan!
Hey Tom, thanks for being here!
How did you decide to build an onprem github? I would imagine most of your devs are used to small, quick iterations and testing/seeing things live quickly. This is different from onprem where you need managed releases, baked migrations, and slower iteration speeds. So, was this a difficult decision, and once you did it, what were the key things you had to figure out?
I havent listened to the podcast yet but i will tonight!
How did you decide to build an onprem github? I would imagine most of your devs are used to small, quick iterations and testing/seeing things live quickly. This is different from onprem where you need managed releases, baked migrations, and slower iteration speeds. So, was this a difficult decision, and once you did it, what were the key things you had to figure out?
I havent listened to the podcast yet but i will tonight!
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!
Give the podcast a listen for more context around that and your other questions!
Thanks, Tom! If you could go back and make the decision over again, would you have done enterprise sooner, or later? Do you think GitHub would still have been very successful if you stuck only with SaaS?
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.
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.
Having grown a geographically distributed company with a central hub in SF, what are your thoughts on remote work? Is there a certain stage or company type that it works best for?
> I almost always struggle with Google's login thing. It's always chosen the wrong person. I'm always having the wrong permissions, and it's infuriating. Places like Slack do this as well. Go and try to log into your Slack account on a specific one. It's like, "Oh my God. I have like, 12. And I have to remember that my one password is just littered with Slack log ins." It's like, "I'm just one person. Either I have access to a room, or I don't."
Ha, I have the same issues with accounts on Google and (previously) Slack. GitHub's approach to simplicity is really something that differentiates them from not only competitors but other companies in IT. It's an interesting counterexample to the typical stereotype that engineers cannot build products with good UX.
> Which is where a lot of our chat up stuff came from.
It should be "chatops" instead of "chat up".
Ha, I have the same issues with accounts on Google and (previously) Slack. GitHub's approach to simplicity is really something that differentiates them from not only competitors but other companies in IT. It's an interesting counterexample to the typical stereotype that engineers cannot build products with good UX.
> Which is where a lot of our chat up stuff came from.
It should be "chatops" instead of "chat up".
> It's an interesting counterexample to the typical stereotype that engineers cannot build products with good UX.
Thanks! To me it's always been about product and I have a lot of background in design so it was always a priority at the company. In my mind, one of the most impactful things you can be today is a developer/designer. There is immense power in that skillset combination.
Thanks! To me it's always been about product and I have a lot of background in design so it was always a priority at the company. In my mind, one of the most impactful things you can be today is a developer/designer. There is immense power in that skillset combination.
[deleted]
[deleted]
Super interesting. I saw you mentioned the headaches that came with merge requests. Did you having the same problem with separate prod, staging, test, and dev repos via a forking git workflow?
All of the internal GitHub development was done on branches, so things stayed very simple. We developed on feature branches and merged to master. That's it. As long as you communicate well between team members you can avoid merge conflicts 99% of the time.
Or maybe I'm misunderstanding your question. Let me know if that's the case.
Or maybe I'm misunderstanding your question. Let me know if that's the case.
Unfortunate timing as Github is currently suffering issues [1].
[1]: https://twitter.com/githubstatus?ref_src=twsrc%5Egoogle%7Ctw...
[1]: https://twitter.com/githubstatus?ref_src=twsrc%5Egoogle%7Ctw...