redoh

Hey HN, Octopus dev here.

Any public, OSI-licensed repository gets unlimited PR reviews. There is no "we train your code" clause. Public code is already public; we don't need to train it to review it. Octopus itself is MIT licensed and can be hosted on your own server, so if you don't want to depend on us, you can run the entire stack on your own infrastructure.

I wrote a more detailed explanation of "Why were we giving octopus free forever?" here: https://dev.to/redoh/why-were-giving-octopus-free-to-open-so...

If the reviews are bad, please report an issue, I read them all.

I'm happy to answer questions in the thread

ps: url correction: https://octopus-review.ai/open-source

this is for claude code status bar

One thing that helped my team a lot was tagging review comments with prefixes like "nit:", "question:", and "blocker:". Authors stop guessing what's required to merge versus what's a preference, and reviewers feel free to leave the small style notes without holding things up. Also a quick voice or pairing call before reviewing anything contentious saves an absurd amount of round trips.

We had a massive merge at work last year where two teams diverged for months on a shared codebase. It took three people a full week to resolve everything, and the worst part was stepping on each other's conflict resolutions. Splitting the merge into independent slices that people can work on in parallel would have saved us a lot of pain. The integration branch approach where non-conflicting changes land automatically is a nice touch too.

A lot of the "free labor for Amazon" framing in this thread misses the core dynamic here. Colin wasn't doing charity work, he was making FreeBSD run on EC2 because Tarsnap literally depends on it. That's probably the healthiest model for open source contribution: you fix the infrastructure your own product sits on, and everyone downstream benefits too. The alternative is waiting for Amazon to care about your niche platform, which could mean waiting forever. It's a different calculus than, say, an indie dev writing a library that AWS wraps into a managed service.

The difference between this and Munich's attempt is that France has been building up gradually. They already run Tchap (Matrix-based) for government messaging, and the gendarmerie switched to Linux years ago with over 70k desktops. Munich tried a big-bang migration without enough internal expertise and caved under political pressure when MS moved their HQ there. Schleswig-Holstein in Germany is taking the same incremental approach now and seeing better results. The pattern is pretty clear: governments that treat it as a multi-year capability build succeed, those that treat it as a licensing swap don't.

Elm's type system and architecture are genuinely pleasant to work with, so seeing those ideas ported to a Go compilation target is interesting. You get the safety and expressiveness of Elm but end up with a Go binary you can deploy anywhere. I wonder how the error messages compare, since that was always one of Elm's strongest features.

The part that keeps bugging me about incidents like this is how the clearest signal was already there and nobody acted on it. Every legitimate v1 release had OIDC provenance attestations, and the malicious one just... didn't. That's a binary check you could automate in any CI pipeline in about ten minutes, but almost nobody does.

I've started adding a provenance verification step to our deploy pipelines after the event-stream incident years ago, and it's caught weird stuff twice now, both times just maintainers accidentally publishing from their local machine instead of CI, not actual attacks, but the point is the same mechanism would catch this. The real problem isn't that we lack signing infrastructure or better NPM policies. It's that the ecosystem has trained everyone to treat dependency updates as a solved problem the moment you have a lockfile. Lockfiles protect you from silent republishing of existing versions, but they do nothing when the attack comes as a "legitimate" new patch release. Diffing your lockfile for unexpected new transitive deps on every deploy is table stakes, and most teams I've worked with still don't do it.

Writing a C compiler in pure shell is one of those projects that sounds absurd until you think about bootstrapping. If you want to compile C on a system where you literally have nothing but a POSIX shell, this is exactly what you need. The fact that the parser itself is BNF-generated from shell modules makes it even more interesting as a study in how far you can push shell scripting before it breaks. Would love to see this evolve into a proper repo with tests so it can actually serve as a minimal bootstrapping tool.

The fzf integration is a really nice touch here. Half the battle with dev tool management isn't installing things, it's remembering what you installed and how six months later. I know everyone's going to recommend Nix (and they already have), but there's something to be said for a solution where the entire logic fits in your head on first read. I've had a similar Makefile-based setup for years and the biggest win is onboarding new team members who can just read the targets and immediately know what's available.

100x is a bold claim but the Zig approach to optimizing hot paths in Bun makes a lot of sense. There is so much low hanging fruit when you actually dig into how package managers interact with git under the hood. Nice writeup, the before/after benchmarks are convincing.

we used Kimi 2.5, its really good