In a previous well funded startup with a FOSS component that I worked for I designed a set up like this:
- 2 git repos, one public, one private
- Custom tooling inspired by other existing tools out there like copybara to move commits in a unidirectional flow from the private repo to the public one
The private repo had the contents of the OSS repo in a subfolder, and a unidirectional workflow where all commits flowed from the private to the public. The way the OSS repo accepted contributions was going through the normal pull request workflow on the OSS repo, then on approval the custom tooling copied the pull request into the private repository where it would go through a second round where it was tested against the private code. On merge in the private repo the commit sha of the original commit along with the original author would get injected into the new commit message and then the custom tooling would then automatically push commits in the private repo subfolder to the public OSS repo, which essentially served as a read only mirror on the main branch.
It actually worked quite well, though obviously this approach comes with some tradeoffs. Here are some of the benefits and drawbacks off the top of my head
Benefits:
- no mixing of free and proprietary code. Public users just check out the OSS repo and it’s completely free
- proprietary code is not visible to the public
Drawbacks:
- workflow slightly more complex for both end users and employees of the enterprise
- more work to mainline code by the enterprise: contributions essentially need to be reviewed twice
- it is not possible to have signed commits by OSS contributors with this workflow
Overall it ended up being a great solution for that organization but this kind of approach can only work for low traffic or easy to review repositories. Anything with a decent amount of traffic or lots of complex contributions has a risk of becoming too much overhead for the organization to double build and test pull requests