Hi everyone, Now that Fluss has graduated from the Incubator as a TLP, I'd like to propose setting up a neutral GitHub organization to host ecosystem projects around Apache Fluss. I'm tentatively calling it "fluss-extensions". The governance model mirrors what the Apache Flink community set up with flink-extended, adapted to our context. Why we need it
A few Fluss-adjacent projects have come up that don't fit cleanly inside the apache/fluss repository — either because they ship on a completely different release cycle than Fluss core, or because they're C/C++ artifacts that can't live in a JVM-centric ASF release. Concrete examples: - *A dedicated RocksDB JNI fork for Fluss.* The Fluss client currently depends on frocksdbjni, an older fork shared with Flink. Upgrading Fluss's RocksDB dependency in place would cause native symbol conflicts with Flink that Java-level shading can't resolve. Maintaining our own fork (with hidden C++ symbols, renamed native libraries, and redirected JNI binding paths) is a cleaner path — but it's a native artifact on RocksDB's release cadence, not Fluss's. It's clearly an ecosystem deliverable, not a core one. I've prototyped this in a partner company's internal environment and verified the isolation works end-to-end. - *Non-JVM ecosystem extensions.* fluss-extensions is a natural home for cross-language / non-JVM work. A concrete candidate is a duckdb-fluss extension that lets DuckDB query Fluss tables directly, giving analysts zero-cluster, ad-hoc access to fresh Fluss data (analogous to duckdb-iceberg / duckdb-delta). This is C++ on DuckDB's release cycle, which the ASF Fluss release simply can't accommodate. - *Connectors, CDC bridges, benchmark suites, and language bindings* (e.g. a Python client) contributed by individuals or companies who aren't ready to donate the code to the ASF, or who need a faster iteration cadence than Fluss core can offer. Putting these under apache/fluss has real downsides: heavy IP clearance for each contribution, a single release cadence forced onto every sub-project (impossible for C/C++ artifacts tied to RocksDB or DuckDB), and an implicit ASF endorsement we can't actually stand behind for third-party code. The proposal Create a GitHub organization named "fluss-extensions", following the flink-extended governance model: 1. The org is maintained by a small group of individual volunteers (in practice, some of us are Fluss committers / PMC members) — not by the PMC, and not as an ASF resource. 2. The org is explicitly not affiliated with the ASF or the Apache Fluss project. A disclaimer to that effect goes at the top of the org README and every hosted repo. 3. When a project asks to be hosted, the volunteers create a repo and immediately hand admin rights to the project owner. Day-to-day maintenance, releases, and security are the project owner's responsibility. 4. All hosted projects are strongly encouraged to use Apache License 2.0, so any project that later matures can be donated back to the ASF without re-licensing pain. 5. Because the org name contains the Apache trademark "Fluss", we still need PMC permission for the name itself. Assuming this discussion goes well, I'll put that to a formal [VOTE] on this list. What I'd like to hear from you - Are there "guilty by association" concerns between fluss-extensions and Apache Fluss that I should address more explicitly in the disclaimer? - Are there better candidate names? I lean toward "fluss-extensions" — the plural makes it clear that each hosted project is itself an extension of Fluss, and it maps naturally onto non-JVM projects like duckdb-fluss that are literally called "extensions" in their own ecosystem. Happy to switch to "fluss-extended" if the community prefers closer naming parity with the Flink precedent. - If you maintain or are building something that would fit here, please chime in — I'd like to get a sense of the seed projects and potential volunteers before we move to a [VOTE]. If the sentiment is positive, I'll open a [VOTE] thread here on dev@ to formally authorize the use of the "Fluss" trademark in the org name. Thanks, Yang
