As proposed, Splitting functionalities, bindings, features could help maintenance burden. If we go with this route, moving some large features like ofs is a good idea.
If we moved away from monorepo, we might reduce contributions to various components. We might deviate from OpenDAL's envisioned integrations/bindings as the legend photo described. Best, Erick On Thu, Oct 2, 2025 at 9:33 AM PsiACE (via GitHub) <[email protected]> wrote: > > GitHub user PsiACE added a comment to the discussion: Split opendal mono > repo in multiple repos > > As a first experimental step, we could consider splitting off `ofs` and > its related integrations, including `fuse3` and `cloud-filter`. > > This project seems to be an ideal candidate because it shares similar > concepts with established projects like [JuiceFS]( > https://github.com/juicedata/juicefs) —that is, providing a file system > interface on top of object storage or other storage services. Spinning ofs > into its own repository would allow it to have its own roadmap and > community, focusing on file system-level features and optimizations without > being tied to the CI and release cycles of the core opendal library. > > This would not only serve as a great trial for our repo-splitting idea but > also create a more focused and high-potential development space for ofs > itself. > > GitHub link: > https://github.com/apache/opendal/discussions/6617#discussioncomment-14570581 > > ---- > This is an automatically sent email for [email protected]. > To unsubscribe, please send an email to: > [email protected] > >
