8 ms·

Devtools must be open source

733 points by bryanmikaelian 2mo ago

doc_ick 2mo ago
I disagree. As if a tool is customized via agents and something goes wrong, it should be the users issue to fix it. Say I want to customize a bank app (or sca tool) to use a nickname instead of my name, if it breaks then who fixes it?
- anygivnthursday 2mo ago
  It does not even have to break, you and your LLM can introduce subtle bugs or vulnerabilities to a codebase you are not familiar with and there is a userbase of 1 person to catch this.
  - doc_ick 2mo ago
    Very true.
- skybrian 2mo ago
  You tell the AI what broke and it fixes it, and this is usually a better experience than contacting support. But what if that fails? This might not generalize beyond developers, or at least not right away. Even if we’re not doing the upgrades ourselves, we know what a merge conflict is, and we’re probably better at telling the AI what went wrong so it can fix it. These don’t seem like skills that are all that hard to learn for someone who’s interested. Also, merge conflicts an AI can’t deal automatically likely mean something major changed upstream. There will be jobs helping people who get into more trouble than they can dig themselves out of. And if you can’t afford that, I guess it’s a learning experience.
  - doc_ick 2mo ago
    Going down that trail, eventually ai will eventually learn how to manage merge conflicts better (or whatever new scam). Or it could simply rewrite its own fork and support it all without user direction or supporting the core effort. All potentially with the ai model(s) running with no secondary prompt other then “make git error commands sarcastic”
simonw 2mo ago
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 that equation in a way that makes the original dream much more feasible. Several times a day I'll prompt regular Claude chat to "Clone x/y from GitHub and tell me how Z works". Getting software to compile in order to start hacking on it used to be enough friction that I often wouldn't bother. Now I treat that as a zero time investment challenge: tell Codex or Claude Code to checkout and build X and then come back ten minutes later and see how it got on. I'm not habitually modifying the software I use yet, but I can see a path to that which didn't exist a year or so ago.
- imrehg 2mo ago
  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 tinkers as before), generally, for a while. Though there are some tools that picked up the pace and actually react faster (so YMMV here too). But there are few things more frustrating as being half-way. Case to point is LM Studio. It's closed source, has bugs (duh!), and there's at least a GitHub issue tracker to report the bugs -- but then by and large nothing happens to those reported things. It's almost worse than not having an issue tracker (then I could justify never to really touch LM Studio again, this way I keep hoping against hope that reports will turn into fixes and thus I keep using and keep reporting...)
  - ravenstine 2mo ago
    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 ignore user submissions unless perhaps someone with a name raises an issue. I completely agree that allowing users to waste their time believing their issue or pull request can make a difference is actually worse than not allowing public submissions in the first place. I'm not sure why I seem to be in the minority on this. Maybe I've just had bad luck in that most of the issues and PRs I've submitted to open source have been ignored. Hell, I'd prefer a "thanks but no thanks" or even "fuck you" over radio silence. The typical response to this frustration of mine is "just fork the code, bro", which is absurd because forking should be a last resort for software that thrives from having a community.
kelnos 2mo ago
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 work, do we want to burn electricity having the LLM build an options dialog or config file parser once, or do we want to burn electricity millions of times as users want to change any little thing about the software they use? I really hope what you should expect is my answer to that question isn't controversial. Having an LLM do bespoke customizations that are unlikely to be interesting to other people? Great, sure. But adding a generally-useful feature to a piece of software, but not caring to try to upstream it? Lame. Lame, lame, lame.
- tajd 2mo ago
  I completely agree - we've seen that tools with plugins are really scalable and then allow the better plugins to be folded back into the main tool where they become popular. I've taken that approach with my own dev tools that I've created.
  - theshrike79 2mo ago
    And I've seen applications where the plugins are so damn complicated to make that it was easier to just make a separate tool to do that.
- herrkanin 2mo ago
  Without any evidence to back it up, my hope is that your criticism in a decade will be the equivalent to "Everybody having a mainframe at home? Do we want to waste a whole room in each and every house just for that?".
  - arandomhuman 2mo ago
    Having an embedded scripting engine for large programs is nice for simplicity and keeping configuration modular - it would be messy to need to modify source constantly. It’s not an issue of it being difficult to compile something so much as it being pointlessly difficult to maintain.
trjordan 2mo ago
I like the idea of devtools being open source. I also like them to work, and that's what I value more that philosophical purity. Take his side project, Meat. I've been chewing on this problem for a while. It's a real problem right now: it sucks to read all this LLM-generated code. It's worthwhile to have an LLM summarize it for you. The problem with that is this particular problem resists vibe coding. I've talked to a bunch of people who have tried to solve it on the side, and it's all sort of ... ok, but still unsolved. - As mentioned, it takes a while to run. You can modify your other tools, as described, to smuggle the latency. - LLMs don't know what you care about, so you have to maintain a list of things that you do care about, which is ever evolving. If you don't give it that, it produces slop. - If you miss something, it hurts. Another layer of swiss-cheese AI doesn't feel right. If you trust the AI, just ask Claude to summarize its work! - The summaries feel shareable, but the author of the PR is actually the most tolerate of slop about a PR. Your reviewers definitely don't want to read the output of a vibe-coded tool talking about 60% of your PR. They could ask their own Claude! So, we're building a version (https://tern.sh https://tern.sh), and it's not open source, because we want it to be shareable and hosted and support teams -- all that stuff that makes it work. At the end of the day, I'm not here to maintain my tools. I'm here to use my tools to do the job.
pbjerkeseth 2mo ago
So, I'm a subscriber/user of exe.dev but even so I was a bit disappointed when the meat.dev tool linked in the article had no screenshots/meaningful docs. So I installed it and was bummed to see it only supported openAI and exe.dev llm integration by default. "You can just fork" - yeah I know, so take it with a grain of salt. That aside aside, I agree. Since reading this article yesterday I've probably been overthinking an MIT from AGPL license switch for my own project Ouijit (shill time: https://ouijit.com https://ouijit.com). Its feels a little counterintuitive since AGPL encourages more open source downstream, but at the same time if I have solved some problem other agent harness devs are curious about, I just want them to take the solution without worrying about paying it back/forward.
- crawshaw 2mo ago
  (Author here.) FWIW the first version of meat was based on anthropic models, I switched to Oai models because they are faster and just as good right now. This is an astonishing thing to say, but the switch was a single shot prompt using a frontier model. I’m happy to add some selector there, but that is also the point of this article: do you really need me to make it configurable when you can switch the tool over to Anthropic with a single prompt? It’s a strange new world we live in. On the website: you’re right. I have some side-by-side diff examples I want to turn into a website. I am just short on hours in the day. My real goal is to make the tool compelling enough that I can convince my colleagues that we should build it into Shelley. :)
  - pbjerkeseth 2mo ago
    Website not even needed! Janky terminal screenshot in the repo would have been good enough for me lol. On another note, the reason I was perusing the blog was because I was curious about more of how exe handles review/quality/testing because you mentioned there being no code review in another post about stripe billings (maybe a different author). So consider this a casual request for more content on reducing delivery bottlenecks :)
2190asfg 2mo ago
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.
- indigodaddy 2mo ago
  Resells OpenClaw? What are you on about? and exe has no markup through their LLM gateway. Maybe educate yourself before talking smack about an awesome little company and platform like exe.dev.
- Brainspackle 2mo ago
  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.
  - the_explainer2 2mo ago
    https://exe.dev/docs/shelley/llm-gateway https://exe.dev/docs/shelley/llm-gateway "The exe.dev LLM gateway provider source within an LLM integration remains supported. It provides exe.dev-managed access to Anthropic, OpenAI, and Fireworks models. Your subscription includes a monthly token allocation, and you can purchase additional tokens at https://exe.dev/user/shelley https://exe.dev/user/shelley." The access to closed platforms is managed according to the docs.
    - indigodaddy 2mo ago
      And? It's a convenience for their users (and most users for sure want this) for easy access to frontier closed and also open models (Fireworks). They advise also there is no markup or profit made for them in providing this managed gateway. I guess I don't understand the OP's point even. Is there some conflict with providing this service and still being passionate about open source? IMV the answer is no. Their main software product, Shelley, is open source: https://github.com/boldsoftware/shelley https://github.com/boldsoftware/shelley
rvz 2mo ago
This is one of the only fields where the customer (developers) almost never pays for their own tools and instead builds their own or even to compete against another developer. Then, they later realize why human developers in open source burnout so easily. Not even Richard Stallman or Linus Torvalds make money on open source or free software despite preaching it. They actually make money from speaking fees. "Open source" is now weaponized to price down entire companies to the floor and instead of humans maintaining the software, it is now coding agents doing the work. Neither the free and open source software movement accounted for this disruption and they have become the new starving artists of the software world.
- 2190asfg 2mo ago
  Torvalds got RedHat and VA Linux stock options and probably has a very good contract with the Linux Foundation.
- davisr 2mo ago
  I earn income selling copies of free/libre/open source software. Other people could too, if they tried, but they don't.
- djaro 2mo ago
  It is crazy how much of the tech industry - one of the biggest industries on Earth - still uses so much volunteer labor. Its crazy because in no other industry would people expect you to not only give away your stuff for free but do it in such a way anyone else can copy your stuff and edit it.
- seba_dos1 2mo ago
  > Not even Richard Stallman or Linus Torvalds make money on open source or free software despite preaching it. I've been paid to produce FLOSS for quite a few years and I know plenty of people who did too. I did not realize we are such unicorns...
- skybrian 2mo ago
  Why not use both open source and closed source software? Pick your battles. It's okay to buy a Mac or pay a hosting provider. Customize the tools that actually matter to you.
theamk 2mo ago
> Set up a nightly cron job that executes the prompt: fetch upstream changes to the <software> 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 not going to cut it, as AI are very, very good at obeying the letter but not the spirit of the ask. Yes, your diffs appear but they lack filenames. You've added this requirements to the prompt? Ok, filenames are back but they are font size 4, unreadably small. You want them well-seen? next week they become size 54, taking entire screen.. This is not a problem with regular AI development - you review the changes and test them a bit. But doing it day-to-day with no overview is just asking for trouble.
- zephen 2mo ago
  > This sounds like hell. You have unreliable actor... But, at least you know the cost up-front. Oh, wait...
- arjie 2mo ago
  I don’t auto-rebase but I definitely vendor in and choose to update on my own cadence.
  - lanstin 2mo ago
    yeah, vendor in is the only way to stay sane over time, if you understand the cost of dependencies (and have a reasonable security model). And forking some Python or Go dep on Github and using that instead of the canonical one is pretty ergonomic. I don't know how Rust folks manage with so many dependencies via Cargo - my friend who loves Rust says they are smaller and more "one thing done well" but the complexity of hundreds or thousands of deps just scares me.
    - arjie 2mo ago
      My number one problem with Rust (which I otherwise like) is that Cargo allows build-time code execution so I need to run in a sandbox (unergonomic for me) or provide agent instructions to inspect `build.rs` style code in libraries etc. prior to compile. In practice it's easy to build and then ship a dev binary into a sandbox, but it's not so pleasant to build in a sandbox, so I don't want to get build-time pwned. Makes me very unhappy. Right now, I just have a build server that I ship things to and does lots of build-caching etc. so it's fine, but I would have preferred not to have a system that actively allows build-time thievery of my ~/.ssh
toplinesoftsys 2mo ago
Like everything else, modifying code of open-source tools has its cons and pros. The biggest advantage is of course an ability to customize the tool exactly to your needs. The problem is that it makes patching and upgrading impossible. This is the reason plugins exist - they do not break ability to patch the host product. So, if customization cannot be avoided even at the cost of losing ability to patch/upgrade - that would definitely work. Otherwise, plugins is probably the best approach.
firasd 2mo ago
I think there is an argument to be made for how this benefits projects too, like if you want distribution then be as unencumbered as possible. I've been making a couple little utils like a Clock for AI with an open public endpoint [https://github.com/firasd/mcpclock https://github.com/firasd/mcpclock], a text file sampler [https://github.com/firasd/vblinds https://github.com/firasd/vblinds] and I was noticing the MIT license seems too encumbered with the requirement to keep crediting authors downstream so I used the 'Unlicense' public domain license (CC-0 seems to be side-eyed by open source orgs cause it preserves patent rights)
nextblock 2mo ago
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.
- ameliaquining 2mo ago
  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 that users run on their own machines.
  - davisr 2mo ago
    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.
    - nextblock 2mo ago
      Also, the money can be made selling premium package/modules/features on that Free core AGPL software.
davidw 2mo ago
It's a bit ironic to talk about key parts of the toolchain being open source while making black-box, closed source LLM's, controlled by external companies an integral part of all of it.
- crawshaw 2mo ago
  (Author here.) Open models are really quite good now. I still use oai as my daily but I have been very impressed by qwen/glm/k3/etc when I try them. They are clearly my future.
knighthacker 2mo ago
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.
- ivanjermakov 2mo ago
  I think it's pretty common in software companies to maintain own custom fork of an open-source tool/library.
- pornel 2mo ago
  Before LLMs the barrier to modifying software was much higher - in skill and time investment required. Now we're getting to the point where any user can say "Claude, I don't like that. Please fix" and have it fixed. Configurability/extensibility can work in some cases, but having source code makes it much more powerful.
- s777 2mo ago
  > 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
js8 2mo ago
Some time ago, there was a comment https://news.ycombinator.com/item?id=48849015 https://news.ycombinator.com/item?id=48849015 I deeply disagree with the light vs dark framing. I think the real tension between "hacker languages" and "blub languages" is the expectation to modify the language by it's user. And this is true for dev tools as well. Hackers prefer modifiable environments (such as Emacs), while corporations prefer standard environments (IDEs) to which programmers will adapt. (As the saying goes: "The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." Might be why Paul Graham preferred founders with non-blub languages after all, nothing to do with Lisp as such.) But to be able to adapt the environment, one must understand it. Therefore the pull to make it simpler, a set of universal tools, rather than a complicated machine with many features and ease of use through following prescription.
lalitmaganti 2mo ago
As 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. Not in the merge conflict sense but in the UX sense. Do you want to resolve that on every release? Is it just "AI will fix this"? Maybe one day, but as of today agents can do something along the right lines but don't capture my UX sense very well; and if the whole point is hyper-personalization, I want it exactly how I want it. "Does it seem to work?" is a fine right until it fails when you're doing something important. Do you then stop and go prompt an agent to fix your tooling, and hope it does a good job this time? What if it doesn't do a good job? Moreover, for devtools which are fundamentally social (i.e. lots of different people looking at the same thing), there's real value in that thing looking the same for everyone. Having a baseline for teaching, auditing, verifying "we are all talking about the same thing" is incredibly valuable and is sometimes where the most value is. All in all, maybe in some categories of devtools, this hyper personalization is indeed what will happen but it's a long way from being universal.
- skybrian 2mo ago
  The idea is that upgrading a devtool is like upgrading a vendored library. It's not something you do automatically or while you're in the middle of doing something else. Usually the AI can fix merge conflicts. If upstream changes are too extensive, you can have the AI rewrite the change entirely. I think will work better for nice-to-have features that are ultimately disposable if they become too hard to maintain.
- zephen 2mo ago
  > 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.
bluegatty 2mo ago
Good point, but extensibility != OSS though. JetBrains and Claude/ChatGPT are not open source. I think we would like them to be ... but ...
intrasight 2mo ago
"Five years ago, most software engineers I spoke to had no programs they had written for themselves." What happened five years ago? Before that everyone used tools they wrote themselves. I think the answer is nothing happened five years ago and everyone still uses tools they wrote themselves.
- zephen 2mo ago
  > What happened five years ago? Apparently the dude found some new acquaintances.
muragekibicho 2mo ago
exe dev is a VC-funded company reselling open source software. Everyone's making cash from your open source code except you.
- zephen 2mo ago
  You write as if they have an ulterior motive to try to trigger your FOMO to keep you proactively burning CPU cycles and AI tokens, just in case something might have changed while you were sleeping. "Lather, rinse, repeat." Some things never change.
bqc 2mo ago
[flagged]
writtenone 2mo ago
exe.dev is NOT open source. Funny
arjie 2mo ago
Everything is now open-source by default. All features are replicable. I don’t really care that much any more that tools need to be OSS because I can make my copies when I want. And I do when I so desire. Your feature page is your source code.
- doc_ick 2mo ago
  Your idea is my source code.
  - arjie 2mo ago
    Absolutely. It’s all an execution and distribution problem now.
    - doc_ick 2mo ago
      That truly is sad, as execution and even distribution is just now a prompt with a credit card.
QwenGlazer9000 2mo ago
LLMs make things easier but can we not advocate for making them a dependency to configure our tools? Even open weight models aren't fully open source. It's basically like having the back end binary but not the source code. Use em to make your life easier but I'd rather not we normalize LLMs becoming the primary way we interact with open source software.
creakingstairs 2mo ago
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.
- 2001zhaozhao 2mo ago
  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.
dismalaf 2mo ago
Really? 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.
- crawshaw 2mo ago
  Hi, author here. The entire second paragraph of my blog post is dedicated to the question you asked. There is really nothing more I can add.
conqrr 2mo ago
Well 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.
- skybrian 2mo ago
  It seems like an odd purity test to advocate for on a Y Combinator website. Why are you here if you're so worried about being influenced by VC's?
deleted 2mo ago
[deleted]
shay_ker 2mo ago
Separately, JetBrains's revenue grew 25%: https://www.jetbrains.com/lp/annualreport-2026/ 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 <software> 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.
thepoet 2mo ago
A bit idealistic for the crowd here but has some good points. The other day I wanted to build personal apps for my Kobo device. It has a single ~800Mhz core and 512 MB of RAM, probably eight times less than a rasbperry pi, but runs a Linux. I wanted to break free from watching my laptop screen for long Claude sessions partially due to degrading eyesight and have a sidekick for approvals streamed to the Kobo. Apart from the Claude and Codex permissions sidekick done via hooks, I ended up building an entire SDK, an HN client, an RSS discovery & reader and an audiobook generator using deep research and ElevenLabs API all running on it. Anyone using an LLM can now personalize it for their own Kobo device, which might have some nuances over my Clara BW. Significantly less work I hope than doing it all from scratch even with a coding agent. https://github.com/BandarLabs/Cobalt https://github.com/BandarLabs/Cobalt
jedberg 2mo ago
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 and ultimately sold to an infra company, returning pennies on the dollar to their investors. The difficulty stems from the fact that your customers are developers and operators, and they all think that they don't need you because they are perfectly capable of running the software themselves and adding whatever they need to it. In a lot of cases they are right. And now, with AI coders, it gets 10 times worse, because they can take your open source and then vibe code a "good enough" version of your commercial product. 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. Some tools have started making licenses that are free for individuals and startups but cost money for profitable companies. That's an interesting strategy but I know some companies won't allow those tools precisely because of their license.
- pbjerkeseth 2mo ago
  > 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 before times.
  - jedberg 2mo ago
    > 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.
- rglover 2mo ago
  > 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 "what's the replacement for <insert incumbent>?" IMO, the combination of OSS and "generous free tier" SaaS plans basically nuked the willingness to pay for software, especially dev tools. Folks are just too conditioned to expect stuff to be cheap or free nowadays. Maybe that changes long-term but shrug, who knows.
pete00074b98426 2mo ago
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.demokluster.com https://peat.eth.limo https://peat.eth.limo https://peat.eth.link https://peat.eth.link git clone https://peat.eth.demokluster.com/peat0.git https://peat.eth.demokluster.com/peat0.git (webpage itself incl ro-git is hosted/mirrored over IPFS/ENS)
fasterik 2mo ago
I used to be much more of an open source fundamentalist than I am now. For me, it's more about trust than source availability. There are closed source projects that I have high trust in, and there are open source projects that I don't trust at all. A project being open source can increase trust, but not necessarily so. Regarding personalization, I would much rather use software with strong design principles that's simple, opinionated, and works out of the box with sane defaults. I want to spend my time getting work done, not tweaking settings and adding custom features.
traveltoursocia 2mo ago
Si
inigyou 2mo ago
Devtools for open source must be open source, but I see no reason to give any shits what corporations use. And we live in capitalism, where making money is not optional.
Bnjoroge 2mo ago
I like using exe but I’m not sure what to feel about this if exe itself isnt open source. Granted, their agent is OSS, but still feels somewhat ironic
duped 2mo ago
> The result is that software that can be personalized doesn’t need a plugin system or a config file. Yes, please make me rebuild my software to change an API endpoint or port number. It's a wonderful use of time and electricity to build and spin up agents to fix the inevitable problems with building software. Instead of changing a string in configuration file. (/s if not obvious). Configuration and plugin systems exist for a good reason: software should be reconfigurable and modular without requiring the wholesale replacement of the original. Even if the code is open source, there are good reasons to move logic and data out of tree and into config or plugins.
luciana1u 2mo ago
[flagged]
dipanshuhappy 2mo ago
I think this became aparent with agentic coding CLIs. In my company, it was not encouraged to use claude code because they haven't open sourced it yet
dataangel 2mo ago
The models are dev tools ;)
abratabia 2mo ago
[flagged]
ValdikSS 2mo ago
>How to Personalize Software I've seen https://v-it.org/ https://v-it.org/ here on hackernews. Same idea, different wording.
darkstarsys 2mo ago
Yes, emphatically! I wouldn't be where I am today without tools like Emacs and Linux. This is why I created [pcons](https://pcons.org https://pcons.org) because software build tools (like all dev tools) need to be open, transparent, hackable and easy to understand.
shevy-java 2mo ago
Microsoft, listen to this.
wasting_time 2mo ago
Does this mean exe.dev will become open source? Or is it not a developer tool?
- skybrian 2mo ago
  It's a VM hosting service. The devtools they have in mind run on top. But there are other open source projects that will help you self-host.
myshapeprotocol 2mo ago
[flagged]
bartleeanderson 2mo ago
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."
usernametaken29 2mo ago
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.
- nightlycosts 2mo ago
  Specially in an article that initiates the conversation advocating for setting a machine that stays on overnight running agents making rebases among who knows what else. There are two other frontpage threads right now tangentially about the cost of AI, I'll have this conversation there, to see how well the idea this cost is gone holds up against a primed crowd.
Escafati 2mo ago
[dead]
link89 2mo ago
AI-generated software is accelerating Shadow IT, putting heavy pressure on internal governance.
ThinkBeat 2mo ago
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.
tizerluo 2mo ago
[flagged]
xsotf 2mo ago
yee
deleted 2mo ago
[deleted]
Jansss 2mo ago
[flagged]
quintu5 2mo ago
"We need the source code." No, you want the source code. You want software someone else put their time, effort, and judgement into to be available for you to do whatever you'd like with it without any recompense. The sense of entitlement here is exhausting. There are plenty of good reasons to choose an an open source tools and sure, the ability to personalize a tool at the source layer can be valuable enough in some instances to justify maintaining a fork manually or with an agent. Asserting that dev tools must be open source to prioritize a paradigm where users roll the dice on adding features by one-shotting them with an agent and then burning tokens until the end of time to try to keep their forks compatible with upstream changes because plugin APIs are too restrictive doesn't pass muster.
madhu_ghalame 2mo ago
[dead]
Terratrader 2mo ago
I am working on a new AI architecture for small AI models. Without open source AI development is dead.
robalni 2mo ago
The article is about only one side of the solution: using AI to make it easier to work with code. I think the other side of it is more important: making software simpler so that people can work with the code without having to use AI. That's what I try to do.
eviks 2mo ago
> It is astonishingly easy to personalize software today. There are two general categories of prompts to an agent that make all of this possible: That's the memed magical thinking of "make no mistakes"
mikasisiki 2mo ago
I'd be curious to hear what the author and others here think about how AI-assisted customization will affect the business models of open-source devtools.
aljgz 2mo ago
Years ago, we were revamping a mission-critical project with more than a 1000 database tables to a backend of .net and EF. Our rewrite was much cleaner, but still had 450 tables. We started noticing that our backend took 2 minutes after starting up to serve the first request, fast after that. It turned out EF had a stage named "view generation" which verified that data would round-trip, meaning if it goes into the DB and comes back, would stay the same. Run time was exponential on the number of tables and complexity of models. People used tricks to work around it, which was basically caching the "generated view" in a file, which could speed up the production startup, not as easy in DEV environment, our programmers still needed to wait 2 minutes after each compile. I started looking into it, and it turned out that Microsoft had open sourced EF a short time ago (long after we had started the project). While profiling, view generation took much longer, 450s, as it was a CPU-heavy process. There was a function excluded from release builds by a `[Conditional('DEBUG')]` attribute, and when I removed the call to it, the time went down to 64 seconds, 63 of which was in a very simple function. A LINQ statement in there could be re-written to make it 120ms. I ended up contributing it to EF core, being acknowledged in their blog post, and we ended up using our own release build of EF libraries until the fix made it to the public release. Had they not open sourced EF, it could turn into an existential threat to the project.
yoanwaidev 2mo ago
[dead]
egeozcan 2mo ago
The thing that made me pull the plug on claude subscription was that I couldn't use pi. I can use codex on pi, deepseek on pi, I use them on different tasks and let them review each other. Tell deepseek flash anything you want changed and a minute later it's there. Forget vibe coding, I'm vibe-using the thing and having so much fun.
mangudai 2mo ago
[flagged]
conartist6 2mo ago
Utterly unimpressed by this. This is an argument for a future of closed source devtools. We are on the road that leads there, and this describes going further along it.
sylware 2mo ago
Open source is not enough: _LEAN_ open source is a strong requirement today... and that includes syntax complexity of any used computer languages. The scammers are now doing open source vendor/dev lock-in via massive size and complexity... while there are small and stable in time alternatives able to do a good enough job. Those guys are not all malicious, many are just brain washed and some suffer from a mental disorder: accute Rube Goldberg Machine syndrome.
lowkey57 2mo ago
[dead]

733 points by bryanmikaelian 2mo ago

I disagree. As if a tool is customized via agents and something goes wrong, it should be the users issue to fix it. Say I want to customize a bank app (or sca tool) to use a nickname instead of my name, if it breaks then who fixes it?

anygivnthursday 2mo ago
It does not even have to break, you and your LLM can introduce subtle bugs or vulnerabilities to a codebase you are not familiar with and there is a userbase of 1 person to catch this.
- doc_ick 2mo ago
  Very true.
skybrian 2mo ago
You tell the AI what broke and it fixes it, and this is usually a better experience than contacting support. But what if that fails? This might not generalize beyond developers, or at least not right away. Even if we’re not doing the upgrades ourselves, we know what a merge conflict is, and we’re probably better at telling the AI what went wrong so it can fix it. These don’t seem like skills that are all that hard to learn for someone who’s interested. Also, merge conflicts an AI can’t deal automatically likely mean something major changed upstream. There will be jobs helping people who get into more trouble than they can dig themselves out of. And if you can’t afford that, I guess it’s a learning experience.
- doc_ick 2mo ago
  Going down that trail, eventually ai will eventually learn how to manage merge conflicts better (or whatever new scam). Or it could simply rewrite its own fork and support it all without user direction or supporting the core effort. All potentially with the ai model(s) running with no secondary prompt other then “make git error commands sarcastic”

simonw 2mo ago

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 that equation in a way that makes the original dream much more feasible. Several times a day I'll prompt regular Claude chat to "Clone x/y from GitHub and tell me how Z works". Getting software to compile in order to start hacking on it used to be enough friction that I often wouldn't bother. Now I treat that as a zero time investment challenge: tell Codex or Claude Code to checkout and build X and then come back ten minutes later and see how it got on. I'm not habitually modifying the software I use yet, but I can see a path to that which didn't exist a year or so ago.

imrehg 2mo ago
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 tinkers as before), generally, for a while. Though there are some tools that picked up the pace and actually react faster (so YMMV here too). But there are few things more frustrating as being half-way. Case to point is LM Studio. It's closed source, has bugs (duh!), and there's at least a GitHub issue tracker to report the bugs -- but then by and large nothing happens to those reported things. It's almost worse than not having an issue tracker (then I could justify never to really touch LM Studio again, this way I keep hoping against hope that reports will turn into fixes and thus I keep using and keep reporting...)
- ravenstine 2mo ago
  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 ignore user submissions unless perhaps someone with a name raises an issue. I completely agree that allowing users to waste their time believing their issue or pull request can make a difference is actually worse than not allowing public submissions in the first place. I'm not sure why I seem to be in the minority on this. Maybe I've just had bad luck in that most of the issues and PRs I've submitted to open source have been ignored. Hell, I'd prefer a "thanks but no thanks" or even "fuck you" over radio silence. The typical response to this frustration of mine is "just fork the code, bro", which is absurd because forking should be a last resort for software that thrives from having a community.

kelnos 2mo ago

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 work, do we want to burn electricity having the LLM build an options dialog or config file parser once, or do we want to burn electricity millions of times as users want to change any little thing about the software they use? I really hope what you should expect is my answer to that question isn't controversial. Having an LLM do bespoke customizations that are unlikely to be interesting to other people? Great, sure. But adding a generally-useful feature to a piece of software, but not caring to try to upstream it? Lame. Lame, lame, lame.

tajd 2mo ago
I completely agree - we've seen that tools with plugins are really scalable and then allow the better plugins to be folded back into the main tool where they become popular. I've taken that approach with my own dev tools that I've created.
- theshrike79 2mo ago
  And I've seen applications where the plugins are so damn complicated to make that it was easier to just make a separate tool to do that.
herrkanin 2mo ago
Without any evidence to back it up, my hope is that your criticism in a decade will be the equivalent to "Everybody having a mainframe at home? Do we want to waste a whole room in each and every house just for that?".
- arandomhuman 2mo ago
  Having an embedded scripting engine for large programs is nice for simplicity and keeping configuration modular - it would be messy to need to modify source constantly. It’s not an issue of it being difficult to compile something so much as it being pointlessly difficult to maintain.

trjordan 2mo ago

I like the idea of devtools being open source. I also like them to work, and that's what I value more that philosophical purity. Take his side project, Meat. I've been chewing on this problem for a while. It's a real problem right now: it sucks to read all this LLM-generated code. It's worthwhile to have an LLM summarize it for you. The problem with that is this particular problem resists vibe coding. I've talked to a bunch of people who have tried to solve it on the side, and it's all sort of ... ok, but still unsolved. - As mentioned, it takes a while to run. You can modify your other tools, as described, to smuggle the latency. - LLMs don't know what you care about, so you have to maintain a list of things that you do care about, which is ever evolving. If you don't give it that, it produces slop. - If you miss something, it hurts. Another layer of swiss-cheese AI doesn't feel right. If you trust the AI, just ask Claude to summarize its work! - The summaries feel shareable, but the author of the PR is actually the most tolerate of slop about a PR. Your reviewers definitely don't want to read the output of a vibe-coded tool talking about 60% of your PR. They could ask their own Claude! So, we're building a version (https://tern.sh https://tern.sh), and it's not open source, because we want it to be shareable and hosted and support teams -- all that stuff that makes it work. At the end of the day, I'm not here to maintain my tools. I'm here to use my tools to do the job.

pbjerkeseth 2mo ago

So, I'm a subscriber/user of exe.dev but even so I was a bit disappointed when the meat.dev tool linked in the article had no screenshots/meaningful docs. So I installed it and was bummed to see it only supported openAI and exe.dev llm integration by default. "You can just fork" - yeah I know, so take it with a grain of salt. That aside aside, I agree. Since reading this article yesterday I've probably been overthinking an MIT from AGPL license switch for my own project Ouijit (shill time: https://ouijit.com https://ouijit.com). Its feels a little counterintuitive since AGPL encourages more open source downstream, but at the same time if I have solved some problem other agent harness devs are curious about, I just want them to take the solution without worrying about paying it back/forward.

crawshaw 2mo ago
(Author here.) FWIW the first version of meat was based on anthropic models, I switched to Oai models because they are faster and just as good right now. This is an astonishing thing to say, but the switch was a single shot prompt using a frontier model. I’m happy to add some selector there, but that is also the point of this article: do you really need me to make it configurable when you can switch the tool over to Anthropic with a single prompt? It’s a strange new world we live in. On the website: you’re right. I have some side-by-side diff examples I want to turn into a website. I am just short on hours in the day. My real goal is to make the tool compelling enough that I can convince my colleagues that we should build it into Shelley. :)
- pbjerkeseth 2mo ago
  Website not even needed! Janky terminal screenshot in the repo would have been good enough for me lol. On another note, the reason I was perusing the blog was because I was curious about more of how exe handles review/quality/testing because you mentioned there being no code review in another post about stripe billings (maybe a different author). So consider this a casual request for more content on reducing delivery bottlenecks :)

2190asfg 2mo ago

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.

indigodaddy 2mo ago
Resells OpenClaw? What are you on about? and exe has no markup through their LLM gateway. Maybe educate yourself before talking smack about an awesome little company and platform like exe.dev.
Brainspackle 2mo ago
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.
- the_explainer2 2mo ago
  https://exe.dev/docs/shelley/llm-gateway https://exe.dev/docs/shelley/llm-gateway "The exe.dev LLM gateway provider source within an LLM integration remains supported. It provides exe.dev-managed access to Anthropic, OpenAI, and Fireworks models. Your subscription includes a monthly token allocation, and you can purchase additional tokens at https://exe.dev/user/shelley https://exe.dev/user/shelley." The access to closed platforms is managed according to the docs.
  - indigodaddy 2mo ago
    And? It's a convenience for their users (and most users for sure want this) for easy access to frontier closed and also open models (Fireworks). They advise also there is no markup or profit made for them in providing this managed gateway. I guess I don't understand the OP's point even. Is there some conflict with providing this service and still being passionate about open source? IMV the answer is no. Their main software product, Shelley, is open source: https://github.com/boldsoftware/shelley https://github.com/boldsoftware/shelley

rvz 2mo ago

This is one of the only fields where the customer (developers) almost never pays for their own tools and instead builds their own or even to compete against another developer. Then, they later realize why human developers in open source burnout so easily. Not even Richard Stallman or Linus Torvalds make money on open source or free software despite preaching it. They actually make money from speaking fees. "Open source" is now weaponized to price down entire companies to the floor and instead of humans maintaining the software, it is now coding agents doing the work. Neither the free and open source software movement accounted for this disruption and they have become the new starving artists of the software world.

2190asfg 2mo ago
Torvalds got RedHat and VA Linux stock options and probably has a very good contract with the Linux Foundation.
davisr 2mo ago
I earn income selling copies of free/libre/open source software. Other people could too, if they tried, but they don't.
djaro 2mo ago
It is crazy how much of the tech industry - one of the biggest industries on Earth - still uses so much volunteer labor. Its crazy because in no other industry would people expect you to not only give away your stuff for free but do it in such a way anyone else can copy your stuff and edit it.
seba_dos1 2mo ago
> Not even Richard Stallman or Linus Torvalds make money on open source or free software despite preaching it. I've been paid to produce FLOSS for quite a few years and I know plenty of people who did too. I did not realize we are such unicorns...
skybrian 2mo ago
Why not use both open source and closed source software? Pick your battles. It's okay to buy a Mac or pay a hosting provider. Customize the tools that actually matter to you.

theamk 2mo ago

> Set up a nightly cron job that executes the prompt: fetch upstream changes to the <software> 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 not going to cut it, as AI are very, very good at obeying the letter but not the spirit of the ask. Yes, your diffs appear but they lack filenames. You've added this requirements to the prompt? Ok, filenames are back but they are font size 4, unreadably small. You want them well-seen? next week they become size 54, taking entire screen.. This is not a problem with regular AI development - you review the changes and test them a bit. But doing it day-to-day with no overview is just asking for trouble.

zephen 2mo ago
> This sounds like hell. You have unreliable actor... But, at least you know the cost up-front. Oh, wait...
arjie 2mo ago
I don’t auto-rebase but I definitely vendor in and choose to update on my own cadence.
- lanstin 2mo ago
  yeah, vendor in is the only way to stay sane over time, if you understand the cost of dependencies (and have a reasonable security model). And forking some Python or Go dep on Github and using that instead of the canonical one is pretty ergonomic. I don't know how Rust folks manage with so many dependencies via Cargo - my friend who loves Rust says they are smaller and more "one thing done well" but the complexity of hundreds or thousands of deps just scares me.
  - arjie 2mo ago
    My number one problem with Rust (which I otherwise like) is that Cargo allows build-time code execution so I need to run in a sandbox (unergonomic for me) or provide agent instructions to inspect `build.rs` style code in libraries etc. prior to compile. In practice it's easy to build and then ship a dev binary into a sandbox, but it's not so pleasant to build in a sandbox, so I don't want to get build-time pwned. Makes me very unhappy. Right now, I just have a build server that I ship things to and does lots of build-caching etc. so it's fine, but I would have preferred not to have a system that actively allows build-time thievery of my ~/.ssh

toplinesoftsys 2mo ago

Like everything else, modifying code of open-source tools has its cons and pros. The biggest advantage is of course an ability to customize the tool exactly to your needs. The problem is that it makes patching and upgrading impossible. This is the reason plugins exist - they do not break ability to patch the host product. So, if customization cannot be avoided even at the cost of losing ability to patch/upgrade - that would definitely work. Otherwise, plugins is probably the best approach.

firasd 2mo ago

I think there is an argument to be made for how this benefits projects too, like if you want distribution then be as unencumbered as possible. I've been making a couple little utils like a Clock for AI with an open public endpoint [https://github.com/firasd/mcpclock https://github.com/firasd/mcpclock], a text file sampler [https://github.com/firasd/vblinds https://github.com/firasd/vblinds] and I was noticing the MIT license seems too encumbered with the requirement to keep crediting authors downstream so I used the 'Unlicense' public domain license (CC-0 seems to be side-eyed by open source orgs cause it preserves patent rights)

nextblock 2mo ago

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.

ameliaquining 2mo ago
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 that users run on their own machines.
- davisr 2mo ago
  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.
  - nextblock 2mo ago
    Also, the money can be made selling premium package/modules/features on that Free core AGPL software.

davidw 2mo ago

It's a bit ironic to talk about key parts of the toolchain being open source while making black-box, closed source LLM's, controlled by external companies an integral part of all of it.

crawshaw 2mo ago
(Author here.) Open models are really quite good now. I still use oai as my daily but I have been very impressed by qwen/glm/k3/etc when I try them. They are clearly my future.

knighthacker 2mo ago

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.

ivanjermakov 2mo ago
I think it's pretty common in software companies to maintain own custom fork of an open-source tool/library.
pornel 2mo ago
Before LLMs the barrier to modifying software was much higher - in skill and time investment required. Now we're getting to the point where any user can say "Claude, I don't like that. Please fix" and have it fixed. Configurability/extensibility can work in some cases, but having source code makes it much more powerful.
s777 2mo ago
> 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

js8 2mo ago

Some time ago, there was a comment https://news.ycombinator.com/item?id=48849015 https://news.ycombinator.com/item?id=48849015 I deeply disagree with the light vs dark framing. I think the real tension between "hacker languages" and "blub languages" is the expectation to modify the language by it's user. And this is true for dev tools as well. Hackers prefer modifiable environments (such as Emacs), while corporations prefer standard environments (IDEs) to which programmers will adapt. (As the saying goes: "The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." Might be why Paul Graham preferred founders with non-blub languages after all, nothing to do with Lisp as such.) But to be able to adapt the environment, one must understand it. Therefore the pull to make it simpler, a set of universal tools, rather than a complicated machine with many features and ease of use through following prescription.

lalitmaganti 2mo ago

As 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. Not in the merge conflict sense but in the UX sense. Do you want to resolve that on every release? Is it just "AI will fix this"? Maybe one day, but as of today agents can do something along the right lines but don't capture my UX sense very well; and if the whole point is hyper-personalization, I want it exactly how I want it. "Does it seem to work?" is a fine right until it fails when you're doing something important. Do you then stop and go prompt an agent to fix your tooling, and hope it does a good job this time? What if it doesn't do a good job? Moreover, for devtools which are fundamentally social (i.e. lots of different people looking at the same thing), there's real value in that thing looking the same for everyone. Having a baseline for teaching, auditing, verifying "we are all talking about the same thing" is incredibly valuable and is sometimes where the most value is. All in all, maybe in some categories of devtools, this hyper personalization is indeed what will happen but it's a long way from being universal.

skybrian 2mo ago
The idea is that upgrading a devtool is like upgrading a vendored library. It's not something you do automatically or while you're in the middle of doing something else. Usually the AI can fix merge conflicts. If upstream changes are too extensive, you can have the AI rewrite the change entirely. I think will work better for nice-to-have features that are ultimately disposable if they become too hard to maintain.
zephen 2mo ago
> 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.

bluegatty 2mo ago

Good point, but extensibility != OSS though. JetBrains and Claude/ChatGPT are not open source. I think we would like them to be ... but ...

intrasight 2mo ago

"Five years ago, most software engineers I spoke to had no programs they had written for themselves." What happened five years ago? Before that everyone used tools they wrote themselves. I think the answer is nothing happened five years ago and everyone still uses tools they wrote themselves.

zephen 2mo ago
> What happened five years ago? Apparently the dude found some new acquaintances.

muragekibicho 2mo ago

exe dev is a VC-funded company reselling open source software. Everyone's making cash from your open source code except you.

zephen 2mo ago
You write as if they have an ulterior motive to try to trigger your FOMO to keep you proactively burning CPU cycles and AI tokens, just in case something might have changed while you were sleeping. "Lather, rinse, repeat." Some things never change.

bqc 2mo ago

[flagged]

writtenone 2mo ago

exe.dev is NOT open source. Funny

arjie 2mo ago

Everything is now open-source by default. All features are replicable. I don’t really care that much any more that tools need to be OSS because I can make my copies when I want. And I do when I so desire. Your feature page is your source code.

doc_ick 2mo ago
Your idea is my source code.
- arjie 2mo ago
  Absolutely. It’s all an execution and distribution problem now.
  - doc_ick 2mo ago
    That truly is sad, as execution and even distribution is just now a prompt with a credit card.

QwenGlazer9000 2mo ago

LLMs make things easier but can we not advocate for making them a dependency to configure our tools? Even open weight models aren't fully open source. It's basically like having the back end binary but not the source code. Use em to make your life easier but I'd rather not we normalize LLMs becoming the primary way we interact with open source software.

creakingstairs 2mo ago

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.

2001zhaozhao 2mo ago
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.

dismalaf 2mo ago

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

crawshaw 2mo ago
Hi, author here. The entire second paragraph of my blog post is dedicated to the question you asked. There is really nothing more I can add.

conqrr 2mo ago

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

skybrian 2mo ago
It seems like an odd purity test to advocate for on a Y Combinator website. Why are you here if you're so worried about being influenced by VC's?

deleted 2mo ago

[deleted]

shay_ker 2mo ago

Separately, JetBrains's revenue grew 25%: https://www.jetbrains.com/lp/annualreport-2026/ 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 <software> 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.

thepoet 2mo ago

A bit idealistic for the crowd here but has some good points. The other day I wanted to build personal apps for my Kobo device. It has a single ~800Mhz core and 512 MB of RAM, probably eight times less than a rasbperry pi, but runs a Linux. I wanted to break free from watching my laptop screen for long Claude sessions partially due to degrading eyesight and have a sidekick for approvals streamed to the Kobo. Apart from the Claude and Codex permissions sidekick done via hooks, I ended up building an entire SDK, an HN client, an RSS discovery & reader and an audiobook generator using deep research and ElevenLabs API all running on it. Anyone using an LLM can now personalize it for their own Kobo device, which might have some nuances over my Clara BW. Significantly less work I hope than doing it all from scratch even with a coding agent. https://github.com/BandarLabs/Cobalt https://github.com/BandarLabs/Cobalt

jedberg 2mo ago

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 and ultimately sold to an infra company, returning pennies on the dollar to their investors. The difficulty stems from the fact that your customers are developers and operators, and they all think that they don't need you because they are perfectly capable of running the software themselves and adding whatever they need to it. In a lot of cases they are right. And now, with AI coders, it gets 10 times worse, because they can take your open source and then vibe code a "good enough" version of your commercial product. 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. Some tools have started making licenses that are free for individuals and startups but cost money for profitable companies. That's an interesting strategy but I know some companies won't allow those tools precisely because of their license.

pbjerkeseth 2mo ago
> 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 before times.
- jedberg 2mo ago
  > 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.
rglover 2mo ago
> 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 "what's the replacement for <insert incumbent>?" IMO, the combination of OSS and "generous free tier" SaaS plans basically nuked the willingness to pay for software, especially dev tools. Folks are just too conditioned to expect stuff to be cheap or free nowadays. Maybe that changes long-term but shrug, who knows.

pete00074b98426 2mo ago

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.demokluster.com https://peat.eth.limo https://peat.eth.limo https://peat.eth.link https://peat.eth.link git clone https://peat.eth.demokluster.com/peat0.git https://peat.eth.demokluster.com/peat0.git (webpage itself incl ro-git is hosted/mirrored over IPFS/ENS)

fasterik 2mo ago

I used to be much more of an open source fundamentalist than I am now. For me, it's more about trust than source availability. There are closed source projects that I have high trust in, and there are open source projects that I don't trust at all. A project being open source can increase trust, but not necessarily so. Regarding personalization, I would much rather use software with strong design principles that's simple, opinionated, and works out of the box with sane defaults. I want to spend my time getting work done, not tweaking settings and adding custom features.

traveltoursocia 2mo ago

inigyou 2mo ago

Devtools for open source must be open source, but I see no reason to give any shits what corporations use. And we live in capitalism, where making money is not optional.

Bnjoroge 2mo ago

I like using exe but I’m not sure what to feel about this if exe itself isnt open source. Granted, their agent is OSS, but still feels somewhat ironic

duped 2mo ago

> The result is that software that can be personalized doesn’t need a plugin system or a config file. Yes, please make me rebuild my software to change an API endpoint or port number. It's a wonderful use of time and electricity to build and spin up agents to fix the inevitable problems with building software. Instead of changing a string in configuration file. (/s if not obvious). Configuration and plugin systems exist for a good reason: software should be reconfigurable and modular without requiring the wholesale replacement of the original. Even if the code is open source, there are good reasons to move logic and data out of tree and into config or plugins.

luciana1u 2mo ago

[flagged]

dipanshuhappy 2mo ago

I think this became aparent with agentic coding CLIs. In my company, it was not encouraged to use claude code because they haven't open sourced it yet

dataangel 2mo ago

The models are dev tools ;)

abratabia 2mo ago

[flagged]

ValdikSS 2mo ago

>How to Personalize Software I've seen https://v-it.org/ https://v-it.org/ here on hackernews. Same idea, different wording.

darkstarsys 2mo ago

Yes, emphatically! I wouldn't be where I am today without tools like Emacs and Linux. This is why I created [pcons](https://pcons.org https://pcons.org) because software build tools (like all dev tools) need to be open, transparent, hackable and easy to understand.

shevy-java 2mo ago

Microsoft, listen to this.

wasting_time 2mo ago

Does this mean exe.dev will become open source? Or is it not a developer tool?

skybrian 2mo ago
It's a VM hosting service. The devtools they have in mind run on top. But there are other open source projects that will help you self-host.

myshapeprotocol 2mo ago

[flagged]

bartleeanderson 2mo ago

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

usernametaken29 2mo ago

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.

nightlycosts 2mo ago
Specially in an article that initiates the conversation advocating for setting a machine that stays on overnight running agents making rebases among who knows what else. There are two other frontpage threads right now tangentially about the cost of AI, I'll have this conversation there, to see how well the idea this cost is gone holds up against a primed crowd.

Escafati 2mo ago

[dead]

link89 2mo ago

AI-generated software is accelerating Shadow IT, putting heavy pressure on internal governance.

ThinkBeat 2mo ago

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.

tizerluo 2mo ago

[flagged]

xsotf 2mo ago

yee

deleted 2mo ago

[deleted]

Jansss 2mo ago

[flagged]

quintu5 2mo ago

"We need the source code." No, you want the source code. You want software someone else put their time, effort, and judgement into to be available for you to do whatever you'd like with it without any recompense. The sense of entitlement here is exhausting. There are plenty of good reasons to choose an an open source tools and sure, the ability to personalize a tool at the source layer can be valuable enough in some instances to justify maintaining a fork manually or with an agent. Asserting that dev tools must be open source to prioritize a paradigm where users roll the dice on adding features by one-shotting them with an agent and then burning tokens until the end of time to try to keep their forks compatible with upstream changes because plugin APIs are too restrictive doesn't pass muster.

madhu_ghalame 2mo ago

[dead]

Terratrader 2mo ago

I am working on a new AI architecture for small AI models. Without open source AI development is dead.

robalni 2mo ago

The article is about only one side of the solution: using AI to make it easier to work with code. I think the other side of it is more important: making software simpler so that people can work with the code without having to use AI. That's what I try to do.

eviks 2mo ago

> It is astonishingly easy to personalize software today. There are two general categories of prompts to an agent that make all of this possible: That's the memed magical thinking of "make no mistakes"

mikasisiki 2mo ago

I'd be curious to hear what the author and others here think about how AI-assisted customization will affect the business models of open-source devtools.

aljgz 2mo ago

Years ago, we were revamping a mission-critical project with more than a 1000 database tables to a backend of .net and EF. Our rewrite was much cleaner, but still had 450 tables. We started noticing that our backend took 2 minutes after starting up to serve the first request, fast after that. It turned out EF had a stage named "view generation" which verified that data would round-trip, meaning if it goes into the DB and comes back, would stay the same. Run time was exponential on the number of tables and complexity of models. People used tricks to work around it, which was basically caching the "generated view" in a file, which could speed up the production startup, not as easy in DEV environment, our programmers still needed to wait 2 minutes after each compile. I started looking into it, and it turned out that Microsoft had open sourced EF a short time ago (long after we had started the project). While profiling, view generation took much longer, 450s, as it was a CPU-heavy process. There was a function excluded from release builds by a `[Conditional('DEBUG')]` attribute, and when I removed the call to it, the time went down to 64 seconds, 63 of which was in a very simple function. A LINQ statement in there could be re-written to make it 120ms. I ended up contributing it to EF core, being acknowledged in their blog post, and we ended up using our own release build of EF libraries until the fix made it to the public release. Had they not open sourced EF, it could turn into an existential threat to the project.

yoanwaidev 2mo ago

[dead]

egeozcan 2mo ago

The thing that made me pull the plug on claude subscription was that I couldn't use pi. I can use codex on pi, deepseek on pi, I use them on different tasks and let them review each other. Tell deepseek flash anything you want changed and a minute later it's there. Forget vibe coding, I'm vibe-using the thing and having so much fun.

mangudai 2mo ago

[flagged]

conartist6 2mo ago

Utterly unimpressed by this. This is an argument for a future of closed source devtools. We are on the road that leads there, and this describes going further along it.

sylware 2mo ago

Open source is not enough: _LEAN_ open source is a strong requirement today... and that includes syntax complexity of any used computer languages. The scammers are now doing open source vendor/dev lock-in via massive size and complexity... while there are small and stable in time alternatives able to do a good enough job. Those guys are not all malicious, many are just brain washed and some suffer from a mental disorder: accute Rube Goldberg Machine syndrome.

lowkey57 2mo ago

[dead]