I'm curious what the actual problems with AGPL were.
If you're worried about enshittification I wouldn't be. It's relatively basic open source software that runs locally. A perfect candidate for a fork if the base app starts degrading.
VC funding can enshitify things but it can also improve them. Here’s hoping for the latter.
Would something like this qualify:
So this is another reason why developers do not pay for their tools and instead the developers of these tools go to VCs anyway. It's not the fault of the author, but most of the users (developers themselves) always want their tools for free at $0.
You have to pay and support the tools you use or else the VCs will do it for you so you can't complain when scenarios like this keep happening.
I have such mixed feelings about this - YC means VC means commercialization means enshitification. I really wish that weren't the case, but it so very often is.
Here's hoping this one's different...
(PS I am a big YC fan in general! I don't mean to sound anti-YC or anti-VC or anti-capitalism. But when it comes to low-level essential development tools, I'll never forget what happened to Warp, which started out as such a nice clean terminal project and turned into an absolute money-chasing mess.)
I see some negative comments here that I could understand why funding scares them when it comes to their open source tool but like.. atleast congratulate the guy.
https://opensource.google/documentation/reference/using/agpl...
This extends way beyond the superficial toxic license stuff. There is a lot of legal ambiguity around copyleft licenses and most companies just don't want to deal with it unless it's absolutely unavoidable.
Do YC CEO's dress in all white like Boss Hogg?
If you want your library to get traction with many real world use cases, you need to have a permissive license. If you want to stick to the principles, you’re going to sacrifice adoption.
Not saying one is better than the other, but there’s a tradeoff.
We (the stagex team) will naturally patch out any corpo tracking bullshit that may or may not happen in the future, and follow the dominant community fork should it be needed, as we did with terraform -> opentofu.
As long as herdr does not enshittify though, we will be happy to provide very high supply chain integrity releases for it as-is starting with probably next months stagex release.
Absolutely no problem with FOSS developers finding revenue streams to give themselves more resources to make their projects better.
My own company is 100% FOSS with nothing held back and will stay that way, even though we are in the current YC batch with more customers signing every week. Admittedly this is atypical, but it can be done.
Genuine question - why?
I don’t know that these are terrible things inherently, it kind of depends if he wishes to extract as money as possible from his users by any means necessary or if he’s truly trying to scale it so it can help people. All we have is this article and infinite speculation.
I personally didn’t find herdr useful, so I have no stake in the direction of what the author decides to do with herdr.
Being toxic to greedy corporations but beneficial to everyone else is the point of the GPL licenses.
For bonus points make sure your fork has better SEO than the original, so when someone who heard it's permissive embeds it in a proprietary product, you can sue them.
Hey everyone, it’s Can, the only person behind Herdr. This post is about how I decided to change that.
Four months ago I was looking for another job. Thinking about where to go career-wise. Thinking about software engineering and its future in general, my hobby projects, applications, whiteboard interviews (I still can’t believe we do those). And at some point it hit me: I am the bottleneck.
This is a management and engineering problem. I don’t want to install an app or learn a new tool just to manage my agents and my development style. I want something that fits me. You know how every company releases their own agent these days? No, don’t do that. Let my agent integrate with your product, don’t offer me another agent.
Same idea here. I didn’t like what I tried, so why not build it? So I built a runtime. But what is a runtime?
CLI coding agents run in terminals, and terminals have always been our home: editing code (yes, nvim chads), running servers, navigating projects, maintaining CI, machines, configurations. It’s the root. It’s the connection. So agents need first class primitives there.
A terminal pane belongs to an agent. A pane belongs to a tab. Tabs belong to a project.
They need to be persistent. We have agents running for hours now, sometimes days. And once you have the runtime, where they run stops mattering. You should be able to run them anywhere and keep them running.
That’s where Herdr was born. But a runtime without an interface is nothing, so: the TUI.
The TUI is the UI I use every day, and it carried Herdr this far. Not because it’s a UI, but because it shows the concepts Herdr believes in: tracking agents at a glance, dividing work between projects instead of getting lost in a pile of agents, being alerted only when an agent actually needs you.
It also has one big advantage, and it’s the reason it stays first class forever: it’s bundled. Install Herdr on your VPS, ssh in, and your UI is already there. Or run herdr --remote user@host and it installs itself. Depending on your network speed, you’re a couple of seconds away from an agent running. One command and you’re in. Nothing beats that.
Still, the TUI was never meant to be the only client. A runtime means people can build on top of it, and people did! A Raycast extension, a Stream Deck with buttons for herdr, an iOS app that drives a whole session from a phone. More than 500 plugins, one month after the marketplace released. I didn’t build any of these.
The TUI has its limits too. Some of the ideas in my head are hard to build inside a terminal, and I trust terminals, but Herdr will need more clients. More on that later.
So a solo project reached 25k stars and 340k downloads, and it became more than one person can carry.
Herdr is joining Y Combinator, F26 batch. I’m excited to make Herdr a company that builds a developer tool for anyone juggling agents all day. I want to build a small team: people who keep the runtime healthy, robust, fast, running anywhere easily, and more extensible. Letting you do more while Herdr stays small.
The runtime, what you use right now, stays free. Apache-2.0. That’s why I recently switched it from AGPL to Apache: I want everyone to use Herdr freely, without any problem.
I want to build on top of the open Herdr runtime like everyone else. I’ll keep supporting the open source while building the features people really need. The demand is already visible: multiple clients, a laptop, a VPS for the six hour job, a sandbox for risky code and ephemeral agents. Herdr can run anywhere today, but those machines are disconnected.
It should be connected.
There are many more features in my head, but I don’t want to rush. People keep telling me they love that Herdr stays lean, and that’s what I want to protect. In an age where adding one more feature costs nothing, choosing what goes in the core is the most important decision, I believe. So the core stays small, and everything else stays possible through extensions: your style, your flows, your company’s setup, your themes, your crazy ideas.
Thank you for getting Herdr this far. Thanks for the support, for sharing the love. You have no idea how grateful I am.
Anyway, back to work.
