Hi everyone, I’m Chris Wanstrath.
When I think of workshops, I think of 8th grade shop class. Where you fashion little letters out of wood and get to play with really big saws for 50 minutes each day. You remember, right?
My shop class was taught by Mr, let’s say, Allen. Mr. Tim Allen. (It’s a fake name but this is a true story.)
Mr. Allen’s shop had a mini computer lab in it, which was very cool. Stocked with state of the art IBM PCs running Netscape Navigator, we could use Lycos, Yahoo, or (my personal favorite) Metacrawler to find and print out designs or wood patterns.
The computer lab was in its own room, near the back of the shop. I never understood why there was a second room, but looking back I’m pretty sure it had something to do with the combination of teenagers, electric saws, and expensive computer equipment. In science class we’d call that “potential energy.”
So the computer lab, being in its own room, had a door and a window or two. The windows had blinds that you could close to prevent glare.
On days where we were independently working on an in-progress project, Mr. Allen would enter the computer lab, shut the door, then close the blinds. Occasionally he’d peak his beady little eyes out to make sure we were all still alive, then quickly retreat back to his work.
We always joked that he was looking at porn, but in reality he was probably looking at houses, reading the news, or (hopefully) trying to find a new job.
No. He was looking at porn.
The police got involved and he was fired the next semester.
I didn’t learn much in shop class, but I did learn one thing: the Internet can be used for good or evil.
(And just to be clear: I’m not saying Mr. Allen’s behavior was necessarily evil. But at school, around children? Creepy.)
8th grade, as it happens, was also when I discovered open source. I went to a Linux install-fest at the University of Cincinnati with some of my older friends and put Red Hat Linux on my family’s Compaq Presario. (Sorry Mom and Dad.)
It didn’t have a window system, only console mode, and was the first time in my life I felt like a badass. Like a hacker in the movies. Awesome.
Over the next few years I worked at a Linux based ISP, worked in a Windows based IT department, wrote ASP, wrote PHP, loved the GPL, hated the GPL, then eventually ended up here.
Today I work at GitHub, a company I co-founded last year. In this workshop I’m going to talk about the ways we’ve used the web and open source to stay cheap and help grow our business from a bootstrapped startup to a profitable company. And no porn, I promise.
Git is a version control system similar to Subversion or CVS. It was written for the Linux Kernel and is used by projects such as Ruby on Rails, Scriptaculous, YUI, Perl, Android, and the open source code that powers Reddit.
GitHub is a site that lets you publish Git repositories, either public or private. Tom Preston-Werner and I started working on it in 2007 while we both had other jobs. He was at the natural language search startup Powerset while I was running a consulting business with PJ Hyett.
Both Tom and I were big fans of open source. I had released dozens of projects and contributed to many, and Tom was the same way.
We were both so active in open source that it was beginning to take a toll. Neither of us had created any huge projects, but we had lots of little ones and the time was adding up. Managing bug trackers, reviewing and merging patches, discussions on mailing lists, writing documentation, on and on.
GitHub was our solution: a way to streamline the open source process. A way to make contributing, accepting, and publishing code stupid simple. In the same way that Django or Rails does the tedious stuff so you can focus on your application, we wanted GitHub to let you focus on your code.
At least, that’s the official sales pitch version. In reality I just wanted GitHub to let me focus on my code. I’ve learned from experience that I’m much better at building things for myself than I am at building things for other people.
Tom had learned from experience that if you’re going to have a side project with the potential to be resource intensive, it’s gotta pay for itself. His last project, Gravatar, got pretty damn popular and pretty damn expensive. He ended up spending a lot of time and money scaling it. Time he could have used for mountain biking and money he could have spent on scotch.
Unfortunately, self-sustaining websites are not easy. It’s literally the million dollar question. How do we make money with this thing?
Well, how was our competition making money?
Sourceforge, a popular code hosting site, is free for open source projects but has ads. Lots of ads.
I hate ads.
I used to work at CNET on a handful of sites that were ad supported. In that model, it’s all about volume. Get as many eyeballs on your site as possible and hope a fraction of them click on the ads. Deal with sales people and advertising agencies. You really need to become popular before making money.
That works for some, but not for me. And it gets worse.
The people paying your salary aren’t your customers. They’re the advertisers. Your business lives and dies by people who care about how much and what kind of traffic you drive, not how good your product is. They care about your demo (that’s short for demographic) and cpms (I don’t even know what that’s short for anymore).
For example, each year Vista was delayed, CNET had to change its budget because there would be no massive Microsoft advertising campaign. Same story with Sony and the delayed Playstation 3.
The funny thing is, these companies bossing you around with their advertising campaigns aren’t making money off advertising. They’re selling things that people want.
It quickly became clear to me that the Microsofts and Sonys had much stronger business models than the CNETs and Sourceforges.
So free is out – this thing needs to pay for itself. And ads are out – they suck. What’s left?
The revolutionary concept of charging people money.
If you want a private project on GitHub, you have to pay. If you want a public project, go nuts: it’s free.
Don’t ever make people pay to participate in open source. That’s as bad as looking at porn in shop class.
So with the business model in place, we continued working on the site in our free time. We didn’t want to put a lot of our own money into it, but we definitely wanted to keep it self funded. It was a side project, not a startup.
At a local tech meetup we showed off the site to some friends who immediately wanted access. Shortly thereafter we launched the beta and invited them to sign up.
After that beta began we began noticing what we’ve dubbed “the YouTube effect.” People were blogging about the cool things they were doing on GitHub – not about GitHub itself. We’d get huge traffic spikes from people writing blog posts announcing their project or idea, with a single, casual link to the project on GitHub. Even better, we’d get tiny traffic spikes in great numbers from less notable projects doing the same. More and more people were blogging about their cool project on Github. Showing off.
You didn’t need a beta to use GitHub. Only to make an account and share. People with accounts could share with anyone. This was pretty key – everyone could see what was going on, they just couldn’t participate without an invite.
After the YouTube-like blogging came “the Facebook effect.” Once a project was hosted on GitHub it made a lot of sense to invite the other people involved. The more, the merrier.
Like the YouTube effect, this was not something we had planned for or anticipated.
Something we did anticipate, however, was our invite system. During a consulting gig I was introduced to the concept of “artificial scarcity.” When you control the means of production, you can limit production to make a product seem more valuable.
Just look at the Wii. Or, more appropriately, gold in World of Warcraft.
So during the beta, our invite system was modeled after Gmail’s: once you received an invite and signed up, you could then invite five others. This meant people would be asking for GitHub invites on Twitter, mailing lists, and message boards. There’d be entire threads devoted to people asking for GitHub invites. It wasn’t hard to get an invite, you just had to ask.
We could have given invites to everyone who asked, but this gave us free publicity and made the invites more desirable. Hey, these invites are rare and I got one – why not give this GitHub thing a try?
Unable to afford any advertising or traditional marketing, the Gmail-style beta system worked better than we could have hoped. Combined with the YouTube and Facebook effect, we were starting to see real traction without spending any money on ads.
Looking back, there is another, more traditional term for what was happening. “Word of mouth.”
If you’re building a website, you have a huge advantage over more traditional businesses: all of your potential customers have access to the Internet. You don’t need to buy billboards, get written up in newspapers, or buy commercials on TV in the hopes of getting your name out there. The Internet provides better, faster, and cheaper means of advertising.
Best of all, it’s more trustworthy and authoritative. Friends recommend quality products to friends. It’s not some baseball player on a TV ad but a person you trust.
Somehow, this is still a secret. Companies still believe that what works offline will work online.
The longer they believe that, the better it is for all of us who know better.
However, we did get curious. We started dabbling with Google AdWords and advertising on small blogs. We sponsored regional conferences. We gave away t-shirts. Who knows – maybe we’d find a hit.
The Adword conversion rates were abysmal. I’m glad that we gave it a shot, but for our business it just doesn’t work. We’ve found people trust their peers and personal experience to find a hosting provider, not random Google ads.
Same for the blog ads. It’s nice to sponsor someone’s quality, unpaid time, but when you’re a self funded startup the dollars spent are not effective enough.
As for the regional conferences, spending money to be just another logo in a pamphlet or on a poster is not something we can afford to do. Instead we’ve started doing more guerilla style marketing: last weekend I flew to a conference in Chicago and spent the money we would have spent sponsoring it on hanging out with developers. Saturday night, for instance, I took a group out for pizza and beers.
I got to drink with GitHub users, talk about version control with people who’d never used the site, and give our website a human face. We’ve done this a few times now and are finding it to be extremely effective.
Who knew: actually meeting your customers is good for business.
The last promotion technique I mentioned was giving away t-shirts. Yeah, that’s awesome. Do that. Everyone loves t-shirts.
So we got an idea, figured out a business model, launched a beta, got users, and made t-shirts. But what about the site itself?
In our efforts to improve and expand the site, we found open source software to be an extremely cost effective way to develop many core pieces of our infrastructure.
GitHub is built on a variant of the highly successful LAMP stack. It stands for Linux, Apache, MySQL, and PHP (or Perl (or Python)).
Our own version looks more like Linux, Nginx, MySQL, Ruby, Git, Bash, Python, C, Monit, God, Xen, HAProxy, and memcached. But none of those start with a vowel and LAMP is very pronounceable.
Basically, going with a LAMP-based stack is pretty much a no brainer unless you’re a Java or Microsoft shop, in which case you’re probably not a bootstrapped startup on a budget.
But we were, so we went with it. Running an open source stack, with a background working with open source libraries, mean you’re constantly looking for code to extract and release from your own projects.
The first thing we open sourced, very early on, was the Git interface library called Grit. There was nothing like it available at the time and it remains a very core piece of our site.
It would have been easy for us to think Grit was some magical secret sauce, a “competitive advantage,” but we now know how wrong that would have been. In fact, I’d say one of the most competitively advantageous things we did was open source Grit.
A few weeks after its release a man by the name of Scott Chacon published a competing library. His had some amazing stuff in it but lacked certain features Grit excelled at. Tom and I chatted with Scott and eventually convinced him to merge his code into Grit, creating one library to rule them all.
A few months later we hired Scott. He went on to write some of the most mind blowing GitHub features.
Good thing we open sourced Grit.
As the site grew and more businesses started using it, people began requesting integration with various third party services. They wanted IRC notifications, ticket tracker awareness, stuff like that.
Integration with established sites is a great thing to have. It’s sexy and lets people use tools they’re familiar with – we wanted to add as many as we could. Doing so, however, would be prohibitively time consuming. We’d have to sign up with the third party service, learn their API, write the integration, test it to make sure it worked, then address any bugs or complaints our customers had with it. Over and over and over again.
So we open sourced that part of the site, too.
People immediately started adding their own pet services and fixing bugs in existing ones. We’ve even seen third party sites write their own service, in order to advertise “GitHub Integration” as a perk.
Everyone wins.
Needless to say, this idea became very attractive to us: open sourcing core parts of the site so motivated individuals can fix, change, or add whatever they see fit.
So we did it again with our gem builder. We host Ruby packages for development versions of code. The utility that creates the packages is now open source. We’ve had various bug fixes and security patches submitted, which feels good. Fixes and patches that perhaps would have otherwise been overlooked had we kept the source closed.
Open sourcing this component also means people can run the builder on their local machine before submitting a package to GitHub and have some idea of whether or not they’re doing things correctly. Cool.
With the final successful project I want to talk about, we went the opposite direction. Tom created a static site generator in his free time called Jekyll. When we launched static site hosting, integrating Jekyll was obvious. Since then we’ve had dozens of bug fixes submitted and features contributed by people who want to use GitHub for their static site but needed just a little bit more out of Jekyll. Now they have it.
And sure, our site does cater to developers. But open source has its own community that any business can take advantage of and contribute back to.
At my last startup, we open sourced a JavaScript plugin we’d developed. I thought that people would see the plugin and get interested in the startup, maybe sign up for a trial account. Peek around. Dip their toe in.
Didn’t happen. Should’ve known.
But! That did not stop people from using and contributing to the plugin. Even though the users of my site weren’t adding features they wanted, other people were. My customers were still benefiting from open source – probably without even knowing the concept existed.
Your site doesn’t need to be developer-centric to benefit from open source. Just don’t count on it driving signups to your Nascar based social network. Use open source to improve the quality of your product, not as a marketing tool.
And while we’re talking about things open source won’t do for you, I might as well address the big question that always comes up:
Why isn’t GitHub open source?
After all, WordPress is open source and still makes money hosting blogs. Lots of money. Why not GitHub?
So, I actually love this question because the answer fits so well with everything I’ve been talking about. In fact, I already gave the answer.
The reason GitHub isn’t open source is the same reason we started GitHub: open source takes a lot of time. And as we all know, time is money. Especially so in a small company.
Managing bug trackers, reviewing and merging patches, discussions on mailing lists, writing documentation – these are all things we’d have to do in addition to working on the site and running the business. So in addition to my current job, I’d basically need to do a second job.
And my current job already takes up a lot of my time.
With that said, it’s not out of the question for the future. It would just be too expensive right now.
I believe that by worrying about every dollar spent and every dollar earned, we’re a much stronger company. We didn’t have an office at first because we couldn’t afford one, but now that we can we still don’t. We’ve realized that, for us, it’s an unnecessary expense. We all enjoy working from home or at cafes.
Company meetings are held at restaurants over dinner and beers. At the end of the month, it’s a lot cheaper than rent would be. And a lot more fun than board rooms and white boards.
Starting small, on a cheap VPS with no office and no money, has made me realize the value of thinking through your decisions. Don’t forgo an office just because we don’t have one. Think about what’s best for you, your employees, and your business.
Start simple, incrementally improve, measure twice, and think about what you’re doing.
Just like in shop class.
Thank you.
Published in Issue #3: Nibbling at the Bits
Back