[hackcasual]

> Q: What if the maintainers won't accept the patch?

> A: The Fish in a Barrel Memory Safety Bounty only rewards contributions that are merged upstream. We strongly encourage people interested in pursuing a bounty to work with, not against, open source maintainers and to behave respectfully.

It's good to see this called out specifically, but I can't help but think this is attaching a monetary incentive to badger a project to accept a patch that at the very least requires changes to the project build system

[Arnavion]

>Partially (or completely) migrate the project to a memory-safe language (e.g., convert one of the decoder/encoders in an image parsing library to Rust)

For this kind of contribution, I'm not sure there'll be too much spam. Eg most of the "Rewrite It In Rust"-kind of spam like [1] is people making suggestions, not actual PRs, because it does actually take effort. But...

>Add bindings making the library usable from Rust or Swift (e.g., adding official Swift bindings to an image parsing library)

... I'm not sure about this one. It could be as mindless as "just run bindgen on the C header, wrap it in a -sys crate" and send a PR. I don't actually understand why that kind of contribution is being awarded though, since having safe bindings doesn't make the actual library any safer. Furthermore, bindings don't need to be contributed to upstream, just like all the Rust bindings libraries today are mostly third-party.

[1]: https://www.postgresql.org/message-id/CAASwCXdQUiuUnhycdRvrU...

[reaperhulk]

Making more things accessible via memory safe languages allows people to more easily transition to those memory safe languages even if they have dependencies that are not themselves memory safe. Boiling the ocean is impractical and memory safety is not all or nothing, so we're interested in encouraging people to find ways to migrate larger and larger pieces.

That said, we will consider level of effort as a component of our judging process when determining eligibility and bounty size.

[Arnavion]

>That said, we will consider level of effort as a component of our judging process when determining eligibility and bounty size.

I hope for your sake that you do, but just to be clear I don't think anyone in this thread is too concerned about whether you pay out the bounty or not. You can be as loose or as tight with your money as you'd like :)

The concern is from the point of view of the maintainers who will receive spam PRs / patches. Even if you don't pay out for that contribution, it will not unsend the PR / patch in the maintainer's mailbox.

[jentist_retol]

It's $100-$500, that's not even a moderate amount of money for the amount of work required. It seems to me to be more of an incentive, and a nice reward for doing good work that helps people.

[kingkilr]

Those of us who organized this both have a long history of involvement in open source. If we have even an iota of this becoming a problem, we will a) be incredibly saddened, b) figure out how to restructure the rules to address the behavior we see.

[Arnavion]

Maybe make it a requirement that the contribution PR / email has to mention https://github.com/fishinabarrel/bounty so that maintainers know who to give feedback to.

[saagarjha]

Right, there a lot of projects that value the fact that their project builds on a lot of platforms, and that they can support old or strange systems that many memory-safe languages do not target (or only do so "unofficially" with some third-party fork of varying quality). I have met a lot of people who brush this off as "yeah but why should we care about those crufty old things, nobody uses them" but such an attitude does not endear itself well.