Following the GitLab model: How to build a profitable, open core, remote-working startup
GitLab is similar to a lot of startups, born out of frustration with existing tools to founders who know the community they serve well. But, the similarities end there. GitLab does not occupy floors of office space in the usual tech hubs but rather has a completely remote workforce. GitLab CEO, Sid Sijbrandi, told me how this decision was initially driven by the original makeup of the founding team who were spread over Europe, and has become ingrained in his company’s DNA. Talking to Sid, you can tell he’s proud of what he’s built and this shows by the effort GitLab has given to promote remote work in startups, something a lot of venture capitalists (VCs) will tell you is “not ideal.”
Getting investors on board
I asked Sid what the reaction was when he told investors they were a remote team. As I’ve experienced with my own startup, remote work is viewed as a negative which required justification to get investment. VCs, Sid explained, are focused on reducing risk; why invest in a startup which is following a different model to the one you are used to and know works? Recently, in a video chat with a potential investor my cofounder and I laid out our rationale for remote work. He responded that he felt everyone had to be in the same place to effectively communicate. I asked if we were not all effectively communicating in our chat this very second. Times are changing as investors realize talent is global, but long-held views die hard.
Deciding on an open core business model
GitLab’s unique approach extends beyond remote work; it has secured investment from some of the best VCs in the world with what it terms an ‘open core’ business model. This is a smart compromise between being completely open source and holding back enough features that enterprises and startups will pay you enough to keep the internet connection flowing in GitLab’s 500 employees’ home offices (GitLab pays for its employees’ internet). The open source model usually involves charging for support, but GitLab found this did not work for them. As they grew more stable and became more intuitive customers were seldom in need of support so they stopped paying. This is great from a product perspective but not an economic one.
So, here comes the million dollar question. How do you decide which features to charge for and which to give for free in your open core? While, at the same time, ensuring you get the benefits of working with the wider development community, who can contribute massively when properly engaged. GitLab’s answer is beautifully simple: look at who is asking for what and follow the budget. If a C-level exec asks for a feature, they probably need it to work across an entire organisation and will be willing to pay for productivity gains. A startup founder has a different set of requirements (and budget) for managing small teams efficiently, so maybe this goes in a middle tier. While a single developer only needs the open core free tier for hobby projects. Sid explained you can generate value for all these segments by separating out the feature and ensuring fair pricing.
Hiring an all-remote team
Once you’ve got a killer business model, an actively engaged community and you’ve raised enough money to build out your product, how do you hire a remote team? Well, it turns out it’s not much different to how most companies hire. Sid explained that potential hires are aware of how remote work operates and how, from an engineering standpoint, it makes relatively little difference where someone is working from as long as they stick to regular office hours. Perhaps remote work will eventually lead to a more diverse workforce and provide a better family-work balance. After all, forcing talented people to undertake ~3-hour daily commutes hardly shows how much you value them. Remote work may not be a magic bullet to automatically improve inclusion and diversity, but perhaps it’s a good starting point.
As our conversation drew to a close, it became clear why GitLab is the poster child for remote work and open core development. But what’s on the horizon? There is increasing disquiet about how cloud vendors have built business models around taking open source software and delivering it ‘as-a-service.’ The mood from investors seems to be to create more restrictive licenses which prevent this. GitLab is published under the open MIT license and Sid hopes they will never be forced to change this. I hope he is right.
