Thanks for driving this Yang, It's a +1 from me to push this forward. I'm not sure about all the details for the "guilty by association" part, but maybe we can check with our mentors on this or ask the ASF brand before the vote?
For the name, I think everything could work - "fluss-extensions", "fluss-extended" or even something like "fluss-extension-tools". I don't think I have any preferences here. Best, Giannis On Sun, Jul 19, 2026 at 11:51 AM Yang Wang <[email protected]> wrote: > 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 >
