Live data from Hacker News

Devtools must be open source

blog.exe.dev

191–200 of 262 posts

Re: Devtools must be open source

#191
post #108
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…

I suspect the people advocating for this don't actually do this, its one of those things that you say because it sounds modern and up to date, and makes for a good sounding blogpost. The actual reality of any of what they're talking about is absolutely terrible Even just the cost of this would be a disaster, especially once everything goes to token based pricing

Author here. FWIW, I do this with my Shelley modifications. It works.

Re: Devtools must be open source

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

Conversely, software that is not open source, but that has a really good API and SDK (like obsidian) is also very easy for your agent to do anything it wants with.

This gives the end user all the customization they need and gives a company like obsidian the capability to have a little bit of secret source in today’s day and age.

Re: Devtools must be open source

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

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.

i have the opposite problem, sometime i tell it to read the doc/header to understand how to use API, but then it proceeds to dive into the SDK to read the source, which is not a bad thing but that takes both time and a lot of token

Re: Devtools must be open source

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

[deleted]

Re: Devtools must be open source

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

But you now have a fork. Main branch gets refactored you have a merge conflict.

Re: Devtools must be open source

#197

I'm not against open source. However, if I were to guess, I think less than 1% of people actually review, let alone modify the open source projects they use. I don't really buy this argument. I think we're seeing a new modality of openness now with open weights, or being able to modify agents with md files, skills, and so forth.

> However, if I were to guess, I think less than 1% of people actually review, let alone modify the open source projects they use.

I've done this a lot when trying to squash bugs

Re: Devtools must be open source

#198
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 "…

I don't know about the long term, but the medium term looks like "Claude, make a replacement for , with the same functionality and user experience."

Re: Devtools must be open source

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

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 you need it.

Re: Devtools must be open source

#200
Well from his product page for exe.dev and the devtools he mentions

- GitHub closed source - AWS closed source - GCP closed source . Slack closed source - ChatGPT closed source . Claud closed source - though mention only in passing Google Docs is also closed source

Then they hawk a product they are selling: Cloud Pool plan

If you limit the argument to just be the exact thing you have running on your desktop then I think the definition is so narrow its nearly useless.

Post reply on HN