The licensing and distribution model for open source make it impossible to simply sell your open source product (i.e. you don't want to sell support, charge for documentation, create a SaaS, or create tiers of closed source and open source - you just want to sell your open source product direct to customers).
An alternative option is 'source available' - give your customers access to your product source code and permission to modify the code to meet their needs but without right to distribute the product. Lots of open source developers dislike this model, but it's up to you to make up your own mind.
I wrote a bit a bit more on this topic in the following recent discussion on HN about on how to make a living with open source. There lots of comments and differences in opinions. Worth a read:
Ask HN: Dear open source devs how do you sustain yourself:
Training or writing books about the software you wrote. For example Wes McKinney is the creator of the Pandas library (https://pandas.pydata.org/) and wrote the "Python for Data Analysis" book.
I don't know all of them, but I can list a few. There are some possibilities:
- Binaries: Some users will pay for precompiled software, so that they do not have to compile it by themself. You might find this sometimes in some "app stores".
- Physical components: You might sell hardware, printed manuals, DVDs, etc.
- Paid support: You can sell support to customers who want priority support and/or professional support. SQLite also has paid support, and in the case of SQLite, this paid support also includes testing.
- Hosting: If you do not want to install and host it by yourself, the company that makes that software may do it for you, if you pay them to do so.
- Dual licensing: Some software has dual licensing, such as Ghostscript and Swiss Ephemeris. SQLite also kind of does; you can pay for a license, even though you won't really need it (since it is already public domain), but it is there in case your company's legal department requires you to have a license.
- Customization: If you do not want to make the changes by yourself, you may be able to pay them to customize the software for your use profesionally.
- Proprietary components: I do not really recommend this for must cases, but it is sometimes a possibility.
- Installation: Payment for the company that produces the software to install it properly, where the customer requires it.
People pay for Value. And usually what they buy is not software. [1]
So how you monetise depends on what you are making, and who the target customer is. B2B software is more about services and support - B2C is more about instant gratification and convenience.[2]
Making money just selling software is hard now because the market is saturated. All word processors do the same task, but I use MS Word over LibreOffice because of network effects.
So the answer to your question is to figure out where your value offering really lies, and focus on that. The software license is not the critical factor.
[1] Google does not sell software, it sells search results. Facebook sells community and so on. Oracle /Red hat doesn't sell software, it sells backup, services, reputation and so on.
[2] every so often there will be a thread here complaining about someone selling open source. But compiling and shipping updated binaries adds a value and saves me time, so I'm happy to pay for that. (and of course it's completely within the bounds of most open source licenses)
There's also the "open-core model"[^1]. From the Wikipedia description:
>The open-core model is a business model for the monetization of commercially produced open-source software. Coined by Andrew Lampitt in 2008,[1] the open-core model primarily involves offering a "core" or feature-limited version of a software product as free and open-source software, while offering "commercial" versions or add-ons as proprietary software.[2][3]
Here's GitLab's CEO[^2] talking about "Offering an on-prem / self-managed version of your software"[^3]
Here's a timestamped video titled "E05 Pioneering version control for data science with Pachyderm co-founder and CEO Joe Doliner"[^4], where Pachyderm's CEO[^5] addresses the business model.
Here's a timestamped video, titled "How to Find Product Market Fit", of Peter Reinhardt[^6], where he answers the question of "why would someone pay anything for an open source library that's 580 lines of code.."[^7]. There's a blog post detailing this, too[^8].
There are several degrees of what is open-source and what is not, and different ways to build a business around that.
Can someone please explain how is the dual license work? Should there be any differentiation in the product, for example, community edition vs enterprise edition?
Also, how is the sponsorship work? For example, OBS Studio has Facebook and Twitch as sponsors.
Dual license can be on different products, e.g. community edition and then you have extra binaries or plugins which come with a commercial non-open license.
But it can also be by use case. MongoDB's has extra requirements for those who run services (database-as-a-service) and thus who compete against MongoDB, the company. https://en.wikipedia.org/wiki/MongoDB#Licensing
Sponsorship is hoping companies rely on your software enough to open their money pockets. Or to have a strategic interest, e.g. by keeping something open/free that a competitor charges money for. https://letsencrypt.org/sponsors/
> Will people pay for a license if there's no differentiation?
That is really a separate issue. If there is no differentiation from its competitors, then it may not be used at all.
People aren't generally the customers of dual-licensed software; usually companies that ship proprietary software are the customers. The typical model for dual-licensing is to allow the code to be used in an open source project for free but charge for the code to be used in a proprietary project.
An alternative option is 'source available' - give your customers access to your product source code and permission to modify the code to meet their needs but without right to distribute the product. Lots of open source developers dislike this model, but it's up to you to make up your own mind.
I wrote a bit a bit more on this topic in the following recent discussion on HN about on how to make a living with open source. There lots of comments and differences in opinions. Worth a read:
Ask HN: Dear open source devs how do you sustain yourself:
https://news.ycombinator.com/item?id=23218943