
The Early Days of GitHub – Interview with Tom Preston-Werner - icey
https://www.heavybit.com/library/podcasts/enterpriseready/ep-2-the-early-days-of-github-with-tom-preston-werner/
======
mojombo
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!

~~~
nodesocket
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
> 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.

~~~
wafflesindeed
> 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?

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

~~~
mojombo
> 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.

------
dsd
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?

~~~
mojombo
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.

------
ben_jones
Unfortunate timing as Github is currently suffering issues [1].

[1]:
[https://twitter.com/githubstatus?ref_src=twsrc%5Egoogle%7Ctw...](https://twitter.com/githubstatus?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor)

