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.

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 tinkers as before), generally, for a while. Though there are some tools that picked up the pace and actually react faster (so YMMV here too).

But there are few things more frustrating as being half-way. Case to point is LM Studio. It's closed source, has bugs (duh!), and there's at least a GitHub issue tracker to report the bugs -- but then by and large nothing happens to those reported things. It's almost worse than not having an issue tracker (then I could justify never to really touch LM Studio again, this way I keep hoping against hope that reports will turn into fixes and thus I keep using and keep reporting...)

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

Ha, yes! A few times I've had a back and forth with Claude about why software X isn't working as I expected it to, with Claude coming up with more and more ludicrous explanations, and in the end I say, "just go and read the code", and it remembers it can do that and goes and does it and then finds the bug, or the weird UX design or whatever. It's really helpful.

> 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 canonical example was RMS needing to fix a printer driver bug back before software updates were really a thing. That meant that there was a greater motivation for users to maintain their changes.

Today, with software being an evergreen stack of turtles from the BIOS all the way up the OS to the remote APIs the qpp interacts with, expecting a user to indefinitely maintain their private fork of any software is a really big stretch.

Unless it is a local-only, unmaintained project that doesn't get deployed through a software repository or an app store, I think that original vision of open source software is very much the exception and not the rule.

> the freedom is more about being able to lean on other people to do that

Alternately: The collective capability is what makes important lasting changes, but individual capability is still a required building-block to get there.

Much like freedom of speech, come to think of it.

> 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, usability and accessibility

> 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 imagine you are correct that most people historically didn't inspect or modify most tools they use, but most developers I know who have relied on open source software -- even if they didn't contribute directly upstream -- have had the experience of locally patching a small bug or adding a small enhancement to suit a use case, or studying a piece of an open source module as a starting place for their own implementation for some piece of functionality, or doing a cursory scan of a project to make sure it isn't e.g. phoning home, or simply taking a morbidly curious look to see how the sausage is made.

Sure, I'm not a representative sample and it would be great to have some actual numbers on this, but I have observed this among engineers at Fortune 500s and YC startups, but also non-tech businesses as well as at local public utilities and health systems.

Anyway, I agree that LLMs can provide a lot of value here and reduce the friction but I question the narrative that open source wasn't providing much value previously because most people didn't have time to read code. It provides value even without developers reading code in the first place, and reading code was historically one of the essential parts of the work

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?

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.

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 for having a Claude attribution even though it was a single code change that was syntax only with no change in behavior just to make it compatible with an older version of the language they claimed to support (so I considered this incompatibility a bug).

Ended up figuring out a workaround in our application code instead just so we could use the upstream. Still not really worth the effort for most projects even with AI.

In the era of AI slop being bombarded at you from all sides 24/7 I don’t blame them. Gatekeeping is the only way to maintain a semblance of quality (and sanity). Once you let slop in it accumulates at an insane rate. You need zero tolerance or you will be overwhelmed.

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

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

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

A lot of modern open source software is often written in dependency heavy languages.

So to do a "proper" examination, by definition you need to consider the dependencies as well as the core code itself. We all know how supply-chain attacks are on the rise.

> 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

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

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

Hell, even when I can justify the time commitment for that, I can't justify the ongoing maintenance burden of fixing up my patches to work on the latest version every release or major security fix...

Do you verify the reply on how Z works too?

[flagged]

[flagged]

[flagged]