JetBrains and Claude/ChatGPT are not open source.
I think we would like them to be ... but ...
51–60 of 262 posts
JetBrains and Claude/ChatGPT are not open source.
I think we would like them to be ... but ...
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…
Earlier quoted context omitted.
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.
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 ." The access to closed platforms is managed according to the docs.
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
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.
Earlier quoted context omitted.
> 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". Still highly dependant on one's access to SOTA AI models (availability and funding). Most people praising LLMs publicly for this sort of use case, are the ones with unlimited access to tokens / AI credits, or simp…
I've gone back and forth on this. A couple of years ago LLM prompts really were incredibly cheap and falling in price. OpenAI's own models had fallen in cost by a factor of about 1000x since GPT-3. They were also cheap because many of the things you might want to do with an LLM took in the order of a few thousands tokens, at most. Then coding agents happened, and suddenly we had a reason to burn 100,000s or even mill…
But then what stops the upstream tools from doing exactly the same thing and getting the same speedups? I've certainly seen AI become a huge boon in my debugging experience for random user reports for example.
FWIW if we are talking about hyper personalized software like the OP, it's going to quickly go beyond "debug and maintain" and towards bigger issues like UX, ergonomics, features etc. And at that point, if the upstream is also being developed you will have differences between your personal visions and upstream
Is the answer at that point "accept whatever AI does"? That to me seems to clash with the entire premise of hyper-personalization which is where your vision is what matters not the AI's. Do you really want to get into the game of having opinions on design of every tool you use forever?
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 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…
Even pre-LLM this is how suckless tools work, I actually don’t much mind having to edit a variable in a header and recompile when you make a config change. https://dwm.suckless.org/customisation/
Earlier quoted context omitted.
I've gone back and forth on this. A couple of years ago LLM prompts really were incredibly cheap and falling in price. OpenAI's own models had fallen in cost by a factor of about 1000x since GPT-3. They were also cheap because many of the things you might want to do with an LLM took in the order of a few thousands tokens, at most. Then coding agents happened, and suddenly we had a reason to burn 100,000s or even mill…
> So I don't think advanced AI that can help debug and maintain software will stay out of the reach of most people for very long. But then what stops the upstream tools from doing exactly the same thing and getting the same speedups? I've certainly seen AI become a huge boon in my debugging experience for random user reports for example. FWIW if we are talking about hyper personalized software like the OP, it's going…
Yeap. Most users want someone else to think for them. Not just "something" (AI). Having a vision on what works best (design) is still, for the time being, a human task IMO.
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…
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 good then, and maybe I should have learned some rust first. But it was close. For a less fast-moving codebase it'd have worked, and that was 8mo ago.
On the other hand as someone building in devtools for the first time, I struggle with how to think about this. We're building a cloud agent + sandbox platform, https://boxes.dev - same problem space as the author's product exe.dev. We could open source our client or the whole stack (we've been thinking about it), but we're adding stuff so quickly that anyone customizing would have a hard time with updates. There's also a lot on the hosted side that users couldn't modify unless they self-host.
But I like this vision of a world where software is some fluid thing, and everyone is writing personal mods and building off of others' - basically OSS with forks but where every user (or their agent at least) is engaged with the code.
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…
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.