Mike, 2) is not really an option, it's being contributed to actively by ~5 committers.
So the question is deciding between 1) and 3). I'm not sure at the moment which I find better, will get back to this thread with a longer response. Cheers, Arpad On Wed, Nov 5, 2025 at 5:17 PM Michael Moser <[email protected]> wrote: > 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 > > >
