Hi Matteo, > On Feb 3, 2024, at 3:25 PM, Matteo Merli <matteo.me...@gmail.com> wrote: > > Hi Dave, > > Thanks for the feedback, replies inline. > > > On Sat, Feb 3, 2024 at 11:23 AM Dave Fisher <w...@apache.org> wrote: > >> Hi - >> >> What? A cascade of agreement without questions? Seems like this has been >> discussed elsewhere? >> > > No, Dave, there was no "elsewhere" discussion. > > Because 12 people agree to the proposal, you're now questioning their > intentions. Based on *your* assumptions, it would either be that: > 1. Everyone acting in bad faith > 2. No one is able to understand the implications of this proposal
I personally find a discussion with only +1s to be of small value, but apparently that’s not how young people view it. > Have you considered the eventuality that they actually agree with the > proposal and do not share your point of view? Do not assume that my asking questions is equivalent to disagreement. > I have concerns since with this PIP we are making changes to support a >> third party library. >> > > I think you are misunderstanding/misrepresenting multiple things here. > > This is not "supporting" a 3rd party library, this is "using" a 3rd party > library to provide additional features, in the same way in which we are > doing with many libraries, eg: we're using Netty for networking, Jackson > for JSON, RocksDB and ETCd for metadata support and *many* others. 1. Relying on dependencies does require assuring that they will be maintained. Here are a couple of examples. - Apache jClouds will be going to the Apache Attic soon. Pulsar Tiered storage uses jClouds. Is the bulk of the Pulsar community aware? - In Apache POI we depend on Apache XMLBeans for XML processing. XMLBeans was put into the Attic and in order to make security updates to fix entity expansion attacks we had to take responsibility for XMLBeans which required getting it out of the Attic. 2. Other questions. If the base Pulsar will now depend on Oxia and no longer use Zookeeper? Or is Oxia an option? Will Oxia be included as a Pulsar dependency in Pulsar convenience binaries? > Can you explain how this would be *any* different here? Adding dependencies should be more than getting the LICENSE and NOTICE correct. It should be a deliberate choice. What’s a little different here is that Oxia may not be tracked for CVEs by dependabot. Another difference I’m OK with is that it is maintained by so many who are also members of this community. >> 1. Have people read the PIP text? I see some typos which could be fixed. >> Simple things nothing objectionable. >> > > Other people have provided more constructive feedback by correcting the > typos in the PR on GitHub. To me it seems like a better approach. Check. >> 2. This would be a commitment by the Pulsar PMC to support third party >> code. What commitment is there by StreamNative to keep the two Oxia >> repositories open source? Relevant because I’ve heard that some >> StreamNative protocol handlers have been archived. I know it’s not >> completely analogous, but if we are making changes to Pulsar then an >> explicit commitment is best. > > Breaking this down in a few parts, because it sounds like a big ball of FUD > to me. I’ve seen other OSS communities be impacted by a vendor changing the license of ecosystem components to Open Core. Kafka and Confluent come to mind. I asked and you answered, thank you. >> This would be a commitment by the Pulsar PMC to support third party > code. What commitment is there by StreamNative to keep the two Oxia > repositories open source? > > StreamNative is already using Oxia in its Cloud Services. There are no > problems in doing that, though it wouldn't benefit the Pulsar community as > a whole if Apache Pulsar distribution wouldn't be able to use Oxia out of > the box. > > This project has been open-sourced for that very reason. Very good. > Are you implying that Oxia is not "open-source" enough? (note: the code is > available with Apache License V2). > > Are you asking for extra "guarantees" and "explicit commitment" for every > dependency, or you're only doing it on certain occasions? I have a peripheral concern that there is confusion about what is Apache Pulsar vs what is part of the larger Pulsar ecosystem. > As I mentioned on multiple occasions and public talks, the plan for Oxia > has always been to build a community around the project and to find a home > in a software foundation. Once you have a community around Oxia … you know your choices. >> Relevant because I’ve heard that some StreamNative protocol handlers have > been archived. > > You're omitting the (quite important) point that these protocol handlers > are *still* open source. The repository and the source code are still there > available to anyone. Great. That’s good to know. It’s unfortunate though that they won’t be maintained which is your right. > Also, you're omitting that you're talking about the component that *your* > employer has been forking and modifying in a bit of a shady way, without > contributing back. I’m confused. The only component I can think of is KoP where there is a DS fork called Starlight for Kafka. Is that it? AFAIK Enrico has contributed nearly everything back. There is a reason he is the #3 committer. What is your concern? > Of course, in a legal way, though not a very nice way to > behave in an OSS community. Forks happen and are encouraged. No, they aren’t always good, but they are what they are and often license choice is what matters: Examples: 1. OpenOffice.org was forked by The Document Foundation as LibreOffice and put under a license that is not compatible with ALv2. Oracle donated OpenOffice.org to the ASF through Incubation and IBM contributed parts of Symphony before exiting. Apache OpenOffice continues and LibreOffice diverges. The world still has a choice. Has everything been pleasant? No. 2. Pekko is in the Incubator as a hostile fork of I forget, but the cause was making the lines Open Core from ALv2. +1 for the PIP. Best, Dave > > > > Thanks, > Matteo
