Building a Worldwide Network of Employees and Contributors with Sid Sijbrandij, CEO and Co-founder at Gitlab.com
GitLab raised $20 million in Series B funding in September 2016, affirming its model that merges a massive open source project with integrated SaaS tools.
The company has forged a unique path within Silicon Valley, eschewing many of the standard constructs of how a growing software startup should operate. GitLab has grown from nine people to 100, many of whom don’t live in San Francisco, which is where CEO and co-founder Sid Sijbrandij has been since GitLab emerged from Y Combinator in 2015.
Co-founder and CTO Dmitriy Zaporozhets resides in Kharkiv, Ukraine. The rest of the GitLab team dot the earth, from South America to Africa, Europe, China, Australia, and Southeast Asia. GitLab maintains perhaps the most interesting team page on the web, with each employee listed in detail below an interactive map that shows where every team member is located.
One of the first jobs for a new employee at GitLab is to update the team page with his or her information, and put in a pull request so that it can be merged into the master branch of code for the website. Unlike many company team pages that seem to lag real life and are rarely up-to-date, the GitLab team page is a dynamic document and a testament to the lengths Sijbrandij goes in ensuring that GitLab’s scattered team operates as a cohesive unit, just as if the entire team were located in a single office in the Bay Area.
To that end, the GitLab team has pioneered methods to establish genuine bonds between coworkers who may be separated by tens of thousands of miles. The company holds all-hands web meetings four times a week for half an hour, and much of that time is reserved for people to chat about their personal lives, things like what they did during the weekend and what’s new with their family. GitLab team members are also encouraged to peel off for 30-minute one-on-one video calls between coworkers.
Sijbrandij thinks that many of his employees actually know one another better than they might if they worked together in the same office. His theories on this seem to be working, as his all-remote team has pushed forward a product that has traction within more than 100,000 companies, including IBM, Uber, Alibaba, Nasdaq, Intel and Verizon.
The core of GitLab’s software, like most open-source projects, is available for free to anybody. It is the special toolkits and features for which the company charges $39 per year (not month) per user. This model allows clients to take advantage of a worldwide community of developers who are constantly improving the base software, while also leveraging a single-tenant installation with proprietary features and unique instruments built for large teams.
GitLab has taken an unconventional route to its success in a number of ways, which are detailed below in an edited conversation between FundersClub’s Christopher Steiner, a YC founder himself (his comments, questions in bold), and GitLab CEO and co-founder Sid Sijbrandij:
You followed an interesting path to becoming a developer and founder. Can you give us quick overview of your career and background before Gitlab?
I studied Applied Physics for a year. After that, I switched to management science and logistics. I really didn't do anything in the tech space other than an internship with IBM, but I ended up working for a recreational submarine manufacturer for five years. I was the first employee.
There are recreational submarines?
Yes, the company that makes them is called U-Boat Worx.
Wow. So how does that work?
We made submarines that you can basically have on a large yacht. If you have a yacht of more than fifty meters and your neighbor already has a helicopter, this is the accessory to get. You can take three to five people below sea.
Are they expensive?
Our dream was to make one for twenty thousand dollars and we completely failed with two orders of magnitude. They're now two million dollars.
You were with U-Boat Worx for five years.
Yes. They still make the most submarines of any company in the world. But in the end, it was just a small to medium-sized company and it was doing its thing. I wanted the next thing and I saw this programming language called Ruby and I fell in love. For the first time programming seemed fun instead of something tedious. I learned Ruby and built a career for myself as a Ruby on Rails consultant.
Had you been much of a programmer before then?
Not really. I dabbled around with it but I always find it a bit too tedious to really get into.
The creator of Rails, he's Danish, I believe. And his company, Basecamp, is in Chicago. David Heinemeier Hansson. Did you see Rails just as it was kind of gaining steam?
Yes, he's Danish. And I got into Rails in 2007, when it was just gaining steam as a framework. I was just so excited with the whole thing and I so went out and learned it. Later on, I taught my wife and we taught a lot of other people through an organization called Rails Girls. It's a great framework and it's a great way to get started with programming.
Correct me if I'm wrong, but Rails is really what helped launched Git and GitHub to a degree. It really put the Git convention on the map, no?
GitHub was written in Ruby on Rails. I think that Ruby adopters were kind of like the JavaScript people nowadays, they were early adopters of anything, and Git was the new thing and they very quickly adopted it. That might be stretching it, but I think Git got popular first with the Ruby on Rails community.
You, of course, were familiar with Git early on. These two things, Rails and Git, have always seemed very related to each other.
Yes. I was familiar with that and I saw GitHub being launched, a great innovation in this space. Then at some point, I saw this project called GitLab. It made so much sense to me that collaboration software is something you can contribute to. I opened up the code base and was just really impressed with how clean it was. That was after a single year of the open source project. There was already a year of contributions and Dmitriy has done an excellent job keeping the code base clean and not incurring technical debt. I said, ‘Well, this is a big future and there should be somebody doing GitLab.com offering it as a service.’
So you took this open source project and then you turned it into SaaS.
Yes, correct. Dmitriy started GitLab in 2011. He open-sourced it and I saw it a year later. I started a thread on Hacker News asking whether people wanted to use this as SaaS. It wasn't trending so I went on and started baking pancakes, and then halfway through, I checked my phone and it exploded. I told my girlfriend, now wife, to please take over the pancake baking and I spent all night upstairs responding to comments.
So that thread is still on HN then? [ note to readers: here is 2012 thread ]
Yes.
It's very hard to get something to trend on Hacker News. At that point, were you bent on doing this?
Hacker News is always very supportive of new ideas. It doesn't mean necessarily it's a good idea, but I was just excited about it and it was something I could easily do along with my day job. I started doing it in my evening hours and my consulting business had one employee at that time. When he had a bit of off time, I would have him improve it. After doing that for a year, I learned that it is really hard to make any money with a SaaS product.
So I was struggling to make money, but I was getting all these requests from these amazing large companies saying, "We have this GitLab installation and we want this feature. Can you build this for us?" I was easy to find on the internet, being related to GitLab.com. Right around then, Dmitriy, the founder of the Gitlab project sent a tweet out to the whole world that said, "I want to work on GitLab full time." I connected the dots, hired Dmitriy and I asked him to make those features that these big clients were asking for.
So GitLab.com is still free and it's popular, and there's hundred of thousands of users and it's growing at a very rapid pace. But we’re making our money on these features we built, some of them we put in our GitLab Enterprise Edition and we're now asking for $39 per user per year to use it. That is our money maker. That's over ninety percent of our revenue.
A lot of people understand what Git is and how repos work—but you’re not charging people money for that. Can you explain where in the chain you guys come in for these large organizations who may be running their single-tenant installations of Gitlab?
Sure. So these companies are running something and you can call it on-premises, but most of it is hosted on AWS or something. Single-tenant, it's an installation that they run for their company and the companies they collaborate with. It's not a SaaS product. It's not multi-tenant.
So, at some point, they adopted it so far that it becomes a critical asset. The IT department finds out, mostly it's been a developer that snuck it in through the back door. It grows and grows and grows, and the IT department finds out, basically unfolds it, and then reaches out to us for the Enterprise Edition features that we offer that are more relevant if you have more than a hundred users.
There's nothing in GitLab that prevents you from using it with a lot of users. There are companies running GitLab Community Edition with over ten thousand people. There are some extra features and it's a no-brainer to pay thirty-nine dollars per user per year to use those features, we think, if you are a larger organization, so a couple of hundreds of users or more. We have three main products, GitLab.com contains all the features in GitLab Enterprise Edition totally free, GitLab Community Edition, open source, unlimited, and GitLab Enterprise Edition with the added features is thirty-nine dollars per user per year.
This model, you obviously didn't strike upon it immediately. How did you arrive at charging for things the way you do? Did VCs have any problem with that or did they understand and liked the way you were doing it from the get-go?
Most beginning entrepreneurs don’t charge enough for their product. We were no different. My first contract was an unlimited subscription for a whole organization that is now using GitLab with more than twenty-five thousand people, and it was fifteen hundred dollars per year. We had to invest an entire year of work to make it work for them.
You could say we lost a lot of money. On the other hand, that customer helped us to create a much more compelling product that was one of the great breakthroughs. Our initial pricing was twenty dollars per user per year. We’ve doubled that now. I think still it's priced very affordably. I think the general advice that says price your product high enough so you're really uncomfortable about it is probably about right.
As for venture capitalists, I think not all of them are familiar with open source projects. What you want to prevent is losing the open source community once you start commercializing your product. So you have to keep releasing about eighty percent of what you do as open source code and open source features. Of course short-term, that generates less revenue, but long-term, I think it's a better path to bigger revenues.
Did you ever have to find yourself help explain that balance to your investors?
So far, our investors have been really supportive of it, the ones we ended up with. But I regularly have to explain it, also inside of the company.
Going back now to when you started working on the idea, when did you make the leap from the Netherlands to San Francisco? This is exactly the kind of thing that a lot of startups grapple with: do I move, should I move?
At the end of 2014, we had a customer cancel. That never happened before. We talked with them and asked, "Aren't you happy?" They said, "Yes, we're totally happy. It's a great product, but we heard from our headquarters, the whole company is standardizing on GitHub."
So we were extremely worried because we realized it makes a lot of sense for whole companies to standardize on one solution internally. This is a collaboration product. It allows you to collaborate within the company to do something called innersourcing where you feed all your source code inside the company as open source. Any team member can access any project and contribute to it. That means it's a benefit to have all the source code inside one product. So our product was perfect for this kind of thing, yet this company went a different direction.
At that time, we weren't very well-known. We realized that during the next few years, the market was going to consolidate, and we risked not being a big part of that. We'd be ten or twenty percent. But we wanted everyone to standardize on GitLab. We wanted GitLab to be eighty percent of those single-tenant customers. That's why we applied to Y Combinator and when we were accepted for the winter 2015 batch, we came to San Francisco.
After that, I started fundraising and most of our prospective investors said, "You have to have a presence here." By that time, I figured out that our investors were here, most of our customers were here, a lot of talented people were here, so it made sense for me to be here for the majority of my time.
What did you find most helpful about Y Combinator in taking your product to the next level?
I think we saw how relentlessly other companies executed. They really made so much progress in two weeks.
Yes, I know how that goes.
We felt slow compared with everybody else, so we started shipping a lot faster. Just going faster overall. That really helped. We increased our pace and it's something we kept until this day. That came just by seeing other great companies and other great founders just going all out and creating whole companies in three months.
YC also raises your ambition level. Y Combinator is interested in companies that want to make a big difference, that are going to go for a billion-dollar plus outcome. We were, as Europeans tend to be, a bit skeptical of that going in. We drunk the Kool-Aid and we're ambitious ourselves now. Our official company goal is IPO in 2020.
You guys came from the startup community in Europe that has produced its own share of unicorns. Obviously, far fewer than the United States, but still, do you think there is a mindset difference in that a lot of entrepreneurs, at least within the tech startup world here, are thinking billion dollar company from the start versus Europe?
There are a lot of differences. There are great, great companies from the Netherlands. I think Adyen is a great example of a breakout success. Although I do think they moved to the Bay eventually. There's a lot of U.S. influence there. For companies that remained Dutch companies only, like Booking.com, you can see that they have a great product by the time Priceline bought them, but the majority of the value was created here in the U.S.
I think the U.S. is the best place to go to market. If you look at how many words there are for sales processes, for marketing processes—people have a common understanding of different jobs and roles and the things that they entail. That is expertise that is extremely hard to acquire in a single year, and it’s so much easier to get those people with that knowledge to join your company here.
Many of the best people in tech are in San Francisco, clearly, but the concentration of great companies in the Bay Area can sometimes make hiring difficult. You guys, however, have a very unique setup in that most of your people—all of your people, really—are elsewhere.
Yes, we're a remote-only company. Everyone at GitLab works from the location they prefer. We have more than a hundred people working from more than a hundred locations. That has been an enormous benefit. It forced us to use GitLab ourselves and make it better. It's also enabled us to hire people all over the world. Hiring engineers in San Francisco can be really hard. But we never had a shortage of great engineers wanting to join our company because they love to work on open source. They love to work out in the open and work with a large community on a project they use themselves. Because of the remote-only culture, we could hire them anywhere they work. We have people in Taiwan and Kazakhstan, in more than thirty countries total. That's been a great enabler.
Amazing. Do you guys have all hands meetings? Is that something you are able to do?
We do that four times a week for half an hour. Yes. More than half of that meeting is spent with people talking about what they did in their private life because we think that remote-only is great, but you tend to have less water-cooler talk, so we encourage people to have these kind of conversations during these meetings, to talk about what interests them personally. We also encourage things that are called coffee breaks where you schedule half an hour with a colleague to just chat. We really try to make sure that that personal connection is still there even though you're working from another location.
So you’ve found that sharing those details about everybody's private lives, their hobbies, and their interests, helps this virtual workplace on an ongoing basis?
Yes. There's people that say, "I feel I know more about my colleagues on another continent than I knew about the colleagues I was sitting next to in my previous job, because the people I was sitting next to, we would just talk about the weather and sports." It is just amazing to have somebody say, somebody who's in Kenya, say, "I couldn't visit my friends because two lions had escaped." That makes you feel close to that person even though they're living in a quite different world that you are.
So when you recruit, what does your process usually look like, because you have this advantage of being able to hire in that you're not limited by geography, and you can offer this allure of being able to work on something that's basically open source. What does your process look like?
We just post the job on our website. We use an applicant tracking system like everyone else. If you want to know the details of the process, our handbook is open source. If you search for GitLab handbook, you'll find all of our internal processes including the hiring process. It’s mostly done through video calls. Then the technical interview consists of contributing a feature to GitLab, which is exactly the task you'll do if you join us. We think that's a very relevant thing to do in a technical interview.
That's great. Do you give them an assignment or do they make up a feature on their own?
We have public issue trackers. Anything a customer asks from us, anything we think of, is in our public issue trackers. We select one of those things, something that's relatively small so it's achievable but is still slightly challenging. It’s an open source project, so we don't have to make anything up. There's always that kind of work that can be done.
You also have the advantage also of being a Y Combinator company that will hire people who aren't just in San Francisco. There's a global community around YC and around Hacker News that wants to be a part of these companies.
Yes, Hacker News has been an amazing part of our visibility. I don't think it's just because we're a YC company but we also try to be very actively participate there. Another reason people tend to be attracted to us is because we have an above average transparency of how we do stuff. The company handbook is part of that. Our issue trackers are open not only just for features in the product that are requested, but also, for example, our marketing department has an open issue tracker. Before you decide to join our company, you can see how we work on stuff, how we interact with each other. That's all done in a public setting.
Do you think that's something that other companies should look at?
I think it's something many companies can benefit from, but of course for us, it's very natural because the code is open source, we're an open core company, we have both open source code in Community Edition and close source code in Enterprise Edition, but at least all our code is publicly viewable and you can contribute to it even with Enterprise Edition. We try to adhere to the spirit of open source and apply it in all the things that we do and all the processes that we have. We’ve heard from startups that have said, "Hey, we took part of your handbook and we're using it now to make our marketing department better or to make this or that better." We're encouraged by that. Even if you don't open up, you can still benefit and engage.
I saw something on your site that said ‘this page is generated from a public file on GitLab.com,’ so people can edit your code and then put in a merge request and you guys will fold it in?
Yes, correct.
Do you find that a lot of people will in fact do work on your website?
Yes, they do. It is mostly us contributing, but we get contributions from others all of the time. They point out outdated information, spelling that isn't right, they re-organize something, a broken table, or something more substantial. That's great and I think people like the idea that they're able to see the history of what happened before.
Want to contribute to the website of Gitlab? Do it here!