Most of the people writing OSS do it for fun/side project/to solve a problem, not for the money.
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.
> Most of the people writing OSS do it for fun/side project/to solve a problem, not for the money.
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 there was a time, most people were doing it for fun but today most people do it for building profile, commercialising it or consulting around it. It offers a path to freedom. Though hard to productise OSS, it seems to work well for the other reasons.
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.
> 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.
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.
It could also be in terms of showing open source community engagement to look attractive to employers, or to work on projects which are popular in corporate use, leading to being hired for that expertise.
I am in this camp. I created a GitHub account and started a project because a recruiter told me I needed to demonstrate my coding skills if I wanted anyone to take me seriously as a junior engineer prospect. Trying to get your first gig as a professional web developer when you're in your late forties is hard work!
Then the project I started decided to trigger my obsessive behaviours and take over my life. And so it goes.
I am more on the hardware side where the economics are different. When I was younger I was largely motivated by trying to commercialize my projects (not just releasing the full design files under permissive license, but trying to use noncommercial license and selling kits or whatever) but as I got older the meger income I might make selling hobby kits on ebay is no longer an attraction and I am solidly in the camp of 'give it away for free, and if someone wants to commercialize it all the power to them'.
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.
> ...this sort of assertion is often thrown around with no data.
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.
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.
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.
I would say a lot of people yes but "Most" may not be accurate clearly there are more projects on github than there are companies which are funding OSS projects.
The results here are going to depend on if someone spending 1 hour a month on a project with 1 user, and someone spending 40 hours a week on a project with 10,000,000 users both count as 1 OSS developer.
True but I was referring to the ones who are not corporate funded but spent 20 Hours or so on OSS, all large OSS projects were dedicated personal projects for many yrs with a lot of users the funding may or may not be there, Before Industry realised Linux kernel is a strategic asset people were contributing patches and many many hours without funding.
Nope even if one company funds 100 projects each we will still run out of companies that fund OSS projects, there are many more individual efforts some of them patreon funded but not all. And people have been writing OSS since 70's with or without funding.
In my experience this is not 100% true. Many times you get involved on OSS to "scratch your own itch" be it a personal project from scratch or collaborating on somebody else OSS project by fixing/adding something that irks/needs you specifically.
I have considered open sourcing projects before but decided against it due to not wanting to support it. I have a hard problem saying no or ignoring people and so little side-projects or proof-of-concepts that I have open sourced turned into more of a pain that they were worth.
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?
Please, please, please still release your source if you don't mind! Especially for "random hacks" like a home brew bridge!
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!
If it's just a small script you can throw it up on GitHub Gist. People can still leave comments there, but you might feel less obligated to spend your time on those than if you see "[x] open issues" on your project.
You can also disable issues entirely on a project, if it's slightly larger than just one script. This, plus a disclaimer on the readme like "This was made solely for my personal use and I cannot provide support!" seems like an okay way to go about this.
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!
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.
One solution might be to publish it but just disable issues on GitHub and add a clear notice setting boundaries. Make sure you don't have your email or Twitter or whatnot in your profile either because people will find that and email you no matter what you say in your README.
You make an excellent point here—it takes a lot of effort to get a solo project (OSS or otherwise) to be profitable enough that can compete with a day job’s salary. As somebody that is monetizing OSS, making a supplanting my salary is my measurement of success. At that point I can focus on my product and my customers during core working hours.
"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"
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.
I'm envious a bit. The hard parts for you are the easiest parts for me. Uploading to Soundcloud is too easy, and sometimes I put stuff on there that's kind of embarrassing. Etsy page creation, Soundcloud metadata, readable READMEs... I wish those were my hardest problems.
I think a lot of developers feel that just getting it to work is the hard part. Once that happens, the rest should fall into place. So when you finally get something that's good and works, it comes as a shocker that its only about 50% of the way there.
Wow, music, art, dev, you did quite a lot. Nice. I plan to try music (drums to be precise), but time..
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.
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.
> 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.
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.
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.
It does nothing of the sort. This is propeganda that mega-corps want you to believe because they are unable to rip off AGPL software effectively. Organizations like Google can afford to not use AGPL software (they can just write their own software), but it costs them money, so they refuse to use AGPL software and spread propeganda that it's impossible to do so, to weaken its market penetration and ensure that they have greater access to software without the responsibility to contribute back.
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're glossing over the fact that being compliant with AGPL requires more competence than the vast majority of software jobs. I know you could competently integrate or use AGPL software, and I might be able to do it (while repeatedly referencing armchair lawyers on stackoverflow), but there is still a risk I fuck it up and my (or my employer's) competitive advantage is in jeopardy.
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.
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.
> 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.
>This depends on what your "client" is. If you're making library calls, lawyers get uncomfortable.
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 agree with you, and this is where my concern lies: it's Open Source software, but I think that terminology is misleading (in the case of this software), where as, I find some of the close-but-no-cigar licenses much more "Open". So, while I see tremendous value in OSI's definition, I find it is somewhat of an impedance mismatch with what the average fool expects.
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.
You're probably right (and also, I find your comment further below regarding interpretation of AGPL insightful, insofar as it touches on a point in AGPL that would impose limits onto unrelated code, and that some people consider unenforceable).
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.
To clarify/correct this a bit, Webpack is not funded by the OpenJS Foundation. Yes, it is an OpenJS project, but the foundation does not provide financial support for open-source development. It does provide legal, marketing, and other support, as well as being able to assist with infrastructure costs, but it's still up to each project to separately run (or not) their own fundraisers and other funding activities.
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.
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.
> Often people want to help out financially, but they don't see an easy and convenient way to do so.
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.
CKEditor (https://ckeditor.com/) releases their product using the GPL license. Most large business avoid the GPL since they don't want to release their own code in accordance with the GPL. CKSource, the company that releases CKEditor, sells commercial licences to those companies, and will issue free licenses to GPL-incompatible open source projects. https://ckeditor.com/pricing/
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.
Consulting or support. State it clearly on the project page and make sure you have a correct license. You need be aware if the library choice in said enterprises is a must-have or nice-to-have. I wouldn’t bet on corp. manager freeing a budget for a non-critical library.
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 :)
Are there any tricks to not getting entangled in the integration web? I could think maybe keep some references on hand of people who do integration work and refer them instead whenever the topic comes up?
Do you have any messaging suggesting that people donate in proportion to their ability/usage?
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!
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."
If you offer GPL/Commercial dual licensing then that basically is the case because large companies generally don't have lawyer-approval for GPL in their codebases (not always but as a rule of thumb they don't like the GPL).
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.
You could just write that term into a modified BSD license or some such. It wouldn't be Open Source at that point but it would get your point across. Enforcement would be difficult but you'd really only need to rely on the rule following behavior of a few big corps
Seems like that would do a lot of harm to your project. GPL isn't the only way to restrict commercial use. It's definitely the best way to annoy people working on non-commercial OSS with any other license though.
Can you just change the license terms on your next update to say, if your market cap reported in the FY is over threshold set by this license then you have to pay a flat fee of X.
The most direct way to monetisation I’ve seen in the community is writing a book or doing consulting. Maybe there are other ways that aren’t as visible to a casual observer.
So for someone trying to follow this path, basically I open source a library and try hard to get important people to adopt it, and then if/when they need more help using my code in their systems, they will pay me money to write the code for them instead of some other dev?
I’ve been part of workshops run by key contributors, as well as seen consultants brought in to try to optimise code using their open source code. There are a lot of ways, but they usually aren’t as direct as “normal” employment.
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.
I assume yes because of your deep knowledge related to the package, whereas they don't have to spend time ramping up an in house dev to learn the ins and outs of it.
You might have some luck with Tidelift (https://tidelift.com/about/lifter). I get pizza money every month for a long time top-20 (by download count) Python package, which isn't much, but I never expected anything so fine.
charging for support and giving companies MIT style license with their name attached as exclusive licensee for that version is the best way that I've found. New features and customizations have worked out well for me. Never made a ton of money but I've gone on a couple of vacations thanks to it. Usually you know who you're dealing with so charge accordingly.
How about asking them to sponsor it? And as part of the sponsorship, they get to schedule meetings (no more than 30 minutes a day, perhaps?) where they can tell you how they're using the library, so you can consider that when making changes.
So long as it's clear you have no obligation to re-write the library especially for them, will this work?
Sponsorship, etc. linked to broader goals, such as features, better docs. Reach out to businesses with a positive message: what can we offer if you help us out? Showcase your sponsors, build a small community.
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.
That's not always true. Turning an open source project into a stable business is difficult, but making a bit of money on the side isn't if you do something important and do it well. If you make the best breakfast in the morning people will come; If your library is the solution for (say) embedding python in COBOL and businesses use it, chances are they won't mind being able to pay for support. The first customer is the hardest to get but even relatively niche programming languages can have hundred dollar bug/feature bounties.
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.
I said most cases. What you are describing are the exceptions, not the rule. I don't remember how he phrased it exactly but about a year or two ago Andy Mueller tweeted that his biggest wish is that scikit-learn would eventually receive enough support to be able to have the maintainers work full time on scikit. Think about this for a second: I can't recall seeing a single ML project that doesn't rely on scikit to a certain degree and the core maintainers are 8 iirc. That's pretty sad if you ask me.
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:
> 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.
Your core product is something that needs to be popular enough that anyone needs your services though, and it's not going to be popular if it's difficult to learn and navigate.
That's true, but that's exactly why this strategy can be so detrimental to the long-term health of a project. The core product has to be just barely good enough to solve a problem for enough people; once it gets popular, it can coast on that momentum for a while, even as it ossifies.
I can think of a number of projects in the "big data" space that seem to have fallen into this trap.
It also has to outcompete other products that do the same thing.
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.
Actually you do, stuff you do can be rolled back into your project. Not everything is binary. You can enjoy hacking on a project as well as making money on it.
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.
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).
I guess the problem is that once there is a paid CLI tool, some other dev will make a clone for his CV / GitHub where even the compiled binaries are free. Now people have to choose between the OG tool and maybe pay for it or use the mostly feature complete (or feature complete for a specific use case) free version.
I would even go as far as the community will continuously switch to the free tool until the free tool has enough clout / traction to actually supersede or replace the OG tool.
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“
One problem I see is that for more tech-savy Linux users, which are the people most CLI software is targeted at, convenience means simply installing something via their distributions package manager. I am not interested in downloading your precompiled static binary or setting up your private repository. I want to run `foo install bar` and get on with my work.
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.
You’re right regarding the convenience point, to have a chance to work it has to be as straightforward as possible to buy and then install your tools.
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.
I fully agree that it is unfair to creators that they cannot reasonably generate income from CLI apps. Still, I am unconvinced that the model you are proposing could gain viable traction.
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.
Certainly I'm interested to see if many people have been clicking the "x packages are looking for funding" links with `npm` and could imagine that sort of in other package managers too...
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.
That's exactly what Aseprite (a pixel-art tool) does. I think it's great, I got it to build on Windows but eventually ended up buying it on Steam because it's so good.
It would be interesting to test this mode. I work for free on the source code, and you can get that for free. But if you don't know what to do with it (i.e. build it) or don't want the hassle of setting up a build environment, you can always pay the project for that effort.
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.
"What about charging for build and distribution? Krita does something like this for their Steam and Windows Store versions, that helps finance their development."
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.
This is the model for the Ardour DAW on Windows. You get the source or either a free binary that disables audio output after a few minutes or a paid for binary eithout that restriction. I don't know how well it works.
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.
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.
An alternative to this option that might make both camps happy is to use the Business Source License [1] that is source-only for new changes, and automatically become open source after a certain time (default after 4 years).
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.
Many companies on this model welcome and maintain improvements. Some also extend that program to nonpaying customers, who may be more capable of contributing back than paying the standard license fee.
Source Available[0] is a model, and it's fine, but it's proprietary software, not Open Source. I really wish people would stop inventing new terms for this or pretending that it's still "open source"; there's nothing wrong with writing proprietary software, just don't pretend that you're doing something else.
Do you have an example of this? If i was on the buying side, I would be wary of just buying source code. Most times writing from scratch is much easier than maintaining someone else's code
That model falls apart from the start. If anyone is savvy enough to compile from source then why buy it? If the code is free, then, I don't see how they'd even bother to pay for it; it being the compiled version; of course.
It the source is out they can't hardly enforce anything or much. People will just go to github and compile it for free.
> 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.
That's why have licenses that forbid certain usages. Obviously those are not 'Open Source' as defined by OSI. If you use such software in ways forbidden by the license, you are liable. Companies would usually be very careful, and would not knowingly ignore the license terms.
The people that are doing that wouldn't have bought it anyway. Most businesses that are legit will pay for what is required to be paid for to remain legal and not get sued.
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.
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".
Anecdotally I don’t believe dual licensing is viable for smaller projects. There simply aren’t enough companies that care about your license to make it a reliable business model.
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.
We shall not challenge the OSI and FSF definitions, because every principle that they defend is not only worth protecting, but under attack by bad interests. "Challenging" these is how you end up being gaslit by companies which are abusing the open source brand to peddle software that isn't. And such muddying of the waters makes it easier for companies to disregard the terms of copyleft licenses. This is non-negotiable: non-commercial licenses ARE NOT OPEN SOURCE, and people who argue for this are actively causing harm to open source. I expected better from you, Matt.
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.
You make a perfectly circular argument. We shouldn't call things the OSI mailing list doesn't like this year "open source" because companies will call things the OSI mailing list doesn't like this year "open source". In other words, "open source" is valuable because it's OSI's exclusive intellectual property. Its utility lies in exclusion and control.
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.
OK, the Prosperity license and others like it shouldn't be called open source. I should have been explicit about that, as I believe Kyle Mitchell (author of the two licenses I linked) is.
I for one don't think that every principle they defend is worth protecting, nor I do fully agree with their definition. I'm not trying to convince you, just to say that some people have a different opinion.
We're in the process of monetizing an open-source project as well (Klaro - https://github.com/kiprotect/klaro). 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.
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.
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.
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.
Without having any knowledge of or experience with Storybook, that sounds like an optimal approach for such a project.
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).
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.
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.
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.
Which in many ways looks deeply unapealing. The last thing I want to do is sell support or services. I'd much rather spend my time writing software that is easy to use and well documented.
GPL would protect more user freedoms and potentially avoid big SaaS providers making profit off of your product, but it won't help you earn money just like that.
Oh come on, if it was possible to run a business model like that it would have been done. You would see multi-billion-dollar-valuation publicly traded companies like, say, Red Hat out there.
If it was sensible you'd see people like RMS and the Free Software Foundation advocating for it.
I noticed that Plausible claims to measure traffic without being able to persistently identify users, but https://plausible.io/data-policy states that they store the following:
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).
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.
I'd think you can see who owns the IP range and check if it's some ISP... probably some api somewhere also... oooor just check the reverse dns and see if it's dyn.someISP
The value of software lies overwhelmingly in the software. Charging for anything else perverts incentives. Charging for features? Make it hard to add features. Charging for configuration? Make it hard to configure. Charging for training or documentation? Make it hard to understand. Charging for hosting? Make it hard to host, monitor, tune, &c. Not charging at all? Slurp up personal data on users, and charge for that.
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.
Are you sure you want to deal with customers who only pay you $12/year? Any profit you get from them will be wiped out the second they send you an email and you take the time to read and reply to it.
I’m willing to test this hypothesis. It’s a marketing exercise for me. I used to overthink a lot about the choice of technology, scaling, etc At the end of the day, what matter is selling something that people want and getting feedback. On the other hand, those analytics are extremely simple, they somehow remind me of a more intelligent version a counter widget we had back in ’90. It’s just a POST with some data additional data being trigger at each visit. I’m sure how this could require a lot of support - time will show... and I’m probably wrong. ;) It boils down to my ability to market the product so that I have this support problem in the first place.
i think you should add more details / screenshots of product. Your landing page doesn't talk much about what user would get. Is it same dashboard as GA.
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.
Haha! You should try it and tell me! Jokes aside, it’s just my attempt at indie hacking. I have some experience in sysadmin, and based on that I simplified certain parts of the system, so overall it’s more affordable, yet remains profitable. It’s still early, and probably much worse than Plausible, Fathom or Simple Analytics, but I decided to make an offering based on the price as the space is pretty crowded. If it works, I promise you I will do my best to not make it a 1/6th of the quality. ;)
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.
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.
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.