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…
Devtools must be open source
101–110 of 262 posts
Re: Devtools must be open source
#102I'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…
I think this has always been true, but you're right, it's much more pronounced now.
Re: Devtools must be open source
#103I 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…
Re: Devtools must be open source
#104One 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.
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
#105Company 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.
Re: Devtools must be open source
#106Company 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.
Re: Devtools must be open source
#107https://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> 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…
Even just the cost of this would be a disaster, especially once everything goes to token based pricing
Re: Devtools must be open source
#109Earlier 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.
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
#110One 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…
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.