Most of the people writing OSS do it for fun/side project/to solve a problem, not for the money.<p>Problems come if that peace of software gets popular, they get a lot of bug reports, improvement suggestions/requests, emails, noise in general. And a person who wrote the software has a full time job, so the time available for OSS is limited. That person is probably well paid in it's current job, so the OSS has a long way to go in order to replace that income, meaning it's very hard to transfer from a regular job to maintaining and living from your OSS.<p>And the most important thing - those people are pure engineers, that don't know/are not interested in business, marketing, making a product out of their software, etc.. practically anything besides coding. It's like advising a mason: "Hey man, you know how to build a building, why don't you build one and sell it? You can pay the rent with it." It's a bit more complicated than that.<p>But nice article overall, good starting point for someone who wants to find out more on the topic.
Good article, but I thought webpack is founded by The OpenJS Foundation these days, who are making an astonishing job of identifying and sustaining core web packages. Unfortunately, they also picked controversial software like AMP (in exchange for contributions by Google I guess) to make it appear a grassroots or "legitimate" effort. Also, I think the ongoing trend to slap a thin wrapper on top of F/OSS and sell it as a service (aka "the Cloud") points to a weakness in F/OSS licensing schemes that needs to be addressed as I'm sure that almost all devs working on F/OSS don't intend their work to become part of a lock-in scheme, mass surveillance, or both, all the while not even getting contributions back. Apart from the licensing situation, F/OSS developers serious about generating an income might also need to work on integration and polish; at least it's what the success of stuff like Docker suggests, which, as super-practical as it is, in a way is benefitting from "too much" F/OSS, too many Linux distros, either too much or not enough NIH in F/OSS, F/OSS failing to directly engage with their user base, and/or developers not personally promoting their software such that the whole thing is falling prey to large corporations giving the illusion of order and maintenance, when the reality is that the initial development of any package of significant depth and its maintenance can only be provided by individual developers or small teams in the end.
I asked this on HN a few days back.<p>I open sourced a library and its become heavily used by some of the largest enterprises who make lot of money using that library as one of many.<p>It takes a lot of my time to keep it updated so I would like to be compensated some how for the time it takes me away from my family<p>Even though its used by small and medium businesses I would like only the largest businesses to pay for it.<p>So how do I keep it open source as well as have the largest business pay for it? Any examples of open sourced applications doing the same?
Sadly the article neglects the single biggest problem in open source: very few people, or companies for that matter, are actively willing to contribute in any way, whether it be contributing with code or financially supporting a project. Even big and popular open source projects are most often self-funded and it's people dedicating their own resources and spare time to support them. All of the things in the article are more than valid but creating an open source project that can potentially pay your rent is arguably just as hard as adding another letter to FAANG. As a matter of fact the letter might very well be an easier task.
I feel like it's weird to first talk about aligning your incentives towards things that provide value to your users, and then suggest this business model:<p>> Training, support or consulting services from the project’s maintainers<p>without even mentioning that it creates exactly the opposite incentive.<p>If you get paid to help people understand how to get stuff done with your product, you have absolutely no reason to improve the core product in ways that make it easy for them to figure it out on their own.
What about charging for build and distribution? Krita does something like this for their Steam and Windows Store versions, that helps finance their development. I personally believe that could also work for other distribution channels, such as a private APT repository, or equivalent to other platforms.<p>People could still build by themselves from sources if that's what they want, and if you want convenience you buy the software. Has that been tested? I personally think that could even work for CLI tools if a great distribution channel exists (that's something I have in mind since a while now, see this ask HN from 5 months ago: <a href="https://news.ycombinator.com/item?id=22178949" rel="nofollow">https://news.ycombinator.com/item?id=22178949</a>).
There is another option, unpopular with some open source advocates, the source-only option. You simply sell your software product (with source code) for a price. That's it. Simple and uncomplicated.<p>Your customers get the source of your app. They can modify the code to suit their needs. But unlike open source, they cannot re-distribute the app. Very few companies would object to this.<p>Some popular and profitable projects that follow the source-only option are Kirby CMS and Craft CMS. Both these projects publish their source code on GitHub and rely on the honesty of their customers to pay for the product. This means that even people who would never purchase the products can still study and learn from the source code.
How about dual licensing of the core software itself? That is, release the source under a copyleft license, and sell licenses to companies who won't accept the copyleft terms. For libraries and tools targeted at software developers, I think the Parity Public License [1] is a particularly good choice.<p>Taking it further, we should be willing to challenge the strict parameters of the Open Source Definition, the Debian Free Software Guidelines, etc. These aren't sacred texts, and for many applications, it doesn't matter if they can never be packaged in the main section of Debian or other distros that hold tightly to these rules. In particular, for applications that aren't targeted at software developers, releasing the source under a license that allows non-commercial use, then selling commercial licenses, is a completely sensible approach. For example, check out the Prosperity License [2]. Edit: To be clear, licenses like this one shouldn't be called open source; a common term is "source available".<p>[1]: <a href="https://paritylicense.com/" rel="nofollow">https://paritylicense.com/</a><p>[2]: <a href="https://prosperitylicense.com/" rel="nofollow">https://prosperitylicense.com/</a>
We're in the process of monetizing an open-source project as well (Klaro - <a href="https://github.com/kiprotect/klaro" rel="nofollow">https://github.com/kiprotect/klaro</a>). The project started as a "weekend hack" for our own website and became quite popular over time, to the points that it's used on thousands of websites already. We plan to keep the client software (i.e. the part that runs in the browser) open-source and feature-complete. We want to charge for backend services (managing consent data, scanning websites) and comfort features like a graphical configuration editor. That way we hope to enable users to still get great free value from the open-source version while allowing us to raise money for the development.<p>Contrary to some other voices here we had great community contributions to our project right from the start: For example, almost all translations are contributed by the community and even some of the non-trivial features have been built by community contributors. That said it's a rather simple Javascript project and we try to keep it as accessible as possible. We have another open-source project (KIProtect - <a href="https://github.com/kiprotect/kiprotect" rel="nofollow">https://github.com/kiprotect/kiprotect</a> - just open-sourced it last week actually) which is way more complex and that we also want to monetize, we'll see how many contributions we'll get for that.
For us, FOSS is the start of the funnel for our SaaS. Somewhat in-between the "hosted version" and the "premium features" buckets, but in separate projects.<p>We employ the two core maintainers of Storybook (one of the most popular FOSS JavaScript projects) who work on it full-time. The rest of us build Chromatic, a SaaS that offers features on top of Storybook, and we occasionally work on Storybook too.<p>Storybook is a tool for local development, so if a feature makes sense there, we add it to Storybook. If it needs some cloud connection/storage (e.g. for team collaboration), it becomes a Chromatic feature. We have a shared roadmap that doesn't prioritize one over the other, and Storybook has it's own steering committee.
I work on open source projects* when I have a need that other tools don't quite fill properly, and because I like to work with languages like Rust and C that I don't get to use at my day job. I'd like to have a "buy me a cup of coffee" button on my Github because I have put thousands of hours into my side projects, but have no idea how to monetize really. And I wouldn't want to use the monthly supporter model because often when I finish a project I want to take months off, and may not have another idea for a while.<p>*like <a href="https://github.com/spieglt/flyingcarpet" rel="nofollow">https://github.com/spieglt/flyingcarpet</a><p><a href="https://github.com/spieglt/whatfiles" rel="nofollow">https://github.com/spieglt/whatfiles</a><p><a href="https://github.com/spieglt/cloaker" rel="nofollow">https://github.com/spieglt/cloaker</a>
In 2019 someone from Elastic also tried to highlight the issue and various models at the market right now in a talk <a href="https://media.ccc.de/v/froscon2019-2463-open_source_as_a_business" rel="nofollow">https://media.ccc.de/v/froscon2019-2463-open_source_as_a_bus...</a>
My main take away was "it's complicated".<p>Sad story is that in many cases the biz paying for interesting contributions is questionable (Googel, Facebook et al).
TL;DR: start a business that sells a (possibly premium) hosted version of the project, sells training/support for the project or try to extract sponsoring from your users.<p>It's less a "pay your rent with your open source project" article (as the title suggests) than a "start a business that happens to produce open source software" article. Also anyone with one or two smallish libraries need not apply, this is about projects with person-years of effort invested in them.
I noticed that Plausible claims to measure traffic without being able to persistently identify users, but <a href="https://plausible.io/data-policy" rel="nofollow">https://plausible.io/data-policy</a> states that they store the following:<p><pre><code> hash(daily_salt + website_domain + ip_address + user_agent)
</code></pre>
There are optimizations that can help brute-force the enumeration of customer domains, browser UAs, and IP addresses (e.g. in some cases you could enumerate only residential ISPs).<p><i>Update:</i> I mis-interpreted "rotating salt" to mean something that could be re-computed on Plausible's backend. It appears that the salt is random[1] and generated on the client-side, which makes this hash much more secure.<p>1. <a href="https://github.com/plausible/analytics/blob/master/lib/plausible/session/salts.ex#L45" rel="nofollow">https://github.com/plausible/analytics/blob/master/lib/plaus...</a>
I’m working on a slightly cheaper alternative to Plausible called Nibspace - it’s $1 instead of $6 for similar traffic volume.<p><a href="https://nibspace.com" rel="nofollow">https://nibspace.com</a>
I've made my time invested in open source projects pay for itself by not giving my source away for free. Present your project as any other paid-for system, let customers pay for it, and only then display access to source. One of two things happen: Paying customers continue to pay for your maintenance of the project, or they pass along the free link to your source and you know they're not a worthwhile customer.
It's kind of strange that the article lists me under "5. support and training". 100% of my income comes from the "4. premium version" model.
I use Plausible and switched immediately after the launch from GA. I am very satisfied except that it seems that I cannot share sites with other people, if we are more than 1 that manage it.<p>I hope they'll fix that!