self-hosted Ultimate seat count limitations breaking open-source contribution workflow

On a self-hosted GitLab Ultimate instance, external contributors are blocked from using the standard fork-and-merge workflow because forking into a personal namespace makes them an “Owner,” which consumes a license seat.

The way Ultimate enforces a fixed seat count has broken our long-standing contribution workflow for external contributors. This was not an issue with GitLab CE, and feels like a regression: previously anyone could create an account and fork to their personal namespace; now many are blocked from contributing because the license seat cap is exceeded.

Background

  • We self-host GitLab, and started off with CE, growing our contributor community around it. We have approximately 100 core Tor contributors, and employees, but we have many external contributors who report issues and submit MRs.
  • We want to encourage external contributions (bug reports, small patches, one-time MRs).

With CE, this worked seamlessly: users could create an account, fork, push changes, and open an MR.

With Ultimate, the workflow fails:

  • Creating an account to file an issue → does not use a seat.
  • Forking into personal namespace → user becomes an “Owner” → does consume a seat.
  • Since we are already over the pre-configured seat limit, new contributors cannot fork → cannot submit MRs.

This has effectively cut off our contribution pipeline.

How did we get here?

When we received a donated GitLab Ultimate license, we had to pre-configure a seat count before activation.

Determining the correct number of seats was extremely difficult:

  • CE provided no seat-count visibility.
  • We had to relay on a narrative description of what counts as a seat and try and reverse engineer a seat count, writing a program to try and get a count
  • We mistakenly did not include personal project Owners in the count.

Result: we activated with 150 seats, but Ultimate immediately showed ~700 in use (including ~550 personal project Owners). This meant we were over the limit from day one.

Impact on Contribution Workflow

We have multiple different open-source projects in our Gitlab instance, and all of them assume the standard open-source contribution workflow:

  1. User creates an account.
  2. User forks a project into their personal namespace.
  3. User pushes changes to their fork and opens a merge request.

This process:

  • Lets contributors use our CI runners.
  • Keeps work isolated in forks.
  • Enables issue tracking and collaboration in one place
  • Is a familiar workflow for open-source contributors, as this is how it typically works with gitlab.com, github.com, etc.

Current state:

  • New users cannot fork into personal space (blocked by seat overage).
  • External contributors are filing issues saying they cannot contribute.
  • Our teams perceive this as a regression: CE allowed collaboration, Ultimate blocks it.
  • As an open-source project, being able to accept outside contributions is critical, and this has blocked those from happening.

Current Behavior

  • Seat usage only increases when a user forks a project into their personal space (becoming “Owner”).
  • We can disable forking in Admin settings, but that only prevents the problem by blocking contributors entirely.

Expected Behavior

  • Forking should not automatically escalate external contributors into license-consuming “Owners.”
  • The fork-and-MR workflow should remain available to community contributors without counting against Ultimate seats (or there should be an explicit “contributor” role/type exempt from seat counting).

Attempts to Mitigate

We tried several things:

  • Manual audit and cleanup of inactive users + auto-deactivation of dormant users.
  • Pilot of a shared “contributor forks” group (modeled on GitLab’s community forks blog Early signs are promising, but it’s manual, brittle, and unpopular with contributors.
  • Considered alternatives (forks within main group, external forks, even rolling back to CE).

Developers are frustrated: moving to Ultimate seems to have removed capabilities they relied on. Contributors dislike workflows where others can write to their branches.

What We Need

We want to continue using GitLab Ultimate — its features are valuable — but not at the cost of our open-source contribution model.

Questions for GitLab:

  1. Seat visibility: Can the same seat usage information available in Ultimate be exposed in CE? That would prevent mis-estimation when preparing for license activation. I'm happy to open a bug report for this, if you can help me identify where that should go!
  2. Clarification / Fix: Why does forking auto-assign “Owner” and consume a seat? Can this be changed?
  3. Open Source Exemption: Could there be a non-seat “contributor” role for open-source projects to allow forks without seat usage?
  4. Contribution model: Is there another way, other than a contributor-forks model, to preserve the “anyone can fork + MR” workflow in a self-hosted Ultimate environment without exhausting seats?
  5. Alternative approaches: Are there upcoming features (e.g. custom roles, external contributors mode, or license exceptions) that would make this easier?

We’d like to find a way to make our self-hosted GitLab with Ultimate welcoming to external contributors again. Right now the seat licensing model is the main blocker.

/cc @gitlab-org/developer-relations/contributor-success

Edited by Micah