Ask Tom Preston-Werner, cofounder of GitHub, anything Today, Mon 18 Oct 2010.

We actually haven't talked to Linus. He only takes part in discussions around Git when he notices something wrong. The model that the Linux kernel uses for contributions is pretty well set in stone (and email) and so it's likely that GitHub doesn't really offer him, personally, much benefit. We do, however, speak regularly with the top core Git maintainers and have a good relationship with them.

It's not a figure that we publicize, but let's just say it's enough to support thirteen well paid employees, a San Francisco office, 34 physical machines at Rackspace, and plenty left over to put in the bank account.

It took three months to go from inception to private beta. We used an invite only system to introduce artificial scarcity and drive buzz on Twitter (each new signup got five invites to use). After six months we launched to the public and started charging for private repos. Because we had such a great beta period, we converted a large number of users that day and were making money immediately! For the next several months we put every dollar that we made into the company bank account and let it accrue.

One year after inception I was faced with a choice: take a full time position at Microsoft (Powerset had been acquired) or quit and go full time at GitHub. We were making enough money at GitHub to pay low salaries for the three cofounders and we decided to Hire Scott Chacon at the same time. So we went from zero to four full time salaries in one day, a year after starting it on the side.

Over the next six months we incrementally raised salaries for everyone as we hit specific revenue goals. So about 18 months after inception we were making decent salaries. We also hired Tekkub to do full time tech support in this timeframe. Our next hire was Melissa, our office manager a few months later.

As far as revenue at these milestones, we were always profitable. We only hired when we had the money to do so. For the first 18 months we didn't carry much balance in the bank account. We used it to hire great people.

Being a subscription service means that recurring revenue is extremely predictable. We've never had a month where revenue has dropped, and we can predict the increase in monthly revenue quite accurately as well. Growth has been surprisingly smooth (not spikey).

We now make money from GitHub.com, GitHub FI, Training, the Job Board, and merchandise.

There is some great advice in Getting Real, but I don't remember being particularly influenced by it. I was more influenced by Ricardo Semler's book Maverick. And by wanting to build a company that I myself would want to work for, regardless of anything anyone else has to say. That has driven nearly every decision.

Not having a set work schedule allows us to work when we're most effective, leaving more time available for taking care of personal affairs. If you want to take Wednesday off because your Mom's in town, then that's what you do. We all work hard enough and smart enough that I don't worry at all about our people getting their work done. We love what we do, and that's what makes it all work out.

So far we haven't hired anyone that has been "unreasonable." I hope that we never do. In past jobs, I have had to deal with unreasonable people. That is one reason I was drawn to being an entrepreneur. So I wouldn't have to do that anymore.

The new shipment of Fork You shirts will arrive at our office today. We will get the inventory online right away!

The BitBucket/Atlassian deal is interesting. Especially the price points they think they need to establish in order to make their offering attractive. I really don't think about it too much, I'm too busy making GitHub the best place to collaborate on code!

We don't talk about planned features. We find that if you talk about what you're GOING to do, then people will just be angry that it's not finished yet. If you wait until you're done, then people will go crazy over the shiny new feature. Apple knows how this works. Judge for yourself which approach you think works better. =)

I used to go to a lot of Ruby meetups. While the talks were generally high quality, my favorite part was always going to the bar afterwards and talking with fellow coders about what got them excited. This is where new ideas really get started.

We decided that we wanted to take that part of the meetup and make it a first class citizen, so we started the GitHub Drinkups. If there's one thing that I've learned about leadership, it's that all people need in order to participate in something is an invitation.

So my advice is this: whatever you're thinking about doing, just do it. You'll find out quickly what does and does not work. If nobody comes to the meetup or nobody signs up for the contest, then shrug it off and figure out what you need to change in order to make it work.

I don't remember whose idea the Pappy was. We like to present GitHub as a fun, edgy company. This has worked out really well at getting the attention of early adopters. Giving out booze was a great way to point at the "establishment" and make fun of how stodgy and limiting they are.

Indeed. GitHub has the mindshare to get a critical mass of people to their drinkups, but a lot of startups don't. But if those startups were to combine forces they might...

Proposal: GitHub used to do their San Francisco drinkup bi-weekly, now it's monthly. How about a bunch of smaller (popularity-wise) startups (or any project with a community) in SF fill in that gap?

This would also facilitate the "cross-polination" that GitHub drinkups achieve by bringing together different groups of people.

Cappuccino already has it's weekly "CPCoder Night" on Wednesdays but that's more sitting a cafe hacking and helping each other out with technical problems. I'd be happy to help organize something like I described above if people are interested (feel free to email me at the address in my profile if you're interested)

It's higher than one percent, but we don't publicize those numbers. It's hard to compute the difference in ratio internationally vs. domestically because we only have the optional user specified location field to go off of.

Making the user the namespace for code instead of the project.

Growing slowly and embracing the constraints of a limited budget in the early days.

Hiring only the absolute best people that we could find. Hiring people that we knew through their code. Making sure they were good cultural fits.

Not getting an office until two years after we started GitHub. Campfire was our office in the meantime and that let us put what money we did have into hiring the best people.

Always thinking for ourselves.

Reading code is one of the best ways to become a better programmer. You can learn so much so quickly by trying to understand how other people you admire solve problems in code. Making it easy to find, follow, and read code is what GitHub is all about.

In the future, participating in open source will be the best way to land a great job. When employers see that you have a demonstrable ability to code and work well in a team, you have a MUCH more likely chance of getting that interview and impressing the right people at that company you'd kill to work for.

I can neither confirm nor deny that we're working on kickass improvements to GitHub Issues.

No, that looks like an ascii dong.

Quora doesn't make it easy to compile a bunch of questions and answers in one place. This is a much better forum for these discussions.

Alcohol can either be a great social lubricator or a dangerous drug depending on how you use it. We're all friends and responsible adults at GitHub. Should there be a problem of this nature, we will address it in a private and personal fashion. Just like any self respecting group of people would.

Git was the first distributed version control system that I spent any time with. It turned out that it was also the most elegant in construction and the most powerful in ability.

I think the future of Git is to become the technology on which really amazing, usable versioning and collaboration is built. Git the technology should be irrelevant to the end user. Git/GitHub the experience should be the best in the world. At least, that's the direction we intend to take it.

I don't have any experience with non-technical cofounders, but I don't think that I'd start an internet company with one unless they were the absolutely most well connected, proven person that was going to be instrumental in getting us into a difficult to enter industry.

We only have one non-technical employee, our office manager Melissa. She's absolutely essential to the team. We have no plans to hire other non-technical people right now, but that doesn't mean that we won't in the future. Who we hire depends on what skills we need.

Yes. Our equity offers are quite generous. Invested employees are motivated employees. Ownership is a huge factor in job satisfaction.

Absolutely. How about Nihon?

Speaking of which, when's the next Boulder drinkup?

We have an awesome tool we call Haystack that we use to collect, categorize, and search exceptions and other notices. It uses MongoDB capped collections to keep the number of stored entries to a manageable level. "Needles" are simple JSON hashes and the views are customizable with Mustache. Exceptions can be rolled up based on a custom value provided by the producer. For instance, we roll up exceptions by filename and line number of origin. We use the hell out of it.

There are other projects, but nothing else that I'm able to talk about at the moment.

We don't put up with any bullshit. If the existing software out there displeases us, no matter how mature it is, we'll be tempted to build something better. This is how progress is made. It's possible that we're duplicating effort somewhere, but we all cherish the act of creation, and if we think we can improve upon the situation, we will. Sometimes just for the sheer joy of it.

I'd wager that pretty much everything you use today was considered an act of NIH by someone at some point in the past.

Well, what we've done seems to be working pretty well. Have an open source tool (or leverage someone else's) and then sell additional hosted or installable tools that expand the power of the underlying tool.

I know of a lot of places that do well with providing support and consulting for their open source offerings, but that doesn't scale as well as something that you can charge for on a recurring basis and that doesn't derive directly from butts in seats.

We hire very slowly and very carefully. And we draw from our personal network first. The best way to get hired by GitHub is to be in San Francisco, come to the Drinkups, write awesome open source code or make insanely beautiful designs, and be a genuinely interesting and hard working person.

As for other startups, I don't really know firsthand the culture of many of them, but I do know the founders of CrowdFlower and they're amazing. And they're hiring. Go check them out.

We look for features that we want to use ourselves. It's usually quite apparent what areas of the site need some love or where entire features are missing. The things that get implemented are the things that are important enough for someone on the team to actually sit down and start working on. If you want a feature badly enough, you'll go build it. It turns out that this is a great filter for what is worthwhile.

Some features (like Pull Requests 2.0) spend many months in development before they're launched. PRs took about 8 months of off and on work before they were ready. Pressure from other team members will often serve as a catalyst for the implementors to finish what they started.

More strategic decisions often bubble up to the founders and we'll make a final decision on whether we need to hire additional people to make things happen faster.