From what I've read about Gitlab I do NOT want to do it that way. I believe they had two completely separate projects that were developed independently for open-source and proprietary.
I'm just looking for any reading to help avoid mistakes. Maybe companies follow a purely dynamic extension method. Maybe they solely keep diffs around (that sounds crazy). I don't know.
Any pointers to read about would be welcome!
GitLab had 2 separate projects before merging into https://gitlab.com/gitlab-org/gitlab in 2019 as a single code base for both, community and enterprise edition.
https://about.gitlab.com/blog/2019/08/23/a-single-codebase-f...
The source code portions use different licenses which are explained in https://gitlab.com/gitlab-org/gitlab/-/blob/master/LICENSE for each directory, etc.
For your use case, speaking with my personal hat:
It depends if you'd prefer the proprietary extensions being source available or not. If they should be visible and are protected with a license, a single code base is a good approach imho.
An alternative way could be treating the OSS project as a Git submodule, including it in your CI/CD pipelines, and dev environments. In these steps, you'll fetch the modules and build everything together.
An example I just thought of: MkDoc Material Theme. You'll get the OSS project at https://github.com/squidfunk/mkdocs-material and the paid insiders version is made available as private project. https://squidfunk.github.io/mkdocs-material/insiders/ CI/CD and deployments then require an extra step to install the proprietary package, example in https://gitlab.com/dnsmichi/opsindev.news/-/blob/main/.gitla...
Multiple separate repositories need good onboarding documentation, and the 5-min-to-success when spinning up a dev environment to contribute. That challenge exists with a single codebase too. In the end, it really depends on the strategy of source available or not :-)