Proposal: Rename OpenDAL File System to YinYang

[Xuanwo]

The opendal-ofs repository is being redesigned as a cross-platform filesystem foundation with two independent choices: Direct or Managed volumes, accessed through Mount or Sync. Before the redesigned runtime establishes new user-facing names, I would like to propose renaming the software product from Apache OpenDAL File System (ofs) to Apache OpenDAL YinYang (YinYang).

Why YinYang?

Data exists in two complementary states:

• Yin is data at rest: persistence, durable identity, versions, and history.
• Yang is data in motion: mounting, synchronization, replication, and circulation.
• YinYang preserves the identity and consistency of the same data across both states.

The proposed tagline is:

YinYang — At rest. In motion. As one.

静而存，动而流，合而为一。

This interpretation does not introduce new architecture modes. Direct/Managed and Mount/Sync remain the complete user-facing model. YinYang is the product identity that connects those capabilities.

Proposed naming

• Product: Apache OpenDAL YinYang
• Short name: YinYang
• Cargo package and Rust crate: yinyang
• Command-line executable: yy
• Proposed repository: apache/opendal-yinyang

For example:

yy volume create workspace
yy mount workspace /mnt/workspace
yy sync workspace ./workspace

Why now?

The main branch is currently a buildable scaffold without a runtime API or mount command. The previous implementation is preserved on the backup branch. Renaming before the redesigned runtime is released avoids introducing new public APIs, configuration namespaces, and documentation under a temporary name.

Existing ofs releases and their historical documentation would remain unchanged. The repository, RFCs, package metadata, examples, and future runtime would move together only after the community reaches consensus.

Feedback requested

I would especially like feedback on:

• whether YinYang communicates the relationship between durable data and data movement;
• whether the name or its cultural interpretation raises concerns;
• whether yy is a suitable command name;
• what compatibility expectations existing ofs users would have.

This discussion is exploratory. If the community supports the direction, we would follow the Apache naming process and handle the concrete rename in separately reviewed changes.

[PsiACE]

+1, I like how this concept is expressed.

[Xuanwo]

This is a binding vote.

[Xuanwo]

+1 binding

[dentiny]

+1

[Xuanwo]

This is a binding vote.