I have a couple of browser extensions, one of them acquired 15k new users in the past two weeks and it is still trending on Firefox Add-ons, yet donation links are rarely clicked, and I haven't received any contributions.
The effectiveness of asking for donations can vary a lot, and in my experience it is not sustainable at all, unless your project is wildly popular, or it supports the needs of an affluent and passionate user base.
I'm not everyone, but many probably feel how I feel about browser extensions. The browser is free, and so are their extensions...
I'm fairly certain that upselling is the best approach to monetizing browser extensions... Provide a freemium service, and have paid features. Much like apps I guess.
But you really have to be providing a service. So it's more like the browser extension or app is just another marketing channel.
Lastpass is a good example. Distill Web Monitor is another. I believe the latter was acquired to be monetized.
I think this comes down to brand visibility, and also to a large extent, deliberately built emotional brand attachment.
Both are completely missing in this article and should really be featured prominently.
There's another article currently at number 2 on the HN front-page[0] about The Guardian. While this isn't an open source project (though they are open source contributors[1]) there are definite parallels. As well as having the nags and donation drives in place, people also need to think the Guardian is worth donating to. And they do, not just because it provides a valuable service to them, but also because the Guardian has a very recognisable name, and because it has been successfully sold to them as a reliable, stable entity they can trust.
Obviously something of the scale of The Guardian is not the ideal comparison to most small FOSS projects, but the general ideas hold true - you have to invest in somehow developing in people an emotional attachment to the idea of your product if they're going to click donate.
Side question about the "core" approach. Can your core be *GPL (in case it needs/ships with GPL libraries/tools) while some "plugins/modules" would be closed source?
Let's say you have an IRC client that is GPL (because you want to use grep for example), but it's only a service with an API. You then make closed front-end that utilizes it. Or other way, there would be a closed tool that the client can use (e.g. auto reply module).
The "service with an API" approach dodges the GPL by keeping the client and server separated in separate processes or even separate servers, which is fine. (The AGPL was created as a stronger version of the GPL which prevents this dodge.)
The long version is that it is unclear whether it's possible or not and it will vary depending on what integrates with what and how. GPL is a nightmare.
Note there is a strong and justified barrage against GPL components in the enterprise world. Assuming you are doing a "core" model because you intend to sell it, that might be a problem.
I'd like to bring a bit of perspective to "GPL is a nightmare [because you cannot create proprietary derivatives]." That's the point of the GPL: to ensure that the code remains open rather than, for example, killed by 'embrace, extend, extinguish'[1].
The GPL is a user-focused license. It sacrifices some freedom for developers (the ability to produce proprietary derivatives) in order to safeguard other freedoms[4] for users.
Whether that's a good trade-off is a matter of opinion, not a universal consensus as the parent comment might lead you to believe.
The GPL is a nightmare for Legal. Compliance can be difficult for larger corporations and as such expensive. Thusly corporations will avoid it in favor of licenses which aren't complicated. This goes doubly for the AGPL.
In addition to that and as a side note; The GPL does not protect against EEE, only against EEE through a fork of the source code. No license can do anything about EEE through standards.
I'm pioneering a futuristic alternative. The user donates their CPU cycles -> to generate hashes -> to mine crypto currency on behalf of the open source project.
If you need a way to accept donations worldwide - without a merchant account and without the donor even needing a credit card or bank account - it might be worth a look.

I know this feels like nit-picking, but you likely mean "proprietary license." Just because the GPL encourages a different style of commerce than most are used to for software, doesn't mean it's not commercial.
As for charging fees for additional proprietary licenses, this link explains Richard Stallman's views on it:
As an outsider to the whole open-source culture, this line struck me as...strange:
>"When I first heard of the practice of selling exceptions, I asked myself whether the practice is ethical. If someone buys an exception to embed a program in a larger proprietary program, he's doing something wrong (namely, making proprietary software)."
This might be a kneejerk reaction, but why does he feel the world is entitled to the labor of a programmer for "free"? What's his alternative business/labor model? Is it compatible with capitalism? What am I missing here? I'm reading through some of the philosophy on gnu.org to try and sympathize but it still seems insane to me:
"When you use proprietary programs or SaaSS [Service as a Software Substitute], first of all you do wrong to yourself, because it gives some entity unjust power over you. For your own sake, you should escape. It also wrongs others if you make a promise not to share. It is evil to keep such a promise, and a lesser evil to break it; to be truly upright, you should not make the promise at all.
There are cases where using nonfree software puts pressure directly on others to do likewise. Skype is a clear example: when one person uses the nonfree Skype client software, it requires another person to use that software too—thus both surrender their freedom. (Google Hangouts have the same problem.) It is wrong even to suggest using such programs. We should refuse to use them even briefly, even on someone else's computer."
You're free to stop using Skype any time if you don't like the terms. When I use the subway, aren't I surrendering my freedom since I can't get off whenever I want? So are subways that don't stop whenever any person demands it unethical? What is this guy smoking?
> This might be a kneejerk reaction, but why does he feel the world is entitled to the labor of a programmer for "free"? What's his alternative business/labor model? Is it compatible with capitalism? What am I missing here?
He doesn't refer to "free" as of cost, but "free" as in "freedom". The Free Software model fully permits that software is only available to people who pay for it, they would just get source+binaries and would have the rights to redistribute as they please.
Most companies who use this model tend to dual-license, though. That is, a copyleft license for most people, and for those who fear it, they can purchase an exception to use it as proprietary software. In years gone by, this was GPL/proprietary, but in this world of SaaS/SaaSS, AGPL has supplanted the GPL as the "toxic" license of choice to encourage companies to buy licenses.
You're absolutely correct, but there's a lot of misinformation, largely attributed to people's understanding of earlier versions of the AGPL, before the GNU project adopted it and reworked it for AGPLv3.
He doesn't. I don't believe he's ever really had issue with programmers selling their labor. What he's objecting to is the idea of proprietary software; that is, the idea of software that the end user cannot see the source code to, and cannot modify for their own purposes if needed.
"You're free to stop using Skype any time if you don't like the terms."
At one point in time, the terms to using Skype could be agreeable to me, and so I invest in using it, get my friends using it, and use it for my business. Then later, those terms change, and because I do not have any rights to the code or do not have any of it under my control, either I have to spend a lot of time, effort, and money to replace Skype with something else, or just suck up and take it.
> that is, the idea of software that the end user cannot see the source code to, and cannot modify for their own purposes if needed.
Ability to share the software (with or without modification) is also amongst the "four freedoms", which places some practical limits on selling copies of the software past the first.
Flipping this around, I find it remarkable that, in the realm of Free Software, we can be having a serious conversation about the applicability and appropriateness of capitalism.
This is part of what I love about ideas like UBI. If I could feel secure in my long term badic needs, I’d like nothing more than to dedicate myself to socially rewarding purposes.
I've atleast once seen "commercial license" to mean "MIT License", so it doesn't always have to mean "proprietary"; it can just as well mean "more business friendly license"
I've done this with Dramatiq[1]. The most surprising thing to me about this approach was how receptive companies are to it and how negatively some people on the internet seem to react to it. Inevitably, whenever the library comes up for discussion, one of the biggest topics ends up being the license and how the project is going to suffer for it.
Looking at your EULA (https://dramatiq.io/EULA.html), did you have it drafted by lawyer? I think I might need one for my projects but I'm not sure if I should pay a lawyer just yet.
That's really interesting. I was thinking of trying this but was a little put off by the massively negative reaction to AGPL you get online.
I think a lot of it comes from people who would like to use the software in their open source projects but are irritated that it isn't compatible with their license.
Roughly (range-wise) many commercial customers do you have?
There is no support "fun", atleast not from my side. I do not feel like anyone is entitled to me supporting the application unless I am specifically paid for that. If I see such comments they will get removed and the offender banned very quickly.
Well, if they pay for the support and their request falls into an agreed-upon SLA, why not? This allows improving the software, keeping it open source and may provide a living wage for the maintainers all at the same time.
It's up to the maintainer to offer up an SLA and price it accordingly. Try to figure out the SLA you get for your windows or office license: Many companies would already be happy with "our payment places this otherwise uninteresting issue that we desperately need fixed at the top of the queue", even if no guarantee for a time frame was attached. If a company expects 24x7 with short response times, price it accordingly. If you find customers willing to pay for this, great, you just validated a market :)
One more I don't think is covered, a trademarked product. You sell your GPL'd product, you deliver sources as is required, but only those who paid can build full functional product because it includes components that you can't redistribute (logos, etc).
Probably only works for very complex software, or software where non-code assets would be important (a game).
If I am not mistaken this is what RedHat does with RHEL.
Most open source projects taking that path have eventually been forked when someone created new assets under a free (as in beer) license and changed the name. The original project is now nothing while the fork is big.
RHEL continues not because of assets but because Red Hat has people who staff who know the ins and outs of RHEL and will fix it. Red Hat employs many kernel developers because when a customer has a problem the customer knows an expert will get on the problem right away. The guy they talk to on the phone is useful, and can solve the vast majority of problems (as could any well trained system admin), but when you get to those rare special cases Red Hat is better able to handle them quick.
True sustainable, scalable funding for open source will never come from donations. It must be approached as a marketing win for companies. This is the only way they can (and will) scale their funding paving the path for true financial sustainability.
I feel that, if you're going to put a bunch of work into setting up donations and bugging people to get them to donate and all that, just charge for your work. There is absolutely nothing wrong with charging for your time, or with asking for what you believe your labor is worth.
Sales people get paid largely on commission for "transactions" ... it should be possible for open or closed source software developers to be paid this way as well.
There should be an option that pays open- (or closed-) source software developers for business value derived, where metrics (representing aspects of "remunerable transactions") from developed software use are gathered, and the company using the software pays based on some formula related to those metrics. The classic way to do this of course is to provide the software via some metered and billed SaaS API (users pay monthly base + tiered charges per network I/O, storage, CPU-hour, document-processed, etc., or a combination thereof), but that can have adverse performance impacts and can introduce larger integration headaches.
In an ideal setup, the "contractor" adapting and deploying the open- (or closed-) source software for a particular company's use also gets a cut of the fees, just like the originators of the software.
This structure would be ideal for smaller companies that can't afford or might not want to pay the full up-front cost for the development and/or configuration and/or deployment of software they need ...
* these companies don't have a lot of money to spend, but independent developers might be willing to develop (permanently- or temporarily-)closed-source software for the companies' use cases ... and to get their compensation based mostly on a "commission structure"
* the company needs might be already satisfied by existing open-source software, but the company may not have expertise in configuring, adapting, and deploying the software -- in this case the deploying expert would hopefully share their fees with the open source software originators
* agreements could sunset the "acquiring" company's exclusive use of this software so the developers can start selling the software elsewhere as closed- or open-source software
There are surely many complications to a model like this, and perhaps can easily work only in a "high-trust" environment ... but it lets developers with a tolerance for risk avoid the illiquid equity trap of stock compensation, while letting companies build their service for less and issue less stock. There are surely scenarios where this would be attractive to larger companies as well.
I'm currently exploring starting a company that incorporates these concepts, I'd appreciate some discussion if this interests you. (You can find instructions to derive my email address from my profile.)
The effectiveness of asking for donations can vary a lot, and in my experience it is not sustainable at all, unless your project is wildly popular, or it supports the needs of an affluent and passionate user base.