A different way to fund freedom-respecting software

1. You announce that you would like to implement a bugfix or feature (or even an app). Mention the time it will take you, and set a corresponding crowdfunding target.
2. When the target is met, implement and release the work.

This is the classic Kickstarter/Indiegogo-style fixed-goal crowdfunding, scaled down to the bug/feature level.

It's how Prav funded the custom username feature in their fork of the Quicksy XMPP client - they got a quote from a software consultancy firm, raised the funds, and paid the company.

Members of the Prav community are also behind DebPhoshFund, trying to crowdfund improvements for mobile GNU/Linux applications in the same manner.

1. You implement an application, bugfix, or a feature (while keeping track of the time it took), without publishing the source code.
2. Announce when you are done, and set a crowdfunding goal based on the time it took.
3. When the goal is met, release the code and make the PR.

The snowdrift.coop wiki ²² What the Snowdrift wiki describes is 'meet the threshold and the code becomes free rather than proprietary', whereas what I'm describing is 'meet the threshold, or you get no code'. calls this the ransom model or the Street Performer Protocol, although the Wikipedia descriptions of these terms differ slightly from what I'm describing.

In practice, there are some more steps involved, but the structure remains the same -

1. Discuss the app/feature/fix with users to understand their needs.

2. In case of features or fixes, inform the maintainers about the intended changes. Discuss the desirability and the design.

   Announce that you are working on it, to prevent duplicate efforts.

3. Begin implementing the feature/fix. Track the time it takes. For long tasks, provide progress updates.
4. When finished, calculate the ransom amount based on the time you spent, and (if applicable) the time the maintainers spent helping you.
5. Announce the app/feature/fix and the ransom amount to users. Show demos in the form of screenshots or screencasts.³³ pranavats suggested that one may also release an obfuscated binary as the proof of work, "and pray [that] nobody bothers reversing it."
   • If funding succeeds, make a PR and go through review. Pay the maintainers before or after review.
   • If funding does not succeed, optionally release the code or the money after some time.
6. If the PR is merged - success! If the PR is not merged, make your code available in a fork.

This, too, is hardly a revolutionary idea - it's how freelancers work across the world. But somehow, it's not very popular in the free software world. The Snowdrift Wiki cites some examples of its use (e.g. liberating Blender as a whole), but never in the way I have described - that is, applied at the feature/bugfix level, and making releasing the work itself contingent on funding, rather than only changing its licensing.

Users are incentivized to pay, because they don't get the feature/fix if they don't.

For me, this is the biggest benefit, and it compensates for any downsides.

Compared to recurring donations, users have finer-grained control over how their money is used.

If the developer is not confident in their skills, the fund-to-release model allows them to successfully complete the task first, without publicly committing to it by crowdfunding it in advance.

Developers will focus on features/fixes most likely to be funded by the users.

There is no question of budget overruns or failure to deliver - the work is already done. Users have a much greater assurance of getting the feature/fix.

(In contrast, there have been plenty of Kickstarter-style campaigns that were successfully funded, but failed to deliver results.)

Unlike bounties, users are not required to reach out to a platform to put up a bounty. (Very few users will do that.) Instead, the developer reaches out to users. This could also be done through the application itself (although it's kind of like an advertisement).

The developer is at risk of not getting paid for work they've already done.

If the ransom has a fixed expiry date (i.e. when the code is released regardless of ransom), people may wait for it to run out instead of paying.

• The OpenAV model (which the Snowdrift Wiki cites as a failure of this model) used an expiry date, which naturally reduces the chances of successful funding - the freeloaders can just wait it out, as they already have a working older version and are assured of the new version being released eventually.

If there is no expiry date (or if it's too far away), people may hesitate to chip in, since their money could be held up without results until others chip in (or the ransom expires).

• Theoretically, the developer could return incomplete ransoms after a while, without releasing the code. But that would mean being wholly uncompensated for their work - I doubt they would accept that.

This is why the initial community input phase is necessary - it prevents such stalemates by ensuring the demand exists.

It's also why fine-grained feature/bugfix-oriented ransoms are helpful. OpenAV tried to apply this to software releases, which is too broad.

A matchfunding platform like Snowdrift could also help, but I don't think the Prisoner's Dilemma is the biggest factor here.

When the code contributor is not part of the project, code may not get reviewed until the payments are in and the code is released. Maintainers may not merge the PR, e.g. for design or code quality reasons. That could waste the users' money, and deter future payments.

• The developer could always publish the changes in a separate repository. But users are more concerned with changes being merged into upstream so they can (easily) use the feature they paid for.

• I suppose this also includes snowdrift.coop's concerns about the fund-to-release model disincentivizing collaboration.

  But I'm fine with that. The software remains freedom-respecting and the developers get paid. The collaboration, if any, happens after the developers are paid and the code is liberated. (Even as things stand, collaboration in the free software world is rare and most projects have a bus factor of 1.)

When the code contributor is not part of the project, maintainers may feel resentful of someone making money off their project while they don't.

One could add on a sum to the ransom which will be given to the maintainers. This could include -

• their help in implementing the feature/fix.
• any code review required for merging
• past unpaid labour they invested into the codebase.

Alternatively, maintainers themselves could set a project-wide percent to be charged for reviewing (but not necessarily accepting) any paid PRs.

Users may get tired of being regularly notified of new ransoms for new features, and payments may decline. In this perspective, subscriptions require less thought…

It's possible to scam users by sharing fabricated screenshots or screencasts. Like any business transaction, the fund-to-release model requires trust, and it helps to have a positive reputation.

Alternatively, an escrow platform could be made and some sort of verification of work could be performed before funds are released.

Some may claim that feature/bugfix-focused funding models incentivize the creation of half-baked/deliberately feature-incomplete software, to allow for greater ransoms for popular features in the future.

There may be people who will try that, but I doubt they will succeed. Feature/bugfix-focused crowdfunding relies on the software being useful to many people - a half-baked application won't acquire the critical mass of donors to begin with.

Crowdfunding always works better with a bigger crowd, and the ideas I have described are no different. All forms of crowdfunding favor popular projects with lots of users.

This is not necessarily a bad thing. There's a lot of complaining about duplication of effort in the free software world, and this works to hinder it.

But with feature/fix-focused models, it can also mean that only the most popular features/bugs are likely to be implemented/fixed. Less-popular features/fixes place greater strain on individual users, or will pay less. Code improvements that are not user-facing (such as refactoring, library migration, etc) are less likely to be funded, unless you can convince users of its necessity.

Developers could counteract this by clubbing costs for less-popular changes into more popular ones.