A few months ago, GitLab - and the DevOps Platform category - reached a big milestone. Two influential analyst firms, Gartner and Forrester, issued reports that validate the market is moving from point solutions to a platform. They officially recognized DevOps platforms as a category. A category we created.
This is the story of how we did it.
I am thrilled that we created a category. Very few companies are able to do so. Other examples are Dropbox for the file hosting service category; Hubspot for inbound marketing; and Slack for searchable logs of all communications and knowledge. The backstory is that we did not start with a vision for creating a category. GitLab didn’t even begin as a business. It started with a programmer’s need for a great open source collaboration tool.
Now, nearly 12 years after GitLab’s very first commit, I want to share what we learned on the journey to creating the DevOps Platform category.
Category design begins with solving your own problem
Dmitriy Zaporozhets needed a tool to collaborate with his team. His employer at the time wasn’t willing to buy the tool he wanted, so he decided to build it himself. He created GitLab in 2011 from his home in Ukraine.
Together with Valeriy Sizov, Dmitriy started to build GitLab as a developer collaboration tool based on Git. Developers from around the world quickly began using it. In the first year, 300 people contributed to improving it.
GitLab was not founded with a grand plan or a 10-year vision to create a single platform for the entire software development lifecycle. The reality is that GitLab began with one person who had a need and built a solution to meet it.
Categories are discovered, not planned
One of the things I respect most about Dmitriy is that he built GitLab as open source, allowing others to use his ideas and build on them in their own ways. He was so committed to open source that he was supportive of me commercializing his work.
I encountered GitLab for the first time in 2012. I recognized the value that it could provide for other software companies, but I also saw the challenges in installing and managing it. Not everyone had the means to do that. I saw the potential for GitLab to be commercialized as a SaaS business: cloud-based source code management (SCM) for everyone.
I was nervous about commercializing Dmitriy’s work, so I reached out to tell him what I was working on. He was happy that what I was doing could help GitLab become more popular and attract even more community contributions, which it did.
This was our exchange:
In late 2012, similar to how Dmitriy made an SCM tool for his own need, he built his own continuous integration (CI) tool called GitLab CI, a tool that ran tests to check the code for conflicts.
Meanwhile, large organizations began adopting GitLab, and Dmitriy tweeted that he wanted to work on GitLab full-time. I got in touch with him to work out an arrangement for him to join GitLab, the company. But when I went to the local Western Union branch to make a wire transfer, I had to convince the teller that I knew Dmitriy and was not falling victim to wire transfer fraud - a common issue at the time.
We then introduced GitLab Enterprise Edition with features asked for by larger organizations.
Then, in 2015, we noticed that a community contributor named Kamil Trzciński built a far better runner than we did (ours was in Ruby and single-threaded, his was in Go and multi-threaded). It was so much better that we decided to adopt his runner as the standard.
Through iteration, building on each other’s ideas, and being open to ideas from outside our company, we continued to build two great tools for SCM and CI.
However, I admit that there were critical moments when our willingness to allow others to contribute would be tested. When Kamil joined GitLab full-time we could not have predicted that he would help us discover a new category. Not by contributing a better CI runner but by changing the way software is developed.
Kamil suggested a radical idea: to integrate GitLab SCM and GitLab CI into one tool.
Disagree, commit, and disagree
Dmitriy and I disagreed with Kamil. Dmitriy believed in the Unix philosophy where one program should do one thing well; if you want a program to do something else, start a new one. I thought that customers wanted separate tools for separate use cases. The market was filled with specialized point solutions.
Many business leaders say, “Disagree and commit,” and we did. We disagreed, and committed to continuing to build two different products.
But Kamil persisted in making a strong case for why SCM and CI should be integrated. This is when our operating principle of disagree, commit, and disagree was born. Every decision can be changed, and the best decisions should often be made despite management’s opinion.
Dmitry and I relented and took Kamil’s suggestion over our opinion and the opinion of the market.
It was a lazy choice because combining SCM and CI would mean having only one Ruby on Rails app to maintain. We could avoid duplicating the interface and the data, making it more efficient to develop code. But it also ended up being a far better user experience, giving customers a much faster way to set up CI, and faster cycle times by not having to switch between apps. GitLab became a platform with one UI, one data store, one way to serve up information, and one way for a company to collaborate and be on the same page at the same time.
By taking the suggestion of someone new to the team and creating the world’s first DevOps platform, we changed the course of our company and, eventually, the whole software development industry. I am proud to be a part of the DevSecOps Platform story because it is a story about allowing everyone to contribute, especially when someone else has the best idea.
It is important to disagree and commit but still disagree. That is how Dmitriy and I realized that there could be one platform for the entire software development lifecycle, and eight years later, Forrester, Gartner, and the market see it, too.
Today, we have a DevSecOps platform.
Looking to the future, we hope to create another category: AllOps, a single application, for all R&D that includes DevSecOps, ModelOps DataOps, and Service Desk.
In the future, we will expand support for ModelOps and DataOps to give customers the ability to manage data and its associated AI/ML models in a similar fashion to their software projects.
And, because customers need the ability to triage application incidents directly where their applications are built and deployed, we will continue to expand our Service Desk offering.
It is GitLab’s mission to ensure that everyone can contribute. Our vision for AllOps moves us further in that direction - to deliver a single application for all innovation.
