4 ms·
The goal is to allow development to happen on the OSS side. Unless you are a Google or Facebook with the ability to properly resource OSS, the 1st approach just
by vaughan 6y ago
The goal is to allow development to happen on the OSS side. Unless you are a Google or Facebook with the ability to properly resource OSS, the 1st approach just leads to abandoned projects.
> this obviously takes more work managing the new external repo, cutting releases and the like, but is more valuable to the community at large.
I guess to gist of my question is how to keep the benefits of a monorepo while allowing a OSS development workflow.
It feels like OSS works best when there is a single Github repo that does not depend on a ton of other dependencies that change often.
- compsciphd 6y agoas we said, presumably your mono repo imports external dependencies, right? its not all developed internally. this just becomes another external dependency to be managed, albeit one you have more control of its actual release schedule if this item depends on many other things that are also internal projects that you don't want to release, you will have to abstract them out and make the implementations pluggable with a working implementation that is part of the OSS side.
- ssivark 6y agoI’m very confused. Open sourcing makes it an independent project (might as well be external), and that’s necessary for the project to be of use to anyone else (Imagine one of your dependencies being part of someone else’s monorepo). In case that’s successful, you can handle it just like any other library dependency. (How do you do that in your monorepo?) To elaborate... How can the community participate in the project if it is not a relatively independent project? If things are closely coupled to one person’s monorepo, then presumably the code is not usable for another person. So, for practical purposes, it might as well be just a code dump.