Live data from Hacker News

Devtools must be open source

blog.exe.dev

101–110 of 262 posts

Re: Devtools must be open source

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

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…

The solution for this is to pay open source maintainers for their attention. If I want them to review and merge my bugfix I should attach $1000 to the PR.

Re: Devtools must be open source

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

> Some tools have started making licenses that are free for individuals and startups but cost money for profitable companies. Ive seen this as well, but at a certain point it just seems like if your code is online, someones either taking it wholesale or recreating core pieces from the spec regardless of any licensing. Its a tough time to be building OSS if you don't have distribution solved AKA some pedigree from the…

> Its a tough time to be building OSS if you don't have distribution solved AKA some pedigree from the before times.

I think this has always been true, but you're right, it's much more pronounced now.

Re: Devtools must be open source

#103
post #21
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…

There are some things that should be configurable and some things that you should not be allowed to configure. Remember you are not working alone. Different people/companies work differently, but nearly every job has - at least once in a while - a time when someone will be ask your computer reading something on your screen with you. vi vs emacs is bad enough, but at least I know how to do minimal navigation, save, an…

LLMs fix all of these things, in the (rare) instances where existing tooling does not.

Re: Devtools must be open source

#104
post #56
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…

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.

What a boringly reductive take.

It's not like hackernews is some amazing bastion of like, optimism and culture and interesting conversation, but surely we can do better than this?

Re: Devtools must be open source

#105

Company that resells openclaw and closed providers preaches about open source. The new personalization talking point appears to be coordinated. It is all over the Internet since last week. Problem is, 99.99% of people (including developers) do not need "personalized" software, unless you mean Emacs style.

exe.dev has quickly become my platform of choice for hosting, testing, playing and tinkering. I haven't had this much fun playing with a providers offerings since VMs were a new thing. You have no idea what you're talking about here and should do a little research on them first. What you are saying they are, is not that.

Yes exe.dev is the first cloud provider I actually enjoy using. It's easy to manage with just ssh and they give me real disks. The lack of real (EBS is still networked) persistent disks on ec2 instances causes me a lot of pain at $WORK.

Re: Devtools must be open source

#106

Company that resells openclaw and closed providers preaches about open source. The new personalization talking point appears to be coordinated. It is all over the Internet since last week. Problem is, 99.99% of people (including developers) do not need "personalized" software, unless you mean Emacs style.

> The new personalization talking point appears to be coordinated. It is all over the Internet since last week. I agree with you. They are manipulating public opinion, fooling users.

exe.dev haters abound, apparently

Re: Devtools must be open source

#107
In the spirit of open source devtools & personalized software, check out my digital garden / monorepo I've been working on for 5years! For self-hosting NextJS on k8s & related infra like cnpg.

https://peat.eth.demokluster.com https://peat.eth.limo https://peat.eth.link

git clone https://peat.eth.demokluster.com/peat0.git

(webpage itself incl ro-git is hosted/mirrored over IPFS/ENS)

Re: Devtools must be open source

#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

Re: Devtools must be open source

#109
post #7

Earlier quoted context omitted.

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…

The solution for this is to pay open source maintainers for their attention. If I want them to review and merge my bugfix I should attach $1000 to the PR.

This is actually not a bad idea for funding open source software. It used to be that you’d have an author who coded a project and then could fix the occasional bug or two quickly.

Now, we have larger projects where it is rare for one people to have a complete understanding, and the main value is a person to reviewing patches and bugs to make sure the changes align with the larger goals/path for the project. There is little incentive for a maintainer to do this, aside from wanting to limit forks.

Paying for that review might be the way to keep this whole model sustainable.

Re: Devtools must be open source

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

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

Post reply on HN