Sid Sijbrandij and the case for an interesting life

Sid Sijbrandij had a respectable decision to make. Leaving university, he could take a job in technology consulting or help build recreational submarines. He made a scorecard. Salary, prospects, colleagues: the ordinary ingredients of an ordinary sensible life. Consulting did well. Then he added a criterion that was harder to explain to his father: how much he would enjoy telling people about the job.

Submarines won. He spent more than four years at U-Boat Worx. His father eventually came around, enjoying the opportunity to tell other people what his son was building. It is a small family story with a useful complication. Sid wanted numbers to help him choose, but he also wanted the numbers to represent something he cared about. A spreadsheet, properly trained, could accommodate a little adventure.

That tension runs through the life of GitLab’s Dutch co-founder and Executive Chair. He likes explicit rules, written decisions and measurable results. He also keeps finding reasons to attempt things that sound slightly improbable at dinner: a company whose colleagues live around the world, businesses built around freely available software, a trail of enormous sculptures through San Francisco.

A programmer arrives after the first commit

Sid’s legal first name is Sytse; he asks people to call him Sid. His surname is pronounced “see-brandy.” He studied Management Science at the University of Twente in the Netherlands. Software became a consuming interest after he encountered Ruby in 2007 and taught himself to program. At the Dutch Ministry of Justice and Security, he worked on Legis, a project developing web applications to support lawmaking. His route into developer tools passed through both submersibles and legislation.

GitLab already existed when he discovered it in 2012. Dmitriy Zaporozhets had started the project in Ukraine in 2011, working with Valeriy Sizov. Sid saw a tool that let programmers collaborate, with code they could inspect and improve themselves. He was impressed by its quality and the contributions it had attracted. The appeal was practical: the people using a collaboration tool could help build the collaboration tool.

He tested interest in a hosted service on Hacker News. At first, the post did little, so he went to make pancakes. Then his phone began delivering evidence that the internet had noticed. He asked Karen to take over for a few minutes. He spent the rest of the day answering questions. In the mythology of company creation, a missed breakfast is refreshingly plausible.

In 2013, Zaporozhets wanted to work on GitLab full time. Sid partnered with him, and the company introduced an Enterprise Edition for organizations asking for additional features. Incorporation followed in 2014. The sequence matters. A working project and interested users came first; the corporate machinery arrived afterward. Sid’s contribution was to help give the project a commercial life.

The office people stopped visiting

In 2015, the team went to Mountain View for Y Combinator’s winter program. GitLab already had paying customers; joining an accelerator was a chance to learn how to grow. Sid described watching other startups make rapid progress and feeling that his own team needed to ship faster. The lesson was to reduce a task until something useful could be delivered, then improve it.

The same willingness to revise a plan shaped GitLab’s working arrangements. Early colleagues were in Serbia, Ukraine and the Netherlands. Moving everyone was impractical. People hired nearby could use an extra desk in Sid’s home, but after a few days they stopped coming. They were still online, and the work continued.

After Y Combinator, GitLab tried a San Francisco office. Advice that remote work might fail outside engineering seemed reasonable enough to test. The familiar pattern returned: people came in, then stopped. Their communication already happened through shared documents, messages, video calls and GitLab itself. The experiment made a commute look like an expense requiring an explanation.

There is something revealing in Sid’s account of this. He entertained the conventional advice. He tried the office. He let the outcome change the policy. Later, remote work became closely associated with his public identity, but its early history contains a founder paying attention to what colleagues actually did. The grand principle had been preceded by some empty desks.

A company you could read

Working across countries raised a problem that an office can conceal: information has to travel without everyone being present. GitLab developed a public handbook describing how it operates. The handbook entered the website repository in 2015. By 2023, Sid described it as more than 2,700 web pages. That is a substantial answer to anyone who thinks company culture fits on a poster.

The handbook-first approach asks people to document changes and direct colleagues to the relevant page. It gives a new employee somewhere to look before interrupting someone. It also makes the operating system of the company available for inspection. A rule that can be read can be questioned, revised and used by someone who missed the original conversation.

“Working remotely is easy. The challenge is working asynchronously.”

Sid Sijbrandij, 2023

Sid’s distinction is demanding. Asynchronous work means a colleague can consume information and contribute on a different schedule. It requires preparation: writing things down, preserving context, making decisions legible. Moving a meeting onto a screen does little for somebody asleep on the other side of the world.

Social life required intention too. In his 2023 account, new hires initiated five virtual coffee chats. Gatherings in person were for meals, excursions and small-group conversations. He questioned flying people somewhere to watch presentations they could have watched at home. The logistical efficiency has a sociable purpose: reserve shared time for activities that benefit from sharing it.

When a colleague changes the founders’ minds

Sid’s preference for iteration had a consequential test inside the product. GitLab’s code collaboration application and its continuous integration tool were separate. Kamil Trzciński, a community contributor who joined the company, argued for combining them. Both founders initially resisted. Sid thought customers wanted to choose and combine their own tools.

Trzciński persisted. The founders reconsidered, and the applications were brought together. Sid later credited that argument with helping create the platform approach: development work and the machinery for testing it could happen in one application. A colleague’s refusal to let a settled answer remain settled became part of the company’s account of itself.

That story gives substance to the language of contribution. Contributions can include an inconvenient opinion. Letting someone improve a product may require letting them disturb its architecture and the founders’ confidence. Sid’s version preserves the embarrassment of having opposed an idea he later embraced. It makes the lesson rather easier to believe.

On October 14, 2021, GitLab became publicly traded on Nasdaq. By then, its software served an estimated 30 million registered users. Those figures describe a business that had traveled far beyond a hosted-service waitlist. The pancake episode remained in its history, but the company now had public shareholders and responsibilities that could not be handled by answering comments all afternoon.

Giving the next project a company

Through Open Core Ventures, Sid has tried to repeat part of that journey for other software projects. The firm starts companies around open-source work and brings in founders and operators. Its portfolio includes Fleet, FlowFuse and Mermaid Chart. The proposition is that a project people already use may become a business that can support continued development.

His commercial views are quite specific. In a July 2026 essay, he argued for paid proprietary features alongside open-source software, while recommending that even proprietary code be visible for contribution. He separates the needs of individual contributors from the governance needs of managers. A tool can be widely available while its business earns money from organizational control.

He is equally particular about whose feedback deserves attention. In June 2026, he advised founders to prioritize their heaviest users over prospects promising to buy if one more feature appears. People who already rely on a product know where it fails. A sales objection can generate work without generating a customer. This is the more unsentimental side of his enthusiasm for participation.

He also co-founded Kilo Code, an open-source platform for AI-assisted development. Anaconda acquired it on July 15, 2026. The attraction, in Sid’s account of the deal, was the fit between Kilo’s model choice and Anaconda’s enterprise experience. Another developer-tool venture had carried him into a different market, with a familiar interest in open software and a business built around it.

A city with room for the improbable

Sid moved from GitLab CEO to Executive Chair in December 2024. His activities extend into philanthropy: he serves on the GitLab Foundation board and leads the Sijbrandij Foundation with Karen. The GitLab Foundation, launched in September 2022, focuses on improving lifetime earnings through access to opportunities. Its ambition is for a million more people to be able to afford a better life.

In San Francisco, Sid and Karen’s Big Art Loop takes a more visible form. Announced with the city in September 2025, it plans up to 100 temporary large sculptures over three years. Existing works come out of storage and into public spaces. The proposed route is walkable and bikeable: art encountered on the way somewhere, with no admission desk to negotiate.

The project involves curators, engineers, artists and city agencies. Even an improbable idea needs permits. That detail suits Sid’s story: enthusiasm becomes an organization, and the organization has to make the enthusiasm work. A sculpture in a warehouse, like a promising software project without support, has possibilities that remain out of reach.

His early career scorecard offers a pleasing way to understand these choices. He made room for work he would want to talk about, then spent years on the less glamorous tasks that let it happen. Submarines needed building. Software needed customers. Distributed colleagues needed written context. Public art needs somewhere to stand. The interesting life comes with quite a lot of administration.