I've been harping for years to anyone who would listen, Open Source is not a business model [0].
If your motivation for doing open source is money, you're doing it wrong. You'll be much better off just getting a job (and GitHub stars can help with that!).
We all know "build it and they will come" and "follow your passion and the money will follow" don't really work in the real world. You have to make something people want and convince those people it's in their best interest to pay you.
Open source can be a part of a larger strategy to earn a living (consulting, customizations/open core, relicensing, books/talks/seminars, etc), but yeah, GitHub stars aren't money.
Frankly I don't get purpose of this article. Guy wrote some software with clear expectation of money and released it for free. Fine - bad pick of distribution model - it happens.
Then he writes article, stating that you shouldn't be ashamed to ask for money. To whom it's directed? All OSS developers? Including developers of electron (one of his dependencies), which then has tens or hundreds of packages in its dependency tree? What would happen to his browser if they all wanted dollar/month for use?
If you want to code for money - do paid product. That's OK. No reason to build philosophy around being entitled to payment because you have github stars.
To people asking "why not open source?" (iirc have asked this at least once myself) on every non-open-source project released. The answer can simply boil down that the dev(s) are looking to money off it.
He wasn't saying just because you have GitHub stars you should get paid. He's encouraging open source developers to be proud of their work and not be shy about setting up a method for getting paid.
Yeah it's worse to give something out good for free and then make lots of awkward attempts thereafter to monetize, essentially diluting or screwing up what was previously good in a belated attempt to collect compensation. I see this with big sites too; thinking glassdoor and coursera, maybe even facebook falls in this category. In which my initial impressions were positive but at some point these free apps became free-ish and annoying.
Of important note-- open source doesn't necessarily mean free. You can still require paid licenses for eg; commercial use but still provide the source code/allow modification.
As someone, who has experience in building and selling open-source businesses, I cannot agree more
Open-source can be a great selling point and a growth driver, but it won't replace all the other parts of running a business, such as marketing, sales and most importantly, a functioning, profitable business model
If you need some advice, feel free to e-mail me
I will take a look at your open-source project and tell you how it can be turned into a business
This times a million. I'm not sure when people started thinking that everything they do outside of office hours should have a paid return, but open source is meant to be something you do to help others, if you feel like doing it. It's basically just giving back to the community after creating something interesting for your own purposes.
Does that mean it can't help you get opportunities that can make you money? No of course not. It can look good on a CV, boost your name reputation online, get you a speaking gig or a spot at a conference, etc.
But it won't necessarily do that, and you shouldn't expect a return in 99.9% of cases. It's like expecting that your video game mods are going to become your career. In theory it could happen, but it 99% of cases it won't, and that's perfectly fine. It's something you do because you enjoy it.
Hard disagree and flip it back to the freedoms of the user of the software. OSS is about giving the people using software the freedom to inspect and modify the code to the system they use, full stop. The developers have always had the ability and right to sell it or earn from making it. That people think it is developer servitude and virtuously giving it away is incorrect. It may happen, but it is def not a requirement
I guess I should mention that there's nothing wrong with selling an open source product, or selling services related to it. And it can work for sure, especially if you market it correctly.
The thing to note is that:
1. If you're sticking your code up on GitHub or whatever, you shouldn't really expect to make money from that alone. People will use it, and the majority of them won't do much more to support the project that give it a star.
2. If you do sell an open source product, other people can compete with you by selling the same code to their users/customers too.
I've always been a proponent of open-sourcing libraries and smaller apps that aren't a core part of one's business. I don't do that much to be honest, I file issues and feature requests and on occasion, will form/fix/pr back upstream.
IMO is about scratching one's own itch first. That said, I'm not good at running a business, and have little motivation to do so. I like what I do, I'm paid pretty well to do it. In the end, that means I'll probably never be a multi-millionaire. If I didn't work for others, I do have a couple projects I'd like to work on, biggest of which would be one that has been tread so many times before.
In the end, it's a mix. Some are completely altruistic with their free time. Others are paid to work on floss as it brings recognition to a corporation, or scratches their own itches, collectively, but doesn't bring direct revenue. And some do want to be Entreprenurial, those are the ones that should think twice about fully open sourcing their core product(s).
Open source the tools and adjacent products, don't necessarily open source your business.
Are people really depending on Open Source for Economics?
Open Source is not a business model, and that should be obvious. It's a distribution model, which has nothing to do with economics. Sure, it may affect a few variables but marketing and sales strategy are what matter more.
>Are people really depending on Open Source for Economics?
No, but it often seems like people argue as though it should be sufficient. There are lots of people who argue that things should be open sourced who in their arguments elide the point about how will people survive working on things for free.
"In a typical year the OpenSSL project receives about US$2000 in donations."
OpenSSL is one of the most known open source projects. It's like https://xkcd.com/2347/ There's little hope to achieve its level of success by doing open source. And even that project did not earn good money. So living from open source project just by writing code just is not a good idea. It's possible to run open source project as part of startup, I guess. But that's more about marketing than writing code.
But in all seriousness, Open Source is a gift economy, and collectively produces better and more stable codebsses for the planet, and allows more innovation and wealth creation than closed, proprieraty systems.
> I've been harping for years to anyone who would listen, Open Source is not a business model [0].
It's not a business model that usually works, but when it does, it's beautiful: you get to work on what you want, on your own terms and building something truly useful. You become a (tech) god, and you being paid for it. Respect and money. Isn't that what many of us dream about? That's the reason many people try to build something "cool" and publish it on GitHub... to see if they win the lottery. I have definitely tried, but perhaps I know beforehand that I have a 99.999% chance of failing.
> I have definitely tried, but perhaps I know beforehand that I have a 99.999% chance of failing.
You can greatly increase your chances if you also learn the business aspects of open-source, not just publishing code on GitHub
I learned the hard way, but you don't have to. Basic economics understanding goes a long way, along with business-oriented thinking and asking right questions at the beginning, eg. what extras can we offer that would save a lot of time/ generate more revenue. Once you can answer that, you're set to success
> whether an OSS project lends itself to monetization is a really interesting and subtle question. rule of thumb, be at least two of these: big, boring (roughly correlates with "infrastructural" as @patio11 puts it), and lacking obvious substitutes
Many projects with high star counts fall into only one of those categories
I've been harping for years to anyone who would listen, Open Source is not a business model [0].
But it is, in that, your business would not exist without it.
Open Source asks so little in return. Get trillions of lines of code for free, just give a few back please.
This is akin, to a trucking business paying gas tax. A large corp might save hundreds of billions on software cost, so why not release a million worth for free?
Yes, I get it. A single product, the entire revenue stream, you need cash, I get it.
Who really knows but is it possibly no different from people who want to support themselves by playing an instrument? Or any other artistic pursuit? It would be interesting to see numbers, but I'm sure there are some out there who do make it off of open source software. They are just the exception.
I continue to think that the best model is the one adopted by Fody.NET[0]. It's open-source, on GitHub, under the MIT license, developed in the open, and with a voluntary OpenCollective. And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. The result is a system that is paid enough to be excellent, excellent enough for most users not to need support, and non-bogged enough for paying users to get excellent support.
The best part is when corporations get involved. A company will absolutely get something for free if it can, but if it has to pay, it'll pay a lot more than the absolute minimum, for PR reasons.
While I'm always excited about new ways of monetizing open source, if I'm looking at the OpenCollective contribution page for Fody correctly, this model has made them under $10,000 in the past 2 years or so.
From a business perspective that's basically a rounding error and nothing compared to what you can do with the conventional approach of selling consulting/support or, heaven forbid, your own proprietary solution.
So in what sense is this the best model? Has anyone used it to generate $100,000 in annual revenue, let alone say $10M+? More profitable model = more hiring developers to improve the software...!
It is indeed terrible from a business perspective, because Fody isn't a business. It's an open-source project. If you want to start a business, you should start a business. The author of TFA wasn't under any illusions it would completely replace her day job, the problem was that it wasn't worth spending the time on after the day job. There's no substitute for selling retail copies / subscriptions, but within the realm of open source for all, Fody's model is the most efficient way of converting appreciation into a little extra cash.
This is a deceptively insightful comment. At least it wasn't clear to me for a while.
If you want to start a business it can definitely have an open-source element to it, but that's just it. The open-source part is just one piece to a business and you better be aware of all the other pieces that need to be done in order to make money which aren't always engineering/programming related. EG: marketing, sales, consulting, fundraising, accounting, etc...
A common approach that people do now is create the open source offering then run it as a service where they can charge a premium for the support and leg work for hosting it. See: mongodb or elasticsearch or influxdb.
I haven't found many pure open source solutions where all they do is make the software better all day and ignore all the elements of business growth needed. Maybe the Linux foundation is a good counter example but I don't think there is a clear path to be paid for just contributing solely to open-source while neglecting other business elements.
>And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy.
Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and you reject it because you want me to pay you first, I'm dropping your software without a second thought.
>Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and it gets rejected because I also need to pay, I'm dropping your library without a second thought.
You have a point. On the other hand, considerable part of maintainers burnout comes from arguing with well-meaning strangers that come with PRs that are (usually) useful, but don't fit the established codebase well. By only accepting PRs from members of a collective, the amount of drama is reduced.
Yes, I'm sure it makes sense for them to have this perspective. And it also makes sense to me that if I'm not going to get the bugs I encounter fixed, even if I make the effort to fix them myself, then my effort is better spent on a project where that will happen. Their loss.
Must get awkward when the PR from a member of the collective comes in with a tonne of issues though? They are paying so may feel entitled for it to be merged.
They are entitled for attention, yes. And if they respond to code review and ready to address comments, they will likely get it merged (depends on the project and the PR, obviously).
The requirement to be a member of a collective is a filter. For popular projects it will likely do more good than bad. For niche projects, it might be worse than no filter.
> You have a point. On the other hand, considerable part of maintainers burnout comes from arguing with well-meaning strangers that come with PRs that are (usually) useful, but don't fit the established codebase well. By only accepting PRs from members of a collective, the amount of drama is reduced.
They were explicitly talking about PR for a bug, not unwanted feature.
Yeah, sure, there is occasionally low quality bug fix that's problematic issue (bug should be fix but the code to fix it is garbage and nobody wants it) but I think that's rarer problem
> I'm dropping your software without a second thought.
Ha, it sounds like more work to replace a free piece of software with something else than to use your own patched version. Especially if you have to replace it with something inferior or proprietary. If there are better-maintained alternatives, why did you adopt it in the first place?
Pull requests take work to review and test. You shouldn't take that for granted and assume everything will be merged for free.
If you manage to review and test fixes faster than the original, or if you're willing to add features and maintain the code yourself, go and promote your fork!
>Ha, it sounds like more work to replace a free piece of software with something else than to use your own patched version.
Nonsense. You think signing yourself up to maintain a patched version of someone else's code for eternity is better than using someone else's code? You have to sign up for upstream CVEs, keep updating the upstream base and rebasing your patches on top.
>Especially if you have to replace it with something inferior or proprietary. If there are better-maintained alternatives, why did you adopt it in the first place?
False dichotomy. A library is measured in various dimensions - how well-maintained it is, what features it has, OS / hardware dependencies, performance, etc. Something that is better in one dimension might be worse in another dimension, so that there's no single objectively better library.
>If you manage to review and test fixes faster than the original, or if you're willing to add features and maintain the code yourself, go and promote your fork!
I have my own work to do, not maintain forks of other people's code.
The page I linked was the FAQ, which addresses this exact point:
> It may seem unfair to expect people both contribute PRs and also financially back this project. However it is important to remember the effort in reviewing and merging a PR is often similar to that of creating the PR. Also the project maintainers are committing to support that added code (feature or bug fix) for the life of the project. Pull Requests from non-Patrons, that are of significant value to the larger Fody user base, may justify the effort in reviewing and merging.
Ultimately if you care enough about Fody to spend over a hundred dollars worth of your time contributing to it, you probably care enough about Fody to drop them three dollars.
> Ultimately if you care enough about Fody to spend over a hundred dollars worth of your time contributing to it, you probably care enough about Fody to drop them three dollars.
Fine. But if my code is useful, and it ends up convincing more users to become Patrons, will I get any financial gratification from the Fody maintainers? Or are any profits from this contribution going solely to the maintainers?
In your average open source project, backing it is separate from using it and contributing code to it. My contribution would therefore benefit all people, including those who cannot pay. But the Fody maintainers consider them to be freeloaders and unwelcome people, so I have reservations about contributing and what the benefit from my contribution would be to others. I'm not working for free for a for-profit entity.
>Ultimately if you care enough about Fody to spend over a hundred dollars worth of your time contributing to it, you probably care enough about Fody to drop them three dollars.
No, I really don't.
https://github.com/keepassxreboot/keepassxc/pull/8500 - I was randomly reading keepassxc's manpage and spotted a curious option, spent some time spelunking through the code and history to discover that it was an outdated option, sent a PR.
https://github.com/python/typeshed/pull/8617 - I converted one of the scripts I use in my DE from shell to Python, saw that VSCode has this new fancy typing support for Python, quickly found a basic bug in the type definitions for the os module, tested a fix locally, sent a PR.
https://gitlab.gnome.org/GNOME/gtk/-/issues/5250 - I found an issue with copy-paste on my phone, investigated it all the way through to the GTK stack, found the commits that introduced the issue, created a distro patch for it while discussing it with GTK upstream.
etc etc. I've made lots of fixes like these. I have no interest in paying for each and every one of them. The projects are all better off for fixes like mine and gatekeeping them on payment would've been nothing but their loss.
Also, to be clear, there is nothing special or unique about what I do. All large community projects where the users greatly outnumber the developers continue to work because of PRs like these from their users.
I do check the LICENSE and CONTRIBUTING files before I contribute. It is likely that I would have not contributed to such a project in the first place. It doesn't change my point, namely that a project where I cannot contribute fixes for bugs I encounter is one that I have no desire to use.
BTW, the reason I mention sending PRs for bugs I encounter is that, when I do encounter a bug I don't immediately file a GH issue and make it the maintainers' problem. Instead I act upon it just like the maintainer would, by checking the source to figure out why the bug is happening, `git blame` etc to see what commit added that code, whether the issue I'm encountering was already identified or discussed when that code was committed, and so on. So as a result of doing these things I often end up either knowing my issue is by design and that I was doing something wrong, or end up having enough knowledge to be able to construct a bugfix myself.
I can understand too, but I won't even dig into your code when I need to pay you first. Shouldn't you pay me too for opening the pull-request, because "I did your work"?
I'm not sure how I feel about this one. Sure, the maintainers have no obligation to review and merge other people's PRs. But when this also applies to genuine high-quality community contributions, I feel like there must be some negative side effects.
I'm sure this model works well for an established project like Fody that's already quite highly polished, but I'd be pretty sad if all (or even a significant subset) of open source adopted this model.
I'd definitely be interested to hear any counter-arguments to this though. Are there any avenues for individuals to contribute for free, if they aren't using it for profit?
I think this may be a case where because you have a bunch of freedoms, you feel like you should have more.
I say this to re-assure you, not critisize you.
Open Source, and Free Software, are very clear on the 4 freedoms you enjoy. You can use, modify, distribute etc.
But it's not a 2-way street. You have no rights about what goes back into the project, the author is under no obligation to receive code contributions, no obligation to add features, fix bugs, or anything like that.
Of course lots of projects actively seek out contributions, but it's certainly not a requirement - nor (IMO) should it be.
Coversely open source has struggled to find viable financial models. This sounds like a success story and we should look long and hard at any successful financial model.
So, I don't think you should feel unsure. If you want to contribute then chip in some loot. If it means the project becomes sustainable you are the big winner.
But most of all, I think, be careful of adding "more freedoms" to your understanding of OS and FS, when they don't exist.
I'm not saying I think the maintainers have any obligation to do things for me (I tried to make that clear in the original comment). What I was really trying to say is that I don't think this model would apply well to most projects, as the GP was saying.
To take an exaggerated example, if I tried to use this model with any of my small OSS side projects, the only result would be that no one would contribute. This model means that the development of the project is going to be almost entirely driven by:
a) The original maintainers of the project (who will rightfully get bored of maintaining it at some point), and
b) The handful of companies that have financial interest in a certain bug/feature.
Again, that's probably fine for projects like Fody, but certainly not all of OSS.
The logical conclusion of everyone taking the model of "pay me to review patches or read your issues" is fragmentation. Instead of a vibrant ecosystem where people collaborate on patches and the project grows, the issues and solutions remain internalized in private forks. Is that a better outcome? From the time/money standpoint it's great, and it may make the project more sustainable since there are fewer issues and PRs to review, but it hurts the project long term.
You have articulated well the trade-off between "project first" and "business first".
From a user point of view, project first is the only thing that matters. There is an instinctive resistance to anything that gets in the way. On the other hand users generally don't care about the project authors getting paid or not.
From the author side, getting paid is often a goal. If that means limiting the community to paying users, then so be it. From their perspective they are offering value, and they choose to spend their time focused on users who are paying.
In other words they need your money, not your code suggestions. They can code, but code doesn't pay rent.
As you say, others can choose to silo their changes, and not post them back, that is their right, and indeed likely happens anyway.
I like it personally. Free to use, pay for support.
The distribution of something already made is free. Supporting, understanding your issue, developing a fix and releasing it…all of that takes a real person’s time.
As a contractor, you learn very quickly that people will ask for anything if it doesn’t cost them anything. There are a lot of people happy to take advantage of you if you let them.
I totally agree for things that would normally be described as support (e.g. feature requests or low quality bug reports), but a lot of things aren't that.
Personally, if I submit a bug report or PR to an OSS project (which admittedly doesn't happen very often), it's almost always because I think the time I've spent investigating the bug/feature could benefit other users of the project.
For my use cases, it's generally much faster and easier (at least in the short term) to just fork a project and make whatever change I need locally, than to wait for it to go through review/merge/release in the original project.
Another commenter has pointed out that they make exceptions for certain types of contributions though, which I guess would help with this.
> This process will depend on the issue quality, and the impact on the larger user base.
So, if I understand correctly, they won't automatically close issues if you aren't a subscriber, but the bar for the quality to keep it open is probably significantly higher.
I don't think that's a bad model. Although, I don' think it would scale well to every open source project having it's own subscription stream. But maybe if there were companies that maintained collections of projects?
Depends on where the bar is set but as long as "A PR that fixes actual bug with nicely written code" passes I think that model is entirely fine (especially in modern era when it can bet mangled thru test suite via CI and merging it is near-zero effort for maintainer).
That's essentially someone helping your paid customers to have better product for free.
But it is MIT, can't I use it for free?
Yes all projects are under MIT so the community backing honesty system can be ignored and Fody used for free.
Do I need to be a Patron to contribute a Pull Request?
Yes. Users must be a Patron to be a user of Fody. Contributing Pull Requests does not cancel this out. It may seem unfair to expect people both contribute PRs and also financially back this project. However it is important to remember the effort in reviewing and merging a PR is often similar to that of creating the PR. Also the project maintainers are committing to support that added code (feature or bug fix) for the life of the project. Pull Requests from non-Patrons, that are of significant value to the larger Fody user base, may justify the effort in reviewing and merging.
Do I need to be a Patron to raise an issue?
Yes. Users must be a Patron to be a user of Fody. As such when raising an issue (question, bug or feature request) and not a Patron, the issue may not be actively triaged, and eventually closed as stale. Issues from non-Patrons, that are bugs and are highly likely to affect the larger Fody user base, may justify the effort and be handled.
Also, the minimum amount is $3/Month: which surely isn’t near enough to pay for their time! Many developers can afford $36 a year, and if not, a developer can still use it for free (BSD licence) and maintain their own branch. https://opencollective.com/fody/contribute/patron-3059/check...
You realize that my dependency stack contains about 2500 dependencies right? If they all follow this model I’m looking at $90k/year just to contribute to a project.
> You realize that my dependency stack contains about 2500 dependencies
That is amazing: when I was younger, sharing code was a goal, but absolutely nothing could prepare me for your world. Previously I have had the luck to be able to rewrite a lot from scratch, removing most runtime dependencies, although definitely not replacing build dependencies.
I imagine auditing for security, and managing dependency upgrades, must both be onerously expensive time sinks?
I imagine auditing for security, and managing dependency upgrades, must both be onerously expensive time sinks?
Modern devs don't care. They just install whatever, let it pull in 1000s of other packages, and continue on their merry way.
Meanwhile, a package you use today, can root your stuff tomorrow. That is, next update and bam!
Package was sold to Evil Entity, or just the dev decides to rm your drive based upon geo location.
I get paid a lot to cleanup much of this mess, and while tools such as composer and node.js are useful, they are a horrible, horrible security risks.
If you use node or composer, be prepared for dozens of updates weekly. Each update risk laden, and feature and security fixes all mashed into one.
On a large project, you'd need multiple devs, just to audit all the change.
But as you will soon see, there will be all sorts of $reasons given, which all lack understanding of how traditional Linux distros handle updates, and boil down to "not my problem" or "someome else magically makes it safe!"
Have an unobvious copyright condition, get your code in thousands of projects, then spider the internet looking for companies that use your code, and charge them a $1000 “licensing fee”.
Or change the copyright in v1.1.2.2 and wait until everyone updates, and do the same thing.
> Modern devs don't care
I think the “modern” is superfluous and vaguely insulting: security isn’t/wasn’t cared about by most old-skool developers either!
Do you PR or raise an issue to every package you use? You can still use 2500 different packages for free. This seems like a good example how it would work well.
My point is that you are taking their point too literally.
Also, the business model is paying a subscription for the right to submit a pull request. Sure, you could wait until you are about to make the PR to buy the subscription, but that's a pain of its own.
Their point here is that this isn't a scalable business model. That's the assertion that started this whole comment thread.
To contribute to 2500 projects yes it would cost that. Otherwise your current rights or license that lets you use those dependencies already should be fine.
If we got subscription to dependencies, we would get only 3 or 5 deps, only required app to run. No more `is-array` like deps. Adding a new one would be deeply thought and reviewed.
For simple patches on my end, I'd port them forwards. For complex patches, I might hard-fork development and find like-minded people to send patches to me instead of the original upstream. Or if the codebase or changes are too complex to work effectively with, I'd abandon the project and treat it as radioactive and failing to satisfy my requirements (or even be correct).
It doesn't work if the project hasn't had any new issues in a while. There is no incentive to be part of the OpenCollective if the project is completed and has no bugs.
I've been struggling with this issue with my project. It's a completed project, no scope creep, no bugs, just occasional update once every 6 months or so. The docs are complete and detailed so nobody needs extra help; no one will pay for support
At the same time, I know for a fact that if the project was buggy or had gaps in the documentation, nobody would use it; they would use an alternative solution from a big corporation.
The level of competition is so intense that there is no room for profit, no room for missing documentation and no room for bugs on my end. Competing products are backed by a big name brand tech corporations; so they can have bugs and gaps in the documentation and users will forgive them.
Branding is extremely powerful. Once people trust a brand name, they will ignore reality. If you don't have a brand name, you need to be 10x better to be perceived as the same quality.
Perhaps it would be helpful to articulate what you feel you are missing? (I'm presuming money, but I don't want to put words in your mouth.)
It sounds to me like you have a solid project, and some number of users. With good docs. Which is great (we'll done.)
I'm assuming you want to monetize it? That seems to be the logical next step. Alas I'm not going to be very comforting with the next bit.
A) the time to think about monetization is when you start the project, not when it's done. Obviously a lot of projects get done for reasons other than money, and when you started you may have had other reasons. That's fine. But monetizing after-the-fact is a very difficult, dare I say "unsolved" problem.
B) this is going to sting, but most successful money-earning products have nothing to do with the code, beyond that it exists. A "business" requires more than "product" - a lot more. Marketing, sales, revenue, administration and so on. All of this is expensive, hence the need to have a business plan (ie, how does this thing make money?) before you start.
As developers we have a code-first mindset. But we try and compete with companies that have a business-first mindset. Companies are winning.
The fact that your project is complete, that it is solid is fantastic. Well done for that. However turning it into a business may be impossible, or expensive. That's OK. Celebrate what is is, don't pine for what isn't.
If nothing else you've learned the difference between a code project, and a business, and if you internalise that then you will have gained something of high value.
I'm not saying that Fody's model is superior to selling retail software, if what you are in the business of doing is selling retail software. I'm saying that it's superior to giving up on open source monetization if what you're in the business of doing is open source.
Fody says they have an “honesty system” and expect all users to pay, even if they’re not raising issues or PRs. That’s despite the fact that the code is MIT licensed.
How is that a more ethical, straightforward, or profitable business model than just GPLing the project and offering proprietary licensing?
Releasing code under a permissive license, then calling people dishonest when they use it according to the license but not the authors’ desires, seems silly and inefficient.
Which makes sense in a way because part of the brand is “we’ll be around in 2033 to support this”. And “need help? see myriad answers on stackoverflow” and so
on.
> And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy.
I don't know enough about the resulting system, but this sounds quite silly and contra-productive. Issues often hint at important flaws. If the community is not open (Ha!) to outsiders notifying them of important flaws, then that is a recipe for bad software. Some people might go there and start asking for features, instead of describing issues (although even that can be valuable input), but in my experience people are more often reporting bugs or asking how to do something, because it is not well described in the docs, or the docs are not as visible as they should be, or probably many other good reasons. Closing ones door to these valuable inputs can only result in worse software.
Closing the door to people that are drive-by posters who cannot be bothered to fork over three dollars can only result in better inputs. The issue with open source tip jars isn't that they're expensive, it's the psychological barrier in front of giving anything at all. That's the subject of TFA and Fody's model is the only real way to circumvent it. Ninety percent of people who submit issues are people who are invested in continuing to use Fody and so should be patrons, and the remainder of the issues are unlikely to be high on the signal-to-noise ratio.
> Closing the door to people that are drive-by posters who cannot be bothered to fork over three dollars can only result in better inputs.
We are not talking about the same kind of issues or people. Aside from the strawman:
People creating an issue with all the detail are already investing time into reporting an aspect of your project. Immediately closing the issues is like giving them a middle finger, for investing their time, trying to help the project.
Sometimes, when I have a problem with some tool being buggy, I consider opening an issue, but sometimes I don't do it, because I know it would be time-consuming. However, when I open an issue, I usually try to provide all required information and maybe even an example to reproduce the issue. I invest time to make it easy for the maintainers to see the actual issue. If they closed that issue immediately and wasted my time like that, I would be very careful to ever invest time again into anything those people create.
It's a UX thing. The "auto-close" behavior makes the policy obvious.
And presumably the maintainers are not bound in any way to not re-open an especially good/important bug. It just makes makes non-patron support opt-in, instead of opt-out.
That logic (your last paragraph) essentially assumes that people only care for selfish reasons. Plenty of people contribute for the sake of giving back to the project (by e.g. taking the time to write a high-quality bug report or PR).
In practice, excepting for major issues. In principle you are supposed to donate in order to use it at all, and the issue tracker is simply where they check to make sure.
I think the part of this that's weird to me, is that non-paying users are able to open issues or pull requests at all. Something about it feels very passive aggressive.
Why not just have the public facing project be a fork of a private, access protected project where bug tracking and PRs are handled, that only patrons can access?
For some reason, saying "only patrons can access our development repo" seems perfectly reasonable, but saying "we'll close your bug report if you don't pay us" feels a bit grumpy.
Thanks for pointing this out, I've never heard about this model before. Sounds quite reasonable to me. The only problem I see is if they treat all requests equally. I'd be concerned if security related PR get cancelled because the submitter is not subscribed. From my understanding they do pre-screen submissions before cancelling so that shouldn't be the case (at the price of creating some overhead for them).
This is a poor choice for a donation-driven project because it allows easy proprietization. It also does not protect from patents, tivoization and so on.
I put up a donation link (before GitHub sponsors was introduced) on a repo that had 5k+ stars. Got just one recurring donation (about $1 a month). This wasn't a s/w tool though (tutorials for CLI text processing).
Later, I switched to creating books out of such tutorials. I gave them away for free during launch weeks (but readers could still pay if they wish) and this model worked so well that selling programming ebooks is now my primary source of income.
It sounded bad, but how much donations that you'll receive don't actually always link to star counts. Stars on GitHub is more like "how many people added this project to their bookmark" than anything else.
That said, as how things goes, there are "high value" projects as well as "low value" ones. If you want to make money out of your open source project, target those "high value" use cases might help. Some fields just don't make a lot's of money even if you tried really hard.
I used to work in a semiconductor industry before. My earnings this year is 25% of what I used to earn 8 years back (literally, not adjusted for inflation). However, this is still more than enough to pay my bills ;)
I was part of a team responsible for design and verification of DSP (digital signal processing) chips. ASIC part of the username refers to both "application-specific integrated circuit" and my college friend circle.
I have been thinking about closing my Github account and moving all my code to gitweb on one of my personal domains. I'm tired of the social/popularity contest aspect of Github and just want to write and publish code that I find interesting. I also want more control and I don't want my code used for AI research like co pilot. I thought about trying source hut, or something similar, but I feel it will end-up just like github once it gets more users.
Has anyone else setup a simple gitweb server on a personal domain? If so, how did it turn out?
The unpleasant truth is that you won't "escape" copilot; if anything is going to be done about that, it's more or less a legal issue.
That all said, the author of SourceHut seems really principled in regards to what they're building. If I was going to bet money on one person not ending up like GitHub (and one platform not ending up like GitHub), I'd probably bet on them.
I kicked the wheels on it recently and was really impressed, though I'm unsure if I'll use it full time yet - for all it does well (kind of putting git back to what it should be), it does draw a line in the sand where I'm not sure I'd draw it. Something like Gitea might be another option since it can provide a familiar enough interface to drive-by contributors.
In truth, I wish Gitea had support for git-send-email similar to SourceHut. Feels like it'd be the best of both worlds.
I have done exactly this, after being fed up with GitHub. Surprising no one, if you set out to build the “social media but for code”, that’s what you get.
I’m using a combination of cgit, Gitolite and Nginx. Once set up, it’s easy to use and rock solid. Gitolite configures through a Git repository. I’m not going back.
Regarding your GitHub account, I suggest to simply replace the content you moved with a notice to the new URL and then archiving the repo, making interaction impossible. Even if you’re looking at deleting everything, maybe keep the account itself around, it’s free and you may need it later.
I use Fossil for self hosting code on my own domain, it's running on a fan-less PC with daily backups to the cloud using restic. It's just so nice, no social pressure and it works for me when the internet is down. I am currently in the process of setting up Concourse CI, it's a really nice config driven ci system.
Also, it doesn't have to be a "one or the other" thing, you can use both GitHub and self hosted for different things. That's what I do, GitHub is for work and things I want to be social, and my own hosting is for private code or code that I want to share in a "take it or leave it" kinda way without any of the social stuff.
I highly recommend hosting your own git/fossil/etc... system for yourself. Think of it like your own little place that you can setup exactly as you like.
I sometimes use github search to double-check if someone has worked on a problem before startin myself. Even when the repo is abandonned, it sometimes gives a good starting point. GitHub often tells me about repos I didn't find on search engines.
I'd say go for it, but the discoverability aspect is important.
I also follow friends and sometimes find interesting projects through their stars.
This is, increasingly, one of the only things I find myself locked into GitHub for: if I'm working in a space that's sufficiently "old" (e.g, macOS APIs), I generally cannot get Google to produce anything useful anymore and end up having to comb through various GitHub repositories. It's maddening.
No other code search engine comes close anymore, unfortunately.
how does another platform help you evade copilot? wouldn’t a “lower” platform have to pursue legal routes that are very unpalatable for those lacking deep pockets and legal expertise?
Anyone may purchase a domain name from a registrar (such as 'example.com'). That is not a 'lower platform'. It's just a domain name. Sure, it's not as popular as 'github.com' but in every other way (in the DNS) it is equal. And unlike github.com, you have full control of that domain and its DNS records.
There are no unique legal issues with regard to buying a domain name and writing and publishing source code on that domain. Using 'github.com' to host your source code does not give you more legal rights or protections. Copyright is copyright and a license is a license no matter where you publish it.
You should not be afraid to buy a domain, write source code and publish it there. It's not illegal to do that and you are not at more risk (although these big central social platforms would like for you to believe that).
I agree. I recently starting contributing to an open source project, really enjoy the feeling of contributing and interacting with other passionate contributors and maintainers.
I don't really get to interact, except with a few users. For me, it's the idea that u actually built something useful, it's my own idea, and I have full ownership of it.
At my day job, the expectation are vague, I have no real power, the people who do can't answer my questions intelligently, and at the end it's like I did some miniscule part of a system that works just OK, but not up to my standards.
Reddit Moderators, Forum Moderators, Chat Moderators, Blog Writers, Open Source Developers.
The Internet is built on a lot of great people doing things for free. That doesn't have to be a bad thing if you are okay with it. But always make sure you feel good about what you are doing. If you get enjoyment or a sense of accomplishment (to quote EA) out of it then it's no worse than playing a video game or watching a tv show.
Or you can get great conversations going, help struggling strangers get up and become pillars of their communities. Which sometimes requires deleting snarking comments, ban aggressive repeat rule offenders and deal with occasional personal attacks.
Moderators have powers, use power and are often not at liberty to reveal all what went into their decisions. Moderation on any scale is however a team effort and is then subject to scrutiny, discussion and review. Power tripping moderators will be removed by the team and in communities with a sole moderator who is on a power trip it will not thrive.
Subreddits thrive mostly based on their name. If a power tripping mod gets on top position of a good name, there is very little you can do. You can try to start an alternative but all new users will go to the other one.
To me it felt like volunteering to keep the community running smoothly.
However it makes you an especially visible member of that community, especially to its worst elements. The constant hostility and eventually the harrassment made me step down.
Now I watch other moderators go through the same motions. People are absolutely vile to them, all over a tiny internet forum.
I would consider Reddit a bit more than a `tiny internet forum`, even thought many topic-specific subreddits are way less useful than an actual forum would be...
The problem with mods is that some of them behave badly enough and go on power trips banning people for their own enjoyment and making tantrums, thus giving a bad rep to the whole category, including those who are actually good people with sane principles.
Because you were asked. When standing out in a forum and demonstrating consistency, responsibility and supporting attitude you may get asked.
Larger boards are like organization with promotions. Abuse of power won‘t earn you one. There are steering structures. Sometime one has to adjust what moderators do and have a discussion on what happened. Occasionally one has to kick a moderator out.
If you don‘t know why people help strangers then this may be worth a thing to investigate for you.
I’ve been a mod for less than 3 months, someone just needs help moderating. Not sure if I agree about power, majority of users in our sub are kids and they can get wild if not moderated.
When talking about GitHub stars and money, it's important to understand the other side of the equation.
A useful free and open source project garners GitHub stars and general recognition because it is useful, but also because it is free. The stars are the social compensation in this case. The free nature of the software is essential to that relationship.
The ‘free’ part in ‘free and open source software’ refers to the freedom given to the user of the software to read, modify and distribute the software that is provided to them [1]. It refers to that freedom and is independently of the price that obtaining the software has. Free doesn’t mean it has no price, creators can profit from it.
In the philosophical sense, sure. But given the context of this conversation, the fact that you don’t have to pay to use GitHub projects is absolutely relevant to their success.
I agree with you on that, sure. I think being gratis overlaps with being free… I think?… Having free access to the software means being able to use it and distribute it. I guess profit comes most of the times from support or distribution of the software, or the binaries. I have read this post [1] on the topic referenced in the Wikipedia article I mentioned, I thought it was interesting.
> When was the last time you chose a value above 1$
> you're a saint for choosing 2.5$
> OMFG THIS SHIRT IS 20$
For the record: the dollar sign comes before the number. I'll take the downvotes, I just can't stand it. I did read the article, and my heart goes out to the author.
> In the United States, Mexico, Australia, Argentina, New Zealand, Hong Kong, Pacific Island nations, and English-speaking Canada, the sign is written before the number ("$5"), even though the word is written or spoken after it ("five dollars", "cinco pesos"). In French-speaking Canada, exceptionally, the dollar symbol usually appears after the number, e.g., "5$".
The linked article appears to be talking about U.S. dollars, and all evidence points to it being written in English, so I don't believe the regional usage is relevant.
It's hard to argue what the accepted usage will be in future generations, but using the dollar sign as a suffix does not appear to have become accepted by any institutions I'm aware of at the moment. Distinguishing a simple mistake from a visionary act of linguistic prophecy is beyond my capabilities.
If you can point me at a reference that makes a good case that the linked article is the accepted usage, I'd be obliged.
I'd imagine people using currencies with symbol after number just do the same for dollar out of habit. Hell I have to fight to remember that stupid symbol is for some obsolete reason before the number.
Regional: Canada can do both before or after number due to French influence--that was mentioned in your link, by the way[0]
Regional: Philippines (personal experience) and many other countries write currency symbol following the number[1]
Generational: starting to show up in texting culture[2]
Having experience with languages evolving due to technology, including a few Filipino dialects, I've observed people adopting new conventions in spite of older generational mores is nothing new. Happens all the time. And as a person gets more experience with places that have different conventions, they typically let go of the provincial views that their learned way is the only way. The dollar sign is not the only chrrency.
Does a US dollar sign after a number look right to me? No, because my grammar teacher taught me differently. But my native French boss flipped it all the time and nothing of communication value was lost.
I hate arguments like this, appealing to some magical distinct codex of grammatical law as if language isn't messy and largely evolutionarily in nature, and highly dependent upon the current socially agreed-upon context.
Like when pedantics get angry about the misuse of "begging the question". If the majority of readers understand the phrase to mean "demands that we ask the question", then that's what it effectively means.
GitHub stars are a useless metric. It’s basically a bookmark count. If there was any correlation between them and donations, my combined projects of 35k+ stars should make me at least a couple of bucks each month.
Instead, lifetime total of ~7 years is ~300 EUR, which includes donations to a NGO I forwarded, which account for most of it.
Most people will not pay voluntarily for something they can get for free. That’s just how it is.
Sadly, it's now got to the point where people will downvote you for charging anything more than 0 and, if possible, they will write 1 star reviews in caps DON'T DOWNLOAD, IT'S NOT FREE!!
You know, let them. Whatever I decide to share with the world, I do for reasons of giving back. If some grab, run and foul-mouth, that’s their issue.
The main idea of free culture is building on each other, not maximum extractive consumption. I believe the idea to be further ahead than our economic systems and accompanying incentives though.
I also am a fan of showing the other cheek but have to admit this does get me down from time to time .. makes me feel like a vending machine with no coin slots. Only hope is regulation of gate keepers at this point
I thought we were discussing GitHub stars' correlation (or lack thereof) to donations. I don't see how usefulness for many people should be limited to software only. Anyway, I've said what I wanted to say.
Making a living on FOSS is hard, as you discovered.
I hope you succeed, of course. But since I have no good idea what your app is, except "a browser for developers" from the blog text, there is really no chance that I would ever search for this app, hear about it thru word of mouth, or eanything really that would make me end up testing your app.
Here's some other ways you could have tried to approach the situation:
- stop providing compiles, while selling access to the compiles on patreon or something. this way you can keep engagement from other developers and stay FOSS.
Aseprite is doing it. Compile for free or pay 20$ for the binary. I compiled once but the next time I just thought to hell with it and bought it on Steam )
It is definitely not easy to pay your rent with open source and the money is likely not as good, but there are a lot of folks who do. Some resources for different ways to do that:
Can confirm. Have many GitHub stars. They can't pay your bills. Converting stars to money is an interesting process. And not asking for donations, that doesn't work except for the top 0.001% of projects. You have to find a large company that wants support and will pay you the equivalent of a salary as a consulting fee. That's a starting point. If you're more ambitious than that you can try sell the same deal to other companies, personal experience says it's really hard. If you're more ambitious than that you can build a product on top of the open source project or sell an open core version. Also very hard. Then there's the whole VC funded route, I did that. It's a whole other thing not worth discussing here.
Open source sustainability is hard. I do think it comes down to the goals of the project lead and what level of financing it will require to sustain that. I have yet to see anything outside of company sponsorship or VC funding that makes it work. These individual donations don't scale. And even the odd $1k/month on patreon isn't enough. Let's face it, people working on open source are no less skilled than FANG employees, maybe even more so if producing code that's directly consumed. Open source should pay far better but I get the feeling it's still like free saas services on the internet. Each has a nuanced monetization path.
May I ask: let's say I am Joe Schmoe, an individual, not a corporation. But I have a particular need for coding done in, say, AutoHotKey or as an Outlook macro. I wish to pay someone for this small coding project. What is the best forum to do this exchange?
I'm assuming this question would be on-topic to this thread because it is essentially, "If someone DOES want to help you to pay your rent, or at least for a week's worth of coffee, where's the best place for that?"
This post totally resonates, but wondering where the initial expectation came from : GH stars -> revenue ?
Open source can be a part of a business model, but cannot be the only foundation of a business model.
It would amount to say 'self-serve won't pay for your rent' if you assume 'self-serve' is just putting your product out there, without marketing, or growth loops.
My understanding of the article is that the author actually got quite a lot of benefits from having that OSS project and github stars. There's a huge difference if you're trying to promote a completely new software that no one ever heard of, and if you promote quite successful and popular OSS project like they do. Even being able to write this article as a way of pushing the new commercial version of the software is only possible thanks to that OSS project. So in the end github stars do payout, just not directly...
Imagine for a moment though, if GitHub stars could pay your rent.
Imagine a corporation spends money on an experiment where they purchase some luxury units of a fancy apartment building, and then rent was decided based on GitHub stars. You must collect a certain number of GitHub stars each month to satisfy rent or you get evicted. I wonder what kind of projects would come out of this.
Also the distribution of stars is... weird. I've got a repo with 24k stars (which is still enough for top 500 on github) which took minimal effort and no maintenance - definitely lower than a lot of large software projects which deserve lots of money. Like, I'm next to pipenv and vagrant and making any money distribution based on that would be absurd.
No mention of the role and benefit of contributors to your open source project? I would have thought that is the main benefit: many hands make light work. Cathedral and the bazaar etc.
In the case of this chap sounds like it never got to that point, he was doing all the work. Seems like his impression of open source is a trade where you have a developer who displays his wares and offers them for free, and praise and donations roll in. Rather than a powerful operating model allowing software to develop that you could never hope to develop alone. Time/effort ratio is much reduced for everyone involved.
Question its viability by all means. It's a progressive and generous idea. Sad that it's not even considered in the article.
> Just imagine if you enter a clothing store and be like "OMFG THIS SHIRT IS 20$? ARE YOU CRAZY? I CAN GO TO THE STORE NEXT DOOR AND GET ONE FOR 7$. I CAN GET A SKIRT, CUT IT, AND WEAR IT AS A T-SHIRT. OR EVEN BETTER, I'M GONNA SEW MY OWN SHIRT!!!111!"
This is a great analogy for open-source/commercial software in general. I still find myself naively thinking: "I could build this random project I just discovered!"
nimbusws.com (this is the moonshot —- a managed service/hosting provider that gives back to F/OSS. Imagine what would happen if a company 1% as big as AWS gave 30% back to F/OSS projects)
awsmfoss.com - A newsletter that features a new F/OSS project every day. 60%+ of recurring subscriptions are donated to F/OSS projects — only 2 paid subscribers right now but it’s a start. Things will get REALLY exciting once I build traffic and start donating ad revenue (probably via EthicalAds)
If either of these sound interesting to you (criticism, encouragement, requests to invest, want to be the first hire) email me victor@(either domain above) and we’ll chat.
When this subject arrives I always think about curl [1] and how a project reaching a market of billion of people and devices receives so few donations and little money [2]. I just discover the project added a link for commercial support [3].
This struggle has been going on a long time and not just in the software development domain. 20 years ago there was a swell of ISVs a (Independent Software Vendors) in the blogosphere telling of their experiences of branching out on their own and selling their own software products. Some were successful but most were not. I think many in the software development industry become frustrated because the excitement and freedom of imagination that drew them into the field diminishes rather quickly in the “real world”.
This is a great encouragement for developers to not undervalue the usefulness of their apps. Most software is free (ad supported) that should be paid for directly instead.
What a load of garbage.. it's not problem of opensource, it's his problem of not understanding how to monetize things.
OpenCore model destroying opensource world already, asking people to pay because they starred your repo is super weird.
Think about this, how many opensource libs you have used in your project and are you going to pay for those all?
Btw if you wanna make money with opensource, check how FastAPI doing it.
I have been thinking about it and created openlist.dev, where you add banners into your Github profile page and make money when someone clicks the banner. I even emailed GitHub community manager and his answer was expected. They don't want ads on GitHub, their GitHub sponsors do not cover most developers. They should give more monetization opportunities.
I believe the macro landscape (I refer to the end of cheap money) is creating a change of Paradigm that is being reflected on multiple angles in our circles and professional sectors. What I'm curious about is where is the line between the software that really should not be open because of its competitive advantage and the software that you can make open?
1. People are less inclined to donate for something that's a day's worth of effort.
2. I wonder if web developers are more stingy than other developers...
3. "I obviously wanted to make a paid version of the app because the donations weren't exactly working out for me" <- Not obvious. The app should serve the public interest, as FOSS.
After 1K GitHub stars, you shouldn't need to leetcode anymore.
People who did things like writing homebrew makes you orders of magnitude more valuable than another dime-a-dozen leetcode warrior.
We have enough people who know how to do a damn BFS. We need people with good ideas and capabilities to execute with software. Lots of GitHub stars proves both
At least considering open source, I love the fact that not much money is involved because I feel that whenever money is involved, people start to serve money instead of users, meaning they might make decisions to maximize the money instead of the usability etc.
I still don't understand why some people want to make social work as a source of their income, while it should be the other way round. You may share some of your work which is source of your income with the society, or if that is not possible keep the two separated.
I carefully avoid using proprietary software (like having not touched Mac/Windows for 15 years) and personally believe that all forms of IP should be in public domain by default. Each step by a man, however small or giant, should be a step for the mankind. Why should you continue contributing to open source projects: The amount of carbon footprint saved by opensource projects is tremendous. Think of how much resources are saved if the opensource solutions that we rely on today were closed and proprietary that the same software solutions had to be recreated from scratch at each instance of deployment rather than simply duplicated.
I have seen projects on github and not be an opensource but a source disclosed project. Certain customers expect your code to be source disclosed in order to mitigate risks. Project may not be free to use.
The only way I've made any money from Github (3k stars) is by verifying my account on Brave Rewards.
I made a grand total of 10 euros in about 3 years.
And then on the other extreme you have something like substack in, which writing political rants easily earns $50-100k/year in recurring donations even if you are not that famous. It's hard to get people to donate open source projects.
A lot of people and companies are making money from Linux, including Linus Torvalds and many kernel hackers. Linux is GPL’d. I think it is hard to make the claim that making money is antithetical to FOSS.
I mean, if you look at amount of "paying users" vs "all users" it still checks out, just that at the economies of scale of Linux even 0.01% funding it is a ton of money.
FOSS is great for doing "common good" code that everyone uses and many sides want to push forward, but not exactly easy to monetize if you're just a dev doing a thing.
Many companies hire people to contribute to the kernel. Torvalds is the name we remember but there are many others.
And that is the kernel. There are also companies like Red Hat and Canonical that make money through their work (more) in the userland. The people that they hire all make money from FOSS.
Edit: For example, look at the “Most active 5.10 employers” list here:
If your motivation for doing open source is money, you're doing it wrong. You'll be much better off just getting a job (and GitHub stars can help with that!).
We all know "build it and they will come" and "follow your passion and the money will follow" don't really work in the real world. You have to make something people want and convince those people it's in their best interest to pay you.
Open source can be a part of a larger strategy to earn a living (consulting, customizations/open core, relicensing, books/talks/seminars, etc), but yeah, GitHub stars aren't money.
[0] https://blog.senko.net/open-source-is-not-a-business-model