Comment by imrehg | Hacker News Reader

Comment by imrehg | Hacker News Reader

Parent Full thread

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

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.

This is actually not a bad idea for funding open source software. It used to be that you’d have an author who coded a project and then could fix the occasional bug or two quickly.

Now, we have larger projects where it is rare for one people to have a complete understanding, and the main value is a person to reviewing patches and bugs to make sure the changes align with the larger goals/path for the project. There is little incentive for a maintainer to do this, aside from wanting to limit forks.

Paying for that review might be the way to keep this whole model sustainable.

Opportunity for gh

“Here is my pr I attach x$ payable when it is merged” and allow me to add $ to other prs.

I have been waiting year + for multiple feature in some projects that have open prs and for one I would easily bid 100-200$

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

Maybe instead of the emoji buttons Github should let people attach money to the issue.

If that gets fixed, the project gets the money.

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.

> which is absurd because forking should be a last resort for software that thrives from having a community.

This is true, of course, but having a community is completely orthogonal to whether software is open or closed source.

The two are correlated which does encourage that mistaken view. Github culture generally blends these two, having an open issue tracker, pull requests etc. as well as the code right there, often with a free license.

But you can very much allow bug reports and feature requests in public while developing proprietary software and you can also very much work on a project alone or with a small group without being open to random patches, contributions or requests and be open source / FLOSS.

The key definitional question is the license, not any of the cultural stuff.

Plenty of proprietary packages had robust communities well before anything like github existed.

In fact, github is arguably a poor substitute for a community. Look at how communities such as the ones around the linux kernel or cPython communicate. It sure as shit isn't through issues or pull requests. Or rather, perhaps, the limited technical communication that an issue tracker is good for is not a valid large community consensus building mechanism.

> The key definitional question is the license, not any of the cultural stuff.

For direct modification, certainly. For customization, maybe. For ignored issues like the parent to my original comment was bemoaning? Maybe LLMs are good enough that we are almost ready to say "Make me a custom version of Photoshop" and then it doesn't matter.

Yes. I've actually added some features to Blender like this, related to some highly specific use case. Just clone the source point an agent at it, say what you'd want (you have to be able to formulate this in a halfway coherent way), and it succeeded. Now, I haven't thought much about what it would mean to maintain this, but I think if I need this ever again, I can point an AI to it again and say "do the equivalent change now to the latest version". For occasional use this is fine.

> thrives from having a community.

Does it? I think a lot of software projects which are not as huge as the Linux kernel etc. thrive best with a tight core development team, and not from a "community" if you mean that word beyond "users".

Look at it from the point of view of a maintainer. Not sure if you've ever tried. People want to pull your software towards a million incompatible directions. They write some big patch and then get angry if you don't merge it.

My advice: consult the maintainers first whether they agree with your idea and whether they are open to considering your submission. You still won't have a guarantee that it will be accepted, because that's their final say. But at least you won't spend effort coding up something that they could already tell you they don't want to have in their software.

Reply on news.ycombinator.com