I like the idea but I think manually editing source code is a bit too extreme. I’d rather have a plugin system or make the config scriptable.
Devtools must be open source
81–90 of 262 posts
Re: Devtools must be open source
#82Earlier quoted context omitted.
That's my biggest gripe with open source software. It's not really the open source part that's bad, but when projects turn into major projects with a substantial user base, I think the owners have an obligation not to delude their users into thinking they have more say than they actually do. Plenty of big projects leave their issue trackers public and have docs that encourage community contribution, yet effectively i…
> which is absurd because forking should be a last resort for software that thrives from having a community. This is true, of course, but having a community is completely orthogonal to whether software is open or closed source.
The two are correlated which does encourage that mistaken view. Github culture generally blends these two, having an open issue tracker, pull requests etc. as well as the code right there, often with a free license.
But you can very much allow bug reports and feature requests in public while developing proprietary software and you can also very much work on a project alone or with a small group without being open to random patches, contributions or requests and be open source / FLOSS.
The key definitional question is the license, not any of the cultural stuff.
Re: Devtools must be open source
#83One 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…
[flagged]
Re: Devtools must be open source
#84As a maintainer of a devtool which has strived to make itself easily forkable and modifiable, I can see the allure of this line of thinking but I think it's sadly too idealistic. Engineers using devtools are not so different to an average user in that they just want things to work. Maintaining a devtool is real work; e.g. suppose upstream adds some feature you want but it clashes with something you did downstream. No…
> I can see the allure of this line of thinking but I think it's sadly too idealistic.
I think it would be exhausting. Even if nothing broke, upstream UI changes could change your program daily. It makes a lot more sense for pulling changes that are security or bug fixes.
It seems like it would make sense for pulling enhanced functionality with no UI changes, but would you even use the enhanced functionality if you didn't even know it was there?
OTOH, I suppose if you organized your workstream correctly, you would always have previous binaries to fall back on.
Re: Devtools must be open source
#85Really? Software engineer and you just started making personalized tools recently?
Emacs has been customizable probably longer than I've been alive. Apart from tinkering with Basic, Delphi and Visual C++ when I was a kid, the first things I made were Ruby scripts as personal tools for various things. Had a personalized Emacs environment 20 years ago. Iterated on some abandoned open source projects. And so on...
I guess congrats on an AI telling you about things that have pretty much always existed.
Re: Devtools must be open source
#86Earlier 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…
That's my biggest gripe with open source software. It's not really the open source part that's bad, but when projects turn into major projects with a substantial user base, I think the owners have an obligation not to delude their users into thinking they have more say than they actually do. Plenty of big projects leave their issue trackers public and have docs that encourage community contribution, yet effectively i…
> thrives from having a community.
Does it? I think a lot of software projects which are not as huge as the Linux kernel etc. thrive best with a tight core development team, and not from a "community" if you mean that word beyond "users".
Look at it from the point of view of a maintainer. Not sure if you've ever tried. People want to pull your software towards a million incompatible directions. They write some big patch and then get angry if you don't merge it.
My advice: consult the maintainers first whether they agree with your idea and whether they are open to considering your submission. You still won't have a guarantee that it will be accepted, because that's their final say. But at least you won't spend effort coding up something that they could already tell you they don't want to have in their software.
Re: Devtools must be open source
#87I like the idea but I think manually editing source code is a bit too extreme. I’d rather have a plugin system or make the config scriptable.
Agreed, i forked a devtool (vibe-kanban) months ago for my own use but keeping up with upstream was a significant burden even with LLMs. The benefit of a well designed plugin system in the devtool is not only to allow sharing of customizations, but also to make users' private customizations cheaper to maintain.
Re: Devtools must be open source
#88Well we can go a step further and say Devtools must not be VC funded too :) Till date, the best and greatest dev tools I've used have not been influenced by VC decisions.
Re: Devtools must be open source
#89[deleted]
Re: Devtools must be open source
#90Separately, JetBrains's revenue grew 25%: https://www.jetbrains.com/lp/annualreport-2026/
But back to OP, for this prompt:
> 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.
Seems like nice syntax sugar to add a `/maintain-fork` command.