GitLab's CEO Sid Sijbrandij on Current Development Practices

In this all-round interview, GitLab CEO Sid Sijbrandij speaks about how GitLab was born, what differentiates it from its competitors, the importance of being an “open” company, how GitLab engineers use continuous integration, what does being a remote-only company mean, and much more.

GitLab is a collaboration platform for software development that was started in 2011 as an open-source Git-in-the-cloud solution. Since its inception, GitLab has evolved to provide more collaboration tools to support new development practices, such as continuous delivery, and performance monitoring. GitLab has adopted an open-core development model, where the core part of the platform is open source, while additional features are available only to paying customers.

InfoQ: Can you explain to BigML readers how GitLab was born? At the time GitLab was launched, GitHub was already a strong player as a Git-in-the-cloud provider. What kind of technical/business reasoning drove you to enter the same arena?

Sid Sijbrandij: GitLab, the open source project, was started in 2011 by Dmitriy Zaporozhets because he was unsatisfied with the options for git repository management in the market. He wanted something affordable that he could self-host. At the time, I was working as a self-taught Ruby developer consultant. I came across GitLab and I was not only impressed by the code quality, but also by the community behind it.

With the success of the open source project, both in terms of downloads and active contributors, it became clear that there was a high demand for an open source self-hosted Git repository manager. While GitHub.com is a strong provider of Git in the cloud, we recognized that there were a number of enterprise organizations that needed social coding features with the security and commercial guarantees of a self-hosted enterprise offering. To meet the needs of those enterprise development teams, Dmitriy and I decided to focus our efforts on a product and services offering that would support large organizations.

The market interest from enterprises was one driving factor and the other was, and still is, our product vision of delivering an integrated product for social coding, continuous integration, application performance monitoring and more.

InfoQ: Over the years, the arena of web platforms providing source code hosting facilities has been evolving a lot. What are the major players, besides GitLab, and how is GitLab differentiating its value proposition?

Sid Sijbrandij: The other Git repository management players are Atlassian BitBucket and GitHub. The reality is that GitLab, GitHub, and BitBucket are all built on Git so there is a level of standardization across all three of us, especially when we’re only talking about code hosting. However, as you start to think about the new generation of developers that are using more modern practices or the future state of an enterprise that is just starting their digital transformation, then you start to see how GitLab diverges from other tools in the market. Our vision and delivery speed differentiate us from our competitors.

In terms of our vision, GitLab is the only integrated product, covering the entire software development lifecycle from project planning to application performance monitoring in a single interface. We’ve built a product that allows enterprises to future-proof their development process. Today, they may start using GitLab for source code management and continuous integration but then as they work to adopt DevOps practices or work towards achieving continuous delivery, GitLab has already built-in the needed tools to help them jumpstart that process without having to adopt and learn another product.

GitLab’s delivery speed and overall approach to development is also a key differentiator. We release a new version of our product every month on the 22nd. This means our customers never have to wait too long for a new feature to be released.

Then finally, our approach to development. GitLab is a radically transparent company. Everything from our source code to our roadmap is open. As a company, we believe that collaboration is key to achieving better results, faster. So we open up almost everything we work on to our customers and community to find the best solution to current and future challenges.

InfoQ: One of the main differentiator of GitLab was it being open-source, originally. Later, it went open-core. Could you explain the importance that being open-source had for GitLab initial success and the rationale behind becoming open-core? Where did the open-source model fall short?

Sid Sijbrandij: Open source is important because it allows us to collaborate closely with our community. To this day our roadmap is public and everyone is invited to comment on features, propose their own, or even submit a merge request for a feature they want in the product. This even applies to our enterprise edition, where the source code for that product is open to customers.

The open source model fell short in being able to build a business around it. You need significant work on installation, performance, security and dependency upgrades. If everything is open source you can only make money on support. Taking what we learned in 2013, we engineered GitLab to be user friendly to install and maintain so after one year of subscribing organizations quickly figured out that they did not use the support at all. Therefore, building a business model around support wouldn’t have been sustainable. Instead, we decided that there are some features and functions that are more useful to large development teams, like an enterprise organization. By offering extra functionality to customers with larger development teams or even more advanced needs, we continue to show our value through our product offering. We, of course, still offer support and training as well since we want to provide a solution that allows teams to focus on their core business without having to worry about their tools.

InfoQ: You started your journey into software development as a Ruby programmer/consultant. Is it just coincidental that GitLab was originally written entirely in Ruby? How important was it for GitLab to be written in Ruby?

Sid Sijbrandij: After working for a submarine company for five years, I discovered Ruby, quite separate from GitLab at the time. I remember thinking it was exactly what I was looking for in a programming tool, it transformed programming from a tedious activity to something enjoyable.

I quickly taught myself Ruby and soon after, made a career change to become a developer. After consulting for a few years at various companies, I came across GitLab and fell in love. While GitLab was originally written in Ruby, some performance sensitive parts have been rewritten in Go.

Ruby enabled GitLab to keep bringing great improvements to the platform month after month. The extensive testing suites and libraries keep the project maintainable at scale.

InfoQ: Later on, some parts of GitLab have been rewritten in Go. What motivated the change? What benefits, if any, did that change bring? How could the split Ruby/Go go in the future?

Sid Sijbrandij: It is hard to do multithreading in Ruby and it is easy to get it wrong. The performance sensitive parts of GitLab (for example accessing the git repositories) need to be multithreaded. These parts were rewritten in Go. We’re very happy with this change since it made everything faster. We’re currently rewriting the git access in Go with the Gitaly project.

InfoQ: Through time, GitLab has come to have a large development team, dealing with a number of different components. Any lessons you learned to make those groups/components communicate efficiently?

Sid Sijbrandij: GitLab employs remote workers from all over the world with 170 employees in 38 different countries. We have always been a remote-only company.

Employing remote workers can be difficult but we’ve spent a lot of time outlining and constantly refining our employee handbook, which is now a running document that details our internal processes, team resources, and more. Our handbook is the “source of truth” where all vital information is stored. Everyone at GitLab has access to this document and is an easy way for employees to refer back to one document for information about projects in the works or company information.

We’ve created a culture of communication and connectedness despite being spread across the world. One of the programs we implemented early on is our daily team call. It lasts for approximately 25 minutes and employees can use that time to share their latest social updates. Prior to these calls, different functional groups present an update to the entire team and explain what they have been working on. All of these updates are recorded using Zoom and are uploaded on our YouTube channel.

We also offer employees the option to travel anywhere in the world by requesting a travel grant. If any GitLab employee would like to collaborate with another colleague in another country they can present a travel plan to their manager and once approved, the employee will receive up to $2,000 to help with travel costs.

InfoQ: You have been recently featured on the “Learn to Code with Me” podcast. One of the questions they asked was about motivation. Besides what you already shared there, could you explain how you managed keeping the GitLab team motivated through a very very long series of monthly releases of your platform?

Sid Sijbrandij: GitLab is fortunate to have a lot of great people working at the company so that certainly helps with motivation. But I also think we are deliberate about our vision, values, and transparent communications across our company. Our vision often serves as a rallying cry for our entire company. We’re all excited about our product and the benefit we provide to the community and our customers. Our values also help with motivation, namely our value of results and efficiency.

GitLab also believes that recognition is a tool that encourages employee motivation. For example, we have a streaming thank you channel so you can always be tapped into seeing and celebrating each other’s wins and efforts. Then finally, our communication style helps with motivation. It’s easy to lose motivation when you don’t understand what is happening at the company or you don’t understand how your role contributes to the company goals. Our daily functional group updates that I mentioned previously help ensure that everyone at the company is aware of what other teams are up to.

InfoQ: What have been the advantages, as well the downsides, of having so many releases at such regular and short intervals? How did the way GitLab managed that process evolve through the years?

Sid Sijbrandij: Early on we decided no matter how we evolved, we always wanted to be an organization dedicated to delivering the latest and greatest tools for developers. In order to do that, setting the expectation that new updates will be released on the 22nd of every month has helped us keep up with the pace of change developers experience daily if not hourly. Over the years, we started branching off the release candidate earlier. Currently, it is done on the 7th of the month.

InfoQ: Staying with this idea of frequent, regular releases, which is linked to one crucial idea emerged in recent years, that of continuous integration and deployment, how would you say that CI/CD is changing the software industry and its practices?

Sid Sijbrandij: CI/CD have quickly become development best practices that are proven to help teams catch errors earlier and release more frequently. As CI/CD become best practices more teams are working CI and eventually CD into their development process. CI/CD adoption fits with the “shift left” notion, where more developers are including early and often testing as part of their development process. This practice of continuous integration and continuous delivery is increasing the quality and shortening cycle times for teams. That’s why we built GitLab to integrate CI/CD functionality with our source code management functionality.

InfoQ: Which role does CI/CD play in your development process?

Sid Sijbrandij: Organizations who take advantage of CI and CD will be more effective. We’ve experienced this ourselves and believe it’s so vital to the development process. We run CI tests on every single commit. We not only use GitLab to build GitLab but we also use it to build our website as well so GitLab CI plays a huge role in our development process.

One great way we are using GitLab CI to improve our development process is in being able to automate some of our code review. Naturally, we have more developers than development leads. With our monthly release cycle, we are constantly looking for ways to save our backend leads time so that they can work efficiently and review all the features submitted by our developers. One thing that we’ve done to improve that process is to write test scripts that can catch common mistakes. These mistakes wouldn’t take backend leads much time to fix if they were doing it once but when you think about all our developers working to merge features before our release date every bit of automation helps. We integrated GitLab CI into our all versions of GitLab so that more teams could improve code quality and hopefully delivery speed as well.

InfoQ: How did GitLab come to make CI/CD a key part of its value proposition? Was it through the experience you gained while building GitLab that you realized how important CI/CD is, or was it the other way round?

Sid Sijbrandij: GitLab’s creator, Dmitriy wanted to have a good CI solution to test GitLab. The most popular open source option is Jenkins but he didn’t like the experience of upgrading Jenkins in the past. Similar to starting GitLab, he thought, how hard can it be and made his own model. He didn’t ask anyone for permission and just did it.

After a year we had some users ask questions about CI and we assigned two people to make it a bit more usable for others. Our team lead suggested to include it as part of GitLab. Dmitriy originally said it was against the unix philosophy of combining “small, sharp tools.”

After some internal debate on CI/CDs value, we ultimately became convinced to integrate it. The results exceeded our expectations. From that point on we never looked back. We began integrating tools to enable emergent properties. We doubled down on the success and now ship CD and metrics as part of the GitLab platform including features such as review apps, canary deploys, and cycle analytics.

InfoQ: What are the key aspects for a successful implementation of CI/CD from your view point?

Sid Sijbrandij: After successfully implementing CI and CD tools a developer will have access to seeing activity that was not possible a few short years ago. For example, with the use of CI and CD a developer can now check a live preview of the code, see changes once they are created and watch a deploy roll out across pods while monitoring the status of each environment.

Prior to the use of CI and CD tools a developer had to wait until the end of the lifecycle to determine what mistake caused a flaw in the code. This process was often time consuming, tedious and ineffective. It also delayed the process and ended up costing developers money by jeopardizing their release date.

You’ll know if your CI and CD tools have been successfully integrated because you’ll start to notice developer teams getting faster. With complete visibility into the development process, developers are able to identify mistakes earlier on in the process and learn from those mistakes before they make a larger impact. This is significant because developers will now be able to learn faster.

InfoQ: Speaking of open-source practices, GitLab has long been a strong proponent of the idea of inner-sourcing, a term coined by Tim O’Reilly to refer to the use of open-source techniques inside corporations. What are in your view the most important practices and how did they evolve since your 2014 post?

Sid Sijbrandij: Since 2014, I have been absolutely convinced if you are an open source organization you need to be practicing inner-sourcing techniques. The most important practice is that every project in the company is open. GitLab has a special setting between public and private called internal. As described in this blog post, this setting allows all people at the company to read the project while excluding external contractors that have accounts on the server.

By doing so, organizations have become more productive by having different team members combine and reuse code. This also allows for improved security as developers can more easily spot and identify security flaws in their code. Over the last three years this has become more popular with more enterprises using open source code. Today more developers than ever before are familiar with the forking workflow where you can make suggestions without having to write access to a repository.

About the Interviewee

Originally a computer programmer for a personal submarine company, GitLab CEO Sid Sijbrandij was first introduced to GitLab while working as a (self-taught) Ruby programming developer. With Sid as the leader of the company, GitLab has grown significantly, closed $20 million in Series B funding led by August Capital and delivered on promises to solve the complete developer lifecycle for customers like IBM, Macy's and Verizon.