Compartir partes de un monorepo

Actualmente tenemos un sistema de compilación complejo e ineficiente que consta de muchos repositorios SVN y Git (aproximadamente 50% cada uno), incluido uno que es un repositorio de submódulos git. También tenemos guiones caseros que manejan más o menos bien todo.
Un punto importante de nuestra base de código (de código cerrado) es que está estrechamente acoplado, y cada proyecto se lanza al mismo tiempo bajo la misma versión.

Queremos migrar esto a un sistema más simple y un único VCS, y estamos considerando varias opciones, que incluyen: submódulos git, Google Repo y monorepos. El VCS final aún no está definido (a excepción de las opciones que lo obligan), y podría ser svn, git o incluso algo más si eso se ajustara mejor a nuestra situación.

Estamos tratando de enumerar el más y el menos de cada solución y uno de los principales problemas que tenemos actualmente con monorepos es que no parece fácil, ni siquiera posible compartir solo algunos módulos con una entidad externa. Queremos que esas personas puedan pagar y trabajar normalmente en esos módulos, pero que no puedan acceder al código o al historial del resto del repositorio. No es algo que hagamos a menudo o ampliamente en este momento, pero podríamos hacerlo en el futuro, y no queremos que esto se convierta en una pesadilla porque tomamos una mala decisión aquí.

¿Existe tal sistema de gestión de privilegios en un sistema VCS?
¿O hay alguna forma de mitigar este problema?

Según su descripción, creo que tiene un par de opciones aquí:

1. Use submódulos git: con un servicio como GitHub (o cualquier otra cosa), puede administrar los permisos por proyecto y desacoplar su proceso de implementación. Sin embargo, he oído que los submódulos git terminan siendo un gran dolor con el tiempo. Las secuencias de comandos automatizadas para reiniciar / descargar de forma limpia sus submódulos git podrían ayudar aquí.
2. Divide tu repositorio en servicios independientes. Esto le permite desarrollarse simultáneamente, pero también presenta una gran cantidad de dolor, ya que necesita comenzar a pensar en el descubrimiento de servicios, la implementación de múltiples servicios, los entornos de desarrollo, la integración / implementación continua y todas las otras pequeñas alegrías que provienen de administrar un Arquitectura de microservicios.
3. Use un sistema formal de administración de paquetes, como pip para Python, npm para Node.js, Maven para Java, etc. Implemente las piezas de código que necesita en el repositorio y consúmalas en su repositorio principal según sea necesario, lo que debería darle la capacidad para versionarlos. Dependiendo del acoplamiento entre sus módulos y su repositorio principal, es posible que no pueda extraer, ejecutar o probar los módulos de nivel inferior de forma independiente. Sin embargo, si puede , esta es una forma bastante buena de hacerlo que funciona bien con múltiples repositorios y al mismo tiempo puede integrar sus paquetes en el momento de la compilación instalándolos desde un repositorio remoto.

Desafortunadamente, ninguna de estas opciones es perfecta, pero todas son válidas según el estado de su base de código. Su descripción parece que la opción 3 podría funcionar mejor aquí.