4

I have developed a open source tool that consists of:

  • Web-Frontend (Angular project)
  • Backend (Java project)
  • Python Lib (Python project)

Both, Web-Frontend and Python Lib communicate with the Backend service.

I want to publish this tool on GitHub and provide it as open source. However, I am thinking of the best way to do it regarding mono vs. multi repos.

My biggest concern at the moment is that if I split it in many repos, then it might end up in a mess, if contributors developed a feature that consists of multiple PRs in all of the repos. This would be a pro for having only one repo with different projects inside. However, this might become a problem for providing the Python lib as a package itself.

Anyone has solved similar issues and can tell me more pros / cons or good practices?

Improve this question
4
  • 2
    I’m voting to close this question because it doesn't really have anything to do with Open Source software. The answers are going to be pretty much the same whether this is Open Source or not.
    – Philip Kendall
    Commented Feb 16, 2021 at 22:53
  • 3
    @PhilipKendall One of the OP's major concerns is how to manage pull requests across repos, which implies at least rights to access and modify (as well as fork) the source code, which I think ties this question quite closely to FLOSS concerns. Questions about, e.g., crayon licenses and license proliferation also have possible applications outside of FLOSS, but the application to FLOSS is obvious and significant. -- However, I am interested in hearing arguments against, from you and others. (If need be, we can open a meta post to discuss it thoroughly.)
    – apsillers ♦
    Commented Feb 16, 2021 at 23:20
  • 2
    I agree with @apsillers here. The lack of "exclusivity" to open source doesn't decrease its relevance, and project management is very much an issue to open source projects.
    – Zizouz212
    Commented Feb 18, 2021 at 2:00
  • I do not think it is the same whether OS or not, since you have other organizational requirements, because everyone should be able and empowered to contribute. However, if the OS channel is not used for technical discussions, I will remove my question and place it somewhere else.
    – Fuchur Kool
    Commented Feb 18, 2021 at 10:29

1 Answer 1

Reset to default
3

Monorepos have become very popular since google does it. I'm not a fan for most situations.

Monorepos seem to make sense for:

  • large organizations
  • complex projects without any easy compartmentalization
  • folks that have lots of CI/CD experience and they're happy to customize tools to work with the monorepo.

It doesn't sound like you're a large organization. I'm guessing you don't have much complexity since you're just starting out. So the questions boils down to: do you have deep talent in CI/CD to develop custom tools for working with the monorepo challenges? If not, you should start with repos that are dedicated to a particular projects, mostly in one language. You're not stuck with this forever. If you decide later to merge things, you can bring the repos together into a monorepo. But by then you'll have a clear idea of the requirements for reach component and know how much work it will be to get them to play together.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.