GitLab

Public work did not mean public rule

An October 2011 GitLab repository commit titled “init commit” preserves an early Rails application for managing Git repositories.¹ By July 2021, GitLab reported approximately 1,350 team members in more than 65 countries and more than 2,600 code contributors. Its October prospectus offered public investors Class A shares while leaving almost all post-offering voting power with holders of Class B shares.²³

Those endpoints contain the institution in miniature. GitLab made source, issues, proposed changes, operating rules, and much of the reasoning around work visible to people who did not share an office. Community contributors supplied code; workers used the same issue-and-merge-request form to coordinate; free users could inspect and adapt a substantial product; enterprise customers funded development; and public investors supplied capital.²⁴⁵⁶³ Yet visibility did not give each participant the same power. Maintainers decided what merged, managers and directly responsible individuals decided work, GitLab decided the boundary between free and paid capabilities, and high-vote shareholders retained voting control over matters submitted to shareholders.⁴⁷⁸³

The case therefore turns on a distinction more precise than “open” versus “closed.” GitLab distributed rights to inspect, propose, reuse, and publicly contest. It concentrated rights to integrate, price, employ, and vote. The relationship between those two arrangements—rather than either one alone—became GitLab's model for growth.

An open project acquired a commercial boundary

In a 2014 shareholder letter, Dmitriy Zaporozhets and Sytse Sijbrandij credited Zaporozhets and Valery Sizov with starting GitLab in 2011. The letter says Zaporozhets initially improved it after a separate day job, Sijbrandij began paying him to work on it in 2012, and a commercial entity formed around the project in 2013. It describes the resulting model plainly: an open-source edition alongside a proprietary Enterprise Edition, with subscriptions to the latter supplying most revenue.⁹ The final prospectus dates the Delaware corporation to 2014, so the sources describe successive entities and roles rather than one uncontested founding moment.¹⁰

Open core converted one kind of contribution into another. Free software attracted users and code; subscriptions funded paid product work and company operations. In its prospectus, GitLab called this a “dual flywheel”: company research and development combined with outside contributions, while the free tier encouraged adoption, contributions, and sales leads. The same filing said features aimed primarily at individual contributors were generally open source, whereas features primarily valued by managers, directors, and executives were source available and sold in paid tiers.⁶ These are management's descriptions of its growth mechanism, not independent estimates of how much revenue any contribution caused.

The legal artifacts make the boundary concrete. At the pinned 2021 release, GitLab's root license gave broad MIT rights to content outside specified directories and restrictions, including use, modification, distribution, sublicensing, and sale. Code under ee/ followed a different license: production use required a valid subscription, and copying, publishing, distribution, sublicensing, and sale beyond the grant were forbidden.⁵⁸ After GitLab combined Community and Enterprise development in one repository in 2019, its own announcement emphasized that the codebase was unified but the licenses were not.¹¹

One repository could therefore lower duplicate work and contribution friction without creating one set of rights. Customers gained a self-hostable, modifiable core. The company kept a paid product boundary and the authority to move capabilities within it. Contributors could inspect more than they could freely redistribute, and a visible feature was not necessarily a commonly owned one.

A contributor could change the product without governing it

Sijbrandij's prospectus letter recounts an episode in which community contributor Kamil Trzciński built a continuous-integration runner as a separate project. According to that account, GitLab's founders initially disagreed with his proposal to integrate source management and continuous integration; Trzciński persisted, the integrated approach was accepted, and he later joined the company.¹² The story shows a contribution changing both the product and the coalition around it. It is also a founder's retrospective chosen for an investor document, not a representative sample of rejected and accepted proposals.

Independent organization-design researchers described the mechanism at larger scale in 2020. Work was decomposed into issues; contributors could select tasks and propose small changes; communication and decisions were preserved in durable artifacts; and maintainers approved changes to protect code quality. The article used Mozilla and Valve as comparison cases while emphasizing that GitLab retained a conventional reporting hierarchy and assigned each outcome to a directly responsible individual.⁴ The public handbook made the distinction explicit near the IPO: gathering evidence should include broad input, but final decisions were hierarchical rather than democratic.⁷

That combination can make voice consequential without making authority equal. A persuasive outside proposal can change the product, and a public record lets others inspect what happened. The contributor still depends on a maintainer to merge the code and on company leaders to alter product strategy. Participation is a route into judgment, not a constitutional right to prevail.

Debian tested the terms of participation

A 2017 dispute over Debian's replacement for its Alioth development service shows how that boundary looked to a prospective institutional user. LWN reported that Debian participants valued GitLab's interface and continuous integration while objecting to its dependency load, open-core feature split, and then-current contributor agreement. Some feared that a feature useful to a large community might remain in the paid edition, leaving Debian to maintain a fork or patches. Sijbrandij responded that GitLab wanted its open-source edition to work for open-source projects but did not believe a wholly free model could compete with proprietary GitHub.¹³

Debian participants initially moved toward another platform. Later that year, Debian Project News recorded that GitLab was replacing its contributor license agreement with a Developer Certificate of Origin and that GitLab Community Edition would become the basis for Salsa, Debian's forthcoming collaborative development server.¹⁴ The sequence does not prove that Debian caused the license-process change. It does show a changing coalition: a large community could withhold adoption, make the costs of the product boundary public, and later join on changed terms.

Debian did not receive a formal vote over GitLab's company or tier structure. Its leverage came from exit, public argument, contribution, and the legitimacy of a consequential open-source community. This resembles the Linux ecosystem, where lawful reuse and fork rights protect a commons without equalizing influence over the shared release. GitLab added a corporate product boundary to that problem: a community could contest not only whether code merged, but also which license and paid tier would govern it.

The handbook turned policy into a work object

GitLab's first preserved team-handbook commit in March 2015 already contained the operating pattern. It told workers to create issues for work, give the community chances to help, use asynchronous channels, document answers, and make company data shareable by default. It invited disagreement and escalation without repercussions. The same artifact ranked emergencies from paying subscribers above other work, directed unhappy workers to a boss or the CEO, and reserved legal signatures to the company's officer.¹⁵

The handbook did more than communicate policies after leaders chose them. By putting rules in a repository, GitLab made a proposed organizational change look like a proposed code change: identify a problem, edit a shared artifact, request review, preserve the discussion, and announce the merged difference. This supported coordination and common understanding across time zones because a worker did not need to attend the original meeting to find the current rule or its revision history.⁴

The mechanism also moved work. Someone had to write an issue, search before asking, turn a conversation into a durable answer, keep the handbook current, and make tacit context legible. The independent case study identifies documentation overload and limits on what could be shared as boundary conditions, not measured harms across GitLab's workforce.⁴ A public handbook records declared rules and some changes; it does not show whether every worker had equal time, confidence, language access, or managerial support to challenge them.

The early handbook thus joined voice to hierarchy rather than abolishing either. “Work out in the open” widened who could see and help. Subscriber priority, manager escalation, maintainer review, and officer authority determined which visible claims became binding. GitLab made its operating constitution unusually inspectable while leaving amendment rights unequal.

All-remote work widened geography and relocated burdens

GitLab's prospectus says its workforce had been entirely remote since inception, and its 2015 team handbook already encoded asynchronous rules for that distributed work.²¹⁵ The 2020 case study described an organization with no offices, more than 1,000 workers in over 60 countries, asynchronous work, and a large public handbook. The authors connect geographic flexibility with access to talent and with workers' ability to remain in places they preferred. They also identify isolation, mentoring, socialization, cultural transmission, documentation load, and work-home boundaries as unresolved challenges.⁴

By July 2021, GitLab reported approximately 1,350 workers in more than 65 countries. Its prospectus said that the workforce included people directly employed by GitLab, people employed or self-employed through professional-employer organizations, and independent contractors. It warned of legal uncertainty around classification, enforceability, local employment rules, home technology, information security, collaboration, and culture.¹⁶ Risk factors identify exposures; they do not establish that every risk became a harm.

The benefit and burden were linked. Removing the office boundary widened where people could participate and reduced dependence on co-location. It also shifted connectivity, workspace, social connection, written self-service, and boundary management into homes and individual routines. Available sources do not compare pay, benefits, promotion, dismissal, voice, or well-being across GitLab's employment categories and countries. Global reach is not evidence of globally equal terms.

The IPO made transparency both evidence and risk

The public-market transition made GitLab's operating model more visible while adding a new legal boundary around disclosure. In its prospectus, the company called transparency a core value and acknowledged that competitors could read its handbook and other public material. It also warned that rapidly changing, widely contributed material might be inaccurate or outdated, and that public company rules such as Regulation FD required additional controls over what the organization disclosed.¹⁷ Publicness was not an unlimited promise; it became a practice managed alongside securities law, confidentiality, and competitive risk.

The offering expected to provide GitLab approximately $610.6 million in net proceeds. Public investors received Class A shares with one vote each. Class B shares carried ten votes each and were expected to retain 99.1 percent of voting power immediately after the offering; directors, executive officers, and holders of at least five percent, with affiliates, were expected to hold 62.3 percent.³ The offering broadened access to the company's economic future and capitalized further work. It did not translate GitLab's participatory work surfaces into equal shareholder governance.

That is the case's sharpest lesson for autonomy with evidence. Evidence can travel farther when code, rules, proposals, and rationales are inspectable. A worker, customer, contributor, or prospective adopter can challenge a claim with a specific artifact rather than relying only on access to a private meeting. Whether the evidence changes action still depends on integration rights, employment authority, customer leverage, capital control, and the credibility of the coalition advancing it.

GitLab's public record is rich but asymmetric. Repository and handbook artifacts show rules and accepted changes more readily than abandoned work or quiet exit. Contributor totals do not distinguish paid from unpaid labor. The independent case is descriptive rather than causal and does not contain a representative workforce survey. The prospectus is authoritative for securities terms and useful for contemporaneous risks, but its mission and growth claims are management representations.

The next decisive evidence would connect the visible process to the distribution of consequences: which proposals were rejected and by whom; how work, pay, protection, and advancement differed across employment forms and locations; when community opposition changed tiering or license decisions; and whether low-vote investors, workers, customers, and contributors could obtain remedy when a documented challenge still lost. GitLab showed that an institution can make power unusually legible. It did not show that legible power is shared power.