My bias is that the subproject approach has benefits that outweigh the benefits of a broken out TLP
1. I think there is merit in shared governance - it's unrealistic that every PMC member knows all parts of a project, and I don't think there are any ASF projects where everyone knows everything from a technical perspective, and there are components where only a few contribute, or even understand. I think the breadth of experience in both technical and non-technical gives all the subprojects resilience. We have people who know and care about these subcomponents that might not otherwise. 2. I think the direct presence that David mentions is a bit of an argument of a lack of visibility (i.e. MiNiFi gets "outshined"), but I could be wrong. That is currently a tacit choice we're making as a community and project. We could be making choices to highlight on the website or in other communication, but we don't. If lack of presence is an issue, we could address in other ways. 3. I think there is value in shared branding and user trust. At least with me, a tight sub project association mitigates risk of fragmenting the somewhat joint "story" of NiFi and MiNiFis for users, folks like integrators, and maybe even ASF? 4. I think splitting has significant overhead costs in coordination, such as cross-project apis or alignment, amplified by some of the reporting that comes along with being a TLP. What I'm not sure I'm seeing is any community divergence or independence that I would expect to see for considering TLP vs PMC. I unsuccessfully searched through some of the other projects mailing lists to try to understand other peoples' considerations for subproject->TLP decisions. Tony On Wed, Nov 5, 2025 at 12:14 PM Joe Witt <[email protected]> wrote: > 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 > > > > > > > > > > > > > > >
