Come gestire in modo efficace il controllo del codice sorgente per il progetto sia con sorgente aperta che chiusa?

Il vero vantaggio dell'idea del vostro subrepository è che lega insieme le dipendenze di revisione tra i due progetti. In altre parole, se una nuova funzionalità di origine chiusa dipende da una versione open source, quando qualcuno ne riceve uno, ottiene automaticamente l'altro. Se si esegue il backup di una versione precedente di un sistema chiuso per eseguire una correzione, si ottiene automaticamente la revisione open source con la quale è stata originariamente creata. Esistono altri modi, come configurare o creare script, per gestire questi tipi di dipendenze, ma sono più difficili da mantenere.

Da quello che posso dire, stai essenzialmente lavorando su due "progetti": un open source, l'altro closed source. Non vedo che ci sia un problema se questi due "progetti" vengono tenuti separati (cioè conservati in repository separati).

Il modo in cui gestisci entrambi questi "progetti" dipende molto da come sono progettati individualmente e da quanto è possibile integrarli con l'altro. Ad esempio, se uno dei "progetti" è una libreria closed-source, l'altro "progetto" open source può integrare e utilizzare questa libreria senza avere accesso all'origine. Ho la sensazione che tu lo stia già facendo. Puoi gestire questa separazione disponendo di team separati responsabili per ciascun "progetto" e coordinando tra loro quando necessario.