How to pay your rent with your open source project
plausible.io
plausible.io
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.
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.
But nice article overall, good starting point for someone who wants to find out more on the topic.
OSS projects that are created by companies as a strategic move are something completely different.
This isn't my experience--I've worked with hundreds of developers who do open source, and only a handful were paid in any way. I don't exactly look deeply into the finances of every open source project, but my own open source projects, I've paid to run. Now, I'm aware that my experience is anecdotal, so I'm not going to confidently say that you're wrong, but I'll say that the best evidence I have (which isn't very good) doesn't match your claim. If you want to persuade me, you'll have to provide better evidence than what I already have.
In fact when I was last employed (I'm now freelance, or at least trying to be freelance) I very much did not work on my OSS project, or use it in client work, because while I had verbal assurances that the company would not assert their rights, the contract I signed included an IP clause that was a little too broad for my liking.
As to the OP, It would be nice if I could figure out a way to make my OSS project earn enough to cover my rent. I would be really happy if I could get it to pay its own rent - hosting the project's home page is not $free.
(Obligatory spam of the project's home URL: https://scrawl-v8.rikweb.org.uk/ )
That doesn't say anything about the number of people who write OSS.
Yeah, that's a serious problem, and one similar to ones that artists and musicians face.
I've made a fair bit of art (paintings, drawings, sculptures) but except for one group exhibit in high school I've never bothered to exhibit it anywhere, sell it online, or show it to anyone apart from family members and a few friends (and even they haven't seen most of my art). It's just too much trouble. I'd like to make a living making art, and have considered creating an Etsy page or something, but have never gotten around to it. So I just keep making art for myself.
I also make music, and have kept that mostly to myself for the same reason. I've uploaded a fraction of it to Soundcloud, but I don't advertise it in any way, so even finding it on Soundcloud would be almost impossible for someone if they didn't search for specific keywords that I've tagged my music with. Mostly I don't bother even uploading it, though. It's too much trouble to record, edit, name, upload, provide metadata to Soundcloud and find an image to go with the track. So I just tend to keep the music to myself.
I've also written quite a bit of software over the years, and have open sourced some of it, and am a big believer in open source, but it's just too much trouble for me to package stuff nicely, write readmes for my software, and make sure the software is decoupled enough from my own environment to be useful/buildable for someone else, so a lot of it has just kind of rotted away on my hard drive for decades without anyone else even knowing of its existence. So I mostly just write this code for myself.
Some people go all out to promote their software, music, or art, but that's just not me. For me the joy is in the creation, and the rest is just not important enough.
Kudos to all those people who actually go to the trouble of open sourcing their code, release music to the public, or show their art. I know how much work just doing that can be, never mind trying to make a living at it.
That said, if you are willing to go to the trouble, there are successful open source projects which manage to make money that you could model your own projects on.
Anyway, this has been a problem since forever. That's why all kinds of occupations like singer managers, sales, marketing etc. exist. It's all perfectly normal.
For you, it would be good to find someone compatible, someone to take care of presenting your work to the public while you can focus on creating.
Example: I got a Eufy RoboVac 15C and I was in a homebridge-craze at the time I got it. So I found some code in python that was able to control the vacuum for the most part and so using that as my base I wrote a homebridge plugin in nodejs that would let you issue all the commands. Now homebridge on it's own is far from stable (IMHO, if it works for you then that's great but for me it would break every month or so randomly), then you throw Tuya into the mix, and a company that made some firmware changes to the vacuum and it's a house of cards.
I was proud of myself for getting it all to work but in practice I run the vacuum on a timer and never futz with controlling it directly. I really just wanted to prove I could do it. To get it to play nice with homebridge I had to publish it on npm (2 libraries, one general purpose nodejs lib to control the vacuum and one that was the homebridge plugin that used the lib).
Queue support requests... I easily spent 30+ hours trying to help people both on GH and over email (email was even harder for me to say no to). This was at a point where I wasn't even using homebridge at all, let alone the plugin.
Maybe I'm just an idiot for not deprecating the repo or putting up a message but I felt obligated to help and then when I procrastinated helping it would just be this background sense of shame for abandoning it. Thankfully someone else, who apparently does use it, stepped up to fix some of the things that broke and has taken over most of the support-related things (which reminds me, I need to see about transferring the repo over to them fully) but I think that's generally the exception and not the rule.
Bottom line publishing anything feels like I'm shackling myself to it which is not a feeling I like or enjoy which leads to me just putting less out there. Maybe I'm missing an obvious solution but I really don't like putting myself in that situation. I am 100% willing to hand over my work for free (as in, for projects that I have no intention of trying to monetize/purse) but I don't want to signup for future work. Is this just selfish or what?
You have no idea how many tiny repos I have used for reference with those types of projects! In many cases your code might be the only working example.
You can put a big disclaimer in it, declare it a PoC, and just ignore issues if you'd like - the code doesn't even have to still be working, it's still cool and helpful!
I've written hacky one-offs before that other people used as a jumping-off point for something more serious, which is pretty cool to see. I'm always in favor of releasing your code for that reason, you never know if someone else will find it useful!
https://sachachua.com/blog/2020/07/why-i-love-free-software/
No. I've abandoned game mods I created because I don't play the game anymore. Had maybe a dozen users ask for it to be updated, it just doesn't fit my priorities.
No shame in setting your boundaries.
Not to pick on you personally, but this sort of assertion is often thrown around with no data.
It's not even clear to me that it's one or the other. For me personally it was always a mixture of both -- there's a lot of fun but I wouldn't do it without the money. But that's kinda true for my non-OSS engineering work, too!
> pure engineers
I see what you're saying, but I think there is an element of "making a product" that goes into almost any new OSS project; there is an attraction of exploring the product space from a fresh start that is part of the motivation of many many new open source projects.
(Also I think the notion that a "pure engineer" doesn't care about all those things is just wrong, but that's a whole other conversation.)
I think it's basically impossible to have "data" on why people work on OSS, on what their actual motivation is. All you're really going to get is anecdotal.
There are good reasons to explore ideas and participate in projects that extend beyond making pocket change through clickbait.
But technically what you are saying may be right. We mostly hear about commercial work because of marketing around it. The real fun problem solving projects are often found only when you need it.
We don't have "official data", this was just my opinion, based on my personal experience. I think most of the people start OSS for the reasons I mentioned, but what happens later depends on many things - success of the project, luck, type of personality of the owner, crossing paths, right place at right time, etc.
"Pure engineer" for me is someone who just wants to code, to solve a problem, and doesn't care a lot about other stuff. Even processes to organise the team (SCRUM meetings for example) are boring, waste of time. Not to mention other stuff. But that same person can, of course, change over time and go searching for other things. Me being an example - a significant part of my career I was like that, with a vision of being a technical lead or architect in the future. Until one day I realised I'm not so hyped about that anymore, that now other things motivate me. This document, 10 years ago, would be mostly new information for me. Probably not so interesting. Now it's old news for me, but it's as a "pure engineer's" good starting point, something to get him in the right direction if he wants to expand his competence toward monetising his OSS.
So you believe "most people" do it for the money?
There's so little money into OSS and yet so many OSS contributors, I can't see how most people could do it for money, even if they wanted to. You would have to include indirect gains to maybe become plausible that most do it for money, like support contracts, but then are they working on the OSS project to get contracts or are they getting contracts to be able to works on the OSS project.
Then the project I started decided to trigger my obsessive behaviours and take over my life. And so it goes.
the solution to "not even getting contributions back." exists since 2007 but apparently just writing the letters "A" "G" "P" "L" is enough to make a lot of people screech.
For the very few companies who are willing to touch AGPL code, they only need to make the changes available (e.g. a CD in the post is sufficient).
Very few companies are willing to use it, because it creates an almost unassailable hurdle in lots of industries.
It's also highly at risk at making a bunch of other projects AGPL as well.
Using "you" in the general "one" sense, not to attack you personally of course
</edit>
> it creates an almost unassailable hurdle in lots of industries.
It's intended to be a hurdle, if you want to build a business on other people's work and not contribute back. Be a player that benefits the ecosystem or go away and build the product from scratch if you think you can.
> a CD in the post is sufficient
Yeah, it would be. If they make valuable contributions to the source code, they'll soon realize that just dumping those on github will have the same effect and save them a full time employee for burning CDs. If the contributions are not valuable, the problem will likely solve itself when the company goes bust.
In actual fact, being compliant with AGPL software is extremely easy. Nothing at all is expected of you if you just ship it into production as-is. And if you modify it, the only obligation is to send the modifications upstream as patches. That's it. Surely any company is capable of completing such a trivial feat.
You are right that AGPL is easy if you can just run it as-is. The real problems start with libraries. If I link an AGPL PDF-generating library with my monolith service which runs financial reports over my business, what happens? Do I need to now publish my SQL queries that access sensitively named tables? Maybe that reveals new secret projects we're working on, or perhaps security incident mitigations underway.
Sure, there are countless ways to architect my way out of those problems, but what if I don't have the resources to do that right now?
The small obligation becomes a large burden pretty quickly.
(The real solution to the above problems is to pay for the corporate license that removes the AGPL obligation, but that assumes you can afford to do so)
AGPL is fundamentally scary to lawyers and management because they're afraid someone will sink the ship. Sure it's mostly FUD, but there are some serious valid concerns.
No one uses AGPL for libraries, except maybe by mistake. LGPL is used for this purpose.
>Do I need to now publish my SQL queries that access sensitively named tables?
No. The FAQ from GNU makes how this works pretty clear:
https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingR...
The AGPL is not viral in the sense that all client software accessing an AGPL-licensed service are required to use the AGPL, but rather, such clients are entitled to the source of that service. It puts no obligations whatsoever on client software.
https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingR...
Maybe you should actually read up on the AGPL license before you make assumptions about it? It seems like you don't really understand it.
This isn't my experience at all. Here's an example:
https://github.com/unidoc/unipdf/blob/master/LICENSE.md
> The AGPL is not viral in the sense that all client software accessing an AGPL-licensed service are required to use the AGPL, but rather, such clients are entitled to the source of that service. It puts no obligations whatsoever on client software.
This depends on what your "client" is. If you're making library calls, lawyers get uncomfortable.
> Maybe you should actually read up on the AGPL license before you make assumptions about it? It seems like you don't really understand it.
I understand it quite well, and I even use it myself! There are just problems associated with it that most proponents gloss over.
Ah, in this case, this software is designed to maximize conversions to the paid commercial license, so they deliberately use the AGPL in a way which makes it inconvenient for your internal use. This is not common in software which does not have an alternative commercial license. I don't really appreciate this model because it is disrespectful of the copyright of third-party contributions.
I actually do. If I write a library, I definitely don't want people to put a web UI on top of it and get away without any obligations, like so many people do for e.g. website that are just ffmpeg frontends.
That is incorrect, the modifications have to go to users not upstream. All the GNU copyleft licenses are like this.
Just wanted to mention that I believe AGPL is sometimes considered with a dual-license scheme in the hope that enterprises buy the commercial license, or to avoid a situation where a commercial third party benefits from a piece of software disproportionally, or to the detriment of the project's funding (such as providing pure hosting), whether contributions are upstreamed or not. Not being able to express clearly what you're after - cash or code - makes AGPL suboptimal. It's a reality that software without funding and maintenance only goes into bitrot mode, so why not come out straight and sell potential customers maintenance and support? Clearly, the software licensing universe needs additional considerations today compared to the time when Affero/AGPL was conceived.
... a large fraction of OSS work these days is sponsored by corporations.
Also, it would be incorrect to say that the foundations "picks software" such as AMP; instead, projects apply to join. The decision to accept AMP was made entirely without consideration for Google's status as a sponsor of the foundation. And finally, while it may count as splitting hairs, Google retains ownership and control of the AMP cache; it's the core technologies that have been transferred to the foundation, not the instance run by Google that relies on those technologies.
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.
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
Even though its used by small and medium businesses I would like only the largest businesses to pay for it.
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?
I personally have found that I end up donating more frequently to projects that are both explicit about donating and make it easy to donate. Put a link in your README, sign up for GitHub sponsors, etc. And if you have a way to communicate directly with the largest businesses, don't feel embarrassed about nagging them about donating. It's likely that most still won't pay anything, but some will!
There’s also another category where you get hired by a company using your code to help drive and prioritise enterprise features in the project. I’ve seen plenty of internal forks of big open source projects where contributors are actively working and trying to upstream the internal development.
The trick is to not also take in their work (i.e. for integration).
1 - Charge for support.
2 - Put a Patreon and/or Paypal link prominently on the front page of the website for your product, and clearly and politely ask for financial support. Often people want to help out financially, but they don't see an easy and convenient way to do so. This is one way to let them know how they can.
3 - Consider running Kickstarter campaigns to add new features. See the successful Magit kickstarter[1] for a perfect model of how this was done for a very popular open source project.
[1] - https://www.kickstarter.com/projects/1681258897/its-magit-th...
Except people who use your product (engineers) have one extra hurdle: they need an OK from the financial department, and I suppose that this hurdle is often quite big.
Also, while handling tickets, you can politely explain the user the paid support or consulting if they need it ASAP or require more support. This will can get the manager’s attention more than just “let’s support this guy because we use it”.
As a last resort, you could consider paywalling new features and improvements. Or basically creating paid downstream product with a support and implement changes to the upstream. Sounds awful but that’s basically what most open-source companies do to keep new products alive :)
I will consider offering consulting support.
I just wish there was an open source license that basically says "its free to use but if your company makes more than x billion of dollars in profit then you have to pay $x per month/year."
I think the aforementioned model is the best one for the longevity of an open source project - If you want to use my work for free, then give something back to the project (your changes) but if you don't want to do that then please support it financially.
Thanks so much.
I hope this is beneficial for others in the same boat as me.
I wonder if that sort of discrimination is allowed though.
I also wonder if package bundlers like Ubuntu would consider to bundle the project with their distros, if it has such a license slapped on it.
the best ways i know of to make money doing OSS is charging for support and selling a commercial license so that enterprises can keep their code changes private.
So long as it's clear you have no obligation to re-write the library especially for them, will this work?
Slightly unrelated: I think the best way to encourage people to contribute is to have a well documented, time-specified, friendly path for contributors.
For example: (I won't name the project) I recently made a PR to a (definitely well known on HN) programming language's library and there was a fairly counterintuitive CI failure. A bunch of people turned up to provide completely useless advice that I had already tried, and promptly disappeared - it's now one of a 200 hundred ish PR queue that is largely full of things that people have wanted to work on but can't because the maintainers (as well as being busy) are dancing around doing a new thing every day rather than deciding whether to close or merge.
PR-hell is a situation where a process obviously helps, like in corporate projects (Look at how Microsoft deal with GitHub issues for example) where someone will actually go through and decide.
> Training, support or consulting services from the project’s maintainers
without even mentioning that it creates exactly the opposite incentive.
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.
I can think of a number of projects in the "big data" space that seem to have fallen into this trap.
That's not going to happen if your product is a baroque mess that requires a ton of support in order to use/setup/understand compared to other competing products.
Ideally, your product is as easy to use as possible compared to other products, yet complex enough to require support.
Anyway, many corporations will buy support as a matter of course, whether they need it or not. And if they want specific features they might pay to have them added rather than dedicate their own engineers to writing and maintaining that code, especially if they don't have the in-house expertise to do so.
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: https://news.ycombinator.com/item?id=22178949).
On the other hand there are some more mainstream optionally paid for (via Steam/Windows Store) GUI tools that I can freely download using my package manager, presumably because the main target audience actually prefers the paid distribution channels.
I think the GUI/CLI app markets could be more different than you think.
I understand the difference people expect from GUI vs CLI, I just don’t think it really makes sense to be ok to pay for one but not the other, and I see it as a missed opportunity for tool creators.
Edit: Regarding Linux users as the main target, I don’t know if that’s true. I had mostly macOS in mind (I know I explicitly mentioned APT in my initial comment, that’s just what I had in mind at that moment), mac users seem to be ready to pay good money for their tools, there is a healthy market for GUIs. Something equivalent to homebrew cask but with an economics component may have its users if the tools being sold are considered valuable enough.
It might be that I am in a sysadmin bubble here, but I just think that the "paid store" model conflicts with how people use CLI software.
For example, I suppose even the MacOS developers you mentioned would be interested in running e.g. `jq` on remote servers, virtual machines, docker, ... How could good UX possibly be achieved here? If you lock your hypothetical store down even a little bit, users now have to do complicated secrets management. If you don't and simply hope that everyone actually pays, you might as well just ask for donations.
- your prod docker images are already very likely to be built by your CI
- a Dockerfile typically does: apt update + install, git clone a private repository with your scripts, then build whatever you have to build
- so you already have secrets to manage, given that you need to access your private git repository
- in an environment such as Jenkins, Travis, Github Action, GitLab equivalent, secrets for your CI pipeline are equivalent to env vars that you add to your pipeline settings. It's quite unlikely that you have setup your own.
- let's say you want to avoid to have the private repository as a point of failure, just store the downloaded archives to your own registry. Not too different from storing build artifacts.
I'm not saying there isn't some friction, but it doesn't seem to be a deal breaker to me.
Personally I'm happy to see it. I keep thinking I'll ask my company to support ones we use, every time I run `npm install`, and I plan to do it soon.
Theory: At this point, tutorials which are consumed by the beginners in the field will select the free tool (because it has a bigger target audience, so better SEO), which makes this whole thing a generational thing? „Oh in the early days we had to pay for this, now we use XY which is newer and shinier and even free, thus better“
Edit: Sources available, but not open source license as far as I understand the EULA. https://github.com/aseprite/aseprite
The license and FAQ are somewhat confusing as to if you need to pay for a license even if you compile from source.
Of course Linux distros are still building and shipping it.
I'd argue this would need a special license deviation from the typical OSS ones to prevent distros from packaging it. Otherwise, this model would break down the moment an Ubuntu or Fedora decides to package the software and then the incentives to contribute some money in exchange for convenience dissappear.
Ardour[1] does this too, and from what I understand its lead developer manages to support himself from this.
The Linux distribution that I use is Gentoo, and it has Ardour in its package repository, but that version is always old compared to the newest version of Ardour.
So if I want the newest version I have to compile it myself (which I can and have done, as I have the technical expertise to follow their build instructions), but for others who want the latest pre-compiled and/or want to support Ardour's development, they can donate.
There's also Harrison Mixbus[2], which is a commercial product built on top of Ardour by another company.
[1] - https://ardour.org/
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.
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.
It the source is out they can't hardly enforce anything or much. People will just go to github and compile it for free.
I think open-source-ux was talking about software where the customers would be companies, where there is comparatively less of an appetite for using pirated or unlicensed software.
Sure, there may be some individuals who will refuse to pay, but companies will not risk legal violations by not adhering to the licence conditions for the app.
In fact, the 'source-only' model is nothing new. Back in the late 1990s, developers used to sell UI and data components for Delphi with full source code. Even though code wasn't published to public code repositorities, there was nothing to stop individuals posting those components to the internet for others to grab without purchasing. Even so, developers were able to successfully sell their 'source-only' components to other developers and companies.
It allows creators to let customers pay for new features and support, while at the same time 'derisking' vendor lock-in by automatically converting to an open source license.
I recently stumbled across a podcast where David Cramer, CTO of Sentry, talks about their move to BSL: https://changelog.com/podcast/371
I don't have a strong opinion on what's the "right" license for services like Sentry, but for me this was definitely worth a listen.
> can still study and learn from the source code.
But will have to be careful not to use any of it and have no possibility of contributing improvements.
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".
However - by no means am I suggesting that non-commercial licenses or licenses which don't meet the other OSI or FSF criteria are wrong, or cannot be used to do good - nothing of the sort. But you need to give it another name. Some projects are using "Fair Source", for example.
If you want to retreat to "principles", that's fine. But then you'll have to deal with how poorly OSI and FSF definitions express them, differences of opinion among members hidden behind handwavy vague definitions, and a long history of inconsistent results on specific licenses.
I have no idea how any of this makes it easier for companies to disregard copyleft terms. Diffusion of copyright ownership and constant initiatives to discourage enforcement, by giving up rights and including by vilifying those enforce theirs, make it easy for companies to disregard copyleft.
This is something I explored initially for Oban[0] and I interviewed a few successful OSS product owners. They attributed zero sales to licensing. All sales were driven by features that a business needed once they had already invested in the core project.
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 - https://github.com/kiprotect/kiprotect - 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.
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.
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 thin Hashicorp does something similar on top of slect core features (which tend to eventually end up on the free and open version eventually, which is funny because the enterprise customers end up being beta testers due to HC's habit of releasing features in a half-working state).
*like https://github.com/spieglt/flyingcarpet
Sad story is that in many cases the biz paying for interesting contributions is questionable (Googel, Facebook et al).
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.
If it was sensible you'd see people like RMS and the Free Software Foundation advocating for it.
New approaches are successful all the time.
hash(daily_salt + website_domain + ip_address + user_agent)
Update: 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.
1. https://github.com/plausible/analytics/blob/master/lib/plaus...
I've targeted residential ISPs before in this project: https://eligrey.com/blog/zerodrop/
You can get good alignment in contracts that pay developers to write new software. And you can get good alignment in license agreements that pay for software already written. You can get good alignment in traditional software-vendor combination contracts for licenses or services plus maintenance and support.
Depending on what you mean by "open source", a substantial number of potentially well aligned models go out of bounds.
Also I would suggest changing your differentiator from cheap alternative to something else. When something is really cheap, it raises question if quality will be as good. You could add '1$ for Beta' or First year to create an impression that you are absorbing the initial cost.
Refresh your filter lists and it'll no longer be blocked.
I hope they'll fix that!