Just recently, Gartner recognized DevOps Value Stream Delivery Platforms as an emerging category in the software marketplace by publishing the new Market Guide for DevOps Value Stream Delivery Platforms (what we're calling a DevOps Platform). The Gartner report may not include the name "Kamil Trzciński," but I want to recognize his contributions to this DevOps Platform category. If it weren't for his idea, we wouldn't have launched GitLab as an all-in-one, single DevOps application. It's a product that changed how engineers build software.
It all started in 2015 with a GitLab runner that was built by one of the contributors from the wider community, Kamil Trzciński, who is now a distinguished engineer, Ops and Enablement, at GitLab. He wrote a runner that was faster, easier to run in parallel, easier to install, and easier to contribute to. We liked his runner so much that we deprecated ours to use his, and asked him to join our engineering team.
At that time, GitLab had two products: GitLab Source Code Management (SCM) and GitLab Continuous Integration (CI). We were a DevOps company, but one with two key products that worked well together with some overlaps in code. Then Kamil made a suggestion that changed our company and has now defined a category: "Why don't you combine the two to make GitLab a single application?"
Dmitriy Zaporozhets, GitLab co-founder, thought there was no need to do it because the products were already perfectly integrated. And my gut reaction was no. Many of our customers were already building their own, DIY DevOps platforms with multiple tools. Combining GitLab SCM and GitLab CI would mean they got two tools where they expected only one. Our customers didn't seem to want an all-in-one tool, so why would we build it?
But as Kamil pointed out, there is a considerable amount of overlap between GitLab SCM and GitLab CI, and our engineers and users were spending a lot of development time and effort in managing functions and libraries that appeared in both technologies. In the end, we realized that it actually made a lot of engineering sense to build an all-in-one DevOps platform. At first, our customers weren't sure about it – some even asked us to turn the CI function off in GitLab SCM because their engineers started using that over their official CI solution. But once we explained how much more efficient this made their application building efforts, they were sold. GitLab all-in-one meant one data store, fewer clicks, less context, and more efficiency in their application development processes. Kamil's idea was brilliant. Our developers were able to save development effort and didn't have to hop around between tools, same with the developers and operators who use GitLab to build their applications.
We wouldn't be where we are today if we didn't welcome the contributions of everyone in our globally distributed, open source software community. Just think, within one year, Kamil went from being a GitLab contributor who wanted to learn Go, to building a GitLab runner that blew us away, to redefining the entire business strategy for our company. It goes to show that companies are smarter when everyone can contribute.
Watch the video below to hear Kamil describe how he came to join GitLab and made a proposal that went on to define the DevOps Platform category.
Gartner, Market Guide for DevOps Value Stream Delivery Platforms, Manjunath Bhat, Hassan Ennaciri, Chris Saunderson, Daniel Betts, Thomas Murphy, Joachim Herschmann, 28 September 2020
Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.