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."
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.
Could you share two of your favourite stories related to this?
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.
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.
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?
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. :)
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.
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!
Give the podcast a listen for more context around that and your other questions!
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.
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".
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.
Or maybe I'm misunderstanding your question. Let me know if that's the case.