We are building Cherry, a tool designd to solve the "spam crisis" currently hitting open-source maintainers.
With the rise of LLMs and agents, the volume of low-quality, automated PRs is making it impossible to find the good contributions.
How we want Cherry to work:
- Connects to your repo: We monitor incoming PRs.
- Whitelists the good bots: Dependabot, Linear agent etc., get a pass.
- Verifies the humans: We intercept new/unknown contributors and ask them to verify their intent and understanding of the code before the PR alerts the maintainers.
- Silences the rest: Low-effort scripts and drive-by spam get filtered out.
We are trying to walk the line between stopping spam and remaining open to new developers. It’s a hard problem.
We’d love to hear your thoughts on how to solve this without discouraging legitimate junior developers. What kind of heuristics do you currently use manually that we could automate?
I’ve been working on Hopp (a low-latency screen sharing app) using Tauri, which means relying on WebKit on macOS. While I loved the idea of a lighter binary compared to Electron, the journey has been full of headaches.
From SVG shadow bugs and weird audio glitching to WebKitGTK lacking WebRTC support on Linux, I wrote up a retrospective on the specific technical hurdles we faced. We are now looking at moving our heavy-duty windows to a native Rust implementation to bypass browser limitations entirely.
Yes! You are right that with turbopuffer you eliminate the need for manual compression and pruning and you get ultra-fast response times out of the box. I tried to stay at a higher system-design level and I think the optimal choice depends heavily on an organization’s scale and maturity: startups vs large enterprises.
Before starting Hopp and searching for alternatives, one of the things I really liked was Zed's paradigm around collaboration, with its Collab panel and Channels.
The streaming quality was also quite good with Zed. VSCode and JetBrains pairing features were a pain, as you needed to share a URL. The experience in general was not optimal. Not something you want to do multiple times a day.
With Zed, the only drawback was that the scope is always IDE (view mode also for whole screen). But from my experience, pairing is more than your IDE. It's terminal, debugging your unnecessarily complex AWS setup, fiddling with Grafana dashboards, etc.
