From reading these threads it’s less about the opinions you hold and more about how you behaved, no?
Zig leadership asked you to not place bug bounties on issues without their consent. You decided to ignore their request and kept the bounty up by moving it to your own repo. Zig leadership decided you weren’t engaging in a particularly constructive way and decided you were unwelcome.
The other part is exactly what yoshuaw described as very disrespectful and immature behavior on your part. I know from my interactions with you that you are extremely argumentative _to a fault_, don't take no for an answer, and always assume you know better than everyone around you. Maybe you're somehow proud of that, but it's not surprising to hear you've been banned from participating in the Zig community.
You should respect the Zig community's wishes and be willing to contract the work out with clear terms, taking on some of the risk that it takes longer than expected yourself.
> Please don’t use bounties to incentivize Zig development.
They explained their reasoning extensively:
- Bounties foster competition at the expense of cooperation.
- Bounties are an utterly simplistic way of dealing with the business management side of creating software:
- Instead of scouting for a suitable candidate, you’re letting battle royale dynamics pick a winner for you, at the expense of everybody who’s going to lose the competition.
- Instead of creating a clear contract where you take on some of the risk, you implicitly put the entirety of the risk on the contestants (eg partial solutions don’t get any payout).
- Instead of allocating time and resources to proper due diligence, you instead penalize any form of thoughtfulness in favor of reckless action (eg a solution just needs to pass a test suite).
- Instead of planning for the full lifecycle of software, which also includes maintenance, you end up with a quickly bitrotting artifact that is of no practical use to anybody.
- Instead of spreading unease to all the people involved, it would be preferable you instead learned how to do business properly.
- On projects less radical than Zig, you might also put pressure on the development team to accept the winning submission, which, given the above, will probably not be the most well-thought-out and maintainable solution.
> Info: while ideally the PR should be merged into Zig master, is not a necessary requirement to receive the bounty. As long as a fork exists that fulfills the requirements laid out before, the bounty will be awarded
To an outsider, this looks like you slapped a new name on the exact thing the Zig team asked you to stop.
Do you feel your new request adaquately addresses the team's issues?
[0] https://ziglang.org/news/bounties-damage-open-source-project...
Furthermore, we also took their post constructively and added two more points on the bounty issue [1] that we believe should solve most of their concerns:
* Wasmer will manage the work and have at most one person or team working on it at a time. Anyone interested on the work should reply here and organization of the work will be done by the Wasmer team
* Partial work that actually works will be rewarded accordingly (for example, the libc layer, or the Zig layer itself)
Of course, the fact that they banned any further conversation from the disagreement doesn't make specially easy to see if such an approach will be sufficient for them or not.
[1] https://github.com/wasmerio/wasmer/issues/4218#issuecomment-...
As a matter of fact we pass more tests than any runtime created by the BA as reflected here:
I assumed they were compliant with the WASI specifications.