I still think #2 is an option. It would be up to those 5 or more committers to determine what to do with it.
There are more NiFi adjacent projects out there (NyPyApi and NiFiKop to name a couple) that are maintained as open source but not governed by the ASF or NiFi PMC. -- Mike On Wed, Nov 5, 2025 at 11:26 AM Arpad Boda <[email protected]> wrote: > 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 > > > > > >
