Live data from Hacker News

Devtools must be open source

blog.exe.dev

91–100 of 262 posts

Re: Devtools must be open source

#91

Earlier quoted context omitted.

Maintaining a fork seems trivial for an LLM. Replaying each upstream commit against your fork is exactly what even dumb models can do without issue. But at the same time LLMs also let you question why you’re using a dependency if it’s causing certain issues for you. e.g. I got tired of waiting for libghostty to publish a new stable release since the one in March which would have a memory leak fix I reported, so I spe…

I too built a terminal emulator and I like it, but I wouldn't say it's easy to maintain even with LLMs. The # of edge cases is insane.

The cool thing is that you can use and adapt the tests of all major third party terminal implementations. Come up with your own invariants (brainstorm them with a smart LLM), and now every third-party test either passes, diverges (due to invariant/arch), or diverges (due to product bug).

And even if you aren't that robust about it, terminal apps are the sort of ideal vibe-coded app since, using it daily, you are giving it a constant real world test that uncovers issues to be fixed incrementally.

Is neovim over tmux over ssh glitching? LLM can fix it.

Is codex or claude code overwriting lines in the TUI, maybe due to alt screen, but it also happens in other major terminal apps? LLM can figure out why and whether you can come up with better general architecture to fix it.

Is there behavior you wish you had but no other terminal app supports? LLM can add it.

You can end up with a far better product than what you would find in the wild, and it's a fun sort of work.

Re: Devtools must be open source

#92

exe dev is a VC-funded company reselling open source software. Everyone's making cash from your open source code except you.

You write as if they have an ulterior motive to try to trigger your FOMO to keep you proactively burning CPU cycles and AI tokens, just in case something might have changed while you were sleeping.

"Lather, rinse, repeat." Some things never change.

Re: Devtools must be open source

#93

Company that resells openclaw and closed providers preaches about open source. The new personalization talking point appears to be coordinated. It is all over the Internet since last week. Problem is, 99.99% of people (including developers) do not need "personalized" software, unless you mean Emacs style.

> The new personalization talking point appears to be coordinated. It is all over the Internet since last week.

I agree with you.

They are manipulating public opinion, fooling users.

Re: Devtools must be open source

#94
A bit idealistic for the crowd here but has some good points.

The other day I wanted to build personal apps for my Kobo device. It has a single ~800Mhz core and 512 MB of RAM, probably eight times less than a rasbperry pi, but runs a Linux.

I wanted to break free from watching my laptop screen for long Claude sessions partially due to degrading eyesight and have a sidekick for approvals streamed to the Kobo. Apart from the Claude and Codex permissions sidekick done via hooks, I ended up building an entire SDK, an HN client, an RSS discovery & reader and an audiobook generator using deep research and ElevenLabs API all running on it.

Anyone using an LLM can now personalize it for their own Kobo device, which might have some nuances over my Clara BW. Significantly less work I hope than doing it all from scratch even with a coding agent.

https://github.com/BandarLabs/Cobalt

Re: Devtools must be open source

#95

"Five years ago, most software engineers I spoke to had no programs they had written for themselves." What happened five years ago? Before that everyone used tools they wrote themselves. I think the answer is nothing happened five years ago and everyone still uses tools they wrote themselves.

> What happened five years ago?

Apparently the dude found some new acquaintances.

Re: Devtools must be open source

#96
I've worked at a DevTools company and been the CEO of one too. Here's my thoughts:

I agree that they need to be open source. But that makes it really hard to make a successful business. Sure, there are examples of success, but also many examples of successful open source tools never becoming successful companies.

The most famous example is Sendmail (where I worked way back in the day). They took millions in funding and ultimately sold to an infra company, returning pennies on the dollar to their investors.

The difficulty stems from the fact that your customers are developers and operators, and they all think that they don't need you because they are perfectly capable of running the software themselves and adding whatever they need to it. In a lot of cases they are right.

And now, with AI coders, it gets 10 times worse, because they can take your open source and then vibe code a "good enough" version of your commercial product.

I don't know how to square this circle. There are a lot of great dev tools made by people for free for the love of the game. But even those people need to eat.

Some tools have started making licenses that are free for individuals and startups but cost money for profitable companies. That's an interesting strategy but I know some companies won't allow those tools precisely because of their license.

Re: Devtools must be open source

#97
post #3

One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. I think LLMs have changed…

Then you’re maintaining a stack of patches on top of the upstream until the end of time because the maintainers of the projects don’t want AI slop contributions, but now you depend on these changes for your own use so now you’ve created more work for yourself keeping your own fork up to date. I used AI to help me make a change to a library I use that ended up being a single line of code. The pull request was refused…

> Then you’re maintaining a stack of patches on top of the upstream until the end of time because the maintainers of the projects don’t want AI slop contributions, but now you depend on these changes for your own use so now you’ve created more work for yourself keeping your own fork up to date.

I thought about this but I currently maintain a fork of about ~6 things I use on my own, none of which I have any interest of contributing upstream because it'd be out-of-scope and put a burden on the maintainers that is unrelated to their primary goal. It has been an extremely easy experience with claude to keep those tools up to date on top of upstream.

StGit/Stacked Git is a proven tool for this and has worked wonders, I can literally just ask claude to fetch upstream and reapply stg patches on top and fix each patch if they break in order. I also keep extensive description of the INTENT on the stg patches so claude can easily figure out if something is no longer relevant (ie: somewhat implement by upstream) or where to land the code/hooks. I've added features, reworked how algorithms work (pathfinding related!) and small nits I hit on daily usage.

Even on a very churny upstream (one of the projects the single dev likes to refactor alot) it's still extremely chill and doesn't take more than an hour to get it updated when everything breaks. I can't say i care enough to setup a daily cron like a sibling suggested, but it would likely work just based off of this stg experience.

It's also nice, because some of those were actual bug fixes too which i have contributed back upstream! Maintaining your personalized fork is truly reasonable nowadays.

Re: Devtools must be open source

#98
post #96

I've worked at a DevTools company and been the CEO of one too. Here's my thoughts: I agree that they need to be open source. But that makes it really hard to make a successful business. Sure, there are examples of success, but also many examples of successful open source tools never becoming successful companies. The most famous example is Sendmail (where I worked way back in the day). They took millions in funding a…

> Some tools have started making licenses that are free for individuals and startups but cost money for profitable companies.

Ive seen this as well, but at a certain point it just seems like if your code is online, someones either taking it wholesale or recreating core pieces from the spec regardless of any licensing.

Its a tough time to be building OSS if you don't have distribution solved AKA some pedigree from the before times.

Re: Devtools must be open source

#99
post #3

One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. I think LLMs have changed…

> One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. A corollary is that more people will have eyes on the source code than the original developer(s), so the project can benefit from a broader skill set and set of orientations and priorities than if it were proprietary. Not just on the development front, but hopefully also in security…

> I question the narrative that open source wasn't providing much value previously

Don't get me wrong, I've been a strong advocate for the benefits of open source for decades. I think it's delivered enormous value, and most of the top valued companies in the world today wouldn't exist without open source!

What's new now is that the end user inspection and modification benefits are feeling a lot more material for a lot more people than before.

Re: Devtools must be open source

#100
post #3

One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. I think LLMs have changed…

Do you verify the reply on how Z works too?
Post reply on HN