I missed this nuance in my first reading, but the person offering the bounty to implement Wasmer’s WASIX extension is Wasmer’s CEO. Wasmer has a dodgy history with Bytecode Alliance so trying to essentially bribe their way into more adoption for their own flavor of WASI seems a continuation of that trend and an indication that they’re still not acting in good faith.
I haven’t paid much attention to them other than being vaguely aware of their existence, but I checked out some of the link in the github thread and… it looks bad: https://mnt.io/2021/10/04/i-leave-wasmer/
You’re not exaggerating. That’s sad.
EDIT: Oh wow, Wasmer apparently tried to trademark WebAssembly. What the actual ****.
I came to disagree after reading the headline but found I agreed after reading the article. Bounty-like things can be done very well if they’re properly administered. The FreeBSD Foundation is pretty good at this. If a few companies all want a feature, but don’t want to pay 100% of it, the Foundation will handle taking the money, finding a contractor, and finding people on the project that can review the patches and ensure that they meet the required quality.
While we do understand that continued exposure to venture capital might have caused some to build an appreciation for endless rat racing, we kindly request that you keep unwarranted hustling away from the Zig community.
I think you definitely need to be careful what you incentivise. I think it would be nice to disconnect the reward from the goal a bit. For example rewarding a valuable contributor after a few chances rather than promising a reward for a particular bug. However that may make it harder to get people to contribute than a bounty for a particular issue that is affecting them. But definitely it needs to be clear that the bounty is for a high quality accepted patch, not just one that passes the test suite or whatever other minimum bar. Of course I agree that it can cause heated disagreements when a patch author thinks that they are owed a reward.
although when you stipulate “accepted” you could get into a situation where, say for this example, andrew decides it’s not in tone with the project and then the person with the hogh quality submission still gets shafted.
I think andrew et. al. are making the right call by getting out in front of it and just saying no.
I think it’s good to have crystal clear rules when we should reward someone, or when we shouldn’t. If those rules are fuzzy, then it’s a matter of time before disagreements arise; For example, “why was that other person rewarded, and not me, since I also did some work?”. Fuzzy rules imply discretionary awards, and in such an environment, it’s really easy to make a mistake, really easy to be influenced: convinced, manipulated, bribed (not necessarily by money).
I think this differs a huge part for “somehow hip or hyped” projects, like Zig, or some random project done by three people where the bounty is hanging around for weeks or months, the chance a second person would even take it is very low and it’s basically some sort of “one person wants a feature, the maintainers would accept it, but don’t/can’t do it”. I’ve seen that work without problems.
It’s fine if the job is assigned more-or-less exclusively. Most of the issues the article talks about come from the “winner takes all” approach that comes with typical bounties and the resulting intransparency:
When it’s clear to everybody that A kinda-sorta-contracted B to implement the feature exclusively, B can reach out for help in the project when hitting a dead-end, discuss designs with everybody else, or just take a bit longer to make it a good solution instead of just being the first with some solution.
All that falls flat when any public interaction of B might help their “competitor” for the bounty and leave B with nothing.
I missed this nuance in my first reading, but the person offering the bounty to implement Wasmer’s WASIX extension is Wasmer’s CEO. Wasmer has a dodgy history with Bytecode Alliance so trying to essentially bribe their way into more adoption for their own flavor of WASI seems a continuation of that trend and an indication that they’re still not acting in good faith.
Wasmer is blocked and blacklisted by everyone in the wasm community. CEO is extremely unhinged and toxic. Speaking from personal experience.
I haven’t paid much attention to them other than being vaguely aware of their existence, but I checked out some of the link in the github thread and… it looks bad: https://mnt.io/2021/10/04/i-leave-wasmer/
You’re not exaggerating. That’s sad.
EDIT: Oh wow, Wasmer apparently tried to trademark WebAssembly. What the actual ****.
I came to disagree after reading the headline but found I agreed after reading the article. Bounty-like things can be done very well if they’re properly administered. The FreeBSD Foundation is pretty good at this. If a few companies all want a feature, but don’t want to pay 100% of it, the Foundation will handle taking the money, finding a contractor, and finding people on the project that can review the patches and ensure that they meet the required quality.
I’m most impressed by this quote:
VC got called out!
I think you definitely need to be careful what you incentivise. I think it would be nice to disconnect the reward from the goal a bit. For example rewarding a valuable contributor after a few chances rather than promising a reward for a particular bug. However that may make it harder to get people to contribute than a bounty for a particular issue that is affecting them. But definitely it needs to be clear that the bounty is for a high quality accepted patch, not just one that passes the test suite or whatever other minimum bar. Of course I agree that it can cause heated disagreements when a patch author thinks that they are owed a reward.
although when you stipulate “accepted” you could get into a situation where, say for this example, andrew decides it’s not in tone with the project and then the person with the hogh quality submission still gets shafted.
I think andrew et. al. are making the right call by getting out in front of it and just saying no.
I think it’s good to have crystal clear rules when we should reward someone, or when we shouldn’t. If those rules are fuzzy, then it’s a matter of time before disagreements arise; For example, “why was that other person rewarded, and not me, since I also did some work?”. Fuzzy rules imply discretionary awards, and in such an environment, it’s really easy to make a mistake, really easy to be influenced: convinced, manipulated, bribed (not necessarily by money).
I think this differs a huge part for “somehow hip or hyped” projects, like Zig, or some random project done by three people where the bounty is hanging around for weeks or months, the chance a second person would even take it is very low and it’s basically some sort of “one person wants a feature, the maintainers would accept it, but don’t/can’t do it”. I’ve seen that work without problems.
It’s fine if the job is assigned more-or-less exclusively. Most of the issues the article talks about come from the “winner takes all” approach that comes with typical bounties and the resulting intransparency:
When it’s clear to everybody that A kinda-sorta-contracted B to implement the feature exclusively, B can reach out for help in the project when hitting a dead-end, discuss designs with everybody else, or just take a bit longer to make it a good solution instead of just being the first with some solution.
All that falls flat when any public interaction of B might help their “competitor” for the bounty and leave B with nothing.
I don’t find that typical, so I guess my experience is different and that’s why I wrote my comment.