Live data from Hacker News

Devtools must be open source

blog.exe.dev

131–140 of 262 posts

Re: Devtools must be open source

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

> Most people can't justify the time commitment needed to read and then modify the code for tools they use very often.

As someone who way long before the LLM age had small patches accepted in several dozens of projects I've been using, I can assure you that this is just a matter of mentality. All I needed to be able to do that was to stop thinking that "nobody has done it so far, so it must be hard" and just do it. Sometimes I failed, but more often than not it turned out it wasn't hard at all and nobody has done it so far simply because nobody cared enough to attempt it.

> Getting software to compile in order to start hacking on it used to be enough friction that I often wouldn't bother.

Not my experience at all. Usually the only limiting factor is the size of the project. Compiling a web browser on my 7 yo 13" laptop is a miserable experience, but compiling most of the desktop components or utilities is and has always been a breeze and, in my experience with both Debian and Arch, just a matter of grabbing the distro's source package. I even do it on my phone these days.

Re: Devtools must be open source

#132
> The result is that software that can be personalized doesn’t need a plugin system or a config file.

Yes, please make me rebuild my software to change an API endpoint or port number. It's a wonderful use of time and electricity to build and spin up agents to fix the inevitable problems with building software. Instead of changing a string in configuration file.

(/s if not obvious).

Configuration and plugin systems exist for a good reason: software should be reconfigurable and modular without requiring the wholesale replacement of the original. Even if the code is open source, there are good reasons to move logic and data out of tree and into config or plugins.

Re: Devtools must be open source

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

This is in my opinion the single most important revolution that will come from llm in the dev space. Not vibecoding or replacing entire teams.

Its this and also the ability for non dev to create their own little tools (for productivity, entertainment, family life, whichever).

I think they will put back the "personal" in personal computing

Re: Devtools must be open source

#136
post #15

> 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. This sounds like hell. You have unreliable actor redoing the software every night, and every day there is a chance you wake up and find your workflow broken. And no, "Check that the software works as intended" is…

> "Check that the software works as intended" is not going to cut it, as AI are very, very good at obeying the letter but not the spirit of the ask.

Surely you don't think that he literally meant to use those seven words as a bullet proof prompt, right?

I will never understand this way of responding literally and pedantically to verbal psudocode. He's leaving it as an exercise to the reader to specify "check that the software works as intended" because he could never possibly properly articulate a perfectly comprehensive QA and validation flow for every piece of software that would satisfy every individual's need.

Re: Devtools must be open source

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

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

We built a free tool to help with this workflow! Just prepend "ask" to any public github repo and get a chat box to ask questions on it :)

For example: https://askgithub.com/openai/codex

Re: Devtools must be open source

#138
post #79

Earlier quoted context omitted.

I don’t auto-rebase but I definitely vendor in and choose to update on my own cadence.

yeah, vendor in is the only way to stay sane over time, if you understand the cost of dependencies (and have a reasonable security model). And forking some Python or Go dep on Github and using that instead of the canonical one is pretty ergonomic. I don't know how Rust folks manage with so many dependencies via Cargo - my friend who loves Rust says they are smaller and more "one thing done well" but the complexity of…

My number one problem with Rust (which I otherwise like) is that Cargo allows build-time code execution so I need to run in a sandbox (unergonomic for me) or provide agent instructions to inspect `build.rs` style code in libraries etc. prior to compile. In practice it's easy to build and then ship a dev binary into a sandbox, but it's not so pleasant to build in a sandbox, so I don't want to get build-time pwned. Makes me very unhappy.

Right now, I just have a build server that I ship things to and does lots of build-caching etc. so it's fine, but I would have preferred not to have a system that actively allows build-time thievery of my ~/.ssh

Re: Devtools must be open source

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

Three points:

1) I think that is a really interesting insight. I have never done the above myself, but often I don't "tinker" with things because the amount of energy it would take me to JUST GET IT RUNNING is large, and I might end up borking my own system in doing so.

An LLM in a VM can reasonably and safely completely work out on its own how to run some software. I'd never thought about really doing that as a reflexive thing when I am curious. Good thought.

2) I wonder if this is going to be a bifurcation. Where open source software is looked at far more often than in the past because it can actually be "live" investigated (not just have the code reviewed) with little effort?

3) On the opposite of 2, I wonder how many people are going to start "close sourcing" their software, because previously they could be open source, and rely on the inertia of actually getting it running to be enough to support a consultancy service or whatever. If getting it running is trivial, then maybe I need your service less, I just need the code. Might result in different business models?

Post reply on HN