I don't own/lead any significant open source projects, but it seems like there are very few projects that even attempt to monetize via dual-licensing, service contracts, etc. Is there some major barrier to monetiziation (i.e. legal fees)? Is it a philosophical barrier?
Because monetizing your open-source project means you take on a second job.
Here are your choices:
* Turn your OSS project into a company (Docker). The pro is that you can capture a lot of the value, the con is that you're splitting your project into CE/EE and also now you're a CEO
* Give the software away for free and charge for the hosting (Gitlab). Pro here is that you get recurring revenue, but the con is that now you're in DevOps and wear a pager. Also this model doesn't work well for libraries, only "apps".
* Charge for support (Ubuntu, Nginx-ish). Pro here is that by helping folks implement your software, you'll have a long line of success stories. Con here is that it isn't scalable - your upside is bounded by the hours you can bill
* Get a job at a company that will fund you to work on it (React, Angular). Pro here is that you can make tons of money with a job you love. Nice work, if you can get it. Con is that now you work for that company and you're subject to whatever whims they have.
* Run a Kickstarter (Light Table, Diaspora). Pro: you can gauge demand and you don't have a boss. Cons: it's one-time revenue, you have potentially inflated expectations, and just kidding, now you have 1,000 bosses.
* Run a Patreon (Vue). Pro: you have autonomy and recurring revenue (yay!). Con: now you're a personality. This is limited to celebs who are good at marketing _themselves_ as much as their software
* Ask for donations (Babel, Webpack). Pro: this works for tools and libraries (not just apps) and you can keep your mission. Con: Companies feel these donations have ambiguous deliverables. There's a lot of mental overhead too (How many projects can one company fund per month?)
* Sell documentation, books, videos (React Training, my current gig). Pro: JavaScript fatigue makes you money! Con: Writing the docs isn't as satisfying as writing software (for many developers)
So to answer your question: monetizing your open-source project means you take on another job _besides writing software_.
In an ideal world if you write software and it gets used, you'd be able to capture some share of that value. But we're not there yet.
[If you want to chat more about funding OSS, reach out to me (see my profile). I'm working on a few new ideas.]
Ask for donations (Babel, Webpack). Pro: this works for tools and libraries (not just apps) and you can keep your mission. Con: Companies feel these donations have ambiguous deliverables. There's a lot of mental overhead too (How many projects can one company fund per month?)
I don't write software, but I have run various small websites for something like 15+ years. I have always gotten more donation money than ad money off my projects. I switched to a tip jar (last year, iirc) and that further improved my take. (It isn't much, but it beats the figures I have seen quoted by most people when data has been asked for on HN. I also don't get much traffic. For the traffic involved, I think it is pretty good.)
I have also seen Patrick McKenzie talk about the fact that he won't donate money to open source, but if you are willing to write an invoice for him, he is happy to give you money. The reason is that he needs to justify his business expenses on his tax returns and a "donation" is charity that he can't justify to the government, but an invoice for a product he uses in his work is a legit tax deduction. He has talked about how he thinks open source should make invoicing business customers painless. I don't readily have a source at my fingertips, but I bet someone on HN can come up with a link.
I don't follow his tweets, so that is unlikely in this case. It is vastly more likely to have been a comment somewhere on HN that I happened to read. (But that's a really great source you have linked to. Thank you.)
Very good list. I would add that most open source projects have many people working on them.
So suppose you actually manage get paid despite all that -- how do you distribute money fairly? This is a huge problem can could actually slow the project down by leading to hurt feelings. Ironically, it's almost better for the group if nobody gets paid.
Corporations have evolved all sorts of imperfect systems to solve this problem, but it comes at a tremendous cost (performance reviews, interviews, firing, all of HR essentially).
But the open source model of collaboration follows the principle of "least bureaucracy". It throws out all these "coordination costs" in the name of just getting the job done. No more and no less.
it's almost better for the group if nobody gets paid.
Relatedly: Studies show that paying people zero money and giving them respect gets better results than paying some pittance well below market rate. The study conclusion was to the effect of "Pay enough (market rates) or pay nothing. Don't pay some pittance because it is all your project can afford."
We used to have a freeware product that a few years after became a commercial product sold as a subscription.
When it was a freeware product, several people wanted to donate but we never accepted any donation, just to avoid the feeling of getting paid too low. Also I guess we were a bit equalitarian: we wanted that either nobody paid or that everybody paid.
In general quite well. It is a B2B product and being able to pay gives them some assurance that there will be someone behind. The freeware version continued to exist, and the transition to actually pay was long (free beta for the subscription lasted 4 months). We also did a heavily discounted launch promotion so that the transition from nothing to something was a lot smoother for existing users. Here is the announcement we did: http://www.apsic.com/blog/?p=25
Let's take a musical analogy - a 'group' group. With a four piece popular beat combo the royalties go four ways, it is all viable as a business. With a larger collective or an orchestra the money gets a bit tight - it goes forty rather than four ways.
But, this is something my internal dialogue says whenever I hear a musician talking about money (and where there share is...) - 'But you are in it for the music, right?'
This musicians seem to forget, they become businessmen and think the value is in the magic of their work and they should be paid for it. I wish they kept music as a fun thing rather than something they 'only do if paid' and for them to see hiring venues and doing tours and selling merchandise as what they need to do for money.
So, analogy is different to reality, however, we must remember why we do stuff for Open Source. Instead of looking for T-shirts and venue tickets to sell, we need to have real world needs for the Open Source code, to work on those problems and get paid for them using and contributing as required to the FOSS projects. As for expectation for pay from the FOSS project (rather than the day job) it should be 'you're in it for the love of music, right?'
Are you actually arguing that musicians should be into it only for the music and not get paid? If so I completely disagree and that's not my point at all. Musicians absolutely should be paid.
Software authors should also be paid. I'm just pointing out that there are some practical problems with it in the open source setting.
My ideal would be that essentially all software is open source, but everyone would also get paid. But I realize there are many reasons why we don't have that situation today.
The problem comes in when people expect professional level music, but insist that musicians should all do it for love while also supporting themselves with a day job. Professional level anything takes significant time and effort. If it has value to others, people should not object to the person providing that value capturing some of it so they can keep a roof over their head.
Sometimes, the answers aren't as simple and easy as we wish they were.
Professional musicians these days earn their living by going on tour and selling concert tickets and merchandise (esp. T-shirts). The biggest ones are quite profitable, and the concert ticket prices I've seen lately are rather high ($50 to sit on the lawn, $200+ for seats, for one big concert in my area).
The problem is getting to that level where you have so many fans that you can fill an arena or even a smaller venue.
Very good list. I would add that most open source projects have many people working on them.
I'm almost positive this isn't true. If you restrict to the top few percent of projects, it'll be much more true, but even so I think you'll find a lot of projects with relatively small core groups, and sometimes a single hacker who wrote most of the core.
Weekend project: try to quantify this via GitHub APIs? Although suspect that might still give a somewhat skewed picture (not every major project is on GitHub...)
Yeah I'm sure that's true if you count by the number of projects. But if you count by utility to the world, I'm sure it's not true.
Think of every open source OS, browser, compiler, interpreter, etc.
There might be one person who initiated the project and did much of the design, like Guido van Rossum for Python, but it wouldn't be fair if he got 100% of the compensation and everybody else on python-dev got 0%.
But you're leaving out one thing.. since it's not licensing, most developers using your project on the job will have to contribute out of their own pockets. Reasonably, they're much more hesitant and will give less.
As evidence, when you buy a piece of software yourself, you probably buy the most basic version you can. When you can expense it, odds are you get those optional components that you _might_ need at some point.
And further, offering "support contracts" can be great but many companies use it as a check box - "do they offer support? yes!" - as opposed to actually buying it. Luckily, of those that buy it, some will never use it. :D
> it's one-time revenue, you have potentially inflated expectations, and just kidding, now you have 1,000 bosses.
I think this dynamic applies pretty widely and it's part of a major problem throughout the open-source community. There are many people who feel entitled to custom development tailored to their exact needs for free or close to it; that population is both considerably larger than the number of people who will contribute at all, much less significantly, and a substantial percentage of them communicate in a rude and entitled manner which contributes to burnout for the actual contributors.
This is a great concise list, however I would add one more item:
* Create bounties for individual features/bugfixes using a platform like Bountysource
I've contributed small amounts to FOSS projects I use personally, because I'd really like to see certain features added (or bugs fixed) but don't always have the means or time to contribute my own pull request.
Pros: customers only pay when the feature/bug is implemented, no pager duty or support hours, easy to gauge demand so time is only spent on work that's most desired by paying customers
Cons: one-time revenue, payments might be low relative to the work required
If I had an open source project with an active userbase (one day...), I would probably combine bounties with Patreon and/or support contracts.
* Sell commercial versions of your software, appliances to run it, hardware interface cards, phones, and cloud services (Digium). Pro: you can fund the OSS project from the sales and continue to innovate. Cons: you have to engineer and support the hardware, and you're running a datacenter and doing DevOps.
> * Charge for support (Ubuntu, Nginx-ish). Pro here is that by helping folks implement your software, you'll have a long line of success stories. Con here is that it isn't scalable - you're upside is bounded by the hours you can bill.
If a project has active community then the owner can scale support by sharing workload and money with the contributors. In general I agree with you monetization is a job/business.
> * Run a Patreon (Vue). Pro: you have autonomy and recurring revenue (yay!). Con: now you're a personality. This is limited to celebs who are good at marketing _themselves_ as much as their software
I don't see this one as necessarily true. And it doesn't even seem to hold up in the one example you gave of Vue. Looking over the patreon page, Evan seems to be totally marketing the technology and not marketing "himself" at all.
Ah sorry! I absolutely did not mean this to disparage Evan. I think very highly of him and love Vue. So in that case, my example may not fit my point, which is that it's hard to become a personality (and/or brand) that is known well enough to support a full time income.
One might say that other open-source projects don't make a significant income because they don't have value, but I think you only need to look at e.g. the npm download stats for many packages to see that this isn't true.
Put another way, _many_ software libraries enable huge amounts of business value that is not captured by the authors of those libraries.
For instance, if you're a JS dev, you've probably used lodash or moment, but maybe can't even name who the authors are of those projects.
Maybe it's more accurate to say that, when you're on Patreon, part of your job suddenly becomes a "hustle"? E.g. in Evan's case I get the feeling that without a constant stream of conference appearances and blog posts it would be harder to drive Patreon donations.
I like this. It's not as if Evan is a "celebrity" a priori - he writes good software, he travels and speaks, and Vue's success is in large part because of his hustle, as you put it.
This idea of "hustle as your new second job" is a better phrasing than my parent comment where it sounds like I'm implying that self-promotion is bad or somehow empty.
Becoming a personality is an excellent strategy - if you're known and loved you'll never starve.
I'm mostly trying to point out that time spent hustling takes away from time building. It's still valuable in it's own way, but many OSS devs (who have created software people find valuable and use) don't want to travel to speak at conferences to pay their bills.
Great list with options. I think more developers should opt for the Patreon. Eugen Rockho aka Gargron is making 3k with this for his Twitter alternative Mastodon @ https://www.patreon.com/mastodon. It is possible to fund a developer, but can you fund a whole company this way?
Liberapay is another platform, an open source Patreon alternative, also has a few funded developers and dev-ops like Technowix @ https://liberapay.com/Technowix/.
If you are going to build and maintain a project, you are already taking on a second job. The difference is whether you make $0 or >$0.
You should not monetize if the problem your OSS is solving is not a problem you care about. You have to be in it for the long term as it always takes years of work to succeed.
There's a simpler answer: it's hard to make money on open source software. Relatively few projects can generate additional services sufficient to pay even a single author's salary.
Anyway I think the original question kind of misses the point of open source. The big driver for the growth of open source is that it enables users license-free access to large quantities of software. The folks that have made the most money off open source are companies like Facebook/Google that run their business on open source or use it to drive adoption of products they can monetize in other ways.
> Run a Kickstarter (Light Table, Diaspora). Pro: you can gauge demand and you don't have a boss. Cons: it's one-time revenue, you have potentially inflated expectations, and just kidding, now you have 1,000 bosses.
Has anyone tried running a kickstarter for a version 2? I think I'd be happier doing that because there is a lot less risk, the pitch is "you like v1, would you like me to add features x, y and z?".
Both projects are released under GPL but offer commercial licenses. In two years, I've only had one person ever inquire about a commercial license, and they backed out.
The barrier isn't legal or philosophical, it's that a lot of very useful open source software (especially libraries that developers interface with) are infrastructure rather than window dressing, which is largely invisible to organizations.
If you only develop window-dressing libraries, then the stuff 'patio11 has said here over the years might hold true. But if you're trying to build a more secure Internet by giving developers better tools, nobody wants to pay you for that.
that's not necessarily a bad thing. Those sound like libs with pretty simple responsibilities, so if they work great there may just not be any real opportunity for feature requests or feedback.
With a backported shim (like at least one of those), I'd honestly take a silent userbase as a sign of success if you know there are downloads/installs.
I'm a Laravel developer and I know about random_compat because of the infamous "There is no suitable CSPRNG installed on your system" message. So I guess it's Wordpress, Laravel, and maybe Symfony too?
Less than 10 for Airship. There's a lot of reasons for that, though (aside from the fact that we built it to be Tor-friendly, so it's nontrivial to measure how many installs exist in the world): We only supported PostgreSQL and only users capable of installing libsodium from PECL could use it. PHP 7.2 will make it possible for everyone to use Airship version 2, and MySQL 8 will add CTEs so we might be able to support the more mainstream database. https://wiki.php.net/rfc/libsodium
This model works pretty well for small apps that you otherwise want to keep in a public repo. The hassle of compiling + signing the app is worth $5 to many people.
For anyone dabbling with the idea, I can't recommend Gumroad enough for simplicity. But it would be nice to see payment/storefront functionality built into GitHub's Releases feature. A GitHub sanctioned payment system might even clue some creators in to the fact that you can charge for some component of your open source work.
There's also a quite well known sprite/pixel art editing/drawing application, named Aseprite, which has a similar model - the author sells it as a paid app in its compiled form, though he also makes the full source available on GitHub. I have huge respect for him for that, and that it seems to work for him!
Because monetizing any business is really really hard. I work on Standard Notes (https://standardnotes.org), which is an encrypted notes app (think of it as an encrypted Evernote alternative). It's fully open source, and I'm monetizing it through paid upgrades.
While the progress is promising enough for me to continue working on it full time, nothing could have prepared me for how difficult this was going to be. I had always been under the illusion that if you had a product you wanted to sell, and there was demand for it, then an automatic transaction takes place.
Not so.
Not so at all. It requires understanding your users, learning about their preferences, learning how to re-engage with them, learning to keep them interested and engaged, and learning how to position your product as one people want to buy.
All of this is very very hard, especially if you don't have a marketing background. It is surpassable though. It just takes time. I'm doing this full time and I still can't keep up. I can't imagine how you could possibly monetize a project part time, unless you're committed enough to spend the next five years of your life on it.
Hey, thanks! The closest to a free trial right now would be the monthly plan, which you can cancel at any time and request a refund. I hope to build in free trials some time soon.
People don't pay unless forced to do it. In other works, people only pay when there's scarcity.
What drives our economy? Scarcity. What's the long term effect of capitalism? Commoditization, i.e. driving the costs down. Some people view open source as being about a post-scarcity economy in which human labor isn't need, an economy based on abundance. That's bullshit though. Open source is about commoditizing software developers in order to increase profits.
So the answer to your question is that there are only 2 ways to commoditize open-source:
1. make it a complementary to something proprietary and sell that instead; the "open core" model is known to work well for some companies
2. choose a restrictive license to make it useless for the target audience (e.g. GPL / AGPL for libraries)
You'll notice that I'm not mentioning selling support. Some consultants earned their name by contributing to open-source. But you can also write books, or blogs and you'd probably earn a bigger following. And you're still selling your own personal time, which is limited, as there are only 24 hours in a day, you're probably not a rockstar to have obscene hourly rates and if you're thinking of building a company around supporting open source, just don't, as you're not Red Hat and you'll never be.
> What drives our economy? Scarcity... Some people view open source as being about a post-scarcity economy in which human labor isn't need, an economy based on abundance. That's bullshit though.
I don't think that is the case at all.
If I have a woodshop and a customer comes in and hands me wood and nails, and I spend a day banging together a table for them, at the end of the day there is one table. A scarce good - one table is created, no more.
If I spent a day coding an Android app, publish it on Google Play, and it takes off and Android's daily two billion users take to it, my day's worth of work is not used by one person or one family. It is used by two billion people. Perhaps my app is mostly based on gluing together open source Android libraries and non-Android-specific libraries for the open source Android OS.
There is a scarcity and labor needed for the creation of the table or the app. The difference in the case of the app which almost for free goes out to two billion people, is that it's virtually free to copy and distribute it. It's really not even a commodity any more.
> If I have a woodshop and a customer comes in and hands me wood and nails, and I spend a day banging together a table for them, at the end of the day there is one table. A scarce good - one table is created, no more.
That's natural scarcity. We also have artificial scarcity imposed by laws and technology.
If you think that's unfair, I might agree morally speaking, but then we'd end up talking about how we're actually debating Marx's "labor theory of value" (i.e. value is given by the total amount of labor required to produce it), which was fundamentally flawed.
What makes Labor Theory of Value fundamentally flawed? The fact that it has the letters M, A, R and X tied to its authoriship?
I agree that toilling at useless task adds zero value in the best case -more often than not, it adds negative value by creating commitments to perform further useless tasks in the future- but what is so wrong with considering costs of production within the value added? I think it makes more sense to recognize zero (or negative) value added task for what they are instead of declaring them "marginally valueable" and then try to push the externality of their cost unto others.
The point is a scarcity of a particular type of resource, though - if you're contracted to make a table, then that one specific table is scarce, but I can still go to IKEA and buy as many tables as I want. Similarly with software, copies of the same piece of software are prevalent, but there's only one specific app that does the thing you need.
Commoditization is about goods being of indistinguishable quality in comparison with each other, such that the consumer doesn't care which is purchased, ie one barrel of oil vs another.
If the project is maintained in someone's spare time, then the cost to monetize it, in time and effort, might exceed what they are willing to put into it.
In my own case, I have a silly JS library with 4,000 hits per month to the docs, but "monetizing" that just sounds like work, whereas working on the library itself is fun.
Following the example of Sidekiq (with Sidekiq Pro), I'm in the process of launching a commercial offering for Kiba ETL (OSS Ruby ETL framework - http://www.kiba-etl.org), dubbed "Kiba Pro".
My take on this is that more developers could try to follow that path, but we lack a bit of guidance (I'm lucky Mike Perham provided some useful insights to guide me actually) to reduce the anxiety & uncertainty associated with such launches.
The hurdles can be numerous & blocking:
- IP - making sure your consulting contracts are IP-safe
- Proper pricing (how do you segment your offer? how to avoid pricing "ceiling" effect etc)
- Product related theory such as "how to create leads channels" etc
- Billing & invoicing
- etc
Personally, I've decided not to attempt to "monetize" the OSS part, but rather launch a paid counterpart covering more advanced uses or built-in components.
This is a process nearly every Enterprise oriented SaaS, a lot of which are built with Ruby/Rails. I think there is a lot of room for this to take off for you!
http://www.kiba-etl.org/ could use some work in stating the business problem and how Kiba can ease the pain of growing your own ETL. If you're not sure what an ETL is (or what problem they solve), the landing page provides 0 justification into reading more.
I run an open source project (turtlapp.com). I want to monetize. I have people who tell me fairly often they want to pay for it.
There are two things that hold me back. First is never quite feeling like it's ready to charge for (perfect being the enemy of good). Second is I don't know how much time I can devote to supporting it.
Both are stupid reasons. I know this. I'm hoping to launch a premium service soon, and we'll see where it goes. If I spend 5 hours a day supporting it, I'll probably just shut it all off and prioritize my Turtl emails a bit lower like I do now. If I end up spending an hour or two a day on it and make some money, I'll kick myself for not doing it earlier.
Just start charging. You'll want to know earlier rather than later which one it is. Life is short. If it turns out this is not the thing you should be working on, knowing which one it is will free your mind up to do something else you should be doing.
Great advice. It's funny because I already know this, it's logical and the decision makes sense in every way, but I still have trouble doing it. I've got a nice chunk of nights/weekends in July, maybe I'll make the final push then.
Yeah, I know the feeling. It's usually some mental block, or erroneous belief you have that's held by those in your circle, or something you identify with. Sometimes it's a fear. But either way, it's usually a bug in the way you're seeing the world.
Once you can identify the bug, it'll be easier to know what's making you hesitate. What's the basic belief you have about money and business that's held in your social circle, or attached to your identity?
Taking that first leap is pretty scary, and it gets weird when you realize sometimes you get more sales when you raise your prices.
It's been ten years or so, but once I had an application I charged £5 for. There were so few users that support costs were always too high. Raising the price to £50 actually resulted in more sales, and fewer "Your application sucks" support-requests.
To answer this I would ask what is the biggest reason to do Open Source. As an individual, the main reason to do that last step and publishing what I do as open source is so other people can use+benefit from it and monetizing it would hinder this.
Now there are many great secondary reasons as an individual, in no particular order: I learn a lot, I got some paying gigs from my open source, better code through more eyeballs, it builds curriculum/personal brand, it feels good to be complimented, etc. For companies I'll guess also it's a great recruiting tool as you are not a name in the dark but you show your code (I've considered that when looking for a job).
Oh wait, I totally (honestly) forgot about your main question when listing the benefits. I would say that the common feeling (at least in JS world) is that open source does not give direct money, so few projects start with the intention of getting it and later on it's more difficult.
Another reason some companies publish open source code is to recruit contributors. Contributors already know what they're doing and are clearly passionate enough about the product to spend time on it for free, so they may be a natural hire when a position opens.
The main reason most companies open source stuff is because they had to build something for some reason or another, the thing works, but they don't want to maintain it because it's plumbing and it's not mission-critical.
Sometimes it's easier to throw the thing on GitHub (where others might find it and at least use it) than throw it in your company's internal repository (where nobody will ever find it and it will rot away).
In general, my thought is that by finding an unobtrusive way to generate revenue you can devote more time to the project and produce a higher quality, better supported product. This of course necessitates that the project is valuable enough to justify spending additional resources on making it significantly better.
In my mind, the best revenue model for OSS is something that is opt-in. For example, if a company wants to pay for enhanced support they can, but if not they can use the software and rely on community/best-effort support.
The main goal in my mind should be making greater resources available to the project while still allowing free use.
Our startup is in the process of launching an open source product and monetizing (currently) by offering it as a SaaS solution. People will be willing to pay for something if it's going to make their life easier
The trouble with monetizing open source is that if your project isn't a "full product" like wordpress, gitlab, or discourse with a well designed interface and plugin support you don't really have a way to sell the product as a service which I think is the most lucrative way and you can then start adding premium features to this service if you want to go down the open core route.
We are monetizing Ionic Framework right now. Two things we're doing: premium tools/services on top of the core (our Creator product is leading that charge), and then additional product features for enterprise, which does have "support" aspects to it, but that's in support of their use of a product. Kind of hard to avoid selling any kind of software for lots of $ without someone being able to contact you in a prioritized way.
Apart from the causes, the reality is that very few companies have been successful at monetizing open source, and many of the ones that do only appear to be successful because of "echo chamber" effects.
Red Hat Linux is the main counterexample. Companies do pay for their support, but CentOS nips at their heels and Red Hat has also lost the support of the "enthusiast" community which has largely gone to Ubuntu.
Cloudera is an example of the kind of "hype-driven" company that gets taken seriously because they get written about in TechCrunch every few days, but they don't have any unique selling point, particularly compared to the free Hadoop distribution. When they got started, the idea of offering a GUI client seemed like a good idea, but after the devops revolution this became value subtraction instead of value addition. (Why click hundreds of times through multiple forms to set up a cluster and have to repeat the whole process all over again next time you build a cluster when you can type a few commands, hit ENTER and have it be done?)
I think it's that A: you have to have a huge open source project for the 1% of the 1% of your audience who will actually pay in any useful quantity to be big enough to support you and B: by the time you've grown to that size, you must have found some way to become that large without the direct monetization, so you may not feel much of a need.
I think it's better to see open source software as "cost reducing" rather than "revenue generating". Consider for example HHMV, developed by Facebook. The way to monetize your open source project is to get adopted/hired by the biggest commercial entity who makes use of your project.
Monetizing, or at least trying to monetize can be kind of counter productive for many projects, specially smaller ones.
Personally, I have a few projects on Github that seems to be somewhat useful to other people... but not a lot people (my most "successful" project has 61 stars, not bad for a side project but ridiculous if you compare it with big projects in the thousands of stars).
Trying to monetize it doesn't worth the burden, maybe I could get a few bucks with Patreon or gratipay, but I would need between 100 to a 1000 times what I could reasonably expect to be given to make a living out of it.
Monetizing them also means I would have some moral obligation to maintain them properly. This really depends on your view on the question, but for me it's kind of import. Right now, I try to respond to bugs and PR as fast as I can, but if I'm feeling lazy or if the issue is to complex to be fix, I can leave it opened for months. Maintenance is purely best effort.
I've started these projects for various reasons, but one common denominator is that they enabled me to learn some stuff and/or maintain my competences (setup proper unit tests, documentation in rst, more advanced knowledge of Python, de-rusting my C, cmake, OpenSSL programming, Puppet types and resources...). One other side effect is that these projects give proof and credibility of what is written on my CV, so, in fact, it's not completely un-monetized...
Also, another driver for publishing these projects is: "why should I keep that to myself? it might be useful to other people" and even if it's not, GitHub is a convenient place to store code ^^.
I'm speaking for my personal projects, but I think I'm far from being an exception, big OSS projects that can be monetized are the exception, they are often core components (a kernel, a big library or framework, a big piece of infrastructure...), but many more smaller projects live (and die) around them serving their small purpose (if any).
Do you have any numbers to support your premise? "Few" is relative and in the eye of the beholder, and I personally don't have the impression that only few projects 'monetize'. There are a lot of commercial open source projects, I find out about a new one almost every day. However, you may be right if what you want to say is that only a small percentage of the total number of open source projects monetize. The same probably holds for proprietary software, too, most of it is in-house or developed by hobbyists and only few proprietary software projects successfully 'monetize'. And let's also not forget that the vast majority of all projects, be they open source or not, are probably abandoned/given up.
I've been encouraging a 5% philosophy for organizations that replace software that had license fees with free software:
Just donate 5% of the previous annual license fee to the project you're now using, each year. You still save 95% on license fees and developers get to eat.
Motivation? Programming has always had a strong undercurrent of sharing. Programmers want to read the code. Programmers want to share how they accomplished something.
That being said, you will likely get different answers on HN than you would on, say, r/programming or IRC.
When you open source a project you don't always want to monetize that project but it fits in your plan to make money. For example big companies release open source projects so the community get expertise in their tools which means it will be cheaper to hire people with that expertise and it becomes easier to move the community to use your other paid tools. Another example to open source a project it is because it is not a key thing in your product and you can have people to use it at the same time they help you to maintain it. You can open source your pet projects so they gave visibility to you and makes easier to find a job.
Open Source Projects is a broad term. It could include a pet project with to large scale projects like the Linux kernel with a few thousand developers.
Here are some of the reasons monetizing is either not feasible or not desirable:
* for small projects, most contribution is done in free time by one or a handful of maintainers for a most part and some random flyby contributions every once in a while. In such cases monetizing would imply more work that distracts from the primary work of building software and the maintainers do not want to spend their free time doing that.
* even for slightly larger projects that possibly commercial companies depend upon, monetizing would imply a change in prioritisation in what gets done. The maintainers would be obligated to invest their free time in doing what paying customers need rather than what the community or the maintainers themselves want.
* for even larger projects unless the interest reaches the threshold where the maintainer(s) can quit their day job and depend on the money coming in from the monetizing it just eats into their free time for not enough money
There are other reasons as well about how to come with a scheme where those contributing do not feel like they are submitting patches just so that the maintainer(s) get to make money for their work, or just the principle of the thing about paying it forward to the community they got so much free (as in beer) knowledge and experience from.
1. Start a convention around it, which could be profitable
2. sell swag, T-shirts and the like (lets say it's a limited quantity that can only be bought by contributors, then it becomes a prized way to show off)
3. in app purchases, for example if I made a photoshop equivalent, but had it linked up to a font store.
4. Get companies/governments that use your software to give you Grants.
That's all I've got that hasn't already been covered. I know a few open source guys who just feel dirty about getting money for it. Personally I'm the same when I make art, I don't want it to be a job, when it starts becoming a job I stop enjoying it, and every time I've taken a break from art in my life it's because it started feeling oppressive like a job. As I learn to code, and as I start to enjoy it, I worry that a similar feeling may happen, in which case I may have an open source project or two on the side just for funzies while I have my moneymaking job separate. I think I would be happier with such an arrangement.
Echoing the sentiment of other posters, monetization doesn't make much sense for many projects (beyond accepting tips) as it's more work to do without much $ in return. For success you'd need to invest time into marketing, revamping the website(s), changing how you present deliverables to (paying) users, setup payment processing, come up with a set of plans for various funding levels, etc.
This may rarely work out, otherwise it's a lot of work for below minimum wage. I tried to see if there was enough out there for one project I've been working on for years ( http://zynaddsubfx.sf.net ) and my attempt (like several others in related communities) was a flop. It was interesting from an experience side of things, but in the end the project was too niche to support itself (like I'd imagine most open-source work is).
> but it seems like there are very few projects that even attempt to monetize via dual-licensing, service contracts, etc.
You don't know everything about the activities of open-source developers with regard to their project. They may be involved in service contracts and dual licensing, without that being advertised on their project site.
One important aspect is attracting contributors: Many potential contributors don't like investing time in a project, where one entity has a notable benefit from the unpaid work. If you don't have monitisation in mind in the project everybody interacts on an more equal level.
Large open source projects have companies or foundations behind them. Project being open source is already part of their operation. Small open source projects don't monetize, because it would be more work then possible gain.
If you're developing a library dual-licensing is a reasonable option.
Many open source developers probably shy away from that option though because they're afraid that fewer companies would use their library in the first place and they're also probably not entirely mistaken:
Enterprise companies are wary of effects licences like AGPL might have on their ability to keep their source code private. Unfortunately, those companies more often than not aren't exactly eager to pay for a licence that allows them to do just that either.
1. Because companies don't want to pay license fees, so then don't use the damn software, who cares.
2. Oh you should just beg for handouts instead, because your effort and work isn't worth crap and you should be lucky to eat the crumbs of the massive tech industries table.
3. Oh don't sell the software, sell a bunch of crap around it instead.
Its about time developers stopped being afraid to charge for their effort.
If you want to charge those who commercially exploit your work, than dual license the damn thing.
IMHO it's because, once you decide to go open source, you're creating with the intention that this is a "for the community" type of product, not a "for profit." It's like a non-profit company with unpaid volunteers. There's a cause that many people believe in and anyone can help work towards that cause to make it a reality.
Moreover, many critical projects are already done by FSF or Apache Foundation, which are non-profit. Other by RedHat, IBM, Google or Oracle, which already monetize them.
Some were done in a "scratch an itch" fashion and author is not interested in maintenance.
Some are research work where a given university (and not the author) would have to draft a contract for anything monetary.
In addition to donations and selling t-shirts (which is why having a proper name and logo is key), one way of monetizing is selling support and training related stuff. e.g: writing a book and selling it.
Unfortunately the reality of trying to monetize open source projects is that Red Hat will just eat your lunch if its any sort of real significant business.
Because the need for monitization is a limitation.
Take a game. You can try everything, but once you dev it for money- the whole shit-circues enters the town- making you think about the audience, the payroll, your family - and all these things limit you.
In a very real way. Every naysayer who is applauded at a companys meeting tells you the answer why open source sometimes is more awesome. Because capitalism cant - and is afraid of risks.
a lot of high profile open source developers/projects are sponsored by commercial entities (redhat, intel, google, facebook, etc.), thereby eliminating the need for direct revenue generation by the contributors and maintainers.
I considered not replying to this just based on the tone, but here we go. If I (theoretically) charge large corporations for SLA support, that means I can devote more time and effort to the project which remains free to use for the collective. The result is a higher quality product with better support at no added cost to anyone but those that desire a higher level of support. Does that make me (again, theoretically) a self serving greedy objectivist dick?
This attitude is one of the biggest reasons why it's so hard to monetize open source software. There are a lot of open source devs that missed it wasn't meant to be "free as in gratis".
Here are your choices:
* Turn your OSS project into a company (Docker). The pro is that you can capture a lot of the value, the con is that you're splitting your project into CE/EE and also now you're a CEO
* Give the software away for free and charge for the hosting (Gitlab). Pro here is that you get recurring revenue, but the con is that now you're in DevOps and wear a pager. Also this model doesn't work well for libraries, only "apps".
* Charge for support (Ubuntu, Nginx-ish). Pro here is that by helping folks implement your software, you'll have a long line of success stories. Con here is that it isn't scalable - your upside is bounded by the hours you can bill
* Get a job at a company that will fund you to work on it (React, Angular). Pro here is that you can make tons of money with a job you love. Nice work, if you can get it. Con is that now you work for that company and you're subject to whatever whims they have.
* Run a Kickstarter (Light Table, Diaspora). Pro: you can gauge demand and you don't have a boss. Cons: it's one-time revenue, you have potentially inflated expectations, and just kidding, now you have 1,000 bosses.
* Run a Patreon (Vue). Pro: you have autonomy and recurring revenue (yay!). Con: now you're a personality. This is limited to celebs who are good at marketing _themselves_ as much as their software
* Ask for donations (Babel, Webpack). Pro: this works for tools and libraries (not just apps) and you can keep your mission. Con: Companies feel these donations have ambiguous deliverables. There's a lot of mental overhead too (How many projects can one company fund per month?)
* Sell documentation, books, videos (React Training, my current gig). Pro: JavaScript fatigue makes you money! Con: Writing the docs isn't as satisfying as writing software (for many developers)
So to answer your question: monetizing your open-source project means you take on another job _besides writing software_.
In an ideal world if you write software and it gets used, you'd be able to capture some share of that value. But we're not there yet.
[If you want to chat more about funding OSS, reach out to me (see my profile). I'm working on a few new ideas.]