The conversation

dregitskyHNSource author
Lessons learnedExperience excerpt · English

On the other hand as someone building in devtools for the first time, I struggle with how to think …

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

Original discussionDevtools must be open source233 source comments · at import
5

What was this responding to?

Parent context · original excerpt

SI
simonwHN

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 mo…

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 5

Direct replies available in this import. Original-language excerpts.

AW
awesome_dudeHN

> On modifying software [..] It was fun and satisfying, but it ended up being a bit of a pain to keep updated. I don't mean this as a criticism in any way - but the need to keep your changes current is a strong motivation for getting those changes incorporated upstream.

Full original
AL
aleqsHN

How are you handling the actual provisioning of the agent boxes/VMs? Are you using a specific provider/cloud, or multi-provider? Are there any providers/clouds you've found are better/worse for your use cases? Asking because I am working on an open/standard protocol/layer for provisioning cloud resources across different providers. One of the ideas is to provide a marketplace of providers/resources via one unified/standard API, which I would allow automatic selection and provisioning of VMs (and other resources) based on price/value/feature/reputation requirements/priorities.

Full original
GR
gritzkoHN

I am working on a malleable SCM system. I just split it in two: the foundational machinery noone wants to mess with and malleable JavaScript on top. Not my invention. More like, it was always this way, but now we also have LLMs.

Full original
SO
SOLAR_FIELDSHN

As an end user, I don't mind if you're building a product with rapidly changing API's out in the open. I'll still use the product if it's useful and deal with the churn. What I DO care about is not having half of that project rug pulled 12 months down the line when your Series B folks decide that this particular money knob needs to be turned up. So if you want to not piss off your users, that's the way to do it. Build a model where you can actually sustain the product, and no, giving it away on seed and series A round money then rug pulling that gift is not the way to achieve that.

Full original
NE
nextaccounticHN

> if licenses permit. As if licenses mattered in the LLM era Case in point https://news.ycombinator.com/item?id=48466812 > In looking at the code that the LLMs have produced for the project, especially given the pretty massive and widespread architectural changes needed to make the implementation libified and memory safe, we decided that the codebase is not a derivative work that would require carrying forward the GPL license and have decided to release the code under the MIT instead. LLM are copyright laundering machines Not only they launder copyright from Internet at large, they can also launder from specific targets

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.