I think all that is being suggested here is should we consider having MiNiFi be its own TLP... 5 members in that PMC is enough and I'd bet at least a few of us would also be part of that PMC as well.
On Wed, Nov 5, 2025 at 10:08 AM Michael Moser <[email protected]> wrote: > 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 > > > > > > > > > >
