The business logic.
The business logic of this website is rather simple:
- Somebody creates a feature request
- Maintainer approves and declares an approved contributor.
- Approved contributor sets a bounty.
- Sponsors pledge support ($)
- If the bounty is reached before X time since step 3, the bounty is collected and access granted to the approved contributor.
- 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:
- (International) Payment systems (SEPA, Stripe, PayPal, etc.)
- 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:
- 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.
- 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.
- Companies can employ contributors and receive their tokens, instead of buying tokens to fund feature requests.
- 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:
- 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.
- 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.
- 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.
See: socialcoding