Git is a fast, efficient, distributed version control system ideal for the collaborative development of software and GitHub is "the easiest (and prettiest) way to participate in that collaboration." GitHub's Chris Wanstrath wrote to tell us how much Getting Real influenced the team there.
Getting Real since day one
We've employed Getting Real (with great success) at GitHub since day one. Not because we wanted to, or because we thought it was the One True Way. We've done it because we had no choice.
Tom Preston-Werner and I were working full time on other startups when we started GitHub. It was just a side project. See, sharing Git repositories was too damn hard. The existing sites sucked and setting everything up by hand was a pain. We didn't know it then, but we immediately hit upon some major Getting Real tenants - picking a fight (crappy existing Git sites), scratching your own itch (we had Git repositories we wanted to share), and staying lean (the two of us planned to do the whole thing ourselves).
Applying Getting Real to GitHub, though we were familiar with it, didn't cross our minds. The main idea was to build something useful we'd enjoy. The beautiful part, of course, is that other people wanted to enjoy it too. As such, we quickly realized we could turn GitHub into a real business. Sure, we always planned to make some money off it, but making money and running a business are different things.
No outside funding
We had a talk and agreed right away: no outside funding. We wanted to keep the whole company. Having very little money, very little time, and a lot of passion leaves few options. You pretty much have to do what Jason, David, and the boys say. It's the smartest way to succeed.
Once we eschewed funding, we made a few more decisions: stay lean, give the site an attitude, bust out features quickly, and define the site's purpose in a single sentence. Oh yeah, and find our third musketeer. We brought on PJ Hyett, a well-rounded and entrepreneurially minded developer, then got to work.
Launched ASAP
We literally launched our "beta" as soon as the signup code was finished. We had real users and real projects on the site right away, bringing us invaluable feedback. What worked, what didn't work, all of that. No lab tests or surveys. We watched what people did instead of listening to what they said they might do (which, of course, is never accurate).
Not only were we not concerned about scaling when we launched our beta, our site architecture prohibited it. We launched the beta on a single box and, due to the disk-based nature of Git and our particular setup, would have been unable to simply 'add another box' had traffic spiked. We would have to re-engineer the entire thing. But that's fine. Getting users was more important.
Getting noticed
We blogged our asses off and watched Twitter (via Summize) like a hawk. We worked hard to build hype and celebrated every time an influential blogger joined GitHub or wrote something positive. Seeing what people were saying, especially the good things, fueled us. In a few (3) months we had a billing system in place, fleshed out the features we thought were necessary, and were ready to launch.
Things broke on launch day, naturally. If you have a flawless launch you're doing it wrong. We recovered quickly and overall had a great day. We even managed to launch some new features as a 'thank you' to our beta testers. We did not, however, launch everything.
A lot of web apps in our space still have a lot more features than us. Bug tracking, integrated chat, continuous integration, stuff like that. Being only three people, we could spend forever building these features or, with considerably less effort, open a few integration points to let people use the sites they already love in conjunction with ours.
Campfire
We're big Campfire fans, so why not give people a way to integrate their code on GitHub with Campfire? We love Lighthouse for ticket tracking, so why not embrace it? Features like 'team chat' and 'ticket system' look good as bullet points on functional specs, especially when compared to the list of features a competitor has, but luckily we had no functional specs. Rather than waste cycles on 'me too' features we were able to spend time on ground breaking ideas like our network visualizer and commit comments.
"Things have been amazing"
We launched three months ago and things have been amazing since then. Great growth, lots of wonderful users, and most of all a fulfilling site we're all proud of and use every day. In fact, after just three months we're already paying salaries. All with no funding.
Really, not accepting funding has been huge for us. Would you pay out of your own pocket for Feature X? No? Shelve it. If I'm not going to love a feature, I'm not going to spend my time (and therefor money) implementing it. Money is quite powerful, and so is its absence.
They say it's hard to live in San Francisco and not take funding, but I beg to differ: out here it's easy to get lucrative consulting gigs and fill your bank account. Contract for someone else with funding, make some money, save it up, then spend it on your company. You don't have to sell your soul to a VC or live off of ramen. Just be smart.
Other invaluable principles
While the 'no funding' and 'less' ideas are pillars, a few Getting Real principles are easy to gloss over but invaluable nonetheless. The 'first-run' is one such idea. Basically, what users see when they first use your application matters. A lot. One well respected Ruby developer approached PJ at a conference and specifically mentioned how much he liked GitHub's first-run news feed. He didn't use those words, of course. Instead he said exactly what we wanted to hear: "After I signed up, the Welcome Event told me exactly what to do next." When you create a new project on GitHub, you can actually copy and paste the "What's Next?" text into your console to setup a repository on your computer. Make it easy.
For me, the 'attitude' aspect is another favorite and potentially overlooked idea. Such a perfect solution for so many problems. Major planned downtime? Show users a YouTube video on the "We'll be back soon page" (we do this - visitors see a video from a pre-selected pool). Need to show a "this page is loading" message for background operations? Make it funny. "Forking" (copying) a repository takes a while and our "Hardcore Forking Action" loading screen has become infamous among users. Adding a bit of spice into things that are normally bland, boring, and unexciting goes a long way. You are not Bank of America or any other faceless mega corporation - showing your creative side in unorthodox places is the best way to prove it.
I mentioned earlier we agreed on a single sentence to define the site's purpose. While GitHub sports seamless 3rd party integration, social networking aspects, APIs and feeds, interesting visualizations, and other features we love, it's really about easily sharing code. And that's what we say: "Git hosting: no longer a pain in the ass."
So far, so good.
Do you use a 37signals product in an interesting or noteworthy way? Let us know.
