I also started with GitHub sponsors after reading about Caleb's post about sponsorware in May 2020 and have managed to grow my sponsorships since then to more than $1k a month.
To those who are interested how I did it: I'm the author of Material for MkDocs [1], a popular solution for technical documentation. I created a private fork called "Material for MkDocs Insiders [2]" where all new features landed since then and tied those features to funding goals at $ 500, $ 1,000 etc. The promise is that the moment a funding goal is hit, the features are merged back into the original repo and released for general availability. It works reasonably well so far, better that I would have thought.
My Twitter following is rather small (700), but I'm posting a lot about Material for MkDocs and new features and try to engage the community. I guess if you have a large following like Caleb, you could up the amount in a few months, given that you have something on your hands that users want and solves a problem.
I really like this model and want it to take over the world. It would solve two problems: compensating people for building open-source software, and replacing the notion of IP for software with something more sustainable. More people should stand up and say, "I made this, I want to make the world better, and I will add this to the commons that everyone can benefit from after I extract $X of value from it."
A social norm of requiring people to "call their shot" in advance feels like a powerful counter-force to greed.
How is the current "notion of IP for software" not sustainable?
And how is this model, which seems like it's just asking to fall into a tragedy of the commons, more sustainable?
And finally, how is making something and holding it back until getting paid a certain amount a "counter-force to greed"? (to be clear, I don't have a problem with this -- if someone makes something, they're free to do what they want with it -- but I don't see how it's any more or less greedy than other options)
Fundamentally, the power a author has ,that is greater than the power granted by IP, is the power to decide whether to release something or not. This is a nontransferable power.
Historically, copyright was the granting of limited time monopoly powers over the distribution and derivatives of something in exchange for the promise of the author to not make use of the power to choose to not publish. In other words, copyright was meant to encourage publishing. The reason was that publishing that was controlled and approved by the state was vastly more preferable to uncontrolled organic spreading of knowledge. It was meant to be a win-win-win for everybody. The author gained revenue, the state gained control and the public gained culture.
The same was true about patents. The state granted the inventor a limited time monopoly over the use of a solution in exchange for the inventor not keeping it a secret. This granted the the inventor a way to extract revenue directly out of an idea instead of out of a finished sealed product. It granted the state control. And it granted the public access to the inner workings of the innovation.
This however does not mean that the power to keep something secret is gone. When it is more profitable to do so, the choice will always be to do so. That is why trade secrets exist. That is why there is a black market for information. Secrets are still highly valuable.
Currently the term of copyright extends far beyond the end of the life of the author. Noone will publish anything after they are dead. Also, all IP rights are now transferrable and inheritable. Oftentimes IP transfers are imposed on employees as part of their contract with the employer. The main beneficiary of IP today are large corporations. Also, the public is no longer just a consumer but a transformer. And due to technology, the state has clearly lost control. All of this makes the system of IP, not sustainable. The incentives are no longer aligned.
This model relies on that fundamental power to keep something secret and to trade that secret. It is an attempt to realign the incentives of each party based on simpler assumptions.
Now please explain why you believe "it's just asking to fall into a tragedy of the commons".
"IP transfers are imposed on employees" - so true. pretty much all the contracts I've seen in the past 8-10 years had something like this in it and I did refuse jobs because of these clauses.
These days - almost everything(related to development) I do is done by my wife, my sisters husband or a very good friend from another country :)
Is it greedy if, after investing months or years of work, answering issues, implementing feature requests, you feel like you deserve to be somehow compensated for your work, especially with successful companies using your software, benefiting from it?
The model may be far from being perfect, I'm still learning and adjusting what works and what doesn't, but it feels much better investing my time into this project since I get something back.
"When free software was born, if you wanted to clone, interoperate with, improve, or modify any existing software, all you needed to do was reverse-engineer that software and go to town.
"The GPL wasn’t permission to make something new that was compatible with something that already existed. People who knew how to make software already behaved as though that was something they were permitted to do, irrespective of the feelings of the company or individual whose code they were interacting with.
"The GPL was a request for companies and software authors to make this process easier and less tedious by handing out source code, so that would-be interoperators could skip the wasteful, time-consuming reverse-engineering step and go right to the good stuff – making a new thing that improved upon (and/or competed with) whatever was already made.
"The GPL was icing on the cake. Applying the GPL to your code didn’t signal that you’d forswear legal vengeance upon those who wanted to make something compatible with your thing. You had no right to that vengeance! Applying the GPL to your code signalled that you wanted to collaborate with interoperators, rather than impotently shake your fist at them from the sidelines as they went right ahead and interoperated with your code against your wishes.
"Some 40 years later, the world is a very different place. Between software copyrights, anti-circumvention rules, software patents, enforceable terms of service, trade secrecy, non-compete agreements, and the pending (at the time of this writing) Oracle/Google dispute over API copyrights, any attempt to interoperate with an existing product service without permission from its corporate master is a legal suicide mission, an invitation to almost unlimited civil – and even criminal! – litigation. That is to say: if you dare to modify, improve, or replace an existing, dominant software-based product or service, you risk bankruptcy and a long prison sentence.
"Forty years ago, we had cake and asked for icing on top of it. Today, all we have left is the icing, and we’ve forgotten that the cake was ever there. If code isn’t licensed as “free,” you’d best leave it alone."
> How is the current "notion of IP for software" not sustainable?
The only reason the "notion of IP for software" is a thing is that our intuitive notions of ownership don't quite work. We can't sell software without sources because nobody wants to allow a stranger to run arbitrary code on their computers. We can't sell software with sources because it's too easy to copy. We can't give away software with sources for free because people gotta eat.
So IP is a hack that slips into a gap just because there’s nothing better. But it's not a great hack.
https://250bpm.com/blog:82 makes a compelling argument that licenses exist only to help CYA companies consume software without risk. All of the software on my computer is owned by others, and yet nobody bears any liability for security holes. It's hard to discuss licenses, because "IANAL". But any time spent looking into licenses quickly uncovers stuff that's only there because nobody has tried to fight it in court yet. Licenses apply to a single snapshot of code, but software has a life cycle and needs a supply chain and governance structure (https://monetize.substack.com/p/a-holistic-vision-of-open-so...)
> how is setting up a situation that seems to be asking for a tragedy of the commons more sustainable?
I think a lot about the tragedy of the commons (https://news.ycombinator.com/item?id=4359257#4361596), but it's not clear to me how people putting things made of bits in a digital commons that anybody can use creates any sort of tragedy here. If you have a specific scenario or externality in mind, we can certainly discuss it.
> how is making something and holding it back until getting paid a certain amount a "counter-force to greed"?
It’s a counter-force because of the bounding effect. You can choose to extract as much value as you want — but you gotta say up front what you want.
Users are not passive entities here. If you choose to set the number too high, discerning consumers may choose to not feed your network effects. If you set the number to something people feel is reasonable, your adoption may speed up, because people feel like they’re contributing to something good entering the commons.
> What do you do if the sum of the monthly pledges goes down at some point? Will you make those features private again?
Nope, any feature that is released will remain public.
> I guess it's a bit counter-intuitive for me that a one-time release of a feature is tied to a recurring sponsorship level.
In the end, I'm selling early access to new features, that's it. If you need something now, and it's available for sponsors only, you need to subscribe to get access to it. You can always implement it yourself, the project is very hackable and puts a great emphasis on extensibility. The documentation is very thorough, also in respect to customization. However, sometimes, maybe especially for something like technical documentation, you don't want to be fighting browser bugs and edge cases.
There’s likely enough people continuing to support. As well: if needed there’s exercising the option to set the next feature at the next highest MRR goal.
Thanks for the explanation. For clarification, does any subset of your community have access to the private version, like perhaps people paying a subscription fee or something?
Or is that version completely hidden from everyone, and just used to develop and test new features until a funding threshold is met to release them into the public version?
Sponsors have access to the private repository (I'm using GitHub's collaborator feature). I have several sponsor tiers and $10 a month or more will get you access to my sponsorware, which means you will be added to the private repository and can use the features immediately. What you're effectively getting is early access, so you can use the features before other users.
The official documentation of my project lists exactly which features are "Insiders only", and which aren't. When the features tied to the funding goal that was hit are merged, everybody can use them. I try to always have sponsors-only features on higher tiers to keep sponsoring attractive.
As I understand, Caleb does it with content and entire projects - I'm doing it with new features for an existing project. Also, I'm doing it fully transparent, disclosing how much I earn with this, which I think is crucial to build the necessary trust relationship.
This is indeed a problem. However, given that you need to pay for a subscription to get access, I consider the risk rather low. The Insiders code is released under the same license (MIT), as I didn't want to make things complicated, so I couldn't even enforce someone publishing it. I have a fair-use policy [1] that (up to now) all users respect.
Yes, the model is far from being perfect, but it allows me to pay at least some of my bills. I'm always curious to learn how to improve it!
I suppose it's licensed under a non open source license until it's released to the public. If so, you can prosecute such individuals who break the license.
It's MIT-licensed, as the original project. I have no interest in legal prosecution. Also, different licensing would make it more complicated for companies.
> different licensing would make it more complicated for companies
True, although just removing a couple of words from the MIT license would still be a very attractive and easy to use license. Examples of words you might remove: "sell" and "sublicense".
Remaining open source but banning the user who leaks the source code from the repository could work too, no? (the RedHat way).
So as a user, you can start some work based on the insider version and be confident that you will be able to release your work even if the insider version never goes public for some reason, instead of relying on a promise that the code will be released in an open source license.
I found your project yesterday and was blown away by not only the quality but how easy you made it to get going. It motivated me to sponsor you for the insider features and has exceeded all expectations!
I never thought I would have so much fun creating documentation :) Cheers and keep up the great work!
Thanks! That is great to hear. Making writing documentation as frictionless and easy as possible is the primary goal of this project. Happy to welcome you aboard as a sponsor!
I do 99% of the work, but of course I also accept contributions. However, PRs are very rare and are mostly about bugfixes, not new features. Bugfixes are always released as part of the non-Insiders version, of course.
What's probably interesting is to consider the user demographics, about which I learned more in a survey [1] I did last year. Only 8% of my user base would consider themselves Frontend engineers. Given that this is an HTML template with some rather complex CSS/JS, it's not surprising that there are only very few PRs that implement new features. I guess most Frontend engineers go for JavaScript-based solutions like Vuepress or Docusaurus. Material for MkDocs is Python-based.
I know that Patreon had these “members only” posts, and it’s pretty meh. Maybe it’s due to the projects I’m sponsoring, but I always had a feeling of “if you’re writing these posts just for us, please don’t bother and just enjoy writing code”. And just to make sure this is not interpreted incorrectly, I mean this in a positive way, I don’t want to be catered to, I want to ensure the survival of the project in the long term.
> Maybe it’s due to the projects I’m sponsoring, but I always had a feeling of “if you’re writing these posts just for us, please don’t bother and just enjoy writing code”.
Note that Patreon isn't just for code. These posts make way more sense where your funding a blogger, podcaster or similar.
You do not have to agree with a person's opinions to see the value in defending their right to express them. I would pre-empt a discussion on whether or not Patreon has exhibited political bias in its bans. Instead, consider that Sam Harris also believes this. Is Sam Harris somehow also an alt-right taboo character? Surely not.
It seems you're referring to Lauren Southern (as that was apparently who Harris defended), who Patreon removed for using the funds she was raising there to block NGO ships.
Is your position that (contrary to Patreon's judgement) this was not an act that put lives at risk, or that she is entitled to use their platform to put lives at risk as a matter of her free speech?
Patron is not obligated to serve anyone (besides protected classes).
You are perhaps trying to imply that patron is such a large monopoly that there is no viable alternative to which I would respond that patrons monopoly should be addressed directly (treat the cause not the symptom.)
To be clear - are you talking about this section or also including the following one (the crackdown on sex workers)? As far as I know, Sam Harris has defended the right of Lauren Southern to express herself on Patreon by raising funds to attack ships in the Mediterranean, but has not defended the rights of sex workers to express themselves on Patreon by posting "NSFW" (a misnomer, because Patreon is not usually a workplace tool) content.
So I'm not sure if Sam Harris is an alt-right taboo character, but I would claim that he is politically biased in what sort of speech rights he defends.
I sense you're making a false equivalence between explicit photographic material and political opinions. I think it is all right to remove sexual content, if that is your desire as a platform. It's a very different can of worms from political censorship.
As for Sam Harris, I have not heard him speak one way or the other on the topic. I think your argument sounds like attacking somebody critical to China because they were not critical over your favorite issue.
Which the sex workers would refer to as their job. If we really want to talk about equivalency, one side wants to air their opinion about some matter, and on the other side are a bunch of people who just want to be able to work and get paid today.
People constantly view pornography solely from a consumption perspective. Yes, not being able to get porn on Patreon is a trivial problem for consumers. Not being able to produce porn is a serious problem for the creators.
Frankly, politics is probably a lot more poisonous to Patreon than porn is. Porn is usually quiet, they don't jam it in people's faces. Politics is all about saying controversial things for air time, which is going to cause them never ending headaches.
The distinction is audience context. Patreon is a sponsor focused audience. Everything else is just informational and of declining value to the code authors. Github is the opposite.
That distinction is so important to the people writing the code. People make all kinds of requests like the sky is falling in. Sometimes there is chest thumping or big tears about how their concern is more important than everything else even if it is a major distraction and irrelevant to the road map. Unfortunately, that sort of stupidity amplifies as projects become more popular. I guess I am fortunate in that case since I am a nobody.
If people want to cut to the front of the line and dictate the importance of their concerns they can do so in a sponsor-only channel prioritized by money pledged. I am a huge fan of that.
Agreed, but a middle balance could be met, such as the ability to vote on feature and bug fix priorities. You get the benefit of having a say in something that was already going to be worked on and the developer doesn't need to waste time on stuff that doesn't matter. All it would do is shuffle the order.
Here is my biggest problem with supporting open source: discoverability.
At the end of last year, I was doing all my last minute charitable giving, and after my PSF donation, I wanted to donate to open source projects. I opened up Github's sponsor page, and stopped there. There were thousands of projects, but I have no idea which ones are important to me, other than a few big ones.
It would be great if a tool existed that would look at everything I've installed via Brew(or your package manager of choice) and all the imports in my own Github projects, and follow all the dependency paths to the bottom, and then give me a report of how often a dependency shows up in that graph.
For example, I know ffmpeg is at the bottom of a few of my stacks. But what else? There might be a library that I rely on 12 different ways, but it's so fundamental and deep in the stack that I have no idea.
It would be even better if this magical tool could then directly link me to the support page (or figure out if one even exists).
My other problem with all of these open source sponsorships is that it seems for some reason none of them support one time donations. They all want me to sign up for a monthly gift (and I don't even get to chose the amount). I understand that that helps their cash flow, but that's now how I donate. I look at my income at the end of the year, set a target percentage, and then make all my donations at the end of December until I run out of budget (except for various fundraisers during the year).
And I know I'm not the only one who donates that way. December is always the biggest month of gifts for charity. They really should have an option for people like me.
I find discoverability a problem totally apart from supporting/contributing/funding. Just even finding projects is awful. Google (and other general purpose search engines) is a disaster. They serve up obviously hacked websites before a GitHub page. GitHub's search is better, but it's hard to use. I highly recommend doing a really braindead naive search on github.com, then choosing the code tab, then filtering for Markdown. Now you're searching READMEs. I've found a ton of amazing projects this way that I had no other path to without knowing their specific README language beforehand.
Edit: also if you're using a regular ass search engine (or GH), just type "awesome [whatever topic/language/platform]" and unless your area of interest is insanely esoteric you're probably gonna find some stuff you wish you knew about, because some nerd maintains an "awesome" list for basically everything used by more than 3 people.
What's the goal of sponsorship? To pay what it's worth or support it's development? Anyone could live a good life off $144k, but is that what Babel deserves?
I'll be honest that when I see a repo making more than $100k I kinda feel they don't need sponsorship. Although how does health insurance and the like work for full-time open source devs?
> both countries are very lenient with regards to necessary business expenses (必須経費 over here).
This seems to be the issue. If you're really paying for the software and not the support, it isn't a neccessary business expense because you can have it for free. Same for the support. If others can get support for free — and it's easy to observe it happening — chances are you can get it for free. Someone down the line might notice it's a donation and not a necessary business expense.
And if you really need extra support, we're back to the old paradigm where open source can help you land a project but you still need to do the work and it's in addition to the work you do on the project, and it's not easy work. For example, a week-long training course, or custom code.
How about I pay for the right to add a `high-priority-MYNAME` tag to an issue, and the maintainers promise to take that into consideration but with no guarantee to make it a priority.
There are a ton of examples of programs that are free or reduced cost for individuals and more money for corporations. Like all the Jetbrains products.
The IRS doesn't get on people for paying for a corporate license for Jetbrains because it would be against the license.
Open source support could be the same way. Free for individuals, but costs money for corporate/commercial uses. I don't think the IRS would even blink twice at that.
Just because there is a free alternative doesn't mean that the paid option isn't a necessary business expense.
If I run a taxi service, most people would understand that having a car is necessary.
However, if I chose to buy a car, even though my brother will give me a brand new one for free that doesn't mean that my purchase ceases to be a "necessary business expense."
OnlyFans has been floated here and in past HN threads, and it perfectly encapsulates the current state of open source software funding: a site used predominantly to distribute porn is a better channel for funding open source developers than most dedicated alternatives.
OnlyFans takes a 20% cut, is Only Sponsors a free or paid service?
OnlySponsors seems to be built entierly on Github API & GitHub Sponsors, and does not take any cut besides what's GH Sponsors itself is doing, which is none, IIRC.
The current GitHub Sponsors costs do still appear to be free for individuals. It looks like they are going to take 10% from sponsorships from organizations, which is also currently waived due to beta status.
I'm concerned about the idea of open source turning into teaser content, the main goal of which is to get people to pay to unlock "sponsors only" content.
Yeah that sounds scary, but we already get that with a lot of open source software written by consultancies selling a paid version.
(Red hat is disincentivized from making the Linux ecosystem more sane on a deep level.)
At the end of the day, given https://en.wikipedia.org/wiki/Goodhart%27s_law, it's probably more feasible to incentivize less sharply: UBI with the incentive improve society's productivity and you and everyone else get's more stuff. Do that overly-blunt incentivisation along with the overly-sharp incentivisation we have today, and we might strike some sort of better balance if not spectral (bluntness ~ wavelength) coverage.
Eh. Most of the Red Hat projects people complain about are targeted mainly at desktops, as opposed to servers. And when it comes to desktops, Red Hat’s biggest competition isn’t Ubuntu or CentOS or whoever; it’s Microsoft. There are far, far more users using Windows, who might be convinced to switch to Red Hat if it works well, than there are users using other Linux distros, who might be convinced to buy support if the packages they share work poorly.
Not sure how it is these days, now that IBM is calling the shots, but when I worked at Red Hat (~2010-2015) the vast majority of people did their level best to make things work well.
Some points:
* While "support" is part of their business, so is training, consulting, etc.
* Not sure what to lump performance tuning under, nor writing up white papers, tuning guides, and best practise docs. But there are whole teams which did that (back then anyway) for products like RHEL.
With support, wouldn't it make more sense for things to be clearer and easier, so there's less staff time needed to provide the documentation and support?
Saying that because AFAIK the places that pay for support (rather than use CentOS or similar) are more doing it for compliance reasons than straight out really needing (much?) support. eg they're going to pay for it anyway, even if they don't really use it
Isn't that the "open core" model? Frankly, I encounter many projects that claim to be open source, based on the license, that sell a cloud version while having difficult or impossible to install/update/maintain community versions. And then there is the old gimmick where the community version is broken, but the cloud version isn't (presumably because the developers know how to fix what's broken).
Patreon (for podcasts) and onlyfans work thanks to parasocial relationships. People don't have a parasocial relationship with the authors of the open source software they use.
Phabricator has been doing that for years (but more extreme - you can't even submit it comment on bugs without paying) and I think they're the only open source project my company gives money to. Definitely a reasonable option.
Just having a paid priority issue section or a direct line contact to the core dev would be worth paying for.
It seems to work with Youtube superchats and Twitch messages.
I would pay for specific features or bug fixes in software, as a user that's more important, than the lerson implementing it, though people are still very important.
There are so many tiny things that bug me when I'm using my devices, it would be great to pay to improve some of them.
Just a couple of weeks ago I did a search on Google for “OnlyDevs” to see if anyone had already thought of this. I didn’t immediately see anything relevant at the time, so I then looked to see if onlydevs.com was available, which it wasn’t – parked by some domain shark. But the service I used for looking for domain availability suggested only.dev which is available and I was like oh neat but then I saw the price that it would cost and it was too much for me.
Only.dev would cost ~870 USD per year which is way to expensive for a domain for some random idea.
Anyways, neat to see that someone came built this, and nice that they were able to come up with a name for it that would not cost them an arm and a leg for the domain :p
While this may work for individual contributors I don't see how it benefits open source work and the community in general. It suggest writing articles and creating videos but there is then a drive to release less information publicly to try and get people to pay because your code is confusing or your docs are lacking. That seems like a big negative.
It also doesn't work for team based projects. I'm one of the maintainers of Streamlink [1] which has members from around the world and we've been running various methods of donation since 2017 or so. In that time our Open Collective [2] has made about $1600 USD. We have over 50,000 users across all platforms (based on download stats as we don't collect any metrics in our apps so it's potentially higher) yet the entire amount we've collected is thanks to less than 100 people. We note the Open Collective on every release as well.
My own personal donation methods total $15 from one person in the past 5 years since we forked the project and started maintaining it. We have more users than many start ups do and I know that there are several companies using our software, but I haven't figured out how to make donations really work yet. How do we determine who should make what from a shared pool of money? How do you value a contribution, PR, etc., and most importantly how do you get users to actually pay without negatively impacting the project?
OP here. I didn't make onlysponsors. I found out about it while listening to a podcast about Vue. and decided it is quite interesting and useful for many open sourcers here.
I worry about this sort of model because it incentivizes you to poorly document your code, or alternatively, it breaks down if someone else documents your code well.
For instance - if there's a particularly tricky way to do something, and you release a sponsor-only video or post explaining it, and then one of your sponsors sees a question about the same topic on StackOverflow and explains it in their own words (StackOverflow already prohibits linking to external explanations without including an answer in-line), would you feel like that is unfair to you?
If you publish a performance trick (as demonstrated on this site), and one of your sponsors sends you a PR to improve performance in the common case, would you want to accept it?
As your project grows, more people will ask questions and more people will be building a community around it. If you want to have market exclusivity for answers, you effectively need to prevent that community from growing so that people must go to you.
It might be possible to do this at scale. This is part of Red Hat's business model, for instance: they have a customer-facing knowledge base that isn't public that includes answers to tricky questions. But Red Hat doesn't depend on the secrecy of this knowledge base. Your entire organization can get access to the KB if you buy a single Red Hat license of any type, which costs something like $50/year. And developers at Red Hat would be happy for those problems to get fixed in the upstream projects.
Red Hat's business model is more strongly around support instead of secret documentation, that is, around responses to specific questions instead of restricted-broadcast answers that help everyone. If you're having a problem in production, Red Hat can help you figure it out (as long as you've been paying them for server licenses for all your servers). And the knowledge base mostly exists to deal with the problem of people having limited time - they document something that's broken, but the intent is to actually solve it, not to leave it in the long-term state where it requires reading the KB article.
Now, people have been trying to do smaller-than-Red-Hat-scale support contracts for their OSS for a long while, and it's worked in some cases (e.g., SQLite, Postgres) but not in general. It might be the case that restricted educational material works out better in practice!
GitHub Pages could add a feature like this using access controls. Right now it's just "Private" and "Public" but I can see a possible demand for "Sponsors". Though, things like sponsor-only RSS feeds and mailing list integrations might be beyond the scope of Pages.
I was just thinking about this and I agree. It would be nice if these settings could apply to the other sections of a repo: Wiki, discussions, issues. Let the software be free but give the devs a way to make cash off people using their software professionally.
I think folks need to be wary of supporting github sponsors, the way it's currently structured only perpetuates a gig style economy for open source maintainers, my guess is <1% of folks using sponsors get enough money equivalent to a salary (unfortunately GitHub doesn't share data on how well the sponsors program is doing)
I actually like the idea but without a Pricing page it's hard to tell if it's build to last or just an experiment. OnlyFans is clearly for a different kind of content for now, until this changes I don't see why something like this shouldn't be considered a good alternative.
Other than github providing something similar, why don't they also expose something useful about github users supporter info through their API? Maybe they already do, don't think so.
It's hard for me to see the value in monetizing posts from OSS projects. If I wanted to pay for someone's thoughts I'd be using substack or paying for pictures from OF - in both cases the value I receive is directly tied to the subscription.
Possibly a more interesting approach could be gated support similar to an exclusive discord for patreon subs to ask questions.
Besides the association, which one might or might not be fine with, I'd worry that being porn-centric would put OF at risk of credit card companies not wanting to work with them, similar to what PornHub faced recently.
This is soon going to devolve into people holding users for ransom after they get sufficient traction of their software due to it being open source. Good that you are using the software. Now any fixes or new features are going to cost you since there is now an elite group of users who get pay for features while the ones who adopted early are left in lurch.
I very much applaud these people making passive money by selling educational content, but we shouldn't kid yourself: there is nothing open about this and your sponsors are not sponsoring your OSS contributions, they just find your content valuable enough.
Do they still benefit from 0% fees from Github / Microsoft?
It'd be nice to find ways to fund open source without closing off aspects of it. Also, capitalizing on FOSS with a walled garden product like this, with a middleman cashing out, doesn't feel right. I'd like to keep my choice to support a developer based on the quality of their work.
I'm sorry; I should have said "taking a cut" - it's not about how much; the point is I'm not in favor of that method of capturing value.
GitHub earns its cut with massive network effect, which it built for years, funded with a quality product that users paid for directly, before rolling out marketplaces.
I don't like the idea of getting people to sponsor your open source work, only to 'close source' the incentives to get them to sponsor.
In effect, this is just a paywall/license for good documentation for popular software/libraries.
To be clear, making money as a pure open source developer is impossibly hard, and creativity is required. Very few enterprises making millions off OSS send monetary support, so you have to cast a wide net for $2-5 sponsors who are willing to throw the equivalent of a coffee a month to you.
One I've used is PixelTrue [1] (no relation, just a happy customer). The envato marketplaces [2] are probably the biggest platform for such content though
onlyfans jokes aside, there's a reason why Patreon, GitHub Sponsors, et al. don't release comprehensive numbers about their platform: no one makes money off of them.
The distribution curve makes no sense for the average person, but it makes a lot of sense for the platform owners.
In many countries when you work as an employee you have to pay taxes like an employee (and tax must be collected at source). How this platform deals with that?
To those who are interested how I did it: I'm the author of Material for MkDocs [1], a popular solution for technical documentation. I created a private fork called "Material for MkDocs Insiders [2]" where all new features landed since then and tied those features to funding goals at $ 500, $ 1,000 etc. The promise is that the moment a funding goal is hit, the features are merged back into the original repo and released for general availability. It works reasonably well so far, better that I would have thought.
My Twitter following is rather small (700), but I'm posting a lot about Material for MkDocs and new features and try to engage the community. I guess if you have a large following like Caleb, you could up the amount in a few months, given that you have something on your hands that users want and solves a problem.
[1]: https://squidfunk.github.io/mkdocs-material/ [2]: https://squidfunk.github.io/mkdocs-material/insiders/