It is not to hard to make living off open source for a solo or very small team of developers. There are many revenue models around open source and they have been documented elsewhere. They include providing services like hosting (Wordpress.com) to support (RedHat), plugins (SugarCRM) and "Enterprise" editions (GitLab)
But each of the approaches requires that you get serious traction.
The key here is to stay independent of revenue for the longest time as you can. This is only possible if you are willing to work as a solo developer, working part-time till you hit certain traction numbers.
Open source is a hard and long game as a business. On the plus side, it is very satisfying and if you are able to sustain. There are many domains where open source is already winning big (OS, infrastructure, databases, web) and as new areas "fall" to open source, the risk on the closed-source side will also keep on increasing.
> But each of the approaches requires that you get serious traction.
Which is part of what makes proprietary software so much easier: you don't have to have "serious traction". You could even do something like bingo cards and make some money at it, growing the business a bit at a time.
Well, long story short, if you want people to pay you, they need incentive to do so. And unfortunately, the MIT license provides no incentive to do so.
Those with the cash to spare and the desire to do so will donate, just as they always have. Those without either, will not donate, just as they always have.
It reads like a plee to a user's conscience, but lacks any teeth to have any more effect than any other permissively licensed donationware.
if you want people to pay you, they need incentive to do so. And unfortunately, the MIT license provides no incentive to do so.
Software is free. Experience is what counts.
You can make money by writing broken software then charging for fixes. MongoDB has their bananas valuation because they released hype-driven broken software, got it deployed globally, then everybody realized "this doesn't work! we need support!"
If your software is free and works flawlessly, average users are less inclined to pay for it. If users have money riding on top of your software, they will happily pay for commercial guarantees and support.
These days you have to release everything as open source, hope it gets wildly adopted, start getting it deployed bottom-up in large organizations, then offer large organizations support and SLAs on the software they bought.
(This is for software though. The other approach is obviously just make everything as-a-Service so everybody is paying based on their usage.)
This is already a solved problem. It's the author's Option 3, but without the silly guilt and donation pieces.
Dual license your thing so that it can be used commercially for a specified monthly fee, with a mechanism for paying that fee (and that fee being actually spelled out rather than handwaved at as in the article). You've written useful software. Charge for it.
Asking for donations physically can't work, as the commercial organizations you'd want to donate often don't have the legal ability to do so. They can buy things. They can't give money away.
Again, it's solved. The author just seems to feel bad about the solution, so he's trying to implement it while apologizing for every step. Seems a bit silly.
> They can buy things. They can't give money away.
Can someone explain this to me? Many corporations support the Red Cross, the American Cancer Society, youth basketball clubs, etc. in various ways.
Why is contributing to the advancement of science and public goods any different? It seems like that should be easier to justify if certain technology is critical to your business model.
That money is usually budgeted for charity, and probably can only go to "legal" charities (at least in the US there are tax benefits to this)
It is probably much harder to compete for a piece of that budget, and also there are a lot of hoops to jump through to become a "legal" charity (in the US, I don't know about other places). Since companies are already used to purchasing software, that is probably a much simpler way to go.
I think they can. Just call it a purchase. That's what I do. I have "purchased" licenses from many MIT licensed projects. I intend to do it for every one I put into my project (once I have it figured out). Also, libre office, mozilla, etc. It just goes into the 'software' account.
I don't think the IRS is going to give a shit. Other companies may have shareholders who cry a little, but they could do it, at least to some level. Sending some love to Debian is a better option than paying for a MS license in some cases.
I think that the companies can and should support FOSS more. Especially if they don't want everything to end up GPL'd.
No, Option 2 was Dual Licensing using a mean version of GPL to make it awkward to use your thing commercially. You actually went out of your way to title it "Difficult Open Source".
You can still do separate hobbyist/commercial licensing with your MIT license, and not impose any restrictions on your users. Apart from asking your commercial customers to pay.
Amazing. I didn't know that. The lengths software people will go to avoid getting compensated for their work, eh?
So yeah, scratch the above then. You'll have to dual license with a modified license for non-commercial use. Same idea, slightly different execution (but still no need to go to GPL extremes if you don't want to).
Any non-commercial license will have to have implications similar to the GPL, and thus scare off most users, prevent projects from wanting to incur this as a dependency, and so on. It is one way to go, but will seriously limit reach. Also, as I said, it'll require contributors to sign over their rights.
The GP said "asking" commercial customers to pay, which you can.
You're right too, you can't constrain commercial use but that doesn't mean you _can't_ sell something that you MIT license it just means that people have the option to try and acquire your MIT licensed software from one of your licensees (or their sub-licensees, etc.) instead.
Because that's the deal they made with you when they started using it. "You may use this software free of charge for non-commercial uses. Commercial use is allowed under our [Commercial Use Agreement][0]", etc. etc.
You're selling software to companies with legal departments for an amount that, frankly, isn't worth the hassle of trying to scam you out of at the risk of you suing them. Companies really do pay for software based only on the software company asking them to do so.
Option 4: sell support contracts. As @jasonkester mentioned, it's a lot easier for many companies to buy something than it is for them to donate. Red Hat became a billion dollar company doing this.
Support contracts put a lot of obligation on you, so should be priced accordingly (aka high). Combine it with #3 to give an out to those who can't afford and/or don't want the support contract.
I've been doing this for years with CodeMirror, but it has been A) a lot of bureaucracy to start and renew such contracts, and B) still not really a big enough source of income to cover the maintenance work.
Sure, but you've only been selling them to people who actually need the support. The key is to also sell them to companies who don't need the support. In other words, include your imprecations against free-loaders.
One thing I'd recommend: have a way to invoice companies monthly who have agreed to pay you monthly.
For us: No invoice? No payment. (I'm not arguing whether that should or should not be a fact; I'm just stating that it is a fact for us and I doubt we're alone.)
Every non-trivial business will have accounting controls such that they won't pay out anything other than payroll without an invoice. And possibly a purchase order as well. Not doing this leaves you open to internal fraud.
(There's still a risk of external fraud, some big companies will pay invoices without checking ...)
They go through audits every now and then, where every single cent needs to be accounted for. "Oh, we ACH'd some money to that cool developer over there" doesn't fly.
Those audits may be for tax reasons (once you send an invoice, the payer can expect you to do your own taxes on that stuff, and they're off the hook) or to see what it's actually spending its owners' money on, which is especially important in public companies.
I don't work in finance, so for me the reason is "because finance won't pay otherwise", but I strongly suspect it's an anti-fraud accounting measure.
Would I pay more to be able to get invoices? No.
Well, technically yes, in the sense that I'm willing/able to pay $0 unless you can invoice, but otherwise, I won't pay an "invoicing fee" as a line-item surcharge any more than I'd pay a "printer paper fee" or an "electric lighting fee". Present the total invoice, and what you spend that money on internally is your business, not mine. If you need $1 for the invoicing process and I've agreed to pay $50, then $49 into one bucket and $1 goes into the invoicing bucket. I agreed to $50/mo, not $51/mo.
The economic motivations that drive FOSS development haven't really been done justice in the peer-reviewed literature on the subject. We used to say "Money, Glory, and Fun" were the reasons, and to some extent that was and remains true. However, I think there's always been quite a lot more to it. After the collapse of the dot-com bubble, there were a LOT of developers, particularly junior level developers, who couldn't find the kind of work they wanted and hoped to find after college, and committing to Open Source projects was a great way to get a kind of apprenticeship with some of the best development teams in the world. Participating in those efforts exposed new developers to new ideas, new ways of building software with distributed development teams, and more often than not exposure to world-class software. The monetary value of that sort of software engineering apprenticeship is hard to gauge, as you typically can't get its equivalent in a corporate internship, and many university CS programs rightly prioritize computer science over software engineering skills.
Crowdfunding open-source projects can work and has worked to get them going, but the "big bang" model of crowdfunding -- a single large payment at the beginning -- has two problems. First, you have to persuade people of the usefulness of your product before they actually have a chance to try it out. This is sometimes possible, but often difficult. Secondly, as anyone in the software business knows, most of the cost of a mature software product is in the maintenance, which can stretch on for years, not the initial development.
For these reasons I think a different approach to crowdfunding is needed: one that is finer-grained, collecting smaller amounts of money for smaller units of work, and that is designed to work on an ongoing basis.
The reason I think this could work is that the developers of a successful open-source product actually do have something to sell: their time. There are always bugs to fix and new features to implement, and crowdfunding contributions can be a way for users to vote on what they want done next.
I am really, really struggling to understand how someone can make a voluntary and conscious decision to release software for free, under a license that permits unlimited redistribution, and then call the people who follow the terms of the license they explicitly chose "freeloaders."
What resources are they using, though? Marginal cost of copying the code is close enough to zero to practically be zero. The project consumes the same amount of resources regardless of whether or not any one user decides to use the software. In other words, where's the "load" in freeload when someone uses open source software under the terms of its license?
It's more of a moral argument. We want open source available for people to use for small projects, but once large organizations take our software and make billions of dollars on top of our architectures without contributing back to the 5 people who made that possible, it's disingenuous.
My general rule of thumb is: if you are a large organization using community powered open source software, you should be paying individual project communities 3-5 senior engineer salaries per year. If an open source project has 5 million users, the creators shouldn't be sitting around worried about making ends meet. This isn't about token gifts of $10k or $50k per year in "community sponsorship." It's about sustaining and growing projects big companies rely on to function in the first place.
The resource is the time and expertise of the people contributing to the projects.
If someone only ever pulls code from open source repositories, and never contributes (either with money, code, time, etc) then I think the 'freeloader' label is valid.
Someone using the "cost of copying the code" argument has nothing worthwhile to say, as they haven't actually thought about what goes into the code. Here's a hint: The GitHub fairy didn't magically add that code to the repo.
Trying to guilt-trip people into paying your absolute costs after you've already given them everything for free is a losing strategy. You either need to charge for complements yourself (support, dual licensing, something) or you need to get money-hatted by someone else who can do those things, like Red Hat.
I think I did an okay job describing the benefits of open-source distribution in the blog posts. Releasing software in that way can be the statement 'I want this to have maximal reach', rather than 'I work for free'.
It's really not that hard. The idea is that the people using the software are a community, and as such should be working together to make the software better. If you're just using the software, and not contributing back fixes, or offering financial support, then you're just taking and not giving back. Hence, the freeloader. Legally, the licenses do allow for that. Ethically, though, it's a problem, and makes you a bad person.
I feel this sentiment as well. However as I understand it since there isn't an existing license that covers this need the author's approach is current best practice. Practicality over ideology.
I like the idea of running crowd funding campaigns to release software as open source. This could be done for certain milestones (like feature X or platform Y) in a longer running or bigger project. I would even think it's fair if the developer included a maintenance cost into the amount he wants to gather before releasing the software.
It's clear to users what they are giving money for. Also the incentive is bigger to contribute because before the amount is reached, the code isn't released. And for the developer, it's more predictable than donations.
Of course, this still wouldn't work so well for maintenance heavy projects that don't gain a lot of features, like security sensitive infrastructure like openssl.
I think it might be an interesting approach to run a kickstarter-style campaign for each major software release, and once the goal is reached, release the software with a normal open source license. Nothing would stop other developers from forking the software, but if the author was providing enough value, I believe people would contribute.
I have one particular open source project that I started back in college that's actually paid off a little bit over the years as it's become more mature. In total, I've probably received ~$20k between custom development and commercial licenses (it's AGPL, so option #2 in the article). However, given the amount of time I've put into it, it still pays less than my current job, and probably even most of the jobs I had in college.
Most of my other open source work gets released as MIT and I have zero expectation of getting any direct money from it. (Although, my open source work has undoubtedly helped me get my current and most of my recent jobs, so there is a fair argument that it's earning me money indirectly.)
I have a kickstarter project that's surpassed it's funding goal to support the development of a not-yet-existing open source project. Im 99% sure it succeeded because I'm already entrenched in the community it is targeted at, which doesn't help the diversity angle. It is encouraging for me because it allows me to dedicate myself exclusively to open source for the remainder of the year.
The best way to monetize open source it to sell optional plugins and services around your core open source product. This isn't always possible though - It depends heavily on what your project does and how it's designed.
Generally; open source platforms, frameworks and operating systems are easy to monetize because they are at the base of the software stack - They own the environment in which people build apps.
Libraries and modules, on the other hand, are difficult to monetize because they are only small parts of an environment over which they have no control.
Fitting copyable things into the capitalist market economy is something of an unsolved problem.
No it's not, it's the same problem that market economies have been dealing with since the invention of the printing press... the solution was a legal and financial concept known as "copyright".
I remember the battle in the 90s. Slashdot vs. the MPAA/RIAA. The "good guys" who were for "freedom of information" and the "bad guys" who wanted to limit what we could do with our technology and make it illegal to circumvent copyright protections...
...and then the "good guys" won! DVD John, Napster... information must be free!
It's quite clear that anti-circumvention laws were not the best approach (they should have put those resources in to things like SoundExchange much earlier), these negative aspects of copyright have unfortunately dominated the conversation since.
Fast forward a decade, and what do we have... well, we're starting to see what happens when you get rid of treating intellectual property as something that can exist as something to be bought and sold in a market economy.
It's not like the whole concept of private property or ownership went away. For the people who own stocks in Google, Apple, Facebook and the other billion dollar companies who deal in distributing and organizing digital media, they've made plenty of money.
Open-source software is funded by corporate coffers. The people who make the software don't get to own anything while the corporations get to use these freely created tools to increase their share values. The vast majority of open-source developers are on corporate payrolls.
Not only are developers giving away their intellectual property, but so are the majority of individuals who the create digital media that drives the eyeballs to the advertisements. The "creative commons", where everyone freely distributes their creations in exchange for comments and clicks...
It is quite clear that digital media does have value. If Google had nothing to index, or if Facebook had nothing to share, there would be no one using these services, and therefor no one to sell any advertisements to.
Yet we have no way to price how much this media is worth. It never enters a marketplace. It is never bought and sold. I'm not sure what kind of creative accounting they have at places like Twitter but I'm sure they don't have a good idea of their actual business inputs and outputs. There's a giant air-gap between users creating content and advertisers buying space next to it.
Because of the fundamental economics of refusing to considering digital media as intellectual property in a market economy, the only profit model is to make the services free and then degrade the products through adding noise to the channel. Now product designers have to actively fight with their organizations profit structures. The result? Crappy and bloated products with crappy content, a plague that has been sweeping web publishing that seems to be increasing by the day if the tech blogosphere is used as a thermometer.
Advertisements do not pay for content. They pay for hosting, distribution and employee salaries. They pay to keep the lights on in Mountain View.
All sorts of hair-brained schemes are dreamt up to try and deal with it, but none actually treat digital media as property. Kickstarter is about the project. The people who support a project are not investors. They don't get equity or ownership, they get t-shirts. Patreon is about the artist. The people who support the artists don't get equity or ownership, just a "worthless" digital media file. Artists are told to sell merchandise and tickets and in-home performances and anything and everything under the sun other than what they are best at making, an absurdity that defines the early 21st century media landscape, as if somehow we can fix this problem if we just convince enough people that they need a closet filled with hundreds of "I supported an artist" t-shirts.
The only place where intellectual property is still honored is with the old giants of the 20th century, the book, music and moving pictures industries. These industries were built on top of the foundations of copyright. Artists create, own, and put their property on an actual marketplace. Companies who own IP and treat it as such on their books have a clearly defined view of their "content creation" accounts as being profit-makers. Speculative investment through publishers creates an incentive structure that aligns itself with the rest of our market economy.
The digital music industry has already ceded the battle to IT. When Sony negotiated with Spotify to put their back-catalog on this new service, they had the presence of mind to know that what really mattered was equity in Spotify. Their recordings and publishing rights were "worthless". A rival service named Tidal offered it's artists ownership in the corporation as opposed to contracts related to their IP for the same reason. Seemingly out of nowhere we're seeing a drastic increase in vinyl records, but I would argue this is less a hipster trend than a return to an economics model where the music itself is given value.
What I find interesting and ironic is that an industry built on information has not only conceded that information is worthless but celebrates this fact. Then we dream up things like "basic income" in order to create a world where the 99% who don't own anything can survive. We're all well aware of the relationship that labor has to capital. We're all well aware of the economic reality of scarce physical resources. In the real world, not everyone can own something. However, anyone has the ability to create intellectual property out of thin air and benefit from owning it like any other capital.
Somehow we blindly believe that things like basic income seem easier to implement on a societal level than accounting for ownership of digital media. We'd rather throw private property out the window then deal with it's complexities. Haven't we been here before?
---
I'd love some feedback on this stuff and I know some of these ideas are half-baked, but everywhere I look I'm seeing the same root issue... we've decided to give up on hundreds of years of treating intellectual creations as property that can be bought and sold in a marketplace, and doing so we've made it very hard for people who make digital media, be it a software library or a song, to survive in a world built on top of private physical property.
But each of the approaches requires that you get serious traction.
The key here is to stay independent of revenue for the longest time as you can. This is only possible if you are willing to work as a solo developer, working part-time till you hit certain traction numbers.
Open source is a hard and long game as a business. On the plus side, it is very satisfying and if you are able to sustain. There are many domains where open source is already winning big (OS, infrastructure, databases, web) and as new areas "fall" to open source, the risk on the closed-source side will also keep on increasing.