At our startup, we chose to start with a monorepo. Our team is small, but one of the big advantages we’ve had so far is avoiding the n*m (for n services and m tools) problem with dev tooling - which leads to a very smooth developer experience.
For example, to run one or more services locally, we use a single script that sits at the repo base - ‘dev.sh service1,service2,...’. This avoids a lot of headaches for our developers, as we enforce compliance when adding a project to the repo. Lint config? One to rule them all. Test coverage thresholds? Single one. This consistency is the biggest win in my opinion.
Similarly, our integration tests are very easy to write without commit skew.
Finally, sharing libraries has been painless - since we have common/ and common/third_party/ directories at the monorepo root.
I care deeply about licenses, and as a contributor to some (A)GPL licensed works, I’d love for people to follow the license to the tee.
The truth is that stealing open source code does not have the same monetary repercussions as stealing closed source code. Nowhere close to it. You have to acknowledge that there is an enforcement issue, either due to monetary or motivational (Linux) reasons.
Have there been license enforcements? Yes, a small number. But nowhere close to enough to make a team with a deadline think twice. Compared to stealing a competitor’s code, the expected value of the punishment for using some GPL code quietly is a rounding error.
The harsh truth for a lot of license purists (myself included) is that nobody cares about GPL/copyleft when push comes to shove. It’s a purely PR thing. Nobody will ever put energy into taking legal action.
I know several programmers working at multi million/billion dollar companies that use GPL/AGPL libraries within completely closed source codebases. Some of these products are shipped as DLLs/binaries rather than hidden behind web services, and even still, nothing has ever come out of it as far as license enforcement. Your company’s legal department will not look for these things proactively.
Copilot may be the Napster moment that changes this, though.
For example, to run one or more services locally, we use a single script that sits at the repo base - ‘dev.sh service1,service2,...’. This avoids a lot of headaches for our developers, as we enforce compliance when adding a project to the repo. Lint config? One to rule them all. Test coverage thresholds? Single one. This consistency is the biggest win in my opinion.
Similarly, our integration tests are very easy to write without commit skew.
Finally, sharing libraries has been painless - since we have common/ and common/third_party/ directories at the monorepo root.