Herdr is joining Y Combinator. The runtime stays open
Posted by collinmanderson 10 hours ago
Comments
Comment by ahmadyan 7 hours ago
The terminal multiplexer / multi-agent coding space is getting very crowded. YC alone has funded many competing startups in this space: herdr, Superset, cmux, Emdash, Orca, Bullet, Conductor (Conductor was in YC before pivoting from chat->coding). I’m probably missing a few, and that’s before counting companies outside YC such as Superlogical and Agentastic.dev (by yours truly).
One thing I find particularly interesting is the role of open source in this market.
A lot of these products started open source (i assume as a tactical way to gain traction and build a community). But after the early traction phase or raise funding, the incentives seem to change.
Being open source by itself is not a product differentiator in this market. The features required for string positioning (orchestration, cloud, custom agents, enterprise features, hosted infrastructure, etc.) often end up either closed source or available only through the hosted product.
That makes me wonder how much developers actually value OSS for this category. How much does it matter to you whether your IDE or coding environment is open source?
Is OSS important because you want to inspect the code, fork it, self-host it, avoid vendor lock-in, or simply because you trust open-source developer tools more? Or, for desktop software like IDEs is open source mostly a nice-to-have rather than a requirement? So I’m curious where HN lands on this
Comment by giodamelio 6 hours ago
This is not the only project like this too. Many of my devtools are piling up changes. I try to upstream changes where it makes sense, but many times they are either very bespoke, or I can't be bothered to do them "right" (for example for the jj workspace change, I just ripped out git support, so I didn't have to futz with syncing the symantics up between the two and config and whatnot).
LLMs have made making personal changes to devtools so effortless that I am now extremely hesitant to use any non source available software at all.
I have been thinking about a possibly expanded market for source available software. I don't really care what the license of the software is, I'm not sharing it at all or using it commercially, so it's kinda a moot point. If someone made some amazing software and sold the source I'd definitely consider it. I know there are all sorts of practical business problems with that, but that aside I'm curious if others feel the same?
Comment by skinfaxi 5 hours ago
This mirrors my view so totally it's crazy. If AI is ushering in the era of personal tooling, closing the harness is orthogonal to what users want.
Comment by soulbadguy 5 hours ago
care to share a pr :)
Comment by giodamelio 3 hours ago
You can also see the combined output of all my changes at [2], which Jujutsu makes so damn easy via megamerges.
1: https://github.com/giodamelio/herdr/tree/jj-workspace-migrat...
Comment by ahmadyan 4 hours ago
alternative is to collect/sell usage data, which is icky, or provide something as a service (token usage, infra, plugins, etc)
Comment by giodamelio 3 hours ago
I am kinda imagining a structure for a theoretical dev tooling business that might be OSS Core, and Source Available additional features. I'm not sure if there is a generally accepted definition of Source Available, but I don't necessarily mean that the source is just out in public on the web. It could be sent to you when you purchase the product, and could maybe even be sold on an upgrade sort of model, where you pay again for the next "big version" of the software, like the good old days of desktop software.
Comment by devmor 2 minutes ago
This came about after 3 separate incidents where I went to use the harness and found it now provided a degraded experience because Microsoft unanimously decided to change some part of it without my consent.
I am a staunch believer that the most important thing a tool can do, other than its job, is provide a static experience until the user opts to change it. I use AI like a tool, because it is. I need it to behave the way I expect, or it's not actually useful to me.
Comment by bgnm2000 1 hour ago
Comment by 2001zhaozhao 5 hours ago
Comment by foltik 5 hours ago
Comment by devin 3 hours ago
Comment by sharts 6 hours ago
Comment by conartist6 6 hours ago
For me OSS is a weapon to be wielded. By making perfect software that cannot be improved upon, and making known my ownership of it, I'm am defending "embrace extend extinguish" attacks that would otherwise be damaging to me. Those attacks rely on being able to undercut a product's position in the market with a similarly positioned product that can be just slightly better and/or cheaper.
Comment by calvinmorrison 4 hours ago
Comment by ahmadyan 4 hours ago
Comment by calvinmorrison 4 hours ago
Comment by miki123211 5 hours ago
External programs will still be useful for the tiny minority who wants different harnesses for different projects, but yeah, tiny minority.
Comment by ahmadyan 4 hours ago
One bad cycle and the next Opus 6 or GPT 7 might flop (think what happend to LLama4 or Gemini), and the user quickly switch to the next best thing. So it make sense to build your tooling to be model-agnostic.
Comment by killix 1 hour ago
Comment by ValentineC 9 hours ago
I'm curious what the actual problems with AGPL were.
Comment by tyre 8 hours ago
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.
Comment by tlamponi 5 hours ago
No, it isn't; a client talking to an AGPLv3 service over a network API stays a separate program and is not touched by the license at all. Section 13 places obligations solely on whoever runs a modified version of the service, while remote users, API clients included, only gain the right to receive that service's source. So nothing on the client side must suddenly become AGPLv3, and the only thing that ever has to be shared is the AGPL'd program itself, not anything across the API boundary. The first half of your post is basically unfounded FUD; the second half tracks.
Comment by mbreese 4 hours ago
Comment by waterproof 4 hours ago
It wasn't the only red flag in this case, but frustrating nonetheless.
Comment by guywithahat 8 hours ago
Comment by inigyou 8 hours ago
Being toxic to greedy corporations but beneficial to everyone else is the point of the GPL licenses.
Comment by icantevenhold 7 hours ago
Comment by a2ff6eeb0 7 hours ago
Comment by jraph 7 hours ago
There's nothing toxic in the AGPL for you as long as you don't want to make that code proprietary (even without making profits)
Comment by jraph 7 hours ago
They just choose avoid agpl software. Their loss. Unfortunately they also spread FUD on this and many commenters here happily convey it.
Comment by outofpaper 6 hours ago
Copyright (c) [year] [copyright holders]
Permission is hereby granted to any person obtaining a copy of this software and associated documentation files, to use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software, including for commercial purposes, subject to the following conditions:
If you distribute this software, or any work derived from it, you must release the complete source code under this same licence. If you modify this software and users interact with your version over a network — as a web application, an API, or a hosted service — you must offer those users the complete source code of your version, at no charge. All copies must include this copyright notice and this licence. You may not impose additional licence restrictions beyond this.
These permissions are irrevocable and royalty-free for the term of copyright. THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND. This is a plain-language summary. The full legal text of the GNU Affero General Public License, version 3, governs all use for you.
Same rights. Same freedoms only a little more opiniated delivery. Same business card. The only difference: when someone takes your code, tweakes it and builds a service on it, the tweaks, the improvements must come back.
Comment by inigyou 7 hours ago
Comment by toomuchtodo 8 hours ago
Comment by inigyou 8 hours ago
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.
Comment by toomuchtodo 8 hours ago
Comment by rajangdavis 9 hours ago
Comment by spudlyo 8 hours ago
Comment by rajangdavis 8 hours ago
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.
Comment by spudlyo 8 hours ago
Comment by inigyou 8 hours ago
Comment by yoyohello13 2 hours ago
It’s fine to use these kind of tools, just don’t get too attached and be ready for the rug pull.
Comment by koiueo 8 hours ago
Comment by yoyohello13 2 hours ago
Comment by inigyou 8 hours ago
Comment by gilthelander 8 hours ago
Comment by gilthelander 8 hours ago
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.
Comment by user- 8 hours ago
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.
Comment by Johnny_Bonk 8 hours ago
Comment by kristjansson 7 hours ago
I appreciate that discipline and respect for your user in the current tool, and hope to be a paying customer of a similarly values-aligned business you’ll build on top of it!
Comment by Taek 4 hours ago
Comment by joegibbs 1 hour ago
Comment by yoyohello13 2 hours ago
Comment by moomoo11 3 hours ago
Comment by asadm 8 hours ago
Comment by SJMG 7 hours ago
Comment by humblepie 9 hours ago
Comment by dgunay 7 hours ago
I'm not sure the tmux project wants to evolve to support this natively so for now herdr seems like one of the best open and forkable options available. Considering how little I've had to really touch my tmux setup after getting it going I don't think it's necessarily the worst thing in the world if the FOSS community maintains a deshittified fork of herdr, should it come to that.
Comment by natsucks 2 hours ago
Comment by chrysoprace 7 hours ago
Comment by lrvick 8 hours ago
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.
Comment by SierraJC 5 hours ago
Comment by haykot 5 hours ago
Comment by qudat 4 hours ago
Comment by tmzt 1 hour ago
I've been evaluating a few of these (and built one into another project I was working on, almost by accident), and am mostly looking for a frontend agnostic, terminal only (not harness) which can submit instructions to agents one line at at time with rate-limiting.
I was also surprised by tmux being built on shared memory when I tried to route it over a vsock to a VM. One of the annoyances with tmux is it's failure to forward environment changes to the individual tabs (such as an option when attaching), or allow for something like a ssh-agent forwarder (shouldn't be built in though).
Comment by mastazi 1 hour ago
Comment by smagnuso 3 hours ago
Comment by vehemenz 6 hours ago
Comment by durdn 6 minutes ago
Comment by threecheese 5 hours ago
It’s not open source, and costs a few bucks, but it works well and has live Claude/Codex/etc notifications if you are willing to install a hook daemon on your hosts with homebrew. I was looking for batteries-included “code from my iPhone” after trying a bunch of self-hosted stuff, now I connect to my Macs over Tailscale and get dropped right into multiplexer sessions with rich status notifications.
Comment by asadm 6 hours ago
Comment by abofh 4 hours ago
Comment by hx8 9 hours ago
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.
Comment by mickaelkerjean 1 hour ago
Comment by exitb 19 minutes ago
Comment by apt-apt-apt-apt 2 hours ago
I find myself to be a huge bottleneck, having to do technical design and design reviews, to make sure they're actually working on the right things.
I feel like there's not enough coding work to justify multiple agents, that part doesn't take long, and then it's back to design again.
Comment by lonesword 5 hours ago
Comment by jdorfman 5 hours ago
Comment by ernsheong 5 hours ago
Comment by xyzsparetimexyz 5 hours ago
Comment by rwz 2 hours ago
I'm personally using the 1.4 canary (the rust rewrite version) and definitely plan on continuing using it in my future projects.
Comment by loveparade 3 hours ago
Comment by loveparade 5 hours ago
Comment by yoyohello13 2 hours ago
Comment by Gooblebrai 6 hours ago
Comment by htrp 6 hours ago
Comment by phrmendes 3 hours ago
Comment by nlh 9 hours ago
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.)
Comment by scubbo 7 hours ago
Genuine question - why?
Comment by an0malous 8 hours ago
Comment by tomhow 7 hours ago
It doesn't have to be that way. YC partners are supportive if you just want to take the YC funding and nothing more, keeping the team small and just focusing on making the product better for customers. Indeed YC advises against taking VC if you don't need it.
Comment by abirch 7 hours ago
Comment by tamimio 9 hours ago
Comment by pecheny 9 hours ago
Comment by sarky-litso 8 hours ago
Comment by inigyou 8 hours ago
Comment by Fervicus 7 hours ago
It won't be.
Comment by Waterluvian 6 hours ago
Comment by kar1181 8 hours ago
Comment by behole 4 hours ago
Comment by DonHopkins 3 hours ago
Comment by dominotw 9 hours ago
Comment by albertgoeswoof 8 hours ago
Comment by foxtrot8672 6 hours ago
Comment by tyleo 8 hours ago
VC funding can enshitify things but it can also improve them. Here’s hoping for the latter.
Comment by throwaway613746 6 hours ago
Comment by barapa 8 hours ago
Comment by EGreg 9 hours ago
Would something like this qualify:
Comment by rrr_oh_man 6 hours ago
Comment by rvz 9 hours ago
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.
Comment by hx8 8 hours ago
Comment by rvz 6 hours ago
This software was "free" (as in libre) and costed $0 and until now, it was licensed under AGPL 3. But contrary to one common misbelief in open source and free software, the maintenance is not free at all.
> The best thing a software dev can do is donate some of their time to do more open source development, and in that way we all benefit from having more and better open source tools. If someone wants to exchange code for money there are plenty of avenues to do that.
In the case of this project which took off, why would you expect the maintainer to work on the project for free?
Comment by LikeAnElephant 7 hours ago
I gladly donate / pay subscriptions to software I use regularly... but the company has a responsibility to make it obvious on how to do so
Comment by rovr138 8 hours ago
Comment by bigyabai 8 hours ago
Comment by rvz 6 hours ago
You are straw-manning a point no-one made. Herdr is open source and if the users would like to see it maintained for a long time, they would donate $$$. Clearly the donations were no-where enough and raising money was.
The point is maintaining open source projects for free is NOT sustainable and most HNers in this thread clearly struggle with not understanding that.
> This status quo is fine.
Seems like you would want him to work for free, then wait until the author becomes demotivated and then he abandons the project entirely and we'll see a new post about why Herdr got abandoned.
Comment by bigyabai 2 hours ago
That's a bad-faith dilemma, you know it. The users can want to see it maintained without necessarily having the money, userbase or motivation to sponsor the lead dev. It's not criminal to have a tight pocketbook, and that's why free devtools succeed while paid ones rot. There will be always be a FOSS version of Herdr, and thanks to vibe coding it will probably retain feature parity with the paid version.
Everyone is happier with this arrangement, you're one of the only ones fulminating at the outcome.
> Seems like you would want him to work for free
Clearly he's content releasing the software for free. Let me guess, you're going to complain that the free market "forced" him to work without pay?
Comment by applfanboysbgon 9 hours ago