Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Devtools must be open source

blog.exe.dev

Post reply on HN
Print view View original

141–150 of 262 posts

Re: Devtools must be open source

#141

Post by CamperBob2 »

20k wrote: post #128
CamperBob2 wrote: post #118

Earlier quoted context omitted.

Been doing it for the past several weeks. It is no longer correct to say that LLMs can't/don't/won't exercise reasonable aesthetic judgement on the finished product. Immense progress in this area has been made recently. If you want the model to maintain a certain look and feel, or to preserve the UX in other ways, tell it . Even if it doesn't get it 100% right today, the direction of progress is pretty clear, so you…

This doesn't appear to relate to the conversation at all, because we aren't talking about generating entire products. Is this just generic AI advertising?

I'm responding specifically to the GP's point: 'And no, "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,' and specifically to your rejoinder ('I suspect the people advocating for this don't actually do this.')

This is simply not the case when working with Fable-class models. Those who persist in believing it are hopefully very close to retirement.

I'm not 'advocating' anything, just stating a fact.

Re: Devtools must be open source

#142

Post by [deleted] »

dregitsky wrote: post #59
simonw wrote: 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…

[deleted]

Re: Devtools must be open source

#143

Post by simonw »

seba_dos1 wrote: post #131
simonw wrote: 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. S…

I expect it's a whole lot easier on Debian and Arch than it is on macOS.

Re: Devtools must be open source

#144

Post by simonw »

stephen_cagle wrote: post #139
simonw wrote: 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 refl…

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

I do think there's a bit of a risk there, actually.

It's not just the consultancy thing - it's the competitive advantage of the software itself.

Used to be that you could release open source safe in the knowledge that few people would extract core parts that they need and discard the rest, or fork the project in another direction, because the friction was too much. Better value for people to contribute to your project directly, which provides a great deal of value in exchange for releasing it in the first place.

Now... if you invent some brilliant new database indexing scheme and release it as open source, I can point my coding agent at your code and have it imitate your new insight in a few minutes.

For some projects that's fine, but for projects that intended to commercialize that's not ideal at all.

So yeah, I do worry about the way coding agents distort the previous incentives for open source projects.

Re: Devtools must be open source

#146

Post by rglover »

jedberg wrote: 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…

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

You really don't. If people can get something for free (effectively what OSS means to the average bear these days), they will, and they really don't care if the creator/maintainer can survive. And if that creator/maintainer doesn't, the logic boils down to "what's the replacement for ?"

IMO, the combination of OSS and "generous free tier" SaaS plans basically nuked the willingness to pay for software, especially dev tools. Folks are just too conditioned to expect stuff to be cheap or free nowadays. Maybe that changes long-term but shrug, who knows.

Re: Devtools must be open source

#147

Post by seba_dos1 »

simonw wrote: post #143
seba_dos1 wrote: post #131

Earlier quoted context omitted.

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

I expect it's a whole lot easier on Debian and Arch than it is on macOS.

Well, a good OS helps in a multitude of ways. It's somewhat harder to do what we're talking about with proprietary tools anyway.

Re: Devtools must be open source

#148

Post by dolmen »

awesome_dude wrote: post #110
dregitsky wrote: post #59

Earlier quoted context omitted.

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…

> On modifying software [..] It was fun and satisfying, but it ended up being a bit of a pain to keep updated. I don't mean this as a criticism in any way - but the need to keep your changes current is a strong motivation for getting those changes incorporated upstream.

> but the need to keep your changes current is a strong motivation for getting those changes incorporated upstream.

But the cost of contributing changes made by AI is higher: * high chance of the being just rejected because code made by AI, or PR made by AI * so contributing would require carefully preparing a human-made patch (but that becomes much more work than telling an agent to just upgrade my fork) * there is still a high chance for the patch to be rejected or just ignored for months/years, like before

Also, there are much more vibe coded projects which are open source, but the author has no interest in maintaining, so issues/PRs will just be ignored.

Re: Devtools must be open source

#149

Post by pif »

simonw wrote: 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".

In principle, you should not need the source code: the AI should be able to answer by examining the binaries.

Re: Devtools must be open source

#150

Post by xmprt »

g3f32r wrote: post #136
theamk wrote: 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…

It's still the same problem. Now instead of checking if the code is correct, you have to check every day if your prompt is still validating the correct features that you expect to work.
Post reply on HN