Maybe it's worth responding directly to the criticism from Zig rather than calling what they are saying a "rant".
Actually, since you don't address anything in your comment, one could call that one a "rant" as well.
Actually, since you don't address anything in your comment, one could call that one a "rant" as well.
We've seen contributors author PRs together and split bounties. Also contributors in the Zig thread were actually trying to collaborate on a solution (comments were deleted)
> Instead of scouting for a suitable candidate
Open calls have faster turnaround & lower overhead
> clear contract ... payout
Sometimes design & implementation is not decided and spec'ed in advance and multiple perspectives & sometimes PoCs are required, at which point the maintainers can choose a plan of action and assign a developer without much duplicate work. That's classic OSS dev with or without bounties.
https://news.ycombinator.com/item?id=37543536 there's more replies here that I agree with
--
I also suggest you checkout the discussions deleted by Zig for a full perspective https://pastebin.com/nDA0LD3N
As a matter of fact the initial convo on the thread proved contrary to the every point made regarding competition and "battle royal dynamics" as people attempting the bounty were actually collaborating. We've seen quite a few cases where people authored PRs together and split the rewards on Algora.
In addition there was no "pressure on the development team to accept the winning submission" it was explicitly stated that the work did not need to be merged upstream, and that the sponsorship would be awarded as soon as the technical requirements were met.
--
Ultimately, bounties are a tool. It's in maintainers' discretion whether or not to use it.
The optimal design for a bounties platform is still a work in progress. We're two bootstrapped founders (one developer) figuring things out along the way, trying to give folks a good experience and trying to learn.
> Open calls have faster turnaround & lower overhead
I think your perspective is made perfectly clear if you believe that having 10 people do duplicate work is less overhead than having one manager do some managerial work.
Add to this some discussions that I've had in private and we get to 10 pretty quickly.
Are you sure it's wise to argue that feature bounties don't result in competition and duplicate work when presented to a healthy-enough OSS project? This bounty was publicized by Wasmer as "the first developer that adds support" is the one who gets the money:
https://twitter.com/wasmerio/status/1701168305103331701?s=20
Also some sort of acceptance criteria have to be in place, and "first viable solution gets the reward" is reasonable enough
People have agency to make decisions such as trying to solve a bounty (to get experience, feedback from peers/maintainers & maybe a reward) but you decided to shut them down, delete their comments and get offended on their behalf
You're not obligated to entertain, review or merge code you don't approve and it was your right to shut down the initiative by Wasmer
1. Consulting with the Ziglang leadership before creating the issue that kicked off the bounty. Doing it this way would have allowed them to provide some input on perhaps splitting the bounty, improving the acceptance criteria and other logistical stuff, rather than allow them find out later when the comments were devolving into personal attacks.
2. Splitting the bounty. Offering three bounties: $2500, $1500 and $1000 increases the likelihood of producing different approaches and rewards skill as opposed to one $5000 bounty that rewards the fastest person, to the detriment of others working on it. The amount spent is the same but the outcome is less of a battle royale.
3. If splitting the bounty is not an option (because the intent is for the high-ticket $5000 on offer to fuel Wasmer’s marketing), then at least more thought should go into how the bounty is administered by working with Ziglang leadership so that it doesn’t create unhealthy competition or at least draw people with the right skills.
Zama runs a big-ticket bounty program that is worth emulating in how it is run https://github.com/zama-ai/bounty-program
Following your feedback, perhaps community bounties should be by default only shared with maintainers, and then the maintainers can choose whether to complete them themselves [1], or make them public, or disregard
This approach would prevent situations like the above and hopefully also helps with FOSS sustainability
[1]: https://twitter.com/algoraio/status/1703115434055082086
Courting the maintainers for their permission first could have avoided this scenario.
So, assuming you did that but Ziglang leadership declined, for whatever reason, then the alternative would be to host the bounty on Wasmer’s repo as they have done now https://github.com/wasmerio/wasmer/issues/4218.
This whole thing is very reminiscent of the disaster that was Hacktoberfest, where a prize was offered to do a task on other people's projects without consideration for the how the nature of the incentive might change the nature of the completed work.