Setup bounties for directed development #569

Closed
opened 2026-02-06 19:50:43 +03:00 by OVERLORD · 7 comments
Owner

Originally created by @manetherenio on GitHub (Apr 6, 2019).

Can you consider setting up a bounty system for certain larger features through something like Bountysource? Your OpenCollective funding system seems to work well with ongoing development costs, but large one-time costs like making a new client app might be better served by a bounty system.

In particular, I'd like to financially support getting the Roku channel/client app officially published on the Roku store. I'm sure there are certification fees and other expenses that would make official publication low on the list of priorities unless there were a pool of money dedicated specifically to that effort.

Originally created by @manetherenio on GitHub (Apr 6, 2019). Can you consider setting up a bounty system for certain larger features through something like Bountysource? Your OpenCollective funding system seems to work well with ongoing development costs, but large one-time costs like making a new client app might be better served by a bounty system. In particular, I'd like to financially support getting the Roku channel/client app officially published on the Roku store. I'm sure there are certification fees and other expenses that would make official publication low on the list of priorities unless there were a pool of money dedicated specifically to that effort.
Author
Owner

@anthonylavado commented on GitHub (Apr 6, 2019):

Gonna call in @jellyfin/core here for the rest of the opinion. What follows is mine.


We don’t have anything against people setting up bounties of their own if they choose, but we have thus far decided not to “officially” do so. We thought about it for a while, and were concerned with the idea of how we would value people’s time.

It’s not to say that we would never do it ever, but it’s a tricky situation - other contributors have given up so much of their time and effort, I would want to reward them first before putting up a reward for another area.

@anthonylavado commented on GitHub (Apr 6, 2019): Gonna call in @jellyfin/core here for the rest of the opinion. What follows is mine. --- We don’t have anything against people setting up bounties of their own if they choose, but we have thus far decided not to “officially” do so. We thought about it for a while, and were concerned with the idea of how we would value people’s time. It’s not to say that we would never do it ever, but it’s a tricky situation - other contributors have given up so much of their time and effort, I would want to reward them first before putting up a reward for another area.
Author
Owner

@anthonylavado commented on GitHub (Apr 6, 2019):

Also - just to add - we don’t have anything against spending money on certification/publishing costs/licensing as needed. The issue is even having the app to begin with. Apparently BrightScript coders are hard to come by 😅

@anthonylavado commented on GitHub (Apr 6, 2019): Also - just to add - we don’t have anything against spending money on certification/publishing costs/licensing as needed. The issue is even having the app to begin with. Apparently BrightScript coders are hard to come by 😅
Author
Owner

@anthonylavado commented on GitHub (May 6, 2019):

Closing this, as the original request has been answered...
also: https://github.com/jellyfin/jellyfin-roku

@anthonylavado commented on GitHub (May 6, 2019): Closing this, as the original request has been answered... also: https://github.com/jellyfin/jellyfin-roku
Author
Owner

@joshuaboniface commented on GitHub (May 6, 2019):

I never did leave my "official" stance here, so might as well so it's out there somewhere.

I'm against the idea of Bug bounties officially for the project. As @anthonylavado said, we don't actively stop anyone from trying to create them but we won't endorse them.

My main reason for being against them is simple: I don't like the idea of prioritizing features just because one or more people are able to throw dollars behind them. Basically, I think it's the wrong incentive for a project with the philosophy and goals we have. More specifically:

  1. This privileges users with money to spare over those who don't, which I'm generally not a fan of - all features should be treated equally, or at least treated based on the overall needs of the project, rather than specific features for niche usecases that happen to have a bounty out.

  2. They're not really compatible with the "doocratic" methodology we're striving for: we want to encourage people to work on features they use themselves and make them good - bounties on individual features tend, in my experience, to lead towards shoddy implementations that "work" today to collect the bounty, but make the software as a whole more unmaintainable - too much "oh I'll implement this terrible hack because $$$" already exists in this software because this is precisely how Emby operated, and that's a philosophy we're not intent on continuing.

  3. It ruins our internal attempts to prioritize things, as much as we can within the "doocracy", by putting a big "implement this now" sign over the feature. It's one thing if this is unofficial, but trying to do so in an official capacity just screams "this is what's important to work on because $$$", while less glamorous parts of the codebase go ignored.

We're fundamentally, and explicitly, a volunteer project that is free as in beer as well as free as in speech, always - that's the philosophy we want to explicitly follow to differentiate ourselves from Plex and Emby, both of which started as "oh yea we're FOSS" but with long-term ulterior motives to take themselves closed for the benefit of the owners. Now I'm not going to say that there's a straight jump from "bug bounties" to "taking the software closed", but the "give us money to do X or Y" mentality is a critical part of that philosophy and our rejection of it helps, in my opinion, to define us as something different - community maintained, community focused, and free.

If you do want to send money our way to help out with infrastructure, feel free to check out our OpenCollective which helps cover app store licenses, VPSes, domains, Patrons (for OMDB), etc. Or simply use Jellyfin, tell people about it, and help report issues/bugs/feature requests - this is one of the best things a normal, non-coder can do to help us out. There are so many niche usecases that having a huge userbase helps us find bugs faster and get them fixed properly!

@joshuaboniface commented on GitHub (May 6, 2019): I never did leave my "official" stance here, so might as well so it's out there somewhere. I'm against the idea of Bug bounties officially for the project. As @anthonylavado said, we don't actively *stop* anyone from trying to create them but we won't endorse them. My main reason for being against them is simple: I don't like the idea of prioritizing features just because one or more people are able to throw dollars behind them. Basically, I think it's the wrong incentive for a project with the philosophy and goals we have. More specifically: 1. This privileges users with money to spare over those who don't, which I'm generally not a fan of - all features should be treated equally, or at least treated based on the overall needs of the project, rather than specific features for niche usecases that happen to have a bounty out. 2. They're not really compatible with the "doocratic" methodology we're striving for: we want to encourage people to work on features they use themselves and make them good - bounties on individual features tend, in my experience, to lead towards shoddy implementations that "work" today to collect the bounty, but make the software as a whole more unmaintainable - too much "oh I'll implement this terrible hack because $$$" already exists in this software because this is precisely how Emby operated, and that's a philosophy we're not intent on continuing. 3. It ruins our internal attempts to prioritize things, as much as we can within the "doocracy", by putting a big "implement this now" sign over the feature. It's one thing if this is unofficial, but trying to do so in an official capacity just screams "this is what's important to work on because $$$", while less glamorous parts of the codebase go ignored. We're fundamentally, and explicitly, a *volunteer* project that is *free as in beer* as well as *free as in speech*, always - that's the philosophy we want to explicitly follow to differentiate ourselves from Plex and Emby, both of which started as "oh yea we're FOSS" but with long-term ulterior motives to take themselves closed for the benefit of the owners. Now I'm not going to say that there's a straight jump from "bug bounties" to "taking the software closed", but the "give us money to do X or Y" mentality is a critical part of that philosophy and our rejection of it helps, in my opinion, to define us as something different - community maintained, community focused, and free. If you do want to send money our way to help out with infrastructure, feel free to check out [our OpenCollective](https://opencollective.com/jellyfin) which helps cover app store licenses, VPSes, domains, Patrons (for OMDB), etc. Or simply use Jellyfin, tell people about it, and help report issues/bugs/feature requests - this is one of the best things a normal, non-coder can do to help us out. There are so many niche usecases that having a huge userbase helps us find bugs faster and get them fixed properly!
Author
Owner

@pktiuk commented on GitHub (Apr 25, 2024):

@joshuaboniface

I think bounties are a really good idea, when properly implemented. (I started a Discussion about it here: https://github.com/jellyfin/jellyfin/discussions/11428 because I was not aware of this issue)

bounties on individual features tend, in my experience, to lead towards shoddy implementations that "work" today to collect the bounty, but make the software as a whole more unmaintainable - too much "oh I'll implement this terrible hack because $$$" already exists in this software because this is precisely how Emby operated

But you will be still in charge and quality of accepted changes will still depend on your agreement. People willing to provide low-effort changes to grab cash will not be accepted.

It ruins our internal attempts to prioritize things, as much as we can within the "doocracy", by putting a big "implement this now" sign over the feature

You are not obligated to work firstly with issues with bounty. Bounties should be meant for new collaborators from outside. You can still prioritize groundwork while still allowing some people (users) to incentivize other people (freelancers) to implement some features you are interested in.

Most of the problems you mention may come from lack of clear communication about bounties and how they are supposed to work.

In my opinion the main goal of bug bounties is to attract new contributors (not redirecting current ones) and for this purpose I don't see better tools. Big and popular projects seem to have some problems with attracting new contributors and some bounties could help to overcome this entry barrier. Just as you said in one of your blogpost

The larger a FLOSS project gets, in terms of user base, the less likely it is that new developers come onboard, causing the project to stagnate.

Bounties may also help with some problems like availability of jellyfin clients on niche platforms, or fixing some obscure bugs.

@pktiuk commented on GitHub (Apr 25, 2024): @joshuaboniface I think bounties are a really good idea, when properly implemented. (I started a Discussion about it here: https://github.com/jellyfin/jellyfin/discussions/11428 because I was not aware of this issue) > bounties on individual features tend, in my experience, to lead towards shoddy implementations that "work" today to collect the bounty, but make the software as a whole more unmaintainable - too much "oh I'll implement this terrible hack because $$$" already exists in this software because this is precisely how Emby operated But you will be still in charge and quality of accepted changes will still depend on your agreement. People willing to provide low-effort changes to grab cash will not be accepted. > It ruins our internal attempts to prioritize things, as much as we can within the "doocracy", by putting a big "implement this now" sign over the feature You are not obligated to work firstly with issues with bounty. Bounties should be meant for new collaborators from outside. You can still prioritize groundwork while still allowing some people (users) to incentivize other people (freelancers) to implement some features you are interested in. Most of the problems you mention may come from lack of clear communication about bounties and how they are supposed to work. In my opinion the main goal of bug bounties is to attract new contributors (not redirecting current ones) and for this purpose I don't see better tools. Big and popular projects seem to have some problems with attracting new contributors and some bounties could help to overcome this entry barrier. Just as you said in one of your [blogpost](https://www.boniface.me/problems-in-floss-3/) > The larger a FLOSS project gets, in terms of user base, the less likely it is that new developers come onboard, causing the project to stagnate. Bounties may also help with some problems like availability of jellyfin clients on niche platforms, or fixing some obscure bugs.
Author
Owner

@pktiuk commented on GitHub (May 31, 2024):

One additional note about Polar. It is not supposed to be a typical bounty platform. They are targeted for community members (FAQ).

However, unlike traditional bounty solutions, we don't currently maintain a public directory of such rewards/bounties. Since such directories have historically attracted the wrong incentives, poor contributions and added overhead. Instead of rewarding your community. Read more about this design choice.

@pktiuk commented on GitHub (May 31, 2024): One additional note about Polar. It is not supposed to be a typical bounty platform. They are targeted for community members ([FAQ](https://polar.sh/docs/overview/faq/for-maintainers)). > However, unlike traditional bounty solutions, we don't currently maintain a public directory of such rewards/bounties. Since such directories have historically attracted the wrong incentives, poor contributions and added overhead. Instead of rewarding your community. [Read more](https://blog.polar.sh/introducing-rewards/) about this design choice.
Author
Owner

@pktiuk commented on GitHub (Jul 21, 2024):

Some feature requests also contain people promising bounties for developers implemented selected features.
Check this thread for bounty keyword: https://features.jellyfin.org/posts/57/support-download-of-transcoded-files

@joshuaboniface
Are you going to respond?

@pktiuk commented on GitHub (Jul 21, 2024): Some feature requests also contain people promising bounties for developers implemented selected features. Check this thread for `bounty` keyword: https://features.jellyfin.org/posts/57/support-download-of-transcoded-files @joshuaboniface Are you going to respond?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#569