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

231–240 of 262 posts

Re: Devtools must be open source

#231

Post by nextaccountic »

nine_k wrote: post #209
nextaccountic wrote: post #180

Earlier quoted context omitted.

> if licenses permit. As if licenses mattered in the LLM era Case in point https://news.ycombinator.com/item?id=48466812 > In looking at the code that the LLMs have produced for the project, especially given the pretty massive and widespread architectural changes needed to make the implementation libified and memory safe, we decided that the codebase is not a derivative work that would require carrying forward the GP…

> As if licenses mattered They still do, if you want your changes be made public, or even upstreamed. No sane license that gives access to the source code forbids modification for internal use; one reason is that it would be really hard to enforce.

Grit isn't made for internal use though, and it's still changing the license

Re: Devtools must be open source

#233

Post by danbruc »

skybrian wrote: post #25
kelnos wrote: 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…

Updating a constant versus a config parameter isn’t all that different if the build is fast. I do think modularity will remain important because it makes merge conflicts less likely, and a system with good modularity could look a lot like a plugin system, except that AI can likely deal with minor compatibility breaks if it’s clear what to do. It’s a similar argument to why Linux device drivers are in-tree. If there a…

Updating a constant versus a config parameter isn’t all that different if the build is fast.

Not even remotely true except that in both cases you change a number in some text file. If you do it in source code, you have to get the source code, you have to identify the correct line[s], you need a build environment, you might have to reinstall the new version after the build. And on top of this you want to involve a language model in this. The difference in complexity, effort, and resource consumption is orders of magnitude. And we are not even considering that you will have to go through this for each future version to keep your modification included. This is an insane way to change a font size.

Re: Devtools must be open source

#234

Post by egeozcan »

The thing that made me pull the plug on claude subscription was that I couldn't use pi.

I can use codex on pi, deepseek on pi, I use them on different tasks and let them review each other.

Tell deepseek flash anything you want changed and a minute later it's there.

Forget vibe coding, I'm vibe-using the thing and having so much fun.

Re: Devtools must be open source

#237

Post by sylware »

Open source is not enough: _LEAN_ open source is a strong requirement today... and that includes syntax complexity of any used computer languages.

The scammers are now doing open source vendor/dev lock-in via massive size and complexity... while there are small and stable in time alternatives able to do a good enough job. Those guys are not all malicious, many are just brain washed and some suffer from a mental disorder: accute Rube Goldberg Machine syndrome.

Re: Devtools must be open source

#238

Post by retropragma »

saltmate wrote: post #215
simonw wrote: post #43

Earlier quoted context omitted.

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

That's not a solution, just the necessary work. You still have a stack of patches you continuously have to (have) rebase(d) on upstream.

That's why you only rebase when you actually need to in such cases. Another trick is to keep as few touch points into the original code as possible, preferring to keep most custom code in custom files.

Re: Devtools must be open source

#239

Post by dismalaf »

__d wrote: post #199
dismalaf wrote: post #187

Earlier quoted context omitted.

The answer is you don't sell the tool. You release the tool, others help you make it better, then you use the tool to build the actual thing.

But the "actual thing" is presumably software too? Why is it any different to a dev tool? All software is now more-or-less available for the token cost, given a specification of what is required. It's not just FOSS: the era of commercial software is equally over. Why pay for something that leaves you dependent on a third party for bug fixes or new features? Vibe it up yourself, and pay for only what you need, when yo…

> But the "actual thing" is presumably software too? Why is it any different to a dev tool?

Dev tools are a tougher sell because other devs can make them. Your normie SP500 manager isn't going to whip up some project management software in his free time.

Re: Devtools must be open source

#240

Post by dismalaf »

jedberg wrote: post #188
dismalaf wrote: post #187

Earlier quoted context omitted.

The answer is you don't sell the tool. You release the tool, others help you make it better, then you use the tool to build the actual thing.

Of course, that’s how all open source companies work. Everything I said applies to what you said.

No all your examples are of dev tool companies.

The successful business model is more like make tool, give away tool, make random project management/accounting/tool that devs would never use and normies can't make.

Post reply on HN