[HN Gopher] Bounties Damage Open Source Projects
___________________________________________________________________
Bounties Damage Open Source Projects
Author : ksec
Score : 173 points
Date : 2023-09-17 06:06 UTC (16 hours ago)
(HTM) web link (ziglang.org)
(TXT) w3m dump (ziglang.org)
| kazinator wrote:
| > _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 wrote:
| 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.
| zcesur wrote:
| 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
| syrusakbary wrote:
| We moved the sponsorship to the Wasmer repository, even though
| the work will need to be in Zig codebase:
|
| https://github.com/wasmerio/wasmer/issues/4218
| [deleted]
| lemper wrote:
| 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.
| Ensorceled wrote:
| 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 wrote:
| 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 wrote:
| 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.
| DishyDev wrote:
| 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 wrote:
| The Zig article specifically says bug fix bounties are
| different.
| r053bud wrote:
| It's ok, I prefer to hold on to my 0Days for when I might need
| them ;)
| NickGerleman wrote:
| 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 wrote:
| > 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.
| bhouston wrote:
| 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.
| matsemann wrote:
| 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.
| HWR_14 wrote:
| 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.
| rendaw wrote:
| 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.
| candiddevmike wrote:
| 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 wrote:
| Have you run your license by a lawyer to see if it's legally
| enforceable?
| candiddevmike wrote:
| 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.
| HideousKojima wrote:
| > Why wouldn't a license be enforceable?
|
| 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.
| [deleted]
| fweimer wrote:
| > 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 wrote:
| > 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?
| kristoff_it wrote:
| > 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.
| jadbox wrote:
| 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 wrote:
| 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.
| epilys wrote:
| WASIX is not even a standard by the Bytecode Alliance,
| which makes the webassembly specs.
| brighteyes wrote:
| To clarify, WebAssembly specs are made by the WebAssembly
| W3C community group here:
|
| 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.
| fdjsfasdhkj wrote:
| > 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 wrote:
| 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.
| drbig wrote:
| 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.
| Valodim wrote:
| 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 wrote:
| 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).
| dale_glass wrote:
| What about bounties for boring tasks nobody is excited to do or
| where the main team lacks competency in the given area?
| wakeupcall wrote:
| 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.
| patmorgan23 wrote:
| 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 wrote:
| 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.
| eatonphil wrote:
| > It seemed to bash bug bounties
|
| To the contrary, the article explicitly called out bug
| bounties as making more sense.
| bawolff wrote:
| 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.
| bawolff wrote:
| 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.
| zcesur wrote:
| 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?
|
| [1]: https://news.ycombinator.com/item?id=37457921
| capableweb wrote:
| Maybe it's worth responding directly to the criticism from Zig
| rather than calling what they are saying a "rant".
|
| Actually, since you don't address anything in your comment, one
| could call that one a "rant" as well.
| Macha wrote:
| 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
| zcesur wrote:
| > competition at the expense of cooperation
|
| 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.
| kristoff_it wrote:
| > > Instead of scouting for a suitable candidate
|
| > 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.
| fdjsfasdhkj wrote:
| Have you ever heard about transaction costs?
| zcesur wrote:
| Can you show me the 10 people that made duplicate work?
| kristoff_it wrote:
| 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:
|
| https://twitter.com/wasmerio/status/1701168305103331701?s
| =20
| zcesur wrote:
| 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
| bdzr wrote:
| 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.
| tpmoney wrote:
| 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.
| ayewo wrote:
| 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.
|
| Zama runs a big-ticket bounty program that is worth
| emulating in how it is run https://github.com/zama-
| ai/bounty-program
| zcesur wrote:
| 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
|
| [1]:
| https://twitter.com/algoraio/status/1703115434055082086
| ayewo wrote:
| Yes, exactly.
|
| 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.
| bawolff wrote:
| 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 wrote:
| 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 wrote:
| 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.
| [deleted]
| irf1 wrote:
| 1) clickbaity title
|
| 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
| laserbeam wrote:
| 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 :).
| wyldfire wrote:
| The "Support WASIX" [1] link shows up there, that's what led to
| this.
|
| [1] https://github.com/ziglang/zig/issues/17115
| laserbeam wrote:
| Can't believe I didn't spot that X_X
| [deleted]
| 38 wrote:
| It's literally the second sentence of the article
|
| http://farside.link/twitter.com/wasmerio/status/170116830510...
| laserbeam wrote:
| Yeah, I screwed up at "reading". Thanks X_X
| countWSS wrote:
| 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 wrote:
| 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.
| guilhas wrote:
| I am starting to think that the Zig leadership has some trouble
| with community management/collaboration
|
| Creator Of Zig Leaves Twitter and Reddit | Prime Reacts
| https://youtube.com/watch?v=8nxrHLQ_YQk
|
| Makes me think 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 immature in general
| [deleted]
| syrusakbary wrote:
| 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.
|
| https://github.com/wasmerio/wasmer/issues/4218
| hypfer wrote:
| You could also like.. just respect the maintainers of zig
| instead of doubling down on this abusive behavior, y'know?
|
| That could help with not getting banned.
| richbell wrote:
| > You could also like.. just respect the maintainers of zig
| instead of doubling down on this abusive behavior, y'know?
|
| What about their behavior is abusive?
| hypfer wrote:
| 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.
| [deleted]
| kyrra wrote:
| Any more background here about position on this matter is right
| compared to the zig maintainers?
| tener wrote:
| 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 wrote:
| 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 wrote:
| Agreed
| ismailadi wrote:
| 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 wrote:
| 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 wrote:
| (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.
| syrusakbary wrote:
| Have you tried creating issues on the Zig repo?
|
| 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
| swsieber wrote:
| > 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 wrote:
| 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).
| kristoff_it wrote:
| This is the context that the parent poster is referring to.
|
| https://github.com/ziglang/zig/issues/14172#issuecomment-16
| 4...
|
| Yes, it's petty stuff.
| richbell wrote:
| > 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?
| arp242 wrote:
| 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.
| mnahkies wrote:
| 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
| laserbeam wrote:
| 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.
| [deleted]
| ismailadi wrote:
| [dead]
| guilhas wrote:
| Don't understand the problem, can't the PRs just be ignored
| forever?
|
| No one can do any work unless the leadership green light
| seems a bit restrictive
| syrusakbary wrote:
| 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
| dartos wrote:
| Well... besides your zig drama... why do you disagree?
| slimsag wrote:
| 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?
|
| [0] https://www.youtube.com/watch?v=Yl_O95zOJbs
| [deleted]
___________________________________________________________________
(page generated 2023-09-17 23:02 UTC)