Bounties Damage Open Source Projects
ziglang.org
ziglang.org
Normally it's the maintainers who create the bounties using our Github app, however in this case our experimental "community bounties" feature was used by Wasmer to create a bounty in someone else's repo (Zig). I think that's where everything went wrong
We have updated the feature [2]. Community bounties are now by default shared privately with the maintainers only, and maintainers can decide to complete the bounties themselves, share them with the contributors, or discard them. That way community bounties are never intrusive to maintainers' time, roadmap & governance while also acting as a sponsorship if accepted
We're sad to see our tool enabling this drama and hope the feature update will prevent this from happening again
[1]: https://algora.io
Honestly, continuing this push, more than anything else in the events so far, makes me distrust wasmer's intentions.
We explicitly stated that the work would not be needed to be merged upstream for the bounty to be rewarded (a comment that for some reason the Zig team decided to delete)
> [The Zig issue tracker] is only, exclusively, and for no other purpose than for working on the Zig compiler and related tools.
I get you're both personally vested in this and personally slighted by their decisions, but claiming you don't know why that comment was deleted is just stirring shit where there's none to be stirred.
You're the CEO of a company trying to push something forward, you should probably put some serious thought into getting a PR person to either vet the things you're going to say, or just have them speak for you and your company and stay out of discussions yourself. It's one thing to have occasional mis-communications, but when you're very publicly having multiple "mis-communications" that are resulting in negative reputation for your company, you're actively doing harm to your employees and their work. Open transparency that isn't filtered through PR speak is a laudable goal, but by the nature of being a business and a business owner, you're going to be held to a higher standard than your average anonymous forum poster, and consequently you need to be aware of when your "open transparency" is a liability rather than a positive for your company.
Fortunately enough the open transparency strategy has helped us to hire incredibly talented people that couldn’t care less about the PR stunt, and full transparency have helped them understand the reality of complex situations, solving any misinterpretations with clear communication. That’s a culture worth fighting for. Of course, if you care more about the PR stunt I can fully understand your point of view
You've somehow managed to twist that into a rant about how wester culture only values PR as a way to "shape the reality" and how I "care more about the PR stunt". You are a bad communicator. The problem isn't your "culture of honesty". The problem is you keep choosing words and phrases that don't mean what you intend them to mean. The problem is that when people try to get that "accountability" out of you, you double down and insist that you are being mis-understood and that people have it out for you. The problem is your tone, words and actions come across as defensive, dishonest and in some cases more like a PR attempt to "shape the reality rather than accountability".
I'm glad you've hired incredibly talented people who couldn't care less about PR stunts. You owe it to those people to stop torpedoing your own business with your inability to live up to your goals of clear communication.
I believe the best way to have clear communication is by having an extra bit of communication when there is any misunderstanding, which is what I'm doing by following up in this conversation. We all have different meaning for words even if they are written the same (you just need to see how the same religious text can have so many different interpretations).
I have done an effort to spend some extra time to explain the things you misunderstood from my communication. For me, that's aiming to have a clear communication. Of course, we don't know each other. So the tone and/or interpretation can vary depending on our feelings of the person.
Let me put a simple example of what I meant: I did stated that "if you care more about the PR stunt I can fully understand your point of view", which is actually quite different to assuming that you "care more about the PR stunt" as you mentioned (there is a big "if" there that somehow you missed). Let me be even more clear of what the "if" meant in my writing:
* if you care about the PR stunt -> I fully understand your point of view.
* if you don't care about the PR stunt -> I don't understand your point of view
As you can see, a thing that was quite clear from my point of view (and I assume for most of the readers), was not clear for you. And I'm not assuming you are a bad communicator, I just assume there was a misunderstanding because we are, in reality, different people with different minds.
In any case, I don't think we make anyone a favor by discussing this more publicly. If you want to have a Zoom chat (because lets be honest, miscommunication is always easily handled via video) about what other things where there might be a misunderstanding, I will be very happy to do so. Please feel free to email me at syrus@wasmer.io
It was worth it in that setting, because the 1% of reports that were real justified the time spent going through the mountain of BS. Security bugs are so bad we were willing to sink a lot of effort into finding them. 99% of reports were incoherent garbage often made by rude aggressive people who were difficult to deal with.
And to be clear, those 1% real reports weren't neccesarily good. They were often poorly explained. Sometimes the reporter didnt even know what they were reporting and had just happened to stumble on something interesting.
Now security vulns and actual code is really different but my experience with security bug bounties makes me think a code one would be an unmitigated disaster. All the bad parts of security bug bounties matter so much more when it comes to code.
In development, getting working code is barely half the battle. Bad quality code can be worse than no code. Making sure the code is not buggy is hard, making sure the code integrates well is hard, making sure its well tested is hard. Even ensuring it follows the not automatically testable coding conventions is important.
Bounties would just incentivize low quality drive by submissions, which helps nobody. Sorting through them would be a real cost that would outweigh any small benefits.
I also disagree about duplicates being a non issue in security bounties though. Its super common for multiple people to find the same bug. Even worse, security bugs are often kept secret so you dont know that someone has you just have to trust the project that it really is a dupe. Its one of the main reasons why sec bug bounties are unfair to researchers imo.
Since (2019) we have an externally managed bug bounty program (they have and manage the platform the initial triage of reports and paying the bounties (we decide what is accepted and how high the bounty is), our success rate (actionable reports) has sky rocketed.
Our devs love the reports since these are verified to be 1: documented so well, everyone can reproduce them, 2: scored reasonable (much less in house fighting if it's a low or a critical), 3: simple interaction with the individual who triaged | filed the finding (and eliminating the horrible interaction via 3 or more steps).
The money we spend on the bounties AND the service are easily offset by the quick turnaround times and saved internal struggles & meetings.
The article points out the more strictly technical aspects with which I agree as well, just that to me they are like worrying about pain when you have a bleeding artery.
Perhaps if "design by committee" is one obviously bad end of a spectrum, I propose "designed by bounty program" as another (and I'm not saying that the space here is one-dimensional).
Bug bounty programs on the other hand are excellent, so it also isn't that "bounty" is inherently bad. Discovery vs design.
If that is the case, I missed it.
Cases of "nothing was done because bounties weren't interesting", or "we had a feature bounty program and it done awesome!" are, for the purpose of my analysis and thus opinion formation, only more or less happy exceptions (hypothetical or real).
- Design by lottery (Single winners of a quarterly lottery dictate all decisions for that quarter)
- Design by deliriant (same as design by committee, but all members of the committee must take Datura before making decisions (probably deeply unethical and problematic, but we're going for the worst possible here))
- Design by Anarchy (Literally anyone can commit straight to the main branch without any checks)
- Design by Ouija Board (Committee members MUST consult a Ouija board before making decisions )
- Design by mob (A real-time public forum, accessible to anyone, can propose/vote up or down potential features or code changes. Highest votes within a 24-hour window are implemented immediately. Allows and even encourages raids from random sites like 4chan or corporate entities)
- Design by Dog (Various options are written down on pieces of paper, scattered on the floor, and the pet's choice is determined by whichever piece it first sits or stands on. (In this alternate reality, our dog STILL hasn't decided to patch log4j. God help us.))
- Design by randomly-elected outsourced labor (Decisions are outsourced to the lowest bidder on freelance job platforms, regardless of their experience or skill level.)
These are just the ones I could think of off the top of my head. Lowkey it'd be hilarious to try and build actual software with these, just for fun.
After my communication they banned me from participating in their community (I quote from them "You're not welcome anymore on our GH repo nor any other community managed directly by us.").
For those interested, we moved the sponsorship work to the Wasmer repo, so those who want to work on it can do it freely.
You can't just offer money and rush people for something to get merged in another open source project without even previously discussing it if the authors of that project want it in the first place.
Just my 2 cents.
This was explicitly stated in a comment in the original issue that for some reason the Zig leadership decided to remove
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.
External contributors can’t select the labels of an issue. New issues get automatically tagged.
In the Wasmer repo we can obviously choose the proper label just because we have the permission to do so
At least these lines sounds reasonable:
Examples of behavior that contribute to creating a positive environment include:
- Using welcoming and inclusive language.
- Being respectful of differing viewpoints and experiences.
- Gracefully accepting constructive criticism.
- Helping another person accomplish their own goals.
- Showing empathy towards others.
- Showing appreciation for others' work.
- Validating someone else's experience, skills, insight, and use cases.
A pity the leadership doesn't appear to hold themselves to the same standard.
I didn't have anything but a passing interest in Zig before, but this is a huge red flag about the project.
Any insight on this? How can this possibly be true?
My guess it's probably something minor, like copying a few lines of trivial code or the like, at most.
(Not involved or affiliated with Zig at all, just observed this person's behaviour over a period of many years).
That's a rather large accusation to throw around. What's the context behind this?
But to give one example out of several, at one point they strategically edited and deleted some comments on a small repo of mine (from before GitHub showed you the edit history) when I announced my (completely unrelated) full-time open-source project, to make me seem an asshole to try and get "revenge" for their perceived slight of denying a pseudo feature request ("pseudo" because they were spamming the same kind of feature request to hundreds, if not thousands, of repos).
I've seen this type of thing a few time with this person: an accusation that makes you go "oh wow!" and then you look in to things and it turns out it's either a spectacular exaggeration or outright misrepresentation (i.e. lying). Maybe they're right this time, but I can't even be bothered to look in to it any more.
https://github.com/ziglang/zig/issues/14172#issuecomment-164...
Yes, it's petty stuff.
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.
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
No one can do any work unless the leadership green light seems a bit restrictive
The $5,000 reward did not required the work to be merged upstream. Please read the rest of the thread
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
Good that came out of your behavior, though: I learned that the Bytecode Alliance is just really bad at communicating historically, but has been trying to improve that and actually has been pushing forward WASI preview 2 quite aggressively, making a ton of progress on it.
Someone linked me this roadmap video[0] in which they say:
* WASI Preview 2 ships by the end of the year and is largely usable now
* Two people are working on WASM threads
* VMWare has been working on Garbage Collection in wasmtools, and is working on getting that running in wasmtime
* Components are isolation units for threads, memory space, etc. It means a WASM module can use components without being aware of threads. Components are named, versioned, etc.
* They're considering resource and handle types (I assume for e.g. externalized file handles)
* Once WASM GC moves forward, it will also go into components.
* WASI sockets, WASI HTTP, clock, filesystem, RNG are all in scope for WASI preview 2 around Fall.
* wasmtime and a JS web implementation are in scope, so two implementations of all this.
Sounds quite promising compared to what was happening in the past! Now I wonder why WASIX is a thing instead of pushing forward with WASI given they've been changing for the better?
A lot of positives came out of it, and it did improve framework quality. There are challenges with the model though. More changes than not are high quality, but some aren’t, or are just inherently risky, and it’s especially tricky to discern when first time contributors touch systems that might no longer have an active maintainer. Unlike someone employed full-time, there isn’t the opportunity to establish long term trust, and the contributor might not be around to support their change if something goes wrong.
A lot of changes fell through the cracks, or needed maintainer time that wasn’t there, which creates a bad situation where someone could have done great work, but isn’t getting paid. Knowing that someone is losing money if you don’t accept a PR can also trend towards guilt-inducing as a maintainer.
That's my experience with bounties: someone does the job because they get paid, not because they have a particular interest in the issue, and then they instantly move on, leaving the submission to rot.
I agree with ZSF here.
We reached out to the primary contributor and offered them money to fix. They countered with a largish donation to the project, we agreed and 5am the next morning there was a patch that got us up and running.
Not sure a bounty would have helped us here.
These were once very popular in form of "we support oss in general, you can get $10 if you get any PR merged to any of these projects"
But, oh man, that “get a PR merged” campaign was a disaster.
The project and contributions required a high degree of skill. And it also wasn’t a super popular project so it didn’t attract a lot of competition.
Then it really feels like working for free as opposed to helping some obscure library.
If the task would get absolutely zero attention without a bounty --- what cooperation?
Conversely, in a situation in which an an external party is motivated to work on something for free, let alone multiple external parties, why would you think about throwing money at it?
For the second question: you may wish to increase time allocation to a project. Showing up with a fat wad of cash doesn't guarantee something can be done faster but if it'd make a bounty do it faster it'd almost always make the standard development process faster too.
The last point is also similar. If I get a significant contribution in area where I'm not competent, I might take it, but is it going to maintain or fix problems to it in the long term? I'd rather not include a feature which I know I can't maintain long term.
Andrew is not arguing against people paying for specific features/work. He is arguing against 1) not coordinating that work with the core team 2) competitive 'first correct submission wins'
To the contrary, the article explicitly called out bug bounties as making more sense.
Sometimes things are boring because nobody really is interested in the results, but i think that is a diferent kind of boring. Sometimes maintainers are overworked and cant do everything, but that is also a different sort of problem.
The fact that pretty much all open source software right now is passion projects means that people are pretty free to aim at ideals, throw things out and iterate/try new ideas. I think open source as we know it exists because there's no money, but it's also limited in scale, and you still need to depend on companies like windows, adobe, google, etc because development just can't reach that scale.
Adding money could absolutely destroy the current good things, but it's also totally possible that the good things could persist while making more projects viable. My dream is to work on useful open source libraries during the day so I can work on fun stuff, art, games, etc. I intend to build from those in my free time, rather than work on the libraries in my free time. But I get that people are scared of losing what we currently have. I don't think we'll know without giving it a go (obviously there are other obstacles to this too, like accounting, taxes, legal questions, etc).
Back to the article, I feel like it's making sweeping arguments about a very specific implementation of bounties. AFAICT what happened leading up to this is
- WASIX put out a bounty for WASIX implementations in other software
- Some people started rolling forward with it in the Zig bug tracker, WASIX (?) publicizes this on twitter/reddit
- Zig maintainers said no
- Debate in the issue tracker
- Zig maintainers said no more discussion
- Bunch of deleted messages
I might have missed something. It seems like the main reaction is about Zig's name being used for WASIX promotion/a 3rd party trying to exert control over Zig development, which doesn't entirely seem related to the bug bounty or bug bounties in general. WASIX put out the bounty and did the publication, they're a bad actor and this could have happened largely the same way entirely without the bounty too.
The points in the article don't seem related to bug bounties. Highlighting a few:
> you end up with a quickly bitrotting artifact
This happens with all MRs, bounty or not. "Upstreaming" is an implicit contract where you write something you want per the maintainer's specifications and in exchange they maintain it afterwards.
> Instead of scouting for a suitable candidate, you’re letting battle royale dynamics pick a winner for you
Non-bounty issues frequently have people taking them who aren't capable of producing a mergeable solution. I'm not sure why a bounty would make this worse - you could easily argue that in order to get the payout people would be more careful to take work they can actually complete, or that people who are capable are can now afford to devote their time to it.
> You instead penalize any form of thoughtfulness in favor of reckless action (eg a solution just needs to pass a test suite)
The maintainers decide whether something gets merged or not, and I've never seen a project that says "We'll merge anything that passes our test suite". Maybe I missed something here...
> Instead of spreading unease to all the people involved, it would be preferable you instead learned how to do business properly.
This feels like an attack directed at the WASIX people and not a general statement.
That said, there's very very little bounty driven development ATM. I think it's hard to extrapolate consequences at this point in time.
Not exactly, the main issue we have with this thing is that it's a process that in the blink of an eye had multiple Zig contributors do duplicate work to implement a PR under implicit conditions that are completely skewed against the individuals.
The Zig project has spent a lot of time and effort in growing a community of contributors that is respectful and collaborative, and we don't appreciate startups trying to turn our community into Mad Max, especially when the same exact amount of money could have been used to move the endeavor forward in a more sustainable way.
It would have been trivial to post an offer to pay for have that PR implemented, interview a few candidates, pick one, offer a contract and have the PR delivered after the contractor maybe even takes a moment to polish it past "passing a test suite", on top of it being a nice starting point for a potential continued collaboration for eventual follow ups.
Instead we got duplicated efforts, stress and ultimately everything would have resulted in a rushed PR that then most probably would have been on us to clean up and maintain going forward.
Our way of leading development is more sustainable and one big reason why we have such a big contributor community.
We're not going to let startups burn our contributor community so that they can squeeze one extra tweet out of their moat-building efforts.
We do have a roadmap and a series of priorities so adding new platforms is not our first priority right now.
That said, interacting with the Zig project is not just a matter of code. Software development, especially when it comes to open source, happens as a result of a delicate social process, and the impact on our contributor community does factor in our decision making.
https://www.w3.org/community/webassembly/
Its true that many of those companies are also members of the Bytecode Alliance. But the W3C community group is where actual specs and standardization happen. That's where votes occur, and that's the Github organization in which they are published, and so forth.
What's trivial about posting an offer, interviewing candidates, picking one, and making a contract?
Maintainers may not want to determine who gets to feed their family, by choosing which contribution gets merged (either by deciding between competing implementations, or deciding which contribution to review). That's even more extreme than typical management tasks like bonus allocation.
Maintainers might also be worried that it turns open-source development in to a gig economy, with all the resulting problems. The Zig developers seem to alude to this, too.
I'm not sure if open source in general has a funding problem. The corporate takeover started in the mid-90s, and is fairly complete by now. If you look closely at some of the often-quoted examples for serious underfunding, it's more about disputes about prioritization, such as long term, bug-for-bug compatibility support vs ongoing development.
Aren't they making such a determination already by disallowing bounties altogether?
The goal is to be ridiculously FOSS and require companies to do the same in order to use your project. If they don't want to embrace the copyleft aspect, they can purchase an exemption from it (see https://yaml8n.dev/pricing/ for an example).
In this model, the FOSS ecosystem can still thrive and build off of each other, and projects can negotiate license exemption to help sustain themselves.
You can write a license that has any kind of requirement in order to use it, such as "you must stand on one foot while using this software". If they don't agree, they can't use the software, and you can take them to court saying they aren't meeting the requirements of the license and must stop using the software.
When writing a license, or any kind of contract, you need to balance your rights and the folks using it. Licenses like MIT rob the creator of their rights, and no license gives the user no rights.
No offense, but you might want a better lawyer if you don't think there is such a thing as an unenforceable software license. At a bare minimum, consider a license that requires committing a crime in order to be compliant with the license. And copyright law and contract law are far more complex than just that.
Creator Of Zig Leaves Twitter and Reddit | Prime Reacts https://youtube.com/watch?v=8nxrHLQ_YQk
Reminds me of the GrapheneOS saga
Both great projects. Zig looks like one of the most promising languages
Maybe bounties are not ideal, but the entire open-source financing/collaboration model is still a bit green in general
2) the project never created or rewarded an open source development bounty
3) the post promotes bug bounties from a platform written in Zig that sponsors Zig
seems legit
There's also an experimental use case where FOSS users themselves create bounties to pay contributors/maintainers to ship new updates and features. We call these 'community bounties'. The $5,000 WASIX support bounty in Zig was created by Wasmer, but the Zig maintainers didn't welcome it (which is totally fair, it's their choice) and this blog post is a rant about it I guess?
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.
But also, one aspect largely absent from the original blog post is the financial sustainability of being an open source developer. While the love for the craft and the mission to Escape Big Tech might be enough to fuel initial enthusiasm, the reality is that developers need to eat, pay bills, and sustain their lives. If someone aspires to be an open source developer as a primary occupation, financial backing becomes non-negotiable. Bounties, donations, and sponsorships serve this very purpose—they are not just incentives for competition, but also a means for livelihood. Rejecting these financial channels out of an idealistic vision of cooperation is not just impractical but dismissive of the economic pressures that developers face. Let’s not forget, FOSS is an open market where both ideas and resources should flow freely. Monetary incentives can co-exist with the altruistic goals of the community. It’s a balancing act, but one that serves both the ideological and material needs of the FOSS world. For those of us aiming to Escape Big Tech, these financial pathways are not just welcome; they are essential.
First, not all zig news gets posted on the official ziglang blog, quite little of it makes it there actually. There's zig.news, stuff gets posted to the discord, there's sycl... quite a lot of news comes through other channels. So the fact that this made it here is intriguing. I'd expect this to be part of an FAQ in on the "Sponsor the ZFS" section, rather than it be news.
Second, development bounties are something that zig has never done. I can't remember of a time that zig offered that. Zig basically spends their money by hiring high value contributors (which I find a great approach).
So, where's the fun drama behind this? I'd love to read it once and then enjoy my Sunday :).
http://farside.link/twitter.com/wasmerio/status/170116830510...
so yeah, I don't like zig and don't care about its people. but to me, the bounty giver shits on zig dudes to put it bluntly.