Get the top HN stories in your inbox every day.
zcesur
syrusakbary
We moved the sponsorship to the Wasmer repository, even though the work will need to be in Zig codebase:
Macha
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.
syrusakbary
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)
undefined
bawolff
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.
throwawaymaths
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.
bawolff
Well i agree with them but for different reasons.
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.
undefined
WelcomeShorty
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.
drbig
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.
swagmoney1606
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.
Valodim
This seems to assume that people actually put up bounties that get any serious amount of work done.
If that is the case, I missed it.
drbig
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).
syrusakbary
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.
laserbeam
I agree with the ban.
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.
guilhas
Don't understand the problem, can't the PRs just be ignored forever or closed?
No one can do any work unless the leadership green light seems a bit restrictive
Macha
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.
syrusakbary
This comment might be insightful: https://news.ycombinator.com/item?id=37545637
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
slimsag
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?
ismailadi
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.
Just my 2 cents.
syrusakbary
It was not required for the PR to be merged upstream for the bounty to be awarded.
This was explicitly stated in a comment in the original issue that for some reason the Zig leadership decided to remove
ismailadi
(you've deleted your previous comment that I replied to)
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.
swsieber
> 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?
arp242
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).
richbell
> 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?
kristoff_it
This is the context that the parent poster is referring to.
https://github.com/ziglang/zig/issues/14172#issuecomment-164...
Yes, it's petty stuff.
mnahkies
Is this surprising? I haven't checked the zig license, but if it's MIT I'd expect any code contributed to the repository to be MIT by extension
tener
The contributors are expected to follow code of conduct: https://github.com/ziglang/zig/blob/master/.github/CODE_OF_C...
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.
bdzr
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.
syrusakbary
Agreed
undefined
dartos
Well… besides your zig drama… why do you disagree?
kyrra
Any more background here about position on this matter is right compared to the zig maintainers?
NickGerleman
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.
templix
> or needed maintainer time that wasn’t there
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.
Ensorceled
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.
Not sure a bounty would have helped us here.
j16sdiz
I think the article was about "outsiders" offer bounty to other "outsiders" to work on arbitrary projects.
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"
Ensorceled
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.
bhouston
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.
HWR_14
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.
matsemann
I think bounties can work. But it's important that the work being bountied comes from the project itself or at least is approved by the maintainers.
countWSS
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.
whatyesaid
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.
kazinator
> 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?
zamadatix
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.
dale_glass
What about bounties for boring tasks nobody is excited to do or where the main team lacks competency in the given area?
patmorgan23
Grants/Sponsorship still exist.
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'
MatthiasPortzel
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.
bawolff
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.
eatonphil
> It seemed to bash bug bounties
To the contrary, the article explicitly called out bug bounties as making more sense.
wakeupcall
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.
bawolff
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.
DishyDev
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
templix
The Zig article specifically says bug fix bounties are different.
rendaw
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.
kristoff_it
> 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.
fdjsfasdhkj
> 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?
kristoff_it
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.
jadbox
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?
kristoff_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.
candiddevmike
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.
HideousKojima
Have you run your license by a lawyer to see if it's legally enforceable?
candiddevmike
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.
fweimer
> 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.
bdzr
> 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?
fweimer
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.
Get the top HN stories in your inbox every day.
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
[1]: https://algora.io
[2]: https://algora.io/bounties/new