GitHub tends to get the press, but GitLab is getting the IPO. The company filed its S-1 September 17, touting a $233 million run rate, more than 2,600 contributors to its open source platform, and a 100% remote, 1,350-strong workforce. Impressive all around.
What’s perhaps most interesting is how GitLab has carved out a market for itself in GitHub’s long shadow. GitHub expects 100 million developers to be using its platform by 2025 (never mind the fuzzy math used to get there) and is the default place for developers to push their open source code. GitHub is also a primary place for corporations to enable their development teams to work together.
But GitHub isn’t the only place. As GitLab’s numbers demonstrate, corporate collaboration around code is happening in a big way on GitLab. This could make GitLab an obvious acquisition target for a cloud vendor that wants to outflank Microsoft, which acquired GitHub in 2018. Regardless of what GitLab may mean for investors or shareholders, however, what it can mean for how enterprises build and run software is what makes it interesting.
The same but different
Wondering how to differentiate between GitHub and GitLab? The standard shorthand is that GitLab is for your private repositories, whereas GitHub is for public repositories. It’s not strictly accurate, but close enough. In terms of functional differences between the two code repositories, a number of comparisons are posted online (see Usersnap, SpectralOps, or hactivist).
Although both are code repositories today, GitLab, unlike GitHub, started as a collaboration tool for developers. That original vision has since been fleshed out to incorporate end-to-end, highly integrated development and deployment tools, with tightly integrated continuous integration and continuous delivery (CI/CD) as a key selling point. You can get to the same base functionality with GitHub, but some assembly is required, whereas GitLab takes care of all that for you. GitLab offers a single application that is opinionated while allowing flexibility and choice (that is, it comes out of the box with integrated CI/CD, for example, but you can swap in your preferred CI/CD tools).
Is one better than the other? That depends on what you’re trying to accomplish. For companies that want to bring together development, operations, IT, security, and business teams, GitLab is the answer. In my experience, GitHub leaves a lot of corporate constituencies out of the software development and deployment story. But then, GitHub isn’t really trying to be the next GitLab, just as GitLab doesn’t aim to be an incarnation of GitHub.
In some ways, GitLab’s vision may be bigger, if harder to pull off.
All your devops are belong to us
In GitLab’s S-1, the company states an all-too-familiar platitude: “Today, every industry, business, and function within a company is dependent on software. To remain competitive and survive, nearly all companies must digitally transform and become experts at building and delivering software.” What’s different about GitLab, however, is that the company takes a holistic approach to enabling that transformation. Developers are often tasked with the heavy lifting of digital transformation, but GitLab’s platform is intended to include parties normally not associated with software development. Why? “Having all teams on a single application with a single interface represents a step change in how organizations plan, build, secure, and deliver software.”
All teams? Yes. According to the S-1, the GitLab platform includes everything “from project planning ... to source code management ... to continuous integration ... to static and dynamic application security testing ... to packaging artifacts ... to continuous delivery and deployment ... to configuring infrastructure for optimal deployment ... to monitoring it for incidents ... to protecting the production deployment … [to] managing the whole cycle with value stream analytics.” Not much left out there. As with GitHub, most customers, the S-1 notes, start using GitLab to enable their developers, but the company’s expectation (and, it would seem, experience) is for customers to keep expanding their use of the platform well beyond developers.
Will it work? That remains to be seen. As the company highlights in its S-1, “The market for our services is new and unproven and may not grow.” So far, signs are good, but it’s reasonable to assume that many enterprises will opt for a best-of-breed approach to devops, piecing together components. There’s ample precedent for this: In the cloud, we may have started with attempts at delivering holistic platform-as-a-service offerings but the market voted for the AWS approach. As RedMonk Analyst Stephen O’Grady explained, “Less than a decade after the infrastructure-as-a-service (and thus, cloud) market was born, the default expectation gradually became base-level infrastructure primitives available as a web service, paid on use and available more or less instantly.”
But that’s where the market was. It’s arguably not where it is today or where it’s moving, given the need for every organization to operate at high velocity. As O’Grady notes in that same post, “If the first era of the cloud is defined by primitives, its days are coming to an end. The next is likely to be defined by, as the computing industry has since its inception, the abstractions we build on top of those primitives.” The need for speed increasingly demands that developers (and the companies that employ them) buy into platforms that abstract away the complexities of building and running software.
So no, you’re not likely to see GitLab challenge GitHub to be the first to host 500 million public, open source code repositories. That’s not its game. Rather, GitLab is trying to make it easier for companies to make software central to how they run, hosting a swelling number of private code repositories with them. Game on.