I don't think there is a "correct" way forward with MiNiFi C++, but I can think of a few options.
1) Status quo. Keep MiNiFi C++ in Apache NiFi. There will be NiFi committers and PMC members who do not touch MiNiFi C++ and those who do not touch NiFi. The risk of harm to the codebases because of this is acceptably low. 2) Jettison the MiNiFi C++ project completely to the point the NiFi PMC itself is no longer responsible for its governance or is involved with its maintenance or continued open source status. 3) The NiFi PMC votes to split MiNiFi C++ into an Apache Incubator podling and provides mentors. I would worry about getting enough participation in the new podling. The biggest issue for me is that MiNiFi C++ has separate issue tracking from NiFi. This makes it essentially a separately run "division" of the NiFi organization with minimal interaction with other divisions. Its separate git repository, while a very sensical decision, also contributes to less interaction with the core nifi repository. If I had to vote, as someone who has never used and probably never will use MiNiFi C++ because MiNiFi Java meets all my needs, I would choose #2. -- Mike On Mon, Nov 3, 2025 at 10:28 PM David Handermann < [email protected]> wrote: > Team, > > I would like to discuss the future relationship of the NiFi and MiNiFi > projects, considering in particular whether MiNiFi should pursue > promotion to an independent Apache Top Level Project. > > The NiFi and MiNiFi projects have had a long history of > interoperability through common contracts and shared implementation > strategies. The Java version of MiNiFi was merged into the primary > NiFi repository several years ago, but maintains a module structure > that is mostly decoupled from the NiFi framework. The C++ version of > MiNiFi has had an independent repository, issue tracking system, and > release cadence since its inception. > > In terms of project governance, the NiFi Project Management Committee > is responsible for everything. In practice, however, responsibility > for MiNiFi, and the C++ version in particular, resides with a subset > of NiFi PMC members. The arrangement has worked more or less, but as > work continues on both projects, it is becoming increasingly clear > that knowledge of both projects is not common. This is a natural > result of independent languages, and distinct implementations. For > this reason, bringing on new members to the NiFi PMC does not > necessarily benefit both projects. Although issue tracking is > independent, it also means that project discussions generally skew in > the direction of NiFi. These are not problems in themselves, but these > realities highlight the functional independence of NiFi and MiNiFi. > > There are technical questions to consider, in terms of API surfaces > like C2 protocol manifests and common Python Processors interfaces. > However, these technical questions can be addressed in various ways, > such as promoting certain shared elements to independent repositories > similar to the Apache NiFi API. > > The real questions concern governance. As mentioned, the C++ version > of MiNiFi already has functional independence in several key areas. > Promotion to a TLP would clarify participation and qualification for > PMC membership in both NiFi and MiNiFi. As a TLP, MiNiFi would also > enjoy a more direct presence, rather than a project page under the > NiFi website. > > This would not necessitate any changes to current NiFi PMC or > committer membership, as participation in multiple Apache projects is > common in places like the Iceberg ecosystem. > > This would require both technical and procedural work, but having > clarity of governance should provide a better path forward for both > projects. > > Regards, > David Handermann >
