With our goal being direct improvement of the open-source project by the community via donations and development, we rely on direct users of the application to submit bounties for feature implementations/bug fixes that are important to them.

Difference between a bounty and a feature request/bug report:

A feature request/bug report is simply a report of a desired functionality or a report of a bug.

A bounty is where you (or more) people from the community list a feature on this site that you want implemented or a bug that you want fixed AND raise funds for this feature/bug fix specifically. Then a developer can fix/implement the bounty and will be paid the bounty amount.

Bounty listing process

  1. You submit your bug/feature bounty below.
  2. It gets reviewed by our team.
  3. We email you back once it’s added to the bounties page. If there is an issue with your bounty submission (e.g. it’s duplicate, or already something implemented/planned, or impossible) then we’ll let you know via email.
  4. Other people can fundraise the bounty and track it’s status via the bounty listings page.
    A goal is listed for each bounty, and once that $ goal is reached, we can find a knowledgable developer to start working on it and pay them the amount once it’s DONE and TESTED (so no funds are wasted).

To list a bounty, please email the following information to This email address is being protected from spambots. You need JavaScript enabled to view it. (all of the following is required to setup a bounty):

  • your name and email address
  • how much you WILL contribute to the bounty (a bounty isn’t just a feature request/bug report so there actually needs to be $ to fund it’s implementation)
  • goal bounty $ amount (how much in total you think this bounty will cost for someone to implement/fix)
  • the bounty tier (see below)
  • bounty description
  • bounty type (is it a feature or bug?)

Bounty tiers

We have decided to group bounties into tiers depending on their impact, code quality, and complexity. This will bring more stability to our program.

Tier 1
Regular small tier bugs or fixes that improve existing functionality.
Tier 2
For medium features, refactorings, improvements.
Medium refactors or optimizations of the code or additions of small non-essential features.
Tier 3
Large features or large performance improvements. An example would be optimizing some parts of the Core for improved performance of a specific function, fixing a larger bug, or implementing a new feature.
Tier 4
Really large feature additions, possibly performance improvements if they really make a big difference (e.g. SSO). Examples of this include extending API functionalities, resolving structural issues that cause circular dependencies, or adding a new bigger feature to our codebase.