GitLab went public on the NASDAQ this Thursday, opening at $77 per share — well above its IPO price of $77 — and quickly climbing to give the company a valuation north of $11 billion. For a company built around an open-source code repository that started as a side project by Ukrainian developer Dmitriy Zaporozhets in 2011, it’s a remarkable milestone.
But beyond the financial headlines, GitLab’s IPO is significant for what it says about the viability of open-source business models, the competitive dynamics of the DevOps platform market, and where developer tooling is headed.
The Open-Core Model, Validated#
GitLab has been one of the most visible practitioners of the “open-core” business model: a substantial open-source community edition (CE) that anyone can self-host for free, paired with proprietary enterprise features that generate revenue. Their pricing tiers are transparent, and they’ve been remarkably open about their internal operations — their handbook is public, their strategy documents are public, even their OKRs are public.
This model has always had its critics. Open-source purists argue that withholding features creates a two-tier community. Investors have historically been skeptical about building a business on software anyone can fork. And competitors have tried to undercut open-core companies by offering their proprietary features as open-source alternatives.
GitLab’s IPO doesn’t settle those debates, but it does demonstrate that open-core can produce a company with real revenue ($233 million ARR at last report), real growth, and enough market confidence to go public. That matters for the entire open-source ecosystem, because it provides a clear proof point for founders and investors considering this model.
Contrast this with the struggles other open-source companies have faced. MongoDB had to create the SSRL license to prevent cloud providers from offering their software as a service. Elastic relicensed away from Apache 2.0 for similar reasons. Redis Labs added the Commons Clause. Each of these moves generated significant community backlash. GitLab, by contrast, has maintained a relatively stable relationship with its community edition while growing its enterprise business. That’s not easy to pull off.
The Single Platform Bet#
What sets GitLab apart strategically is their commitment to being a single application for the entire DevOps lifecycle. Source control, CI/CD, package registry, security scanning, monitoring, issue tracking — it’s all in one product. This is a fundamentally different approach from GitHub, which has been assembling capabilities through acquisitions and integrations (Actions for CI/CD, npm for packages, Dependabot for security, Codespaces for development environments).
I’ve used both platforms extensively, and the trade-offs are real. GitLab’s integrated approach means everything works together without configuration — your merge request shows CI results, security scan findings, and deployment status in one view. But it also means you’re locked into GitLab’s implementation of each capability. If their CI runner performance doesn’t meet your needs, or their security scanning misses things that a specialized tool catches, you’re stuck with workarounds.
GitHub’s approach gives you best-of-breed flexibility through its marketplace and integrations, but you pay for it in configuration complexity and the occasional integration that breaks after an update.
For smaller teams, I increasingly recommend GitLab because the operational overhead of managing multiple tool integrations outweighs the benefits of best-of-breed selection. For larger organizations with dedicated platform teams, GitHub plus specialized tools often makes more sense. But this is a genuinely close call, and the gap is narrowing.
What This Means for Self-Hosted Infrastructure#
One aspect that doesn’t get enough attention: GitLab’s self-hosted offering remains genuinely viable, and for many organizations, it’s the right choice. Financial institutions, government agencies, healthcare organizations, and companies with strict data sovereignty requirements can run the full GitLab stack on their own infrastructure.
I’ve deployed GitLab on-premises for clients in regulated industries, and while it’s not trivial — the Omnibus package is large, upgrades require planning, and high-availability configurations demand real infrastructure expertise — it works. This is increasingly rare in a world where most developer tools have gone SaaS-only.
The IPO pressure could change this calculus. Public markets want growing SaaS revenue with high margins. Self-hosted licenses are lumpy, harder to upsell, and carry support costs. I hope GitLab continues to invest in their self-hosted offering, but I’ll be watching their resource allocation carefully over the coming quarters.
The Competitive Landscape#
GitLab’s IPO happens against a backdrop of intense competition in the DevOps platform space. GitHub, backed by Microsoft’s resources, continues to ship features at a remarkable pace. Atlassian’s Bitbucket still has significant enterprise penetration, though it feels like it’s losing momentum. AWS CodeCommit exists but is rarely anyone’s first choice.
The more interesting competition might come from the edges. Smaller tools like Gitea and Forgejo are picking up steam in the self-hosted space. Specialized CI/CD platforms like CircleCI and Buildkite continue to push the performance envelope. And the entire “platform engineering” movement — where companies build internal developer platforms using tools like Backstage — represents a different approach to the same problem GitLab is solving.
My Take#
I have a soft spot for GitLab’s story. A company that started as an open-source project, maintained its commitment to transparency and community, and grew into a public company without abandoning its core values — that’s rare. It’s not perfect; the open-core tension is real, and some of the feature gating decisions feel arbitrary. But compared to the licensing gymnastics we’ve seen from other open-source companies, GitLab’s approach has been remarkably consistent.
What I’m most curious about is how being public affects their development velocity and decision-making. Quarterly earnings pressure has a way of shifting priorities from “what’s right for the product” to “what moves the revenue number.” GitLab’s radical transparency — including their public product roadmap — means we’ll be able to watch this play out in real time.
For now, this is a good day for open-source business models. Not because financial success is the ultimate measure of an open-source project — it isn’t — but because it demonstrates that you can build sustainable businesses that fund open-source development at scale. And we need more of those.
Part of the Developer Landscape series, exploring the tools, platforms, and business models shaping software development. GitLab’s journey from side project to public company is one of the more compelling stories in recent developer tooling history.