Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Devtools must be open source

blog.exe.dev

Post reply on HN
Print view View original

151–160 of 262 posts

Re: Devtools must be open source

#151

Post by kaelenvoss »

brunoborges wrote: post #41
simonw wrote: post #3

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

[flagged]

Re: Devtools must be open source

#152

Post by [deleted] »

zephen wrote: post #72
ravenstine wrote: post #60

Earlier quoted context omitted.

That's my biggest gripe with open source software. It's not really the open source part that's bad, but when projects turn into major projects with a substantial user base, I think the owners have an obligation not to delude their users into thinking they have more say than they actually do. Plenty of big projects leave their issue trackers public and have docs that encourage community contribution, yet effectively i…

> which is absurd because forking should be a last resort for software that thrives from having a community. This is true, of course, but having a community is completely orthogonal to whether software is open or closed source.

[deleted]

Re: Devtools must be open source

#153

Post by jbritton »

fleventynine wrote: post #101
imrehg wrote: post #7

Earlier quoted context omitted.

I have sent countless small bug fixes even before, to tools that I use that I could dig into when something was off... No big heavy lifting, but plenty of "tinker on your tools" stuff. And I don't think what I did was that special, so maybe the experiences are different? The current LLM-driven stuff seems to break down the expectations, and now there are a lot of places which just ignore anything I send in (the same…

The solution for this is to pay open source maintainers for their attention. If I want them to review and merge my bugfix I should attach $1000 to the PR.

Maybe a donate link attached too. The dollars tied to a PR could help set priority of fixes.

Re: Devtools must be open source

#155

Post by kami23 »

aleqs wrote: post #129
dregitsky wrote: post #59

Earlier quoted context omitted.

Yeah I think this is changing, fast. 100% agree on "clone X and tell me how it works". I'd also add: "clone X and see how it does Y; use that as design reference for building feature Z" if licenses permit. On modifying software... I forked codex in ~Dec and had my own lightweight "plan mode" and a few other things. It was fun and satisfying, but it ended up being a bit of a pain to keep updated. The models were less…

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/st…

Coder uses terraform providers to do the provisioning. I think that's the correct layer of abstraction, all major providers will be there and can be customized with the modifications needed via various other terraform features.

I've written three different solutions for platforms that solve this standard protocol layer. What has worked for us was deciding to standardize on the Kubernetes API for our services back in 2017, and then from then on, all our providers have provided either a k8s API to interact with resources, or provide a Cluster API for provisioning. For example we have two datacenter VM providers that implement the k8s API and we've been able to swap the providers with no user refactoring, it's a good solution in hindsight with how many people have k8s in their stack.

For the second big feature you're thinking of, we never really go a good solution to this problem, a lot of our workloads are long lived and not necessarily spot instance-able, but it's a very fun routing problem. Most of our need to be in multiple clouds is that we want to heavily separate our customer facing services, and keeping it away from internal workloads that support those customer APIs.

Is this public work? I'd love to take a look. This is my bread and butter.

Re: Devtools must be open source

#156

Post by seba_dos1 »

rvz wrote: post #14

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

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

Re: Devtools must be open source

#157

Post by mmcdermott »

rvz wrote: post #124
pjmlp wrote: post #111

Earlier quoted context omitted.

HackerNews, the site when someone posts about their business for developer tooling, there is always a bunch of folks posting links about half implemented alternatives, because who wants to pay for tooling like any other professionals?

This is also completely self inflicted. This is one of the only professions that does not want to pay for their tools and will do anything to get it for free, including building it themselves. So this is quite unsurprising that open source developers have become this decade's new starving artists asking for donations for their "free software" only for a coding agent to do it for close to $0.

Perhaps, but it is also the way in which LLM providers eat their seed corn. If everyone publishes less because the only one to consume it will be an LLM gives no credit, then LLMs will lose training material over time.

Re: Devtools must be open source

#158

Post by SOLAR_FIELDS »

dregitsky wrote: post #59
simonw wrote: post #3

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…

Yeah I think this is changing, fast. 100% agree on "clone X and tell me how it works". I'd also add: "clone X and see how it does Y; use that as design reference for building feature Z" if licenses permit. On modifying software... I forked codex in ~Dec and had my own lightweight "plan mode" and a few other things. It was fun and satisfying, but it ended up being a bit of a pain to keep updated. The models were less…

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.

Re: Devtools must be open source

#159

Post by simonw »

pif wrote: post #149
simonw wrote: post #3

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…

> Several times a day I'll prompt regular Claude chat to "Clone x/y from GitHub and tell me how Z works". In principle, you should not need the source code: the AI should be able to answer by examining the binaries.

I mostly work with Python, and often coding agents answer questions about dependencies for me just by digging around in the site-packages folder in whatever virtual environment they have access to.

The "clone X and tell me" trick is something I mostly use on my phone - I can answer questions about pretty much any piece of software on GitHub with a regular Claude session, no coding agent needed.

Post reply on HN