Personally, I'm happy to see them evolving it with my juices left intact. When we transitioned benthos.dev to https://docs.redpanda.com/redpanda-connect we gained a much larger (and more competent) docs team, but as a consequence had to trim a lot of the old personality. I don't regret the transition but I do take a bit of comfort seeing the WarpStream peeps continue to have fun with it.
It's like shedding an almost intact full body skin and finding comfort in watching colleagues take it bowling, having a great time.
Sure, if they change the MIT license of the core engine then you could fork it at that point. What they're doing right now is taking on a much larger maintainence burden than potentially necessary and fragmenting the ecosystem at the same time.
You're also at the same risk if you choose to use their fork.
It absolutely doesn't need a fork. The entire project is designed specifically to allow vendors and users to have their own ecosystem of plugins and they can all compile and integrate seamlessly. I'll be explaining live in 30 mins: https://www.youtube.com/watch?v=X8nVdUuWZ80
Hey it's Ash (the maintainer being talked about in the blog). I'm not one for fork drama and I haven't had a chance to fully read the blog so I don't have a lot to say. However, this is a full fork of the entire codebase, which means plugin authors will need to choose one project or the other and are locked in, and is entirely unnecessary on both a technical and legal perspective.
If they'd instead chose to fork the plugins themselves (the only parts where the licenses changed, all except two are Apache V2) then all users can pick and choose which ones they include in their projects, and it doesn't fragment the ecosystem at all. Your plugins would compile in my project, and mine would compile in yours.
The part they're choosing to fork here, which will cause this rift in the community, is still MIT licensed: https://github.com/redpanda-data/benthos. If they simply chose to continue using this MIT part we can all live happily together in a utopian society fully saturated with plugged blobbery.
Edit: I'm bit a baby brained so I forgot that I'm literally streaming live in 30 minutes in order to explain all the changes in detail for those out of the loop: https://www.youtube.com/watch?v=X8nVdUuWZ80
Yeah that's my bad, the site assumes you already know what benthos is as it's an early stages UI for it. The best place to start is https://www.benthos.dev, or if you like dumb videos: https://youtu.be/88DSzCFV4Ng
If I want to achieve something then I find the joy in pursuing it, at which point I will naturally do it when I'm capable and will do other things when I'm not.
Letting my attention float around freely (within limits obviously) often looks like I have a low attention span. However, with a birds eye view on what I'm able to get done I look like I'm hyper focused.
And if I can't find the joy in a long term pursuit then it's very unlikely to be worth my time.
Hey everyone, this is a video I put together summarising a decades worth of stream processing delivery guarantee misconceptions and bugs that I've seen frequently.
I'm not trying to scare anyone away from stream processing, in fact a lot of the issues outlined also apply to automated batch processing systems as well. Personally, I think that being realistic and pragmatic about failure conditions makes these systems less intimidating.
Anecdotally I'd say professions that often double up as a hobby and don't have a significant material or energy cost to exercise will be more susceptible to burn out. If you're _really_ into software engineering and struggle to pace yourself then burn out will often stop you sooner than finger fatigue or your computing costs.
I'm not saying workplace pressure etc isn't a factor, but those are also similar factors in pretty much all careers.
Maintaining an OS project definitely gives you a crash course in (and boosted respect for) non-engineering roles at tech companies.
However, I'd say if you're maintaining something and don't enjoy one or more of these hats then keep in mind that totally dominating a problem space doesn't need to be the end goal. There is such a thing as a lifestyle OS project and you can still make a success out of it, gain a loyal (perhaps modest) community, and enjoy taking it slow.
I'm massively rooting for this. I really wanted to use Gitter as the official chat for my projects, but the experience was just so painful that I ended up fragmenting the community across Discord and a gated Slack. I would love to have a forever home where I can feel comfortable getting everyone on board.
It's like shedding an almost intact full body skin and finding comfort in watching colleagues take it bowling, having a great time.