Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree with the ban.

You proposed a change to a repo you do not own. You offered an incentive to 3rd party developers to push PRs to that repo. You did not wait until the proposal was accepted. You thus required the community maintaining that repo to do extra review work on a feature they hadn't officially accepted yet. You were refused, and then offered the same incentives somewhere else, with the same drawbacks on the zig community.

Even in your new offer it's unclear whether people should make changes in zig (add support for your features in zig) or in wasmer (change the samples to work with the current zig compiler, or build libraries that work with zig) to support your features.

There's a time and place to offer incentives for someone else's project, but that shouldn't happen without their approval.



Don't understand the problem, can't the PRs just be ignored forever or closed?

No one can do any work unless the leadership green light seems a bit restrictive


But now the zig project are responsible for denying someone else $5,000. I think that's unfair pressure to put on them. It may also cause some of the potential bounty claimants to exert pressure on the zig team too.


This is not true.

The $5,000 reward did not required the work to be merged upstream. Please read the rest of the thread


If you want the work done, why not just pay someone to do it instead of playing games with bounties?


Couldn't he just put it in a roadmap to be reviewed, merge the work if acceptable, accept the reward himself, and reward Zig team accordingly by other means?

This seems to be a negotiation attempt being made fully in public by two open-source projects. I would think as the project gets popular darker pressures will be attempt


This comment might be insightful: https://news.ycombinator.com/item?id=37545637

EDIT: added extra context

> You proposed a change to a repo you do not own

That’s not accurate, your assumption would imply that the bounty would require the work to be merged upstream or reviewed by the Zig team, which was not. The bounty just required to have a working prototype. We explicitly stated that merging upstream was not required

> Even in your new offer it's unclear whether people should make changes in zig (add support for your features in zig) or in wasmer (change the samples to work with the current zig compiler, or build libraries that work with zig) to support your features

That's a fair critique, I'll update the issue to make sure this is clear


[deleted]


But then why did you open an issue in the Zig repo and even marked it as "Bug", while in your repo you added the "Enhancement" label?

Just admit that you've communicated it poorly and move on.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: