I tell every entrepreneur that asks me for advice that the donation model for any business gets no more than 1-10% (depending on the industry) compared to a business model of selling commercial software. This is the difference between poverty and 6-figures. The open-source model is good for launching your own career, but you should avoid trying to make the career the open-source project itself.
The open-core model is a good alternative if you wish to be around open-source software. Or make your project de-facto standard and charge for consulting. Or, you can make an entirely commercial project that uses and contributes to open-source projects. That way, you are surrounded by open-source and can help them financially to add features you need.
Consider public-private licensing. Choose a license that requires sharing back, or limits to noncommercial use, and sell individual exceptions to that rule. https://indieopensource.com/public-private/indies
This, I think, is the key. The few projects I'm working on right now are not at the point where business logic would come into play, but all contributors are in agreement that they would support this model over all.
It allows the public to continue to use your work to collaborate and create better things, which is the point of open source, while allowing businesses (which should be able to afford to license a software product) to still pitch in and generate a profit. Both of these will attract talent and interest and allow collaborators to prosper.
This approach is as old as the hills. From RMS' Copyleft: Pragmatic Idealism:
> Many years ago, a friend of mine was asked to rerelease a copylefted program under noncopyleft terms, and he responded more or less like this:
>
> > "Sometimes I work on free software, and sometimes I work on proprietary software---but when I work on proprietary software, I expect to get paid."
>
> He was willing to share his work with a community that shares software, but saw no reason to give a handout to a business making products that would be off-limits to our community. His goal was different from mine, but he decided that the GNU GPL was useful for his goal too.
The approach is far more common in other kinds of licensed, creative work. Creative Commons' choice to standardized noncommercial license terms helped make commercial-noncommercial licensing familiar in photography, illustration, music, and so on.
The model has gone by a few names. Those researching should search on "selling exceptions" and "dual licensing", too.
Some of the times when people would repeat things RMS said about sustaining Free Software work by making money from consulting on the side, this seemed misleading.
I understand RMS was at times the beneficiary of people who were sympathetic to his mission. For example, students said at one point he was living in a university office that someone arranged to be allocated to him.
Personal sacrifices like this, towards his principles, were to RMS's credit, but the suggestion that one could just pick up consulting work on the side seemed misleading. RMS was one of the better programmers, and famous, and even he didn't seem to pull off that sustainability reliably.
RMS originally made money for FSF by selling copies of Emacs and other programs on tape. That was back when the first person to buy on physical media couldn't just slap on the Internet.
That's before my time, and I think some of the stuff I heard about was from when most people were getting GNU software via FTP, and later. (Though FSF sold paper books.)
The term "free software" was effectively coined by RMS & The Free Software Foundation. It is used explicitly when referring to copyleft licenses, which restrict certain uses of the licensed software in order to protect user freedoms. You can argue that other people use the term in other ways, but the most commonly accepted definition is the one used by the FSF.
The term "open source" is somewhat vague. Software that is merely "open source" is not necessarily licensed in a way that allows redistribution/modification. The only thing guaranteed about "open source" software is that you can read the source.
>The only thing guaranteed about "open source" software is that you can read the source.
'Open Source' was/is a rebranding of the term 'Free Software' to make it easier to sell to suits. Eric Raymond has said as much about his invention of the phrase. The idea that it's just about "being able to read the source" is wrong. It's not vague at all, you just didn't do your research.
The only people looking to redefine (yes, redefine, there is no supposed ongoing dispute or vagueness about what it means to be FLOSS software) are those looking to push their own agenda, its not an honest conversation and never has been.
What is and isn't FOSS is not clear and never has been, when it comes to copyleft. We could rewrite any copyleft license as a limit on use. Don't use this MPL library to build a closed, competing fork. Don't use this GPL program to build a larger, closed program. Don't use this AGPL framework to build a closed web service.
> What is and isn't FOSS is not clear and never has been, when it comes to copyleft.
OSI and FSF would disagree.
> We could rewrite any copyleft license as a limit on use.
What is the purpose of your argument? What are you trying to achieve? Do you want a Lobjan specification of FOSS? There may be difficult cases around the edges of the definition of FOSS, but restrictions on commercial use are not one of them.
OSI itself hosts the best evidence that its Open Source Definition isn't clear: its license-review mailing list archives. Have a look sometime!
As for FSF, their process for considering licenses is a black box. We have "What is Free Software?", published largely in response to the creation of the Open Source Initiative. But it's no more a technical specification than OSD is.
I never claimed that restrictions on commercial use are "open" or "free", or that any particular license that does so is "open" or "free". I have and do claim that neither OSI nor FSF provides any clear, complete guidance on what "open" or "free" copyleft can and cannot do. Consensus within the relatively small groups of folks actively engaged with those institutions is founded in good-sounding generalities, not any rigorous definition.
> never claimed that restrictions on commercial use are "open" or "free", or that any particular license that does so is "open" or "free".
There was enough ambiguity in your statement on public-private licensing that I felt the need to make the clarification. My intention was a much a "public service announcement" as anything.
> I have and do claim that neither OSI nor FSF provides any clear, complete guidance on what "open" or "free" copyleft can and cannot do. Consensus within the relatively small groups of folks actively engaged with those institutions is founded in good-sounding generalities, not any rigorous definition.
A fair contention, though I might disagree. However, that does not change the fact that non-commercial licenses are not FLOSS. Both the OSI and FSF have made that patently clear.
Your initial advice was fine, I just want to make sure that people who follow your advice don't confuse non-commercial source-available licenses with FLOSS.
As an author of some niche open source, I've tried simple licensing like that (e.g., "GPL, or ask me about other license"), but the software had only a few commercial users that I know of, and I never made a penny that way.
You need commercial users who want to use your stuff enough, and the GPL/LGPL/whatever license won't work for them, such that it will get pushed up to someone who'll follow through and negotiate a license.
(You also need it to not quietly be used by parties ignoring the license, like has happened many times with Linux and certain GNU-ish libraries that would be expensive to reimplement.)
I've advised a number of clients away from public-private licensing toward simply approaching their clientele directly and pitching traditional software deals. Some who manage to sell licenses that way choose to release their work under copyleft or restricted terms, after the fact.
The tell is a known, small, approachable target market. Especially when the developer already has positive relationships with important would-be customers.
A very good example on this is Vue.js. While it is very popular, a quick look at the donation amounts on Evan's patreon page gives a good reality check for those who are dreaming of living off donations.
Vue.js is one of the most used JavaScript frameworks out there.
If this was a commercial project, his income would be magnitudes higher.
Yes, $20k a month is comfortable. But is it appropriate given the popularity of Vue and considering how many organizations profit from it?
Now, if you scale this down to a framework that has half or a quarter of that popularity. When do you reach the point where it isn't comfortable at all anymore? And does that still seem appropriate?
> If this was a commercial project, his income would be magnitudes higher.
If it was a commercial project I imagine there would likely need to be other staff involved, and adoption would be lesser. Whether that ends up being more or less money for him in specific in the end (or whether the project/company would survive) is not without question, in my mind.
The argument you make is quite popular. I'd say adoption would only be lower because there's competition that's also MIT licensed. And if that wasn't there, every framework author would be better off (e.g. in a public-private licensing scenario).
It will be hard to find evidence for both sides I guess. So it boils down to being kind of a gamble: adoption or fair compensation — you can't have both.
This looks like a race to the bottom to me, which is what the data presented in the article seems to support.
If this were a commercial product, he owned the company and wasn’t an employee, and he could still get the widespread adoption that open source can bring.
I might suggest for a company to use VueJS since it is open source and donate but I’m never going to suggest that a company bases its product on Telerik components.
That's not all, as he's pulling revenue from multiple sources with Patreon being only one of them.Even with extremely conservative estimates he should be making at least $500K. However the point of my previous post was that one needs to take his project to stratosphere for it to generate anything substantial using this model.
Or, phrased differently, he's already doing whatever he's doing, and $20k/month is just one income stream.
I'm a developer who's presented at conferences. I don't consider that "another" job, but rather, part of this job. And I don't have any monthly donation income coming in at all.
That's hardly another job. It's completely based on Vue. I know if I needed an expert on it and he was available that he'd probably be my first choice.
Is this advice based solely on your own experience (I see that you are an open source creator, thank you), or are basing this advice on actual data that you have collected/analyzed? If you have actual data would you consider sharing it?
Absolutely. Imagine how much more you can help if you had a team helping to build and grow your website. If you want, don't take a dime for yourself and instead invest it all into growing your business and helping others. If you're delivering something that gives real value to someone's life, and it's priced correctly, they will pay for it.
Can you help anyone if you're homeless on the street?
At some point there is a trade off to any number of choices. I choose to keep active employment, and open what I can, when I can. Mostly utilities that I wrote for work that aren't core functionality that it makes sense to separate out anyway. Heaven help me if something got too popular and people wanted a support model.
>Here is my great question, can I help more, if I charge money?
It depends on which dimension of "help more" you want to affect.
I looked at your website "efficiencyiseverything.com" and here's how I would break it down: "more people" vs "more features"...
- if you want to help more people, it's better to keep it free because no subscription/paywall payments means the biggest audience (including those without discretionary income) can be helped by your information
- if you want to help less people but add more features, you should charge money. The paying audience will always be less than a non-paying one but the ones who do monetarily support you can be assisted with new website features that requires revenue to develop
(One can sort of try to get the best of both of the above scenarios by keeping it free with voluntary donations but to me, that just simplifies down to "free" since the percentage of donators will be very small.)
>if you want to help less people but add more features, you should charge money
I would add one more thing. It would help less people in short-term, but in long-term, it might actually end up helping more people, as those features have the potential to attract way more people than you would have gotten without those features but for free.
You would be able to afford helping more if you charge money, now you're your boss, you charge based on what you believe and know you need to survive and based on periods where you aren't consulting.
The open-core model is a good alternative if you wish to be around open-source software. Or make your project de-facto standard and charge for consulting. Or, you can make an entirely commercial project that uses and contributes to open-source projects. That way, you are surrounded by open-source and can help them financially to add features you need.