About this Article
This article was published in April of 2006 and describes our micro-donation funded software site as it existed at that time.
TABLE OF CONTENTS
3. The Problem
4.1. A Hypothesis
4.2. 3 Strategies
5.1. A Dilemma
5.4. Utility Theory
5.5. Project Funds
6.2. Lessons Learned
DonationCoder.com Software is LovedI love Process Tamer very much! I also love DonationCoder.com very much! And Thank you very much for producting the Process Tamer that's make lots of fun to my life! Thank you very much for DonationCoder.com producting so much useful and funny free softwares to the beautiful world
When Do Users Donate? Experiments with Donationware: Ethical Software, Work Equalization, Temporary Licenses, Collective Bargaining, and Microdonations (2006)
April 2016 - by Jesse Reichler
This article is a one-year report on the experiments with Donationware at DonationCoder.com.
Throughout the article I will focus on the specific experiences of our site (DonationCoder.com) in attempting to strike a kind of middle ground - keeping software free but making enough money from donations to fund the site.
This is not an article about how to make money with Donationware or an advertisement for our site. It's an honest appraisal of our motivations, goals, and experiences - and a candid discussion of what we've learned after a year.
It's addressed primarily to authors who would prefer to keep their software freely available, whether for ethical or practical reasons, but need to find some way to make enough money to justify the time spent coding.
You will not get rich making Donationware. If you don't make a concerted effort to raise donations, you won't get any. If you are willing to accept the fact that asking for donations is going to have to be an important part of your work, you may be able to make enough money to justify your time. Moreover, you will become part of a thoughtful and helpful community of users which can greatly increase the satisfaction of programming.
1. Why Donationware?
The reasons for writing free software are numerous and have been discussed elsewhere in depth [1a,1b]. Some people write code solely to make money. Some write code solely for the enjoyment of it and for the pleasure of interacting with appreciative users. Most code for some combination of the two.
Some coders are freeware authors for ethical reasons - believing that software should be available to everyone regardless of their financial means. Some freeware authors have simply come to the conclusion that the money to be made from commercializing a program is not worth the additional hassles involved in dealing with payments, marketing, and support.
Everyone knows what freeware is - it's software that costs nothing and has no ads or unwanted components. Everyone knows what Shareware is - it's software you can try but have to pay for to keep using. But what is Donationware?
A Donationware program is usually just a freeware program where the author is making a request for optional donations. This is a somewhat unhelpful definition, since it means that a freeware program becomes a Donationware program the minute the author asks someone to consider making a donation. A more useful definition for Donationware might be a program where the author requires a donation of some sort for full access to the program, but one rarely has the luxury of unilaterally redefining terms.
For the purposes of this article, I will use the term Donationware in the most general sense - software that can be freely used but for which monetary donations are requested. Or put differently, a Donationware author is a freeware author who needs a little help paying the rent.
2. How to avoid becoming homeless while writing free software
Users have increasingly come to expect free software that matches the quality of its commercial counterpart. Fortunately for commercial developers, they still seem willing to pay for software when the commercial alternative is superior to existing free alternatives.
At the same time, some freeware and open source developers have found creative ways to make money from "free" software. This is most often in the form of big business sponsorship of a project, or from fees charged for commercial support.
In some ways this represents the best of both worlds - the software remains free for individual users, but money is made from commercial entities who are presumably profiting from the software.
However, there are a number of serious drawbacks to this approach as a business model:
- Very few applications are candidates for substantial corporate funding.
- It turns fundraising into a game of finding one or two companies to bankroll the entire project.
- If money is being made from selling support services, it can make the middlemen rich and leave the programmers in the poor house.
There are other alternatives.
One increasingly common approach to making money on "free" software is to offer a "dual license", where commercial users pay for the product, and individual home/non-commercial users get the program for free. This can be a viable and ethical approach when there is a substantial commercial demand for the product. But it does pose a challenge when the software appeals mainly to individual users.
An alternative for popular mass-market software is to make money from the advertisements on the program website, or embedded within the program itself (commonly known as Adware). The former can be done in a way so as not to overly annoy people, but the financial rewards are minimal to negligible. The latter is generally unacceptable to authors who are trying to find an ethical alternative to commercial software.
3. The problem with Donationware
The success of the freeware and open source communities has led to a dramatic bifurcation of the software community. On one hand, users increasingly expect free software to be of the same caliber as commercial software, and do not expect to have to contribute financially to its development. On the other hand they don't seem to mind paying for good software.
But they seem to reject the concept of voluntary donations wholesale. Why?
Deciding between free software and commercial alternatives seems to be largely a utilitarian decision made at the time of adoption. The idea of making an optional donation to support software development or to reward the development of an existing program simply does not fit into this short-term decision.
Making a donation has no immediate benefit for the donor - and I would argue that this is the major problem for the Donationware author.
In fact, however, the situation is even worse for the Donationware author.
Not only is there no immediate benefit for the donor - there are additional substantial impediments to donating:
- First, there is the obvious monetary cost to the donor. I will argue that this is in fact the least significant of the impediments to donating, and requires little attention from the Donationware author.
- Second, there is the time and effort involved in donating. People don't want to spend even a few minutes figuring out how to donate and fill in forms, etc., even if they already have a credit card or PayPal account set up already.
- Third, there is the security risk involved in donating. Any exposure of financial information is a risk to be minimized for the user. Uncomfortable decisions have to be made about the safety of the site and the donation process.
- Other factors, such as the psychological discomfort in having to decide how much to donate, or wishing to remain anonymous, may also play a factor in users not wanting to donate.
As a whole, these impediments represent a substantial hurdle for the software developer who is interested in recovering some monetary return for their work through donations.
The DonationCoder.com website was started in March 2005, as an experiment in a different approach to Donationware.
Our early experience asking for donations mirrors that of other authors: Text in an "About box" or on a web page saying "click here to donate" is simply ignored. Users do not seriously consider such requests. When asked to donate they tend to respond like Bartleby the Scrivener : "I prefer not to." They don't think the author really needs the donation and they don't see any reason to go through the trouble involved to donate.
Ironically, adding a desperate plea for donations probably has a negative overall effect; people do not like the idea of adopting a program that may disappear the next day due to lack of funding.
We wondered if here was an alternative approach to soliciting donations.
Our starting point for the site was the concession that, as much as we disliked asking for money, we would have to make raising money a more central element of the site if we were going to be able to pay bills and keep working on our software.
It's important to repeat this starting point, because it frames everything else we do. We are not now trying to get rich. Our goal is to make enough money to offset our time and let us justify continued work on our programs. If we could continue coding freeware and had an alternative stream of reliable income that would pay rent and food, we'd be just as happy doing that and not having to ask for donations.
Having accepted that we would need to swallow our pride and make asking for donations a major part of the site, we had to figure out a way to do this that felt ethically comfortable.
Our first guiding principle is that our software programs should be freely available, in their full form (otherwise we could have called it CrippleWare.com), to anyone who couldn't afford to donate. This is our primary guiding principle which constrains everything else we do.
4.1 A controversial hypothesis
We began with a hypothesis that the main obstacle people had to donating was not a desire to minimize the explicit monetary costs.
We believed that if we could get people to go through the effort of donating, then at that point they would reasonably choose an amount to donate which matched their financial means, rather than simply donating the minimum they could "get away with".
While many people we talked to were skeptical about this hypothesis, our experience seems to have confirmed its validity. Almost everyone who donates, donates more than the minimum allowable. Among those who only donate a token amount, many have expressed a willingness to donate again in the future if the site continues to be useful to them.
4.2 Three strategies for encouraging donations (Convey Benefits, Work Equalization, and Something Extra)
Over time our approach has evolved into a three-pronged approach.
4.2.1 Strategy one - Explain why donating benefits the donor (i.e. Users don't care about you)
Users don't care about you [3a,3b]. In other words, users will visit your site and make a donation when it benefits them, not because they want to do a good deed.
One of the most important things we do on DonationCoder.com is try to convey the connection between donations and continued development of the site and the software on the site. While this connection may seem fairly straightforward, it's not something people normally think about. We have tried to engage our readers in a kind of informal contract - if they are willing to donate to support the site, we promise to continue developing the software to meet their needs.
This is a conscious effort to get users to think beyond the immediate benefits of donating (which may be minimal) and think about the longer-range benefits of donating, such as additional features, bugfixes, and new programs.
Such an approach requires a real commitment to continued development and interaction with our users. It's only feasible because we really do enjoy interacting with our users, getting bug reports, and adding features that they want to see.
As a programmer this is where you have to ask yourself: Do you enjoy interacting with your users and are you motivated by enthusiastic beta testers? Or do you view such interactions as the necessary cost of making sales? If the latter, then Donationware, and this particular strategy for encouraging donations, will be painful for you. If the former, then this kind of approach can be very rewarding.
We were surprised by how enthusiastic the members were on our forum and how willing they were to help us test and improve our programs. A benefit of making donating a core part of the process is that users who do donate become part of a community on the website, and make the site a more satisfying experience for everyone.
In fact we had no idea how central the community of donors would become to us when we started the website. The forum, which was originally set up only as a place where we could provide some technical support, has become for us the most rewarding aspect of the site, and a major source of our inspiration and enjoyment.
Somewhat surprisingly, asking seriously for donations may bring you closer to your users - who become part of the team making continued development possible. Deciding whether Donationware is for you in part depends on whether letting users play a bigger role in the development process is something you want.
4.2.2 Strategy two - Work Equalization
When the site first opened, our software was all freely usable with no limits, nag screens, or expirations. We simply asked people to consider donating.
One of the problems with a site like ours, which tries to make a real case to our visitors regarding why they should donate, is that many of our users never even visited our site(!). The Internet is filled with software download sites which list programs and provide users with direct downloads to the programs on author's sites. That means that most users will download freeware programs and use them without ever even visiting the homepage of the program. This meant that for most users we didn't even have a fair chance to explain to them why we thought they should consider donation to us.
After about 6 months of operation we put in place a License Keys system, which is still in place today (though some changes are planned). The basic idea of the license key was to "equalize" the work involved in donating and not donating. After donating to the site, a user gets a single license key which works on all of our programs and lets them run forever (a donation also entitles users to other membership benefits).
If a user chooses not to donate, he/she must sign up and download a free license key which lasts six months, after which the user must return to the site to download another free license key. After a year they are given a permanent license.
The main idea for requiring people to sign up for free license keys was that we wanted to make it actually "easier" and "quicker" to donate than to not donate. In this way, we hoped to remove the effort imbalance that keeps people from going through the work of donating. By making people work a little to get the freeware keys we hoped to make it easier for those with money to donate than to grab the free version, while still putting only a minor inconvenience on those who couldn't afford to (or refuse to donate).
Asking users to sign up to download a free license key had another substantial side benefit, which was that by default such users are signed up to receive our mailing list that goes out twice a month. We do not send out advertisements to this mailing list or sell access to it, but it does give us a chance to let people know about new features on the site and give us a chance to reach potential future donors (users can easily remove themselves from this list if they don't want to be contacted).
This strategy is still somewhat controversial, and there were some lively debates within the freeware community about whether our approach still fits in with the freeware model. We were fortunate to have an active community on our site that supported our attempt to balance competing needs, and we tried to involve our users in these decisions, and view the entire process as one of balancing competing needs. The challenge was to keep the core ethical principles while encouraging donations. One downside that does need to be acknowledged is that these attempts to encourage people to donate end up inconveniencing the very small minority of truly generous people who would be inclined to donate anyway.
Again keeping with our hypothesis that it's not necessary to worry about the amount people donate, a one time donation to our site of any amount grants lifetime access to all of our software and member benefits.
4.2.3 Strategy three - A community and something extra for donors
The third strategy was to try to offer donors something extra. Not extra features in the software (which we were philosophically opposed to), but extra features in terms of ancillary benefits on the site.
Sometimes these are non-tangible benefits, like being recognized on the site as a charter/supporting member, and receiving recognition on our site as a special supporting member; we set up a prominent Supporter Yearbook Page which let's people explore who else has donated to the site, with images and quotes, to help convey our appreciation of such supporters, and their importance to the site.
Although it was not part of our original intent, we discovered as the site grew that companies became more interested in offering discounts to our members, and offering us a commission on sales.
We knew from the start that we did not want to become involved in affiliate sales and commissions. It would compromise the role of our forum as an open place to debate and discuss opinions about the best free and commercial software, and it wasn't the way we wanted to raise money.
However, as our member base grew, and as users discussed their favorite programs, we realized that there was something we could do that would benefit our members and still remove even the appearance of us benefiting from software sales. We asked companies if they would be willing to offer discounts to our members and pass on any affiliate/commission fees directly to the purchaser. One of the benefits to being a donating member of the site is access to these software discounts. By avoiding any affiliate commissions we are able to secure larger discounts to our members, so the users benefit, and by limiting the access to discounts to donating members, we are able to offer an additional incentive to donating to the site, and by skipping commission fees we benefit the companies. So everyone wins.
This actually fit well with a main focus of our forum which is to bring together coders and users. So we have tried to be a place where programmers could come and talk about their software with users and exchange ideas. Although we have our own freeware/Donationware software, we have tried to foster an atmosphere of non-competitiveness, and find ways to reward generous behavior and information sharing. Keeping with this spirit we have tried to follow the lesson of "Miracle on 34th Street" , and openly discuss and point people to alternatives to our programs, both Shareware and freeware. Our hope is that our visitors will view the site as a whole as something worth supporting.
5. DonationCredits: A microdonation system for growing the site and community sharing
When the DonationCoder.com site was initially set up, almost all of the content (software, reviews, web design) was created and maintained by one person - so distributing incoming donation money was not an issue.
However, over time more people began contributing content to the site. This was all done on a volunteer basis, and the nature of the site seemed to appeal to people who were motivated by the desire to create and share.
One feature we started, called "Coding Snacks", started out as a once-a-month weekend of coding where we brought some coders together to implement requests by users for quick small utility requests. The idea was to try to implement new small freeware utilities on demand, and let users take part in the software creation process. This proved to be a popular and fun feature on the site, and we started a special section of the forum where people could request such utilities at any time.
One visiting coder in particular found a home in the Coding Snacks section, and stunned everyone with his skill and determination at implementing requests. We eventually set up a page dedicated to his work on the site, which now numbers over 40 small utilities, and he became the second official site programmer (Skrommel).
5.1 A Dilemma: How to distribute donations to contributors
A dilemma we faced at this point was how to fairly share donations with such coders. Initially the process was very ad hoc, and we simply just made occasional donations to those who were contributing content, based on our estimate of relative time spent working. This wasn't really an issue of concern to anyone - those contributing weren't doing so for the money, and the coders were happy to have free hosting and the recognition and exposure.
But we clearly needed a more systematic long-term solution to the problem, where contributors to the site get a fair share of the incoming donations. We want the site to be a place where talented and active programmers (and writers) find a welcome home for their work. Most significantly, we don't view the role of the site as a service to make money from such coders, but rather as a cooperative designed to make a little money for everyone involved in creating content, and designed to attract people more interested in creating content than maximizing profits.
At first, in order to keep things as simple as possible, we thought it might be sufficient to simply remind and encourage people on our site to donate directly to contributors. We hoped that after making an initial donation to the main site, people would be more amenable to donating again to an individual author.
As much as we tried to encourage such donations, the effort was largely unsuccessful, for a variety of reasons. All of the issues regarding the momentum against donating discussed earlier in this article come into play again. And people are even more wary of donating to individual authors and writers who don't have a well established site, even when using an established financial service like PayPal. And perhaps most troubling is the fact that the transaction fees charged by services like PayPal make donating small amounts (smaller than say $2) impractical.
Our solution to this dilemma was to implement an in-house microdonation system.
Micropayments were at one time heralded as the next wave in the Internet economy [5a,5b], but never really took off and have since fallen largely out of favor [6a,6b,6c,6d,6e,6f], though there are still some notable exceptions [7a,7b].
The general idea of micropayments is to make small payments (under $1 and possibly as little as a fraction of a cent) economically feasible. How do microdonations get around the problem of high overheads charged by typical financial services?
The most common approach to implementing microdonations is for transactions to be in some sense "virtual" and then processed as "bundled" transfers of larger amounts. A micropayment service acts like a middleman, allowing users to pre-deposit some money into an account, and then make micropayments to companies that have also signed up with the micropayment service. After the service has received a certain number of virtual payments, the service can send a real lump payment to the company. In this way many small payments are performed virtually, and the "physical" transfer of funds occurs rarely and in large enough amounts to make the overhead negligible.
Micropayments have never really caught on for a variety of reasons, including the difficulty in administration, the reluctance of companies and users to sign up, and the fact that advertising seems to be a viable alternative to such small payments.
Our case was somewhat unusual - we were not looking for a way to let people make micropayments to our site.
We believed (and experience has shown) that our software and services were substantial enough that people did not have a problem making substantial donations to us. Our problem was finding an easy way for users on our site to donate to one another, or to independent contributors to the site, in smaller amounts.
We call our in-house microdonation system "DonationCredits" and it works like this:
Whenever someone donates to the site,
half of their donation is credited back to them in the form of "credits". In the long run, we hope to raise this amount to 100%, assuming the idea proves practical and users donate enough to a general site fund; for now 50% allows us some control over insuring a fair distribution of donations Users now are credited with 100% of their donation which they can allocate as they wish. These credits are as good as cash and users may donate them to anyone else on the site with a few trivially easy clicks.
If users find a coder on the site doing work they like, they need only click on a gold coin symbol next to their name to be brought to a simple screen where they can choose how many credits to give them. In the forum, all authors have this symbol for easy donating if someone posts something particularly useful. Donations can be as little at 10 cents.
We've tried to make it easy to give out credits and make it easy to spot who to donate to if you are reading something on the site you like and want to support.
We have also tried hard to make it fun for users to give out credits to each other, and thus make it something people feel good about doing. Users can write up a little something about themselves that donors can read, and users can check their records at any time to see a history of credits given and received, along with comments describing why.
Users are also encouraged to set up direct donation links (PayPal, etc.) so that people who want to make a direct cash donation to them can easily do so bypassing the microdonation system and the DonationCoder.com site. Our intention is not to make a profit as a middleman between donations, but rather to make it easier for members of our site to donate to each other, so we are happy to encourage direct donations. Users are also welcome to link to their DonationCoder.com donation page from their own websites.
Sending a few credits with a little thank you note takes almost no effort and the feedback we've received so far seems to indicate that we have succeeded in making the credits a fun way for people to interact with each other and show their support for each other's work.
When a user receives enough credits, they can submit a cashout request to be sent the cash equivalent of their credits. Cashout transactions occur in bulk and never between users directly, so users never have to worry about revealing personal or financial information. The site itself makes these payments, funded by the original direct donations to the site.
Security is always a concern for users, and one of the advantages of our system is that donations to other users are all virtual - actual transactions are paid for in bundled amounts by us, out of the initial deposit of money a user made to the site. As such, there is no risk incurred by a user in donating to others. For internal security, we use a large number of redundant logging systems, and process all cashout requests manually by someone familiar with the site userbase. An additional layer of security is that while credits are always immediately available for giving out to others, credits must sit in someone's account for 30 days before they can be cashed out. In this way, we always have 30 days to handle any canceled/refunded donations, and 30 days for people to report errors in donating to one another.
Of course many users elect not to participate in the DonationCredit system. They may either donate all of their credits directly to the site for us to distribute at our discretion, or they can simply leave their credits unused; after 12 months of non-use they are converted into a general site donation.
5.4 Decision Theory vs Utility Theory
One thing we didn't fully appreciate when we first put the DonationCredit system in place, is how rewarding it would feel to simply receive and then re-give some credits, even when this results in no net gain of credits. This is a powerful idea because our site is filled with people who are typically not motivated by money but who still enjoy participating in the system because it serves as a mechanism for showing appreciation. We are all familiar with the idea that it can be more pleasing to give than to receive, and this can be the case with the DonationCredits system. The credits are a fun and engaging way for people on the forum to show their appreciation of one another.
Donations come into the system as credits, and the same donated dollar may pass through many hands in the form of credits before it finally winds up in the hands of someone who is producing content on the site and feels like keeping it, and cashing it out for real money. As it passes through different hands it seems to bring some measure of satisfaction to each person it touches, and the whole system acts like a mechanism for bouncing around donations until they reach individual members who deserve them. This isn't trickle-down or trickle-up economics, but rather pinball economics.
5.5 Project Funds
Another advantage of the microdonation system we set up is that it allows us to set up "funds" where people can pledge money toward some project. Some funds can be set up just as a way for us to give back to open source projects that we use on the site. Other funds can be set up to help finance a programming project. The fund goal amount is public and if the goal amount is not reached within some timeframe we can easily refund all pledges. This solves a real problem in trying to raise money for a project: For some projects, people tend to be wary about donating money when they are not sure if the project will actually raise enough money to go forward. With DonationCredit funds, money is pledged and earmarked for a particular project so it becomes unavailable to the donor, but is easily returned if the project doesn't raise some critical threshold amount, so it's a risk-free mechanism of pledging donations to fund proposed projects.
5.6 The ethical use of DonationCredits
There are some challenges posed by the introduction of DonationCredits on our site. The one that concerns us the most is the fear that our site will go from a volunteer-driven site, where people code and help others for the pure satisfaction of helping out, to a site where people are haggling to find profitable programming "jobs".
We do not want to lose the special volunteer/donation based spirit of our site by turning into a bidding site for coding projects. There are several sites (Rentacoder, ExpertExchange) which do very well with such an approach, and they serve an important function. But this is not what we want for our site - we are much more interested in building a community of people motivated by the pleasure of interaction rather than the desire to maximize profits. We have no objection to people making independent job arrangements for real money, we just don't want our site becoming all about jobs-for-money contracting, where people don't do anything unless they think they will make a good profit from it.
The site is in effect largely defined by the people who hang out on our forum and write content, whether it be in the form of reviews, software, or forum posts. The core group of people who have made the site as valuable as it is now are not motivated by money - and if the site shifted too much in that direction, they would surely find another home - which would be a major loss for everyone on our site.
So how do we keep this from happening? The first thing to recognize is that the DonationCredit system doesn't actually add anything that wasn't possible before - it was still possible in the past for people to offer money in return for jobs - and this rarely happened. DonationCredits just makes it a little more tempting to make such offers.
One potential policy would be to expressly prohibit negotiating for credits. That would forbid a coder from saying "it's not worth it for me to do it for x amount of money, but i will do it for y." People could add pledges to a request until it was answered if they like, but we could forbid public negotiating for price. It's not entirely clear that the concrete benefit of this policy would be substantial, but it does have a intuitive appeal in keeping talk about money on the forum to a minimum.
However, the main policy we have put in place which seems to solve most of the problem is to simply disallow any arrangements on the forum for private work. That is, the result of any programming or writing that is discussed on the forum must be made available for free to the public (Donationware is fine). So that a person cannot offer money on the forum for a private piece of software for commercial use (we have no problem with off-site negotiations of this form, just not public forum negotiations). In this way, negotiations are really just one person offering to put up some money up front, which others can add to, to pledge enough to make a project feasible. This also eliminates those people who are trying to commission work that they can turn around and sell for a profit, which goes a long way toward reducing crass commercialism on the forum.
The best advice we can offer to a potential Donationware author is to have fun and stay balanced. Remember the reason why the idea of freeware/Donationware is appealing to you as a coder: because you love to code. The focus of our site, and the focus of this article, has been on trying to find a balanced middle ground where you can do what you love (write code and interact with users), and make enough money to pay your bills. If you find yourself leaning too far toward either extreme, trying to squeeze money like blood out of a stone, or burying your head in code and ignoring the electric bill, it's only a matter of time before reality forces you into making some hard career choices.
6.1 The future of micropayments/microdonations: Easy macro-payments
The idea of micropayments has been around for quite a while. They've not yet taken off and many people think they never will. Our experiences suggest the opposite. We believe that if donating were safe, easy, and immediate, with a low overhead incurred for small donations, it would in fact become a viable funding source for many.
Our experience suggests that people are willing to donate, and donate non-trivial sums, if the motivation to do so can overcome the effort involved and the perceived security risk.
In fact, we believe that the paradigm shift required for successful adoption may not be the move to "micro" donations at all, but the move to super-easy-donations.
If users could simply hit a button on their keyboard to donate a dollar or two to a website, and be confident that their donation would be securely processed with no risk to themselves, and knew that their donation was going to the content creator and not some middleman, we think it would become a viable funding mechanism for all kinds of content creators including musicians, writers, and software authors. The key is making it easy, and giving donors feedback that their donations have a real and concrete effect on the content creation.
Our experience with making comments an integrated part of donating, and providing a fun way to view past donation activity suggests that users may come to view micropayments less as a financial expenditure, and more as a standardized way to give feedback to others. In a very real sense this suggests that micropayments could come to be viewed by users as something they enjoy doing and view as a benefit rather than a cost.
While our in-house microdonation system has been a success, it's clearly just an internal system with no hopes of expanding to donations outside of our site. While there are a few small micropayment services in existence now, they don't have enough market share to make them attractive to users or content creators. Until users are motivated to donate into these services to create a buffer account of money they can donate, and until content providers support such payments widely, it's a lost cause. However it seems inevitable to us that eventually as digital payment systems become universally accepted and standardized, we're likely to see a standardized micropayment system where any user can buy anything on any web page, from any computer terminal, with a simple click or thumbprint swipe. When that happens, it should make micropayments considerably easier for individuals to make a living off of, rather than depending on the filters of large corporations, news organizations, software companies, music labels, etc.
6.2 Some things we've learned:
It's probably not possible to make a good living on Donationware, but it might be possible to give up your day job and live above the poverty line eventually, if you're willing to take the work seriously and willing to invest a lot of time and energy.
While this probably doesn't sound all that appealing to you business majors who want to get rich quick and retire - for those that love coding and crave the freedom of working their own hours on projects mostly of their own choosing, and enjoy interacting with appreciative users, Donationware is an option worth considering.
If you want donations - you're going to have to ask. It's a humbling thing, but if you don't ask, and ask seriously, people won't give.
Furthermore, while you may be tempted to tell your users that if they don't donate you won't be able to continue coding, this is probably a very bad idea for a software developer. It's not like a public broadcasting station, where there is no penalty for a watcher to start watching a show and then have the show go off the air. In such a scenario, predicting doom unless enough donations are received may be a viable incentive and threat. For software, if the visitors to your site get the feeling that you may stop work on and support of the software if you don't raise enough money, that alone may be enough to scare them away.
Users don't want to invest their time and effort learning to use your software and become dependent upon it only to have it dissapear. Because of this, you really need to adopt a somewhat unusual approach, and make a contract with your users: You will be there for them, through thick and thin, and in return you ask for some monetary support. If you can't make a promise to support the software no matter what, then you can't expect your users to donate, do beta testing, and file bug reports, and then risk finding themselves left out to dry because there aren't enough people supporting you. You need to set a baseline of support you are willing to guarantee no matter what - and then you can offer further incentives for donating beyond that.
If you are honest and willing to engage your users in a kind of collaborative development process, they will be happy to contribute to your success and they will see the benefits of their donations. And those few that donate are likely to be unique individuals that inspire and motivate you, and make your coding that much more rewarding.
- 1a. Open Sources: Voices from the Open Source Revolution, 1999, Chris DiBona, Sam Ockman, Mark Stone, eds., O'Reilly, http://www.oreilly.com/catalog/opensources/book/toc.html
- 1b. The Cathedral & the Bazaar, 2001, Eric S. Raymond, O'Reilly, http://www.oreilly.com/catalog/cathbazpaper/
- 2. Bartleby, the Scrivener, 1853, Herman Melville, http://www.csustan.edu/english/reuben/pal/chap3/melville.html
- 3a. Users don't care about YOU, Mar 10, 2006, Jeff Atwood, Coding Horror Blog, http://www.codinghorror.com/blog/archives/000536.html
- 3b. Users shouldn't think about YOU, Jan 3, 2005, Kathy Sierra, Creating Passionate Users Blog, http://headrush.typepad.com/creating_passionate_users/2005/01/users_shouldnt_.html
- 4. Miracle on 34th Street, Valentine Davies, Harcourt Brace Jovanovich, 1947, http://www.imdb.com/title/tt0039628/
- 5a. The Digital Silk Road, 1996, Norman Hardy and Eric Dean Tribble, Agoric Systems: Market Based Computation, edited by Wm. Tulloh, Mark S. Miller and Don Lavoie, http://www.agorics.com/Library/dsr.html
- 5b. The Case For Micropayments, Jan 1998, Jakob Nielson, useit.com Alertbox, http://www.useit.com/alertbox/980125.html
- 6a. The Case Against Micropayments, 2000, Clay Shirky, O'Reilly openp2p.com, http://www.openp2p.com/pub/a/p2p/2000/12/19/micropayments.html
- 6b. Fame vs. Fortune: Micropayments and Free Content, 2003, Clay Shirky, Clay Shirky's Writings About the Internet, http://www.shirky.com/writings/fame_vs_fortune.html
- 6c. Nickeled-and-Dimed to Death, 2001, George Anders, Fast Company Magazine #52, http://www.fastcompany.com/online/52/untangle.html
- 6d. Micropayments: An Idea Whose Time Has Passed Twice?, Michael Lesk, 2004, IEEE Security and Privacy vol. 2, no. 1, http://csdl.computer.org/comp/mags/sp/2004/01/j1061abs.htm
- 6e. The Case Against Micropayments, 2003, Andrew Odlyzko, Proceedings of the 7th International Conference on Financial Cryptography, http://www.dtc.umn.edu/~odlyzko/doc/case.against.micropayments.pdf
- 6f. The Mental Accounting Barrier to Micropayments, 1996, Nick Szabo, Nick Szabo's Essays and Concise Tuturials, http://szabo.best.vwh.net/micropayments.html
- 7a. Micropayments Drive Asian Games, Apr 4, 2006, Kathleen Craig, Wired News, http://www.wired.com/news/technology/0,70573-0.html
- 7b. BitPass Press Release, Dec 9, 2003, http://corp.bitpass.com/aboutus/releases2003.html#dec09