I looked into it after this year’s massive price hike… There’s no meaningful alternative. We’re on the FOSS version of GitLab now (GitLab-CE), but the lack of code ownership / multiple reviewers / etc. is a real pain and poses problems with accountability.
Honestly there are not that many features in Gitlab EE that are truly necessary for a corporate environment, so a GitLab-CE fork may be able to set itself apart by providing those. To me there are two hurdles:
- Legal uncertainties (do we need a clean room implementation to make sure Gitlab Inc doesn’t sue for re-implementing the EE-only features into a Gitlab fork?)
- The enormous complexity of the GitLab codebase will make any fork, to put it mildly, a major PITA to maintain. 2,264 people work for GitLab FFS (with hundreds in dev/ops), it’s indecent.
Honestly I think I’d be happy if forgejo supported gitlab-runner, that seems like a much more reasonable ask given the clean interface between runner and server. Maybe I should experiment with that…
We can argue on whether it’s a “bug” outright (since it is technically a correct implementation of a faulty design), but Boeing’s MCAS pitching the plane based on the input of a singular faulty sensor has probably caused billions in direct damages, and billions more in reputational damage.
NULL
references (which Crowdstrike is an instance of) are often referred to as “the billion dollar mistake”, but the actual cost of “historical” languages skimping out on optionally-nullable types is certainly in the trillions.