Hey HN, I'm one of the creators of the tool [1] that was used to post this bounty
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
This seems to have all the same issues of pressuring the maintainers to accept your feature by making them responsible for denying a payout to a third party, even if the feature doesn't fit their codebase.
Honestly, continuing this push, more than anything else in the events so far, makes me distrust wasmer's intentions.
Have you read the issue and other comments on this thread?
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)
They deleted all the comments regarding the bounty. So "for some reason" seems to be as stated in the issue tracker:
> [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.
Stating “for some reason” is simply a way to reinforce my full disagreement with the decision of deleting comments, as I don’t think it was the right one.
Sorry if that was not clear
So I mean what I'm about to say completely sincerely. I don't know if english isn't your first language, if you have a completely separate cultural background, or you fall into a neuro-divergent category that presents problems with communication. I get that the english language is full of idioms and unstated assumptions, and further that text online communication lacks the tone and body language cues that make reading some of those side channels harder. Regardless, you seem to have a lot of communication mis-steps and moments of being "not clear", around this and other problems that have come up with your company in the past.
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.
I think you laid out very well one of the issues of the last century in the western culture: PR as a way to help shape the reality rather than accountability through transparency.
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
I'm not even sure how to respond to this other than by pointing out that it's a perfect example of your terrible communication skills. I'm telling you that you take a common phrase like "for some reason" which any reasonable person would at best interpret as a genuine lack of known reason, and more likely (both because of the medium, and your generally hostile tone) as a snarky implication that there's something nefarious going on, and you claim that you meant it as a general expression of disagreement. I'm fairly confident that no one hears "for some reason" and translates that to "I completely understand and acknowledge the stated reasons and disagree that they are right". I'm giving you the benefit of the doubt and assuming that you have a reason to – consistently, over months and multiple "incidents" – have these sorts of "misunderstandings", and am suggesting that you do something to make sure your communications are clear, or otherwise stay out of doing the communicating. I even noted that your goal of transparency was laudable, but that you weren't actually accomplishing what you thought you were.
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.
> and am suggesting that you do something to make sure your communications are clear
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
In a previous job i helped manage a security bug bounty program.
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.
Tfa specifically excludes security bounties because there are often multiple security bugs, it's a discovery bounty and not a "compete for this one thing" scenario.
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.
The "99% of reports were incoherent garbage" is exactly what I become from unsolicited sources. They come mainly in via our (security.txt) email.
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.
I have always been of the same opinion, which I formed years ago helping with Cataclysm: Dark Days Ahead development: "development by bounty" leads to inevitable "(un)designed by a whale", i.e. a few with cash to spend on such things enforcing whatever they _feel they will like_ on everybody else. The notion of a coherent whole, whether it's a game or anything else, doesn't really go well with "voting with wallets".
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.
Your comment posed a very interesting question to me, so I took the time to think of some other points in this multi-dimensional space of terrible software engineering. Here are some other terrible design systems:
- 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.
Yes. It assumes the asymptotic end condition, because to me that is the only reasonable way to judge such policies.
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).
I didn't really either way. Which given a) how long ago that was and, b) I specifically declined to look at bounties - the only thing I'm close to being sure about is that I don't remember any drama nor ruin from that.
I respectfully disagree with the take that Bounties damages Open Source Projefts, which I also respectfully communicated to the Zig leadership team.
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 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.
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.
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
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
I'm glad your communication with them in the aftermath was respectful.
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?
Sorry, but in my opinion you are in the wrong here.
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.
> also to anyone reading this. DONT POST any code to Zig issue tracker. post it to your own repo, and link to it if need be. any code you post to the tracker becomes MIT license, which I learned the hard way.
Any insight on this? How can this possibly be true?
Meh, weird accusation from a known bad-faith troll with a history of misrepresenting facts (i.e. lying) to make weird accusations and more sockpuppets on the internet than I have socks.
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).
> Meh, weird accusation from a known bad-faith troll with a history of misrepresenting facts (i.e. lying) to make weird accusations and more sockpuppets on the internet than I have socks.
That's a rather large accusation to throw around. What's the context behind this?
To be honest I kind of regret my previous comment as I don't really want to bring up heaps of drama here, and also I can't be bothered to go looking for all sorts of links (constantly having GitHub accounts banned means its actually quite hard to do that unless you keep links around, which I don't; they always have the same profile picture so it's easy to spot). OTOH, it's also some important context I guess...
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.
The deleting of half the comments is what's really irritating IMO. Go ahead and lock the thread, ban people if you don't want bounty discussion, but leave the history intact.
This person is a third-party who runs a company that does X.
In an effort to push X and in turn their company and their personal financial gain, they decided to go to the issue tracker of an open-source project, demanding that X should be implemented because it's important to do so.
It was never an "Hey, I have this thing and maybe it would be a good fit for Zig". Instead it was an "This needs to be done."
But that's just regular foss nonsense.
Where this turned into something different is when the person - only 15 minutes after creating that feature request labelled as a bug - started a $5000 bounty for people to implement X.
The maintainers never agreed to having X in the first place. They were never even consulted, given that the author didn't ask if X could be implemented. There was never a question. It was an attempted hostile takeover of the direction of the project.
But the worst part of it is that this person wasn't even going to do the maintainer-harrassing all by themself. No, they're a smart one. They know that if they trow out a bounty of $5000, a lot of naive and unsuspecting useful idiots will jump in and apply pressure to the zig maintainers for them.
Tbh I think it's quite clever to perform such an amplification attack to force your way into a project. It would probably also be just business as usual in a business context with different commercial entities competing with each other.
But as always, people don't understand that foss projects usually do not take part in that rat race and therefore never consented to playing games with morally questionable tactics like these.
A company using React Native recently used bounties to solicit bug-fixes to RN issues their app was hitting.
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.
Years ago we had a pretty critical issue in an open source project that we were dependent on. I looked into fixing it but it was pretty complex to even figure out the real cause.
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.
Bounties are offered to the community at large and can be jumped on by anyone. I think a “bounty” that is offered just to the current contributors is less of an issue.
But, oh man, that “get a PR merged” campaign was a disaster.
I done bounties on some open source projects and it worked out well. The contributors made great contributions and the owners of the projects reviewed them. It was a great way of getting a project to move faster.
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.
I think a lot of their issues with bug bounties only apply if the project is pretty popular. If it increases the number of developers working on an issue/feature from 0 to 1, that's a win. Their analysis is why it's bad to go from 1 to many.
Its probably distracting them from rapidly
developing features. In stable projects its a much more
better incentive to get programmers focus via
some gamification techniques like bounties/prizes/competitions.
Open source projects usually stagnate without
some "competitive" incentives, because its feels like working for free.
Agreed, because nowadays big open-source projects are backed by sponsors (users, other companies) or have revenue streams (e.g. like Obsidian although that's closed).
Then it really feels like working for free as opposed to helping some obscure library.
> Bounties foster competition at the expense of cooperation.
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?
I think the article does a good job in then showing ways it's not necessarily that the act of funding something removes existing cooperation in all cases, rather of the ways to fund something holding a bounty will foster competition at a loss of not fostering cooperation instead.
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.
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'
I wish the original post had explained this better. It seemed to bash bug bounties without offering any alternative, except “employing well-designed business management processes.” Which is not a helpful statement unless you already agree with the authors.
I feel its unfair to expect people to have a solution just because they are discussing a problem. Just because something doesn't work doesn't mean a fix is obvious or one even exists.
From by my own experience, you'll have to review/test the boring task from a one-time contributor, which is also not fun. You don't need to do that as often if the contributor is going to stay, but you're not attracting this sort of contributions with bounties.
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.
In my experience its rare for there actually to be boring useful tasks in open source. Everything is interesting to someone.
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.
I've had a good experience doing a couple of bug fix bounties for urllib3 https://github.com/urllib3/urllib3/issues . I'd be interested in how the maintainers how found running the bug bounty and if it's given them more useful fixes or if it just adds more noise to deal with
So... just to get it out there, I really want to see more funding in open source development.
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.
> 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
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.
> 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
What's trivial about posting an offer, interviewing candidates, picking one, and making a contract?
You're right, it's not trivial, I take that back. It requires some effort from the company that is interested in having the work done, but why put that effort when you can toss 5k in the ring and watch the best candidate self-select at the expense of everybody else who lost.
Thank you for the additional context. Is there any issue in principal with Zig supporting WASIX in the future (in a sustainable fashion)? Or is there any technical debate to just not support it?
Generally speaking we're open to support all kinds of platforms going forward.
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.
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.
I am testing a solution to the problem of funding open source through a custom license based off the AGPL, the Candid Public License: https://github.com/candiddev/cpl
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.
Yes? I had them help me draft it. Why wouldn't a license be enforceable?
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.
> 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...
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.
> 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).
Aren't they making such a determination already by disallowing bounties altogether?
No, the would-be contributors could work on something else. That's no longer about preferring contribution X from would-be contributor A over would-be contribution Y from non-contributor B.
I'm in charge of managing the community and what you're seeing here is a reflection of the fact that we care about our community and that more in general we know how to play the open source game.
These projects [1] would disagree. This year 498 bounties ($53,410) have been rewarded to 166 contributors from 45 countries, they were funded primarily by commercial open source founders/maintainers
to support product & devrel (get more work done, grow community, reward contributors, gain visibility).
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?
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.
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.
You can see in the archived thread you yourself linked that 3 people are working on it in parallel while a 4th who was interested in doing the work states that they don't want to participate in a battle royale.
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:
I don't think people discussing approaches, asking questions & looking to collaborate is battle royale. In healthy-enough OSS projects that happens with or without bounties
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
I think there are 2 dynamics that Andrew Kelley alluded to that Algora / Wasmer could have addressed better:
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.
Agreed on all 3 points here, thanks for sharing your thoughts, super helpful
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
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.
It's not worth arguing. The irony of all of this is that free labor is welcomed in the open source world, but if a carrot is offered it's somehow evil and consenting adults need to be protected from themselves.
I think it's less that a carrot is offered and more than carrots can be more or less harmful to the project as a whole and the developers both maintaining the project and working for the carrot depending on how the carrot is offered. ZSF seems plenty happy to pay people for work. They also seem plenty happy with companies that are employing people that do work with and for Zig. The complaint here is about a form of payment that amounts to encouraging developers to race against time and each other to complete a specific task, rather than actually take the time to do work that has been prioritized and vetted.
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.
I thought we would have learned for platforms not to facilitate bounties for non-participating projects after the tip4commit/mitsuhiko drama of years past: https://github.com/tip4commit/tip4commit/issues/127
Kelley and Cro argue that bounties foster competition at the expense of cooperation. But isn’t it through competition that we Escape Big Tech’s clutches? Without competition, we’d all be slaves to the monopoly of Big Tech, a corporate monolith driven by surveillance capitalism. Competition brings innovation and diversity, giving each of us the tools to fight against centralized power. Bounties create an environment where developers are incentivized to solve problems creatively and help users Escape Big Tech through faster development and better solutions. Cooperation and competition can coexist. In fact, they must coexist if we are to Escape Big Tech. The FOSS community is not a utopia; it’s a battleground. And in a battle, we need all the weapons we can get. Bounties are one of those weapons.
The FOSS space thrives when there is a race—not just against time, but against mediocrity. Bounties create an environment where developers are incentivized to push their boundaries, leading to faster development cycles and better software solutions. To argue against this is to undermine the essence of free-market capitalism, a realm devoid of governmental intrusion and packed with individual liberties.
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.
I'm curious what led to this article. I don't disagree to the contents, but the story that led to it sounds more interesting and now I want to read about it.
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 :).
other people have said that it's a different things compared to "anyone who fixes this problem in this free software, I will give them certain amount of real world monies." what happened in the article is: "anyone who implements our product in this free software, I will give them certain amount of monies. I haven't talked to the maintainer of this free software whether our product has net benefit or not to this project, though. so you have to fight your way against the maintainer to get it implemented."
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.
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
[2]: https://algora.io/bounties/new