How I can monetize GNU GPL product developed (and currently updating) by me?

Question

I am a developer of Open Source product under GNU GPL license. I always looking for some time and power to make important changes in it (fix bugs and add more improvements), however, it becomes harder and harder each new time.

The GPL idea looks great, people should not overpay for software, I completely agree, but does it mean there should be a valid and legal way for a developer to get enough money from his product? Please share ideas.

Here are my points:

• Paid support - it works, but it's not great. If a developer (like me) want for his product to be awesome and useful, he usually created the documentation for it, meanwhile making his income smaller. It's a discrepancy.

• Automatic updates - it also works, but there are lots of 3rd-side companies who proposed an automatic update of lots of GPL products (including my one) for smaller money. For example I get $10/y for automatic updates and I have only one product. While these ones who resell thousands of such GPL products only takes $10/y for everything. In the perspective, I have no chances.

• Begging for money - no, please. I am not a bum and I'm very frustrated by the idea that I will try my best for someone to give me a coin out of pity.

• Selling an advertisement - no way, anyone can change GPL product and he will remove this from the product or put his own ads. And I think it's even illegal for GPL.

Answer 1

There is no known solution to the “economics of open source” problem. Some projects try to apply more restrictive licenses so that the “correct” maintainers can capture a larger part of the value chain. Yet such licenses are frequently non-free or have other flaws, e.g. see the discussion about the recent SSPL license from MongoDB.

Three financing models tend to work fine:

• The project is maintained as a hobby. There will always be more work than can be done, but that's fine.

• The project is sponsored by individuals or companies with a direct interest in this software. For example, a consultant may create some libraries and happen to open source them. They maintain the project because it helps them with their work – they'd have to develop the software anyway. Another example would be companies that profit by hosting a software, or need the software internally. Projects like Linux, Wordpress, or Discourse fit this bill. Advertising or developer relations may also play a role (see e.g. Microsoft's current open source strategy).

• A foundation or individual gives out grants for specific work on the project, where the foundation's budget comes from donations by individuals or companies.

A few strategies that may work but have issues:

• A strategy that works for a few people is relying on small donations, Patreon-style. But whether this works depends more on your user base and your social media presence than the value of your work.

• Something I've also seen is selling pre-built official binaries, but I feel that is unfair to users that don't have as much technical knowledge, and it creates a perverse incentive to make the build process as complicated as possible (e.g. I think the Ardour project is toeing the line here). This is similar to your idea of selling updates. The idea is not to extract money from every user, but only to capture some fraction of the software's value.

• Quite a lot of projects try to make money through dual licensing with a free copyleft license and a paid more permissive option. This tends to only work for libraries, or for white-label applications. The iText PDF library is a successful example of this.

  The problem with this approach is dual-fold:

  1. The copyleft license is usually more permissive than the maintainers might think so not many use cases do not need the paid license.
  2. Dual licensing only works if outside contributors sign a CLA. Outside contributors do not profit from their contributions. A CLA also enables the project to switch licenses in a future, and possibly stop being open source (see e.g. the MongoDB and Redis license changes in the last few months). A CLA is not just extra bureaucracy, it is also a deterrent for contributors.

In the end, it is important to remember that the GPL does not address any economic points at all. The intention of the GPL is only to maintain end user freedom. That GPL software is usually free of charge is not a direct requirement by the GPL, but a consequence that monetizing software under these freedoms is quite difficult.

For the open source project I maintain, I've decided to keep it exclusively as a hobby. Monetization such as setting up donations is not going to be worth it (because this would complicate my tax filings substantially). Users are free to ask for features or bugfixes, but I don't feel obligated to deliver anything. This means the project is quite crappy in some respects. I tend to focus my work on supporting users and other developers. I.e. instead of developing a feature myself, I try to make it as easy as possible for someone else to implement it. But this is not really a financing model, more like an anti-burnout barrier.

Answer 2

I'm going to suggest revisiting support & services as a business model. It works. It worked to fund my previous project, and it worked for my current employer (a $5b company that just got acquired for $34b).

Yes, balancing improved documentation and automation against potential lost services revenue is annoying. However, my experience in three different companies has been that customer demands are insatiable, and as soon as you automate away one headache they will find another one for you to solve.

The hard part about the support & services model is that you have to split your time between working on customer problems and working on improving the software. Speaking from my previous, proprietary software company experience, though, this is true for any software business that has customers, even ones that collect license fees.

The good thing about support & services is that it keeps you in close contact with your user base, which means that you have a much better idea which bugs and missing features need to be addressed soonest.

Caveat: Support & Services works well as a business model for infrastructure software, enterprise software, and things like storage. It works a lot less well for software marketed to developers, or personal end-user software. In both of those cases, your user base is more likely to do without than to pay.

Answer 3

If "updating" in your Subject line includes enhancements, I'd suggest forking your project into its existing gpl/free version, and a new for-fee, non-gpl professional version that includes future enhancements/features/support/etc. And hopefully your product is sufficiently useful that its serious user base will be happy to purchase that professional version.

This is assuming you're the sole developer and sole copyright-owner of the software. Then all current users are licensees under the gpl. Therefore, if any of them develop enhancements, etc, based on your code, then they have to distribute their new-or-modified source (if they distribute anything at all) as well. But you're not a licensee; you're the one-and-only copyright-owner. So you're the only person who can develop and distribute enhancements without releasing the corresponding new source. And that gives you an opportunity to monetize your enhanced versions, leaving the current gpl'ed version as is.

So go figure out some really cool, value-added enahncements that you think serious users would likely be willing to pay something for. (And don't forget my 15% commission for suggesting the idea:)