8 ms·

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 po

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!

sqs 8y ago
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?
- mojombo 8y ago
  > 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. :)
rckclmbr 8y ago
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!
- mojombo 8y ago
  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!
nodesocket 8y ago
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."
- mojombo 8y ago
  > 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.
- mojombo 8y ago
  > 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.
- mojombo 8y ago
  > 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.
whitepoplar 8y ago
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?
- mojombo 8y ago
  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 8y ago
    [deleted]
stonesixone 8y ago
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?
- mojombo 8y ago
  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.
amasad 8y ago
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?
- mojombo 8y ago
  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.
  - tenderlove 8y ago
    I am a superfan!
ilovecaching 8y ago
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?
- mojombo 8y ago
  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.
rgbrgb 8y ago
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?

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!

sqs 8y ago

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?

mojombo 8y ago
> 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. :)

rckclmbr 8y ago

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!

mojombo 8y ago
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!

nodesocket 8y ago

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."

mojombo 8y ago
> 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.
mojombo 8y ago
> 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.
mojombo 8y ago
> 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.

whitepoplar 8y ago

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?

mojombo 8y ago
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 8y ago
  [deleted]

stonesixone 8y ago

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?

mojombo 8y ago
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.

amasad 8y ago

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?

mojombo 8y ago
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.
- tenderlove 8y ago
  I am a superfan!

ilovecaching 8y ago

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?

mojombo 8y ago
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.

rgbrgb 8y ago

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?