How Open-Source Processes Power Internal Collaboration

man writing with magic marker during business meeting

Everyone Can Contribute: How GitLab Uses Open-Source Processes to Power Internal Collaboration

It was a pleasure to present at the InnerSource Summit on how GitLab breaks down barriers between teams, and between the company and the open source community.


Ownership Without Bottlenecks: The DRI Model

Engineering priorities are driven by a Directly Responsible Individual (DRI) — typically the Product Manager — working in close collaboration with engineering managers, sales, support, and other stakeholders. The PM and Engineering Manager jointly manage the backlog, ensuring alignment without creating approval gridlock.


Radical Transparency by Default

Nearly every epic and its child issues are open for comment — not just to employees, but to the general public for a significant portion of them. This isn’t just a cultural nicety. It means that the person who spots a problem is often the best person to fix it, regardless of which team they’re on.


The Lifecycle of a Change

Anyone can author a change — a team member who owns that section of code, a colleague from another team, or a member of the public.

Here’s how it flows:

  1. The author builds and tests the change, validating it manually and through automated test cases and security scanning
  2. The change is labeled to the appropriate owning team
  3. A team member reviews it, including verifying it qualifies as a Minimal Viable Change (MVC), living the value of iteration
  4. A bot determines whether the change requires additional maintainer review across:
    • Frontend
    • Backend
    • Database
    • Security
  5. After maintainer approval, the change is merged, deployed to SaaS, and later bundled into the next monthly release for self-hosted users

Why This Works

The real unlock is simple: teams don’t have to wait on other teams.

If an engineer sees something broken or suboptimal in code owned by another team, they can open a Merge Request (MR) and fix it themselves. This applies equally to free users, paid customers, and the public — anyone can improve the product or even the company handbook.

Contributors are celebrated through the GitLab Heroes program, recognizing the community members who make GitLab better for everyone.


This is what “everyone can contribute” looks like in practice — not as a slogan, but as an operating model.

Leave a Reply

Discover more from Wayne Haber | Engineering Leader

Subscribe now to keep reading and get access to the full archive.

Continue reading