I think splitting the codebase will be a pain for gnunet.
The only good reasons for manyrepos are social or ego politics "this is my lawn" or legal. The only one that applies to gnunet is legal because one needs to fill a gnu form to be able to contribute.
I am biased toward monorepo by experience dealing with big project (100k+ SLOC) and the only time it made sens to split the project into many repositories because it was different teams / workflow (social) and different legal terms for the various services/daemons, at previous $WORK, they had to fork gentoo to make it work.
Otherwise, each time I saw another repository it was a source of pain:
- Need to manage several versions
- git submodule workflow is not good enough, it doesn't track branch, I personally I never remember how to know the branch of a commit, plus it requires some more git-fu to bump the submodule.
- refactoring anyone?
- generally speaking manyrepos at small scale is more work
And again, it requires somehow to track down every versions (what works with what) and you end up with another repository (or distribution) with another build system that puts everything together. Continuous Integration can do that? Where is the code of the CI? Another repo? More versions, more git clone more grep across repositories / directories not even in sync.
a) Ok, everybody know GAFAM love monorepos and that is a also a source of pain (dedicated team and software). That said, gnunet is not the size of any GAFAM, hence it will not suffer from monorepo pain points.
c) Now, there is GNOME. GNOME is famous for its bazaar model of development and also famous for the adoption of meson (maybe even its inception) or its previous incarnation jhbuild. Anyway, even if GNOME and GNU (which is also a bazaar) success is appealing, gnunet is not GNU or GNOME. From my point of view the bazaar development model scales better / more easily in a socially distributed setting. Also why Linux is still a single repository?