Idea: Micro-crowdfunding for feature requests

There are a few ways of paywalling feature requests. The first is the premium tier model, such as using Patreon as a way of accepting feature requests. The second is the commission model, where a user, needing a feature, can commission any developer to patch up the code and potentially send it upstream.

The commission model works best when the work done is very personal. Some feature requests are like this. In the furry art world, commissions are generally done to one’s personal character, which is why furry art commissions are so lucrative. However, a significant portion of feature requests are non-personal; they benefit a lot of different people similarly.

Therefore, we can draw from the crowdfunding model, where a bunch of people who wants a product can pool their money together, and – critically – you only pay if enough funds are raised, so nobody “tanks” the entire budget by themselves, and projects don’t go ahead with incomplete funds.

Applying this to GitHub, the user flow would be:

  1. A user creates an issue (in this case a feature request, though a bug report is not out of the question).

  2. A maintainer[1] sets the budget for fufilling the issue.

  3. Users contribute funds to the issue if it affects them and they would want it resolved. Users may withdraw their contribution at any time, before the pool reaches the budget.

  4. Only once the pool reach the budget, will the users pay the maintainer. The maintainer will then start work on the issue.

Currently, there are two issues (hah) preventing this from happening:

  1. Culture, though we may build upon art commissioning culture.

  2. Integration of a crowdfunding engine into an issue tracker. There are multiple free issue tracker implementations; I do not know of the crowdfunding aspect, though.

[1] Why not any developer? They may not be trusted to fufill the issue properly, while the maintainers have a reputation to maintain (hah). I haven’t thought this part through, though.

1 Like

Related: Crowdfunding to solve issues · Discussion #17526 · community/community · GitHub

Nice. I like this idea.

There’s another aspect that makes it better for the maintainer (or the project governance) to be the decider of the bounty / fee. And that is that the new feature should fit the product positioning and roadmap.

Especially projects that have companies using it in production, often feel a pressure from that client to add highly custom extensions. The company is able to pay good rates, but their customizations aren’t appropriate additions from a product development perspective.

It may be needed that the funds are held in escrow. It may take a long time until the amount is reached, and the maintainer should be ensured the money is there. So contributors pay upfront, and get refund if the feature request is canceled, or maybe after their offer to fund expires.

Right. And since it’s free software, a company (or anybody, really) who needs personal patches can commission any developer to patch up the code for them, for much cheaper than having to rewrite all the code from scratch.

I agree.

1 Like

I like the idea and would like to make it possible.

On the implementation side: I don’t think it will be necessary to integrate this tool into an issue tracker or software forge.

A website could be created where a maintainer could list the feature requests and required commissions ajnd link to them from the relevant issues.

This approach is independent of the software forge and could be integrated using their APIs. And it could very quickly be prototyped.

I believe this crowdfunding idea is very similar to bounties, with the added functionality of a threshold – the authors cannot be paid unless the threshold is reached.

If you want to implement this, a good starting point may be to build off of an existing bounty platform’s code, to add this functionality: #111 - Alternatives to BountySource? - website - Codeberg.org

The business logic.

The business logic of this website is rather simple:

  1. Somebody creates a feature request
  2. Maintainer approves and declares an approved contributor.
  3. Approved contributor sets a bounty.
  4. Sponsors pledge support ($)
  5. If the bounty is reached before X time since step 3, the bounty is collected and access granted to the approved contributor.
  6. Otherwise the feature request is out-dated and removed.

The approved contributor is a programmer of sufficient skill and resources, who is trusted by the maintainer to complete the feature request according to the project’s standards. This can be the maintainer themselves.
Every other actor should be self-explanatory.

The most complex part of this project would be the integration with:

  1. (International) Payment systems (SEPA, Stripe, PayPal, etc.)
  2. Software forges (to connect a maintainer with their projects)

An out-there idea

Disclaimer: I’m not an economist or modern monetary theorist. I only watched this video about the subject and thought it was neat. This is my first attempt at applying the concept as I understood it.

One disadvantage of the feature request approach is that it only rewards and supports the new development of novel features and not continuous maintenance or prior work. It could also tilt the development effort away from sustainable development by forcing the project to commit to overly ambitious goals to retain funding in the form of feature request funding, instead of improving documentation, fixing bugs, adding tests and other activities that are unlikely to receive support through a feature request.

I think there maybe a scheme to leverage these feature requests to support the entire project, not just the one feature that a commercial interest desires to implement.

In this scheme a feature request bounty would not be set in terms of dollars or euros, but instead in the project’s own token. This token could only be created by the maintainer of the project and handed out to contributors in exchange for their contributions to the software project. Regardless of whether their were work was for a feature request or not.
These contributors are then free to transfer their tokens to whomever they wish and in exchange for whatever currency or other benefits or commodities they desire (e.g. employment).

When a feature request reaches it’s bounty, the total amount of tokens pledged to this bounty is destroyed.

A scenario

What are the consequences of such a system? Imagine a project with one maintainer and four contributors.

The maintainer (as the owner of a monopoly on the creation of new tokens) issued tokens to the contributors according to the amount of work they put into contributing to the project. Let’s name the contributors A…D and let’s also assume that the maintainer issued one token per hour of work on the project:

  • A received 20 tokens
  • B received 5 tokens
  • C received 10 tokens
  • D received 13 tokens
    The total amount of tokens in circulation is 48 tokens.

Now assume that there is a person (P) willing to pay $5000 for a certain feature request. The request was approved and the maintainer set the bounty for this request at 25 tokens, because they expect it to take about 25 hours. of work. Assuming P is none of the contributors themselves, they’ll have convince at least two of the contributors to transfer their tokens to them, so they can use them for the bounty.

The maximum price they’d be willing to pay per token would be $5 000/25 = $200. For simplicity, let’s assume they actually pay this price and buy all the tokens from contributors A and B. A would receive $4000 and B would have received $1000.

After transferring the tokens to the maintainer, they would destroy them and make sure (either through their own work or by rewarding one of the contributors in the token) that the request would be fulfilled and merged.

Hoped for advantages of this scheme

Through this scheme, I hope that several advantages are gained for the free software project:

  1. The maintainer remains in control of the direction of a project. They can decide how to reward contributions, what bounties to set and which requests to approve.
  2. The contributors may receive support without working only on feature requests. As long as their is financially supported demand for new features, they could sell their tokens in exchange for real currency, regardless of the work they were issued those tokens for.
  3. Companies can employ contributors and receive their tokens, instead of buying tokens to fund feature requests.
  4. The project can be maintained with an approach prioritizing the project as a whole, instead of simply the interested of financial sponsors. Making projects more capable of fighting technical debt and easing development through additional documentation, tests and bug fixes that could not be supported through feature requests.

Of course there are also disadvantages to this approach, among them I can imagine:

  1. The value of tokens depends on the current demand for new features. These may vary and thus the price at which a developer can exchange their tokens may fluctuate. Exposing them to a degree of risk when working on a free software project with the expectation of profit. But since all business activity carries a degree of risk, this is to be expected. We’ll need to evaluate (through simulations and experiments) how high this risk is. Cooperatives could also be founded to buffer the developers from this risk by working on different free software projects simultaneously within a group.
  2. The maintainer has to evaluate the work that went into a certain contribution and issue tokens accordingly. This is a novel responsibility for the maintainer, but certain rules could be established (such as 1 token per hour of work) that the maintainer could apply on either a good-will basis or by inspecting some proof.
  3. The maintainer must be trusted to only issue tokens according to transparent rules. Of course a maintainer is already a very trusted individual within a project, otherwise the project would be forked under a new person or entity more trusted. If a maintainer is seen to abuse their power over a project, a fork must be created that can correct for this behavior. Now, when the maintainer also controls the issuance of project tokens, contributors and companies could be hesitant to support a fork over the original project. Unless they can carry over their stakes in the original project’s token to the forks token. Given the correct implementation of a token system, this could be achieved. And I even believe that I may have a technology that could achieve this, without exposing the balance every account publicly or using a Blockchain - I reject any system trying to use cryptocurrency for this purpose. Such a system would be more complex and dangerous, where the issuance of coins is controlled by the maintainer by design.

Conclusion

The above scheme is anything but ready for implementation. I think we ought to consider several different scenarios for this scheme, before testing it on any real-world software project.

I’m unsure whether it works, although the logic seems sound to me, the theory I am basing this on (MMT) is contentious and I am not an economist. Experiments and simulations may help in understanding this system further.

The question of whether we should do this of course is also important. I think this approach could seriously help in making free software sustainable, as long as there is financially backed demand for the specific free software project. It will not be a tool for projects without such demand behind them. For example, I doubt it will ever be possible to use this scheme to support the TOR project, which is non-profit in nature and is not (to my knowledge) used my large commercial interests. Except perhaps certain government agencies. But quite a lot of free software projects are depended upon by and require continuous development for commercial interests or simply have people with a desire for improvement and the disposable income to support these improvements financially.

Even if this idea is shown to be unworkable, I still think that we should continue to look at economics and specifically macro-economic theories to inspire us to develop models for financing free software that don’t sufficiently fund these projects, but also avoid creating incentives for the project that don’t align with the sustainable development of the project.

But regardless of this idea, I’d help work with this project of Micro-crowdfunding. It’d be the basis of the more experimental idea I outlined above anyway.

I’m willing to work on this either as a co-maintainer or as a contributor. Are you interested in maintaining this project @IgnisIncendio ?

Before starting on a project like this, I strongly recommend chatting with Wolftune (Aaron Wolf) in the Snowdrift.coop matrix chatroom. There is no one that has a clearer picture on the dynamics that need to be taken into account. Snowdrift is under preparation for a number of years, a very long time, but there are reasons for that. And that is that they do not want to make any concessions to post-growth FLO values (Free, Libre, Open).

1 Like

Hi, thanks for the mention. I don’t plan to prioritize participating here, but I made an account, so I can be pinged.

It sounds like people are thinking clearly about many nuances here. Indeed, bounties are constantly brought up and have rarely achieved the sustainability we want in the ecosystem. It’s hard to really know how much a feature will cost in some cases. It can be awkward when money is budgeted strictly for certain things.

My overall take is to push for sustaining support of projects in general with methods for prioritizing requests from patrons. Project teams need freedom to make good judgments about their work and priorities. When debating between priorities, it’s fair to give preference to requests from patrons over those from the general public. So, I prefer mechanisms that don’t make it a strict money for specific work limitation. I’d like to see it simply shown informatively to project teams that certain requests or votes are from patrons. Teams can weigh in the importance of serving patrons well especially. Teams can say to the general public that any requests are considered, and please become a patron to get requests prioritized.

I would urge checking out my LibrePlanet talk from last year for the broad perspective and some idea of what Snowdrift.coop is aiming to do about it: Why our economy fails public goods like free software - Framatube

Other solutions may be feasible. The importance is to start with knowing the macro-economic patterns we need to work within to get to the world we want. Cheers

2 Likes