Live data from Hacker News

Devtools must be open source

blog.exe.dev

181–190 of 262 posts

Re: Devtools must be open source

#181
post #143

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.

Perhaps it's time to start using a decent OS?

Re: Devtools must be open source

#182

Earlier quoted context omitted.

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/

Only for trivial programs - I don't mind running make on a 2500 line C program, I would mind having to recompile LLVM or Firefox.

Firefox is a nice example of a human-managable set of preferences in the 'settings', and "about:config" for everythig else 'those few users' might need (without the need to reompile)

Re: Devtools must be open source

#183
from the article I was reading up until I got to a prompt I could not parse. I assume if it worked it was because the AI interpreted so as show. If I am misreading the intent of the prompt, forgive me, I am a pedantic and imperfect human. "Please build meat.dev into Shelley. Install the latest version in the PATH. When a git commit is created by Shelley, start meat processing in the background on the commit. Add a toggle to the Shelley Diffs view for meat. If the commit is still being processed, so the user it is in process."

Re: Devtools must be open source

#184

Earlier quoted context omitted.

Some people even claim that they don't commit the code into source control, only the prompts. The best part about the internet is that you can publish any random shower thought.

Around 2020 I started getting downvoted for predicting that while the most popular programming languages at the time were Python, Java, and JavaScript, or whatever they were, the most popular programming languages in 2035 would be English and Mandarin. Looks more like 2030, after all. So the downvoters had a point.

I think having some real examples of this 2035 is a lot more feasible now than it would have looked to most people in 2020, but the majority of projects in 2030 is absurd. Can you name even one piece of software today that is actually built this way?

This means:

Every release, the only thing done is they edit a prompt and then ship the build that comes out of LLM -> CI/CD ?

Then they delete all the source that was generated, along with the context, and only the prompt is carried forward to the next release?

Re: Devtools must be open source

#185
post #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…

And my point is, no matter how advanced you are going to make that prompt, AI will find a way to mess it up. If you say, "A, B and C must be true", then eventually an agent will find property D which you did not thing about, making the program unusable.

Again, this is normal if you are interactively working on software and can fix any problems you see. It is only problematic if you do what OP says, and make it on cron, daily and unattended.

Re: Devtools must be open source

#186
I liked your article on its merits but this:

> Both the upfront fixed costs and the ongoing costs of personalizing software have disappeared.

Is just wishful thinking, at best. We can say your own quirky little personalised software that works on your computer might have become cheaper. Production grade software that people pay for is a different beast. That’s why people pay for software: support and ongoing maintenance. LLMs have not and are unlikely to change that part of the equation. As a business the pure liability of not having anyone to call about an issue is a BIG issue.

Re: Devtools must be open source

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

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.

Re: Devtools must be open source

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

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.

Re: Devtools must be open source

#189

Open-sourced doesnt have to be free either. There's always the very good GNU Affero General Public License 3 (AGPL-3) and others. I think most developers want open-source for transparency. We want to know what we are downloading.

AGPL software is in practice always gratis, because anyone who has a copy can post it on the internet where anyone can download it. The monetization benefit of AGPL is that it makes it significantly more annoying (but by no means impossible) for IaaS providers to sell managed hosting for the software without making a separate commercial agreement with the copyright holder. This usually isn't relevant to dev tools tha…

You say this as a fact, but you're wrong and I'm living proof of that. You can earn good income selling copies of AGPL software. It doesn't matter if people upload it to a public place, that's their right, and *that right* is why so many people buy a copy in the first place. You are spreading FUD.
Post reply on HN