I don't have an example, but I know the pattern. You are working on your software, security researcher finds a bug, it's in your project, for you it's just another bug, but for them it's a point on their CV, so they make a theater about it, and expect priority in dealing with it. It must get tiring if you get many of these.
I've run a bug bounty program for a relatively large corporation and you are exactly right. It's worse in open source, because none of the developers owe a researcher their time. At least in a bug bounty program you've communicated willingness both ways already
I feel that Zig will stay a niche language. In this world, there is no reason for corporations to use anything but Rust for this kind of code. And without the corporate push, it will probably still exist for a long time, but the D trajectory is what I predict. I really like the language and I hope it gets more popular, but it seems unlikely to me.
With the amount of problems I had using Redis Sentinel, I really wish there was another way. On multiple occasions, with completely different deployments, it got itself into a non-repairable state where the only option was to drop it and setup the replicas manually. I was hoping someone would do a Patroni-like project for Redis, but I've not found it yet. I've moved all persistent data to PostgreSQL and use a number of Valkeys behind Envoy proxy as a cache.
I suggest you to take a look at rdsync (https://github.com/yandex/rdsync), exactly what you want: Patroni-like high-availability tool for Valkey/Redis. Uses ZooKeeper for external coordination. We use it in our large deployment and with a couple patches you will forged about the need to take manual actions to resolve broken states.
To be honest - at any scale, this really does help me not wake up at night to fix broken states by hand as sometimes on-call engineer. Although note that rdsync is mainly for Valkey up to 9.1, there were Redis patches for 7.2 (last BSD version).
What made open source great, is the fact that if you find a problem, you can patch it. It's what motivated me, anyway. Ladybird is not SQLite, it's under development and very likely will be forever. To me it looks like they are transitioning into a company, where this model makes sense.
Indeed, while there is communication that the situation with merging external pull requests should improve, the reality is that it's easier to land a patch in Linux, than in Zig.
I wonder how can a new browser engine survive with the source available model. Like, why would anyone support this, unless they have business association with the Ladybird developers?
It's not source available. It's OpenSource(TM) because of the BSD-2 license.
This is not unheard of. The most famous models are emacs & SQLite. SQLite doesn't accept outside patches, emacs is developed opaquely and only releases are put forward.
You can do this with GPL, too. You put out tarballs of the releases only.
There's a great misconception between Free Software, Open Source, and Open Development (bazaar model). They complement each other, but they are completely independent things.
Addenda: Looks like emacs' Git repo is publicly accessible now, but it's not a requirement for GPL or Free or Open Source software.
It's actually common, many companies develop their products this way. The source is available, you can see the VCS, but you can't participate in the development. That's why I see this as signal that it's going to turn into a company.
However many if not most of these companies use "Source Available" licenses which say "Thou shall look, thou shan't compile". This is very different than Open Source license of Ladybird itself.
I've tried many AI code review tools. Nothing comes close to the depth of CodeRabbit reviews. It's the only such tool that can find real logical bugs. I'd love to be able to get Claude Code to do similar quality of review, but I can't get it right, no matter how I try.
Even if this was true, it’s hard to believe, and written a bit like an ad. Eg no vendor would get me to write a comment like this. All the more so, I tried CR and my team asked me to remove it. Maybe they got better but it’s a bit weird to me considering they only charge $20 and Claude Code say they estimate the same cost for a single PR for their competing product.
Well, I'm just an extremely happy user. I've honestly tried to find an alternative, and couldn't. I'm using it in the context of solo developer and it provides a huge value to me.
There must be some degree of communication from customers to developers. Even if it is a free volunteer service.
Poor communication results in professionals firing the customer as well. None of this is exclusive to OSS of volunteer effort. But the communication in general is necessary.
This is just product management and communication issues. There is an perceived problem and the problem MUST be communicated.
Problems aren't solved by shutting up and ignoring things. And based on the discussion in this topic, it's clear there's a lot of people who are worried about rsync code quality here.
Look, it's not that long time ago when we had the xz malware. The pattern is always the same. Maintainer of the project is doing X, people start to pressure them to do something else, maintainer gives up and opens the project up to other maintainers, and then many things can happen. If there is any lesson from the incident, open source maintainers should never allow the pressure to happen, ignore it if it's too strong, block people. Rsync has been maintained for a very long time. Bugs happen, even regression bugs happen. People don't get to dictate how should the volunteer do development.
If I were the rsync maintainer after this I'd unpublish it everywhere I had control over, delete the repo and turn off my computer to go walk in the park. The linked thread is insane.
Again, this is not work and they are not customers.
This is somebody spending their free time on code they enjoy and then putting the result online.
The reason businesses are careful about which customers they fire is because they want to keep having customers. Open source maintainers have no reason to deal with that shit.
And it seems like regressions that lead to rsync losing data is just as serious.
Again: we are talking about rsync here. This new methodology being used this year seems to be associated with a regression (ie: Data loss since this is rsync after all....) that likely wouldn't have happened any other year.
Or at least: the regressions at play are consisting of thousands of lines of changes that was only navigated by Claude later down in the discussion.
We are reaching the point of AI developed code that requires AI itself to analyze. One step at a time. It's right for the open source customers who are used to understanding changes and smaller patches than this.
Before you call yourself a customer of an FOSS project, perhaps show us the receipt that a monetary transaction had actually taken place between you and the developer.
Otherwise, you're just a beggar. And beggars don't get to choose.
Customers pay money for goods and services. They thus get a bunch of social, ethical, and legal positions in terms of their relationship with the seller.
Rsync is an open source project that its maintainers put onto the Internet. People who use it are not customers, and they do not have the right to expectations around how the maintainers will change the software or change how they develop it.
You've never had a customer in your professional setting who didn't pay money for goods and/or services? Yet it was very important for your boss (and therefore you, as a programmer) to service their every whim?
Customers are customers. Whether they're paying or not. Not all customers are worth servicing (even with infinite money offered, "firing a customer" is important to keep the community in check).
But this isn't a situation where the RSYNC maintainer should fire the customer. There's a LOT of backlash to this release. Even if this one particular customer is a bit of an ass, there's plenty of good users in that 90+ comment chain (hundreds now?) where this regression has clearly struck a nerve.
This is not a professional setting. This is an open source project that somebody published to the internet. Using it does not make you a customer, and it doesn’t matter if it “struck a nerve” with users.
Well in my professional setting, I deal with non-paying customers all the time. They're still customers and I'm still expected to listen to them.
It was better when a dedicated PM was shielding me from this crap but here we are. Deciding who and who not to listen to is just part of project management.
If committing thousands of lines of unreviewed AI generated code is "doing their best", I'd argue that them not contributing anymore would be a net benefit for the project.
The result might be closing bug trackers for the core open source projects. Or make them invite only. Even fundamental projects like Linux or LLVM accept AI contributions.
reply