Live data from Hacker News

Devtools must be open source

blog.exe.dev

51–60 of 262 posts

Re: Devtools must be open source

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

The real waste is that tweaking a config setting is a one-and-done deal, I don't want my tools to be side projects that require maintaining their build chains and frequent customization even if an LLM is doing the heavy-lifting.

Re: Devtools must be open source

#53

Earlier quoted context omitted.

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.

And? It's a convenience for their users (and most users for sure want this) for easy access to frontier closed and also open models (Fireworks). They advise also there is no markup or profit made for them in providing this managed gateway.

I guess I don't understand the OP's point even. Is there some conflict with providing this service and still being passionate about open source? IMV the answer is no.

Their main software product, Shelley, is open source: https://github.com/boldsoftware/shelley

Re: Devtools must be open source

#54
"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.

Re: Devtools must be open source

#55
post #48

Earlier quoted context omitted.

> 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 mill…

> 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.

But then what stops the upstream tools from doing exactly the same thing and getting the same speedups? I've certainly seen AI become a huge boon in my debugging experience for random user reports for example.

FWIW if we are talking about hyper personalized software like the OP, it's going to quickly go beyond "debug and maintain" and towards bigger issues like UX, ergonomics, features etc. And at that point, if the upstream is also being developed you will have differences between your personal visions and upstream

Is the answer at that point "accept whatever AI does"? That to me seems to clash with the entire premise of hyper-personalization which is where your vision is what matters not the AI's. Do you really want to get into the game of having opinions on design of every tool you use forever?

Re: Devtools must be open source

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

Actually, the harsh reality is that for a large majority it has been an easier way to pirate, nothing else, while feeling entitled to scream at the poor maintainers for not implementing whatever features they needed for yesterday.

Re: Devtools must be open source

#57
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/

Which is why many of us happily ignore their existence.

Re: Devtools must be open source

#58
post #48

Earlier quoted context omitted.

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 mill…

> 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. But then what stops the upstream tools from doing exactly the same thing and getting the same speedups? I've certainly seen AI become a huge boon in my debugging experience for random user reports for example. FWIW if we are talking about hyper personalized software like the OP, it's going…

> Do you really want to get into the game of having opinions on design of every tool you use forever?

Yeap. Most users want someone else to think for them. Not just "something" (AI). Having a vision on what works best (design) is still, for the time being, a human task IMO.

Re: Devtools must be open source

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

Yeah I think this is changing, fast.

100% agree on "clone X and tell me how it works". I'd also add: "clone X and see how it does Y; use that as design reference for building feature Z" if licenses permit.

On modifying software... I forked codex in ~Dec and had my own lightweight "plan mode" and a few other things. It was fun and satisfying, but it ended up being a bit of a pain to keep updated. The models were less good then, and maybe I should have learned some rust first. But it was close. For a less fast-moving codebase it'd have worked, and that was 8mo ago.

On the other hand as someone building in devtools for the first time, I struggle with how to think about this. We're building a cloud agent + sandbox platform, https://boxes.dev - same problem space as the author's product exe.dev. We could open source our client or the whole stack (we've been thinking about it), but we're adding stuff so quickly that anyone customizing would have a hard time with updates. There's also a lot on the hosted side that users couldn't modify unless they self-host.

But I like this vision of a world where software is some fluid thing, and everyone is writing personal mods and building off of others' - basically OSS with forks but where every user (or their agent at least) is engaged with the code.

Re: Devtools must be open source

#60
post #7
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 have sent countless small bug fixes even before, to tools that I use that I could dig into when something was off... No big heavy lifting, but plenty of "tinker on your tools" stuff. And I don't think what I did was that special, so maybe the experiences are different? The current LLM-driven stuff seems to break down the expectations, and now there are a lot of places which just ignore anything I send in (the same…

That's my biggest gripe with open source software. It's not really the open source part that's bad, but when projects turn into major projects with a substantial user base, I think the owners have an obligation not to delude their users into thinking they have more say than they actually do. Plenty of big projects leave their issue trackers public and have docs that encourage community contribution, yet effectively ignore user submissions unless perhaps someone with a name raises an issue. I completely agree that allowing users to waste their time believing their issue or pull request can make a difference is actually worse than not allowing public submissions in the first place.

I'm not sure why I seem to be in the minority on this. Maybe I've just had bad luck in that most of the issues and PRs I've submitted to open source have been ignored. Hell, I'd prefer a "thanks but no thanks" or even "fuck you" over radio silence. The typical response to this frustration of mine is "just fork the code, bro", which is absurd because forking should be a last resort for software that thrives from having a community.

Post reply on HN