I understand your perspective on this, and I’m certainly not saying it’s wrong. But there’s some background you should consider.
GitLab CE instructions used to be the default. Paying customers would find they installed GitLab CE by default and run it, and then want to use features. They’d have to install GitLab EE over it. Well if they’re a year or two behind in upgrades, that transition can be painful and require services.
This created alot of anger and frustration from enterprises who paid for GitLab or wanted to convert to paying for GitLab. The solution was simple; install GitLab EE by default per the instructions. Because FOSS folks will search out the free editions. Yet customers won’t; and they’ll get caught with the CE edition unable to migrate to EE.
The move wasn’t one built on bad faith to move people to paid versions; or somehow bury the CE versions. It was to reduce paid customer frustrations. Even now GitLab docs talk about running GitLab directly from source.
GitLab CE instructions used to be the default. Paying customers would find they installed GitLab CE by default and run it, and then want to use features. They’d have to install GitLab EE over it. Well if they’re a year or two behind in upgrades, that transition can be painful and require services.
This created alot of anger and frustration from enterprises who paid for GitLab or wanted to convert to paying for GitLab. The solution was simple; install GitLab EE by default per the instructions. Because FOSS folks will search out the free editions. Yet customers won’t; and they’ll get caught with the CE edition unable to migrate to EE.
The move wasn’t one built on bad faith to move people to paid versions; or somehow bury the CE versions. It was to reduce paid customer frustrations. Even now GitLab docs talk about running GitLab directly from source.