We like having our dependencies living inside the project directory. As much as possible.
First reason is to be able to have different versions “installed” for different projects on one machine.
Second reason (more philosophical): We're of the firm opinion that a central repository is a bad hack from times when disk space was still expensive. There's absolutely no reason to mix or share dependencies in a single location from a project point of view, it only brings the potential of errors introduced without even being aware of it.
Seeing as LabVIEW is not very flexible in terms of linking to dependencies, and as VI Package Manager is the de facto tool in the community, we maintain all of our reuse code and open source projects as VI packages (.vip) which get installed into vi.lib.
We use our own Release Automation Tools for automatically creating releases.
We only use git submodules where we think that we want to implement modifications to reuse libraries within the project and push back those modifications to the original repo of the library from within the project we're working on.
For some packing mechanisms, it will not be possible to change or even view the source code (i.e. block diagram) of the packaged library. This requires the library to be in a very mature state. While working with mature libraries is desirable, in reality, we find it useful and sometimes necessary to be able to view, debug and modify code when it makes sense.
When using source distributions instead of built (binary) packages, we specifically trade rigidity for the flexibility to move forward with the application, rather than awkward workarounds of a fixed interface to the library.
We build VI packages for generic and stable reuse libraries, as VIPM is the de-facto standard way of working for most of the community.
Examples for generic open-source projects with VIPM support are