Patreon and the future of free software

Crowdfunding is big, and Patreon makes it useful to frequent makers of free art. The model works so well that I think it might revolutionize the way free software is made and paid for.

Paying for software sucks

Ever try applying a mod to Minecraft? They’re free to download, and they can add immensely to the gameplay. The trouble is that to pay for them, the developers put the files behind the nastiest advertising-based paywalls I’ve ever seen.

Finding ways to fund free software is broken. Part of it is the broad and fuzzy meaning of “free” here; it might be crucial open-source software like Linux produced by thousands of developers, or a freeware game made in an afternoon. It might be “free” and supported by ads (like those mods), or “free” and funded by a deep-pocketed patron who benefits from it (like Google Chrome).

Paid software isn’t much better. Despite the revolution brought by app stores (Steam and iOS in particular), the pay-up-front model still encourages developers to concentrate on a flashy big release with lots of features. Bug fixes and UX improvements are appreciated by users, but those users aren’t paying anything extra to get them.

In general, though, there’s a developer who has to choose between building your app and working on something else. Whether you’re waiting for a bug fix that keeps Kafka from paging you at 3am, or an update that adds reentry heating to Kerbal Space Program, you might find yourself wanting to shovel a little extra money in that developer’s direction to help them choose.

From the developer’s side, the ideal business model would be to give away the software to as many people as possible, then pick out the ones who can’t live without it and charge them as much as they’re willing to pay, monthly if they’ll put up with it.

Enter Patreon

Patreon was created in 2013 by Jack Conte, a musician who wanted to get his videos in front of as many people as possible. Jack didn’t like the two choices available to pay for them: YouTube advertising and iTunes. He was tempted to try crowdfunding, but couldn’t imagine running a new Kickstarter campaign for every new video just to cover a few hundred dollars.

Patreon works a lot like Kickstarter, but it’s progressive and recurring: Someone who loves Jack’s videos and wants him to make more can go to his Patreon page and pledge $1 toward the next video, which carries over to each video after that. Jack can then see how much patrons have pledged for the next video, whether $3 or $3000, and budget accordingly. When the video is done, Jack distributes it for free (to everyone, not just backers) and finds new people who love the video enough to kick in another dollar.

Patreon is new, but it’s already working well for both big and small projects. It provides recurring income to the artist, and a direct connection to the patrons. The patrons are paying a small amount for each release ($1 isn’t uncommon), but they can easily see how their pledges add up to give the project a decent budget. In some cases, artists have already dropped advertising because it annoys patrons who are kicking in enough to offset the income.

The key to Patreon’s model is that it encourages frequent releases of art made with the patrons in mind. When Jack is deciding whether a new video is worth doing, he has two natural questions to ask: “Will my patrons think this is worth the $1 they pledged?” and  ”Am I willing to give up that patron money if I don’t do this?” The result is a regular cadence of good art.

Patreon is ready for free software as-is

If you’ve worked with an open-source software project, this might sound familiar to you. There might be lots of people waiting on new releases that fix bugs or add crucial features, but there are only so many spare hours in the day to work on them. A steady stream of patron dollars might encourage developers to work on their free software projects rather than take a contract job or start a new app for the App Store.

Patreon is neutral about the kinds of projects it accepts, so a developer could theoretically set up a Patreon page and start accepting backers right now. Each time an update is released, instead of linking to Youtube the developer would link to the update on GitHub or RubyGems or wherever they normally would.

Links back to Patreon could be added to the project’s README or changelog, or better yet mentioned on feature requests and when closing bugs. After a while, I imagine the relationship between backers and good releases would become plain in both directions: If you want better software, pledge more. If you want us to give more, make real improvements more often.

Frequent updates make better software

As a side benefit, the Patreon model would support the agile software development model. Each iteration (a short development cycle, usually with a fixed time) is judged on whether a notable improvement was shipped to customers, and patrons would be more likely to pledge based on the same metric. Bug fixes can be as valuable to existing users as new features, so there would be a strong business case for fixing bugs and making UX improvements each sprint that otherwise wouldn’t get on the roadmap.

Semantic versioning might see a surge in use, too. Rather than bundling flashy new features into big releases that justify re-purchasing software, the Patreon model would reward regular, repeated progress. Without a monetary reason to treat a point release as a major version (cough Twitterbot 3 cough), the field might be clear to set version numbers based on API compatibility.

Build funding into project sites

The obvious next step would be to create a patron-funding site specifically for software projects. GitHub is already a great community for describing, delivering, and collaborating on open-source software. Integrating patron funding would probably be straightforward. The same could be said of RubyGems or any other site that keeps track of version releases, too.

The tricky part, though, is getting the balance right; Patreon and Kickstarter have both done a great job (and put in some serious UX and community work) distinguishing “backers” and “pledges” from “donors” and “tips”, which seems to make all the difference. Software-patronage sites would have to work to connect the money pledged to real and regularly-delivered improvements to the software.

Still, I hope this model gets adopted by software projects sooner rather than later. I’d love to pay for updates to an amazing Minecraft mod by kicking in a dollar instead of dodging sketchy ads. Wouldn’t you?