Live data from Hacker News

Devtools must be open source

blog.exe.dev

41–50 of 262 posts

Re: Devtools must be open source

#41
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…

> I think LLMs have changed that equation in a way that makes the original dream much more feasible.

> Several times a day I'll prompt regular Claude chat to "Clone x/y from GitHub and tell me how Z works".

Still highly dependant on one's access to SOTA AI models (availability and funding). Most people praising LLMs publicly for this sort of use case, are the ones with unlimited access to tokens / AI credits, or simply with a lot of money to burn.

But reality is that between using one's limited employer-sponsored quota of tokens to do their 9-5 business logic coding maintenance job, versus exploring 3rd-party software as end-users, I am sure of which one their managers will prefer.

I believe it will eventually happen, whether with SOTA local models on highly capable local hardware, or super cheap inference APIs... or both.

Re: Devtools must be open source

#42
post #4

I agree that devtools should be open source, but... I very much disagree with the premise that no tools should have config files, options, or plugin systems, and instead when you want to change something like your text editor's font size, you should have an LLM download the code, change the hard-coded value, and rebuild it. That's just so inefficient and wasteful. Assuming a world in which LLMs do most of the coding…

Even pre-LLM this is how suckless tools work, I actually don’t much mind having to edit a variable in a header and recompile when you make a config change.

https://dwm.suckless.org/customisation/

Re: Devtools must be open source

#43
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

The linked article has an ambitious solution for that, in the form of this prompt to a coding agent harness:

  Set up a nightly cron job that
  executes the prompt: fetch upstream
  changes to the  and
  rebase all local changes on
  top of upstream. Check that the
  software works as intended and
  replace the current version.

Re: Devtools must be open source

#44

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.

exe.dev has quickly become my platform of choice for hosting, testing, playing and tinkering. I haven't had this much fun playing with a providers offerings since VMs were a new thing. You have no idea what you're talking about here and should do a little research on them first. What you are saying they are, is not that.

Re: Devtools must be open source

#45

Open-sourced doesnt have to be free either. There's always the very good GNU Affero General Public License 3 (AGPL-3) and others. I think most developers want open-source for transparency. We want to know what we are downloading.

AGPL software is in practice always gratis, because anyone who has a copy can post it on the internet where anyone can download it. The monetization benefit of AGPL is that it makes it significantly more annoying (but by no means impossible) for IaaS providers to sell managed hosting for the software without making a separate commercial agreement with the copyright holder. This usually isn't relevant to dev tools that users run on their own machines.

Re: Devtools must be open source

#46

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.

exe.dev has quickly become my platform of choice for hosting, testing, playing and tinkering. I haven't had this much fun playing with a providers offerings since VMs were a new thing. You have no idea what you're talking about here and should do a little research on them first. What you are saying they are, is not that.

https://exe.dev/docs/shelley/llm-gateway

"The exe.dev LLM gateway provider source within an LLM integration remains supported. It provides exe.dev-managed access to Anthropic, OpenAI, and Fireworks models. Your subscription includes a monthly token allocation, and you can purchase additional tokens at https://exe.dev/user/shelley."

The access to closed platforms is managed according to the docs.

Re: Devtools must be open source

#47
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…

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 spent a week of getting LLMs to build my own solid pty/terminal emulator. Now I have my own and frankly I'm in a better position having done it.

That's a ridiculously massive change to our relationship with software projects.

Re: Devtools must be open source

#48
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…

> I think LLMs have changed that equation in a way that makes the original dream much more feasible. > Several times a day I'll prompt regular Claude chat to "Clone x/y from GitHub and tell me how Z works". Still highly dependant on one's access to SOTA AI models (availability and funding). Most people praising LLMs publicly for this sort of use case, are the ones with unlimited access to tokens / AI credits, or simp…

I've gone back and forth on this.

A couple of years ago LLM prompts really were incredibly cheap and falling in price. OpenAI's own models had fallen in cost by a factor of about 1000x since GPT-3.

They were also cheap because many of the things you might want to do with an LLM took in the order of a few thousands tokens, at most.

Then coding agents happened, and suddenly we had a reason to burn 100,000s or even millions of tokens on a single task. Stuff got expensive!

(Classic Jevon's paradox right there.)

It feels to me like that's trending back down again though. DeepSeek and Kimi are massively less expensive than OpenAI and Anthropic, and almost as useful.

OpenAI dropped the price of Luna by 80% the other day, and it's proving very capable of exploring codebases and generating quite competent code.

So I don't think advanced AI that can help debug and maintain software will stay out of the reach of most people for very long.

Re: Devtools must be open source

#49
post #4

I agree that devtools should be open source, but... I very much disagree with the premise that no tools should have config files, options, or plugin systems, and instead when you want to change something like your text editor's font size, you should have an LLM download the code, change the hard-coded value, and rebuild it. That's just so inefficient and wasteful. Assuming a world in which LLMs do most of the coding…

Even pre-LLM this is how suckless tools work, I actually don’t much mind having to edit a variable in a header and recompile when you make a config change. https://dwm.suckless.org/customisation/

Only for trivial programs - I don't mind running make on a 2500 line C program, I would mind having to recompile LLVM or Firefox.

Re: Devtools must be open source

#50
As a maintainer of a devtool which has strived to make itself easily forkable and modifiable, I can see the allure of this line of thinking but I think it's sadly too idealistic.

Engineers using devtools are not so different to an average user in that they just want things to work. Maintaining a devtool is real work; e.g. suppose upstream adds some feature you want but it clashes with something you did downstream. Not in the merge conflict sense but in the UX sense. Do you want to resolve that on every release? Is it just "AI will fix this"? Maybe one day, but as of today agents can do something along the right lines but don't capture my UX sense very well; and if the whole point is hyper-personalization, I want it exactly how I want it.

"Does it seem to work?" is a fine right until it fails when you're doing something important. Do you then stop and go prompt an agent to fix your tooling, and hope it does a good job this time? What if it doesn't do a good job?

Moreover, for devtools which are fundamentally social (i.e. lots of different people looking at the same thing), there's real value in that thing looking the same for everyone. Having a baseline for teaching, auditing, verifying "we are all talking about the same thing" is incredibly valuable and is sometimes where the most value is.

All in all, maybe in some categories of devtools, this hyper personalization is indeed what will happen but it's a long way from being universal.

Post reply on HN