It seems like the HN consensus from the existing comments is to make the source of truth the public repo, and import that repo into the monorepo build somehow.

It seems like the HN consensus from the existing comments is to make the source of truth the public repo, and import that repo into the monorepo build somehow. This works in a lot of cases, but it does come with some drawbacks. Basically you will lose a lot of the benefits of a monorepo: - You can't make atomic commits across the open source repo and the internal monorepo. - Changes to the open source project won't automatically trigger internal integration tests. - Your coworkers can no longer just run `bazel build` or `bazel test` on your project anymore, so there's relatively large amount of friction for them before they can make changes. I don't think there's a simple answer to this question yet, but a few things to consider based on my experience with this: - If you expect contributions to mostly come from internal developers, then maybe lean towards keeping it in the monorepo, but if you think contributions will come from external developers, lean towards an external repo. - If it's going to be a mix of both, it's going to be difficult, so make sure you regularly sync the two repos, otherwise you're going to have to spend a lot of time resolving conflicts. - Think about what build system you're going to use (usually it'll be something like bazel or buck inside the monorepo, but some people prefer language-specific ones for open source repos, e.g. cmake, gradle, yarn/npm). If you decide to use separate build systems internally and externally, make sure both have CI systems in place that will catch build errors.