Reconsider 1:1 fork

[sagikazarmark]

Sorry about the weird title, I wasn't sure how to start a conversation about the topic.

First of all: kudos for taking on the hardships of forking a popular open source project. That's never easy.

Given things are pretty much in flux, it feels like forking may have been a bit premature. I also realize that someone had to be first, so there is that.

Looking at the current state of things, the benthos core is still proper open source (MIT) and there has been no changes there. Changes are limited to the plugins themselves.

I wonder if it would make sense to follow the pattern that apparently Jeff has always intended to do: maintain a separate core from plugins.

It might even make sense to continue using the core library, since it's MIT and only fork it if it really is in danger of changing.

Apologies for the braindump format, I just wanted to kick off a conversation.

[gregfurman]

I believe the long-term goal is to have Bento be managed under some shared governance model with an independent ownership structure.

I understand this to mean that so long as a project (like Benthos) is centrally controlled, there is always a risk of an acquisition or license change. Forking the original is perhaps the first step in that process.

The blog post made the following point (see the footnotes):

2. This relicensing was done with the justification that “all the users that are using those services are used to paying for the integration with those services.” This seemed to us like a clear signal of more potentially hostile things to come.

Perhaps there should be some more documentation as to why this was forked in the README. Happy to hear some opposing viewpoints on this.

[sagikazarmark]

I believe the long-term goal is to have Bento be managed under some shared governance model with an independent ownership structure.

That's all fine, I'm not arguing the need for some fork. I was wondering though if keeping things closer to the original project as long as it's feasible is a desirable thing or not. And I think it is. That would, however, mean that this particular fork (or most of it) should be dumped/replaced with a structure closer to the new repo structure.

The blog post made the following point (see the footnotes):

2. This relicensing was done with the justification that “all the users that are using those services are used to paying for the integration with those services.” This seemed to us like a clear signal of more potentially hostile things to come.

That's a fair point, although until that time comes, it's probably safe to reuse bits and pieces from the original project (ie. the "new" core repo).

I doubt Redpanda would take the original source code off of GitHub. That would essentially be community suicide for them.

Keeping things close to the original project would essentially mean we could fork anytime they do anything nasty.

While preparing for that (and hoping that it never happens), there could be alternative community efforts built around Benthos. Things like a marketplace for individual plugins, infrastructure that helps building custom binaries (something like xk6), etc.

Hard forks tend to incur a high price in terms of duplicated efforts. Keeping that to a minimum would increase the viability of any future efforts.

BTW although I haven't made up my mind whether I want to move away from benthos/redpanda and use a fork or not, but I'd be happy to participate in moving things forward.

That being said, I'm also not sure if a hard fork is the right way forward at this point (yet).

[ryanworl]

Thanks for your interest @sagikazarmark!

We tried to lay out our reasoning for the fork in the original blog post, so I won't repeat all of that here. That said, we're not opposed to mirroring the structure of the new Redpanda Connect repositories with a core and plugins split. The project was not originally structured that way, so when we created our fork it was not natural to mirror that split right away.