Reworking the Open Source Donation Model
The methods for supporting open source software haven’t really changed in 20 years. Software authors typically put a large orange “Donate” button at the bottom of their website in hopes that it attracts the eyeballs of users who are in a hurry to grab some free software. In the last decade, some developers have added Bitcoin addresses, but the basic idea remains the same; convince people to go out of their way to donate in the moment when they are trying to get something accomplished. I’d argue this model is inherently broken. If we’re using other people’s software, supporting the people who write and publish it freely should be top-of-mind.
I’d like to propose an alternative. One that should take a minimal amount of friction to implement for developers. And one that doesn’t lock users into a specific platform. But first, lets take a deeper look at all the options that open source developers have for soliciting support.
PayPal
Pro — accepts most credit cards, people are familiar with the platform, little learning curve for donors and very little friction for developers.
Con — Placing the button at bottom of website lacks visibility, strong distrust of platform by some users, unavoidable fees which make small donations impossible.
Bitcoin / Cryptocurrency
Pro — Decentralized, global, irreversible, etc. There are plenty of articles to read if you’re unfamiliar.
Con — Steep learning curve for average users, high fees for popular coins, requires knowledge of good security practices.
Patreon / Flattr
Pro — Recurring means consistent motivation for developers to improve, clear backing goals and rewards structure.
Con — Software creators need to create a Patreon / Flattr profile to receive funds, high barrier to entry for some users, mandatory 10% fee.
All of these share a common problem — recurring donations are confusing and don’t scale with the size of your project. Hands down, Patreon has done a great job of bringing recurring donations mainstream, but it was built for general makers; they have no way of knowing which software you add or remove to your projects. The Donate Spec opens the door to do just that — allow scalable donations that grow as your project grows.
The Donate Spec
I’d like to propose a specification for accepting donations, starting with the Node ecosystem. The concept is simple: add a donate field to your package.json, detailing how users of your software can donate. Since this is within the repository, the management of donations can be changed or redirected whenever the owner chooses, and is platform agnostic.
For Developers
There are many ways to list your donation criteria, but a basic example might look like this:
In this example, Alice is the creator of the software, but Bob has made significant contributions, so they agreed to split the donations 70/30. Its good to have multiple platforms listed as a backup (as Alice does), in case the payment processor can’t pay out to the preferred platform. If all recipient’s platforms are supported, however, the donation processor could convert the donor’s currency to each contributor’s preferred platform transparently. In this case, the donor might set a recurring payment of $10 every month, and it would automatically be converted to $7 of Bitcoin and $3 of Monero, and sent to the developers. The beauty of putting this info in the package metadata is that if the authors later agree that Bob should get a higher percentage for doing more work, either of them can propose a change to the allocation at any time by submitting a pull request to their package, without logging into any third-party platform.
Check out the full documentation on GitHub.
I want this to be an open, evolving spec, so I’d love to hear your honest feedback in the comments, but also feel free to make a pull request to the spec itself.
For Donors: The Thanks App
Writing a new specification and simply hoping that people will adopt it is a lost cause. So we built a web app which allows you to discover projects and donate to your favorite authors. The concept is simple — Set up a donation for all the software you use, and we’ll take care of sending it to the maintainers of your dependencies, however they prefer. If it finds a donate field in the package, it parses it and includes their package in the donation.
If your favorite author to hasn’t added a donate spec to their project, then spread the word! You can still include their project in your donation bundle, and we will reach out to let them know they have a donation waiting. We only charge your card for projects we can pay out, so we never hold on to any funds.
What’s powerful about the Thanks platform is that it is heavily tied into the NPM and GitHub ecosystems, so if the author of a package you are using later decides they want to share some of the donations with other contributors, they can add them to their package.json and they will automatically get picked up next time your donation gets processed.
Currently, the platform supports searching and donating to any NPM project or GitHub repository. We just launched our site at https://givethanks.app, and I’d love to hear your feedback on how we can continue making this the best platform for open source authors.
Who is this for?
Anyone, ranging from indie developers, or large companies with an open source budget, to end users of software. During my time at Imgur, we frequently discussed how we could give back to the open source community, and having an option like this would have greatly simplified donations so that we could allocate a single monthly budget to open source.
While we started with the Node ecosystem, we ultimately want to support all open source authors. Currently, if your project doesn’t have a package.json, you can add a .donate.json file, and supporters can find your project by searching for the GitHub repository on our platform.
Final Thoughts
I hope that the open source community will find this idea useful. I certainly want to get my fellow makers, creators, and developers on board so that I can financially help them keep doing what they do best — creating. I’d love to hear your thoughts and feedback as well.
