"The Internet" is more than just software - open source or otherwise. Open source developers were not sitting on trans-oceanic cable-laying ships. Open-source developers are not building the (very proprietary) electronics that form the basis for all the communications infrastructure. The applications that people use from Google search to your banking website were not built with free labour. In my narrow exposure in the nineties, it seemed that the Internet was built on the back of low-paid students providing support for dial-up customers and medium-sized businesses paying eye-watering sums of money for a leased line so that mediocre email services would work. We weren't as cool as the open source rockstars sticking it to commercial Unix, we were just stacking modems in cabinets.
Open source software and open standards (all the RFCs) have made, and will continue to make, a significant contribution - but saying that 'The Internet Was Built on (the) Free Labour' is simply incorrect and positions open source advocates, who are trying to draw attention to real problems in the industry, as holier-than-thou shills that people stop listening to.
The Internet is a very commercial space, built on the backs of people that are well paid for their services, by companies that are the most valuable in the world. Some crucial infrastructure needs recognition and/or some way to share in the commercial aspects. Try and find a solution to the funding problem for OpenSSL without saying that the Internet exists because some people (thankfully) worked for free.
Like the cherished image of a startup beginning in someone's garage, $title has only a grain of truth. Sure, some open-source software was built on free labor. Much was built by people who were paid to do it, either willingly and intentionally, grudgingly, or sometimes quite unwittingly when developers used company time and resources to do something other than their jobs. Bored students are an interesting case. Is that "free labor" or an unstructured but still mostly intentional use of tuition dollars?
Myths and stereotypes aside, though, there is at least some subset of open-source software that has relied too much on altruism and needs to be put on a more sustainable financial footing. The example that comes to mind for me is not mentioned in the article: NTP. Here's an article about it.
The Core Infrastructure Initiative (mentioned in both that story and the OP) is great, but it's simply not enough. Maintaining a project like NTP is hard enough that acquiring the necessary domain and code knowledge is likely to mean years spent a long way from anything resembling a viable career path. Without guaranteed long term support that's a lot of sacrifice. This kind of thing needs a government-level (or Gates/Zuckerberg/Bezos level) benefactor to provide resources, salaries, and organizational support.
It's true. Companies are amazingly reluctant to pay developers to support open source that is absolutely critical to their business operations. As a result they don't have a leg to stand on when code that they rely on - but don't pay for - doesn't work. You know all those crazy disclaimers about how this code MAY NOT BE FIT FOR ANY PURPOSE WHATSOEVER IN PERPETUITY PLEASE DON'T CALL US IF IT KILLS YOUR DOG AND BURNS DOWN YOUR HOUSE? That's the level of support that a lot of companies are willing to go for.
We developed a library for regex matching used in a lot of security products, and I was always blown away by how little support people seemed to want/need once it was open sourced. Support contracts? Follow-up? Feedback of any kind? "Nah, we're good".
As a corollary of this, companies that don't even acknowledge the open source that they use or provide feedback have only themselves to blame if the developers of those projects aren't recognized for their work. If you do OSS development at a BigCo, and no-one bothers to tell your management that they are using your stuff, it's pretty hard to make the claim that the development is still worth funding.
It is possible to look at this from a different perspective. Paying a grant to a couple of developers may be a nice thing to do, but you still don't get a contract with any guarantees.
Paying a shitton of money to established company like Red Hat, on another hand, gives you a contract with liabilities and all other stuff that you'll be able to lean on - and cover your ass with, if need arises.
> Paying a grant to a couple of developers may be a nice thing to do, but you still don't get a contract with any guarantees.
We started polyglot.network for exactly this reason. It's an external development agency that works on the FOSS features/bugfixes that you care about. By having multiple customers, it can distribute the costs (which would not be possible if you tried doing the same work in-house).
So, you essentially pay 1/3rd for a developer seat but get 2/3rd of a developer's output. The buffer exists because open-source projects have some inherent risks. You might want a library/framework to implement a feature, but the upstream may not be willing to merge their PR: Either to protect their commercial interests, or philosophical differences.
We've been working with a few companies and have started contributing to a few Clojure, Python projects already. We work with a community of developers working remotely, and hence, have talent available at almost all languages/frameworks (hence, "polyglot.network").
Fair enough, but we floated the idea of support contracts (with a large company, not a tip or grant to a couple of developers) and still didn't get much interest. As far as I can tell companies are not offering contracts or asking for guarantees either.
There are clearly exceptions. Red Hat is obviously one, as are many successful OSS companies. But a lot of those companies play hardball with dual-licensing - so if you want it for free, you better love GPLv3! :-)
You were blown away by companies not wanting to enter a support contract with every little library they use?
And remember you are talking there about software, not infra. Software companies have tons of developers in-house. They probably don't need your support when they can figure out stuff themselves.
Maybe it was simply a bad business decision to open source a regex library and expect to get paid for giving "support".
You seem to know a surprising amount about (a) the significance of a regex library to security companies and (b) the business reasons for open sourcing it. Perhaps you were there at Intel, or one of our customers, and I just don't recognize your Hacker News id?
To fill in: many security products put almost every packet on the wire past our library, sometimes multiple times. This wasn't a product used to, I dunno, validate user fields or something. Companies used to build hardware to do this, many of which are now pushing up the daisies (I like to think in part due to our work), and we got quite a nice acquisition out of it (while still open source).
I actually expected $0 from open sourcing it and was not surprised - the business reasons had absolutely nothing to do with direct revenue (which honestly would have been an enormous hassle to collect). I was still wowed at how standoffish a lot of our customers were (to the point of having 'secret' customers we found with detective work). My real complaint wasn't about money, it was about companies giving pretty much zero recognition to OSS groups at other companies upon use of their s/w - they shouldn't be surprised when, as a result, the infrastructure they depend on rots away.
But hey, they can "figure stuff out themselves". Maybe...
Your point is well taken, and what I suspect is the issue is something that I learned quite a while ago: people just cannot value what they get for free.
That’s not a statement of moral or ethical anything, just a impartial statement of a basic generalized truth.
> it was about companies giving pretty much zero recognition to OSS groups at other companies upon use of their s/w - they shouldn't be surprised when, as a result, the infrastructure they depend on rots away
Why would they care? Businesses were happy to pay these hardware companies that you deride for their devices, they're more than happy to use your library as long as it is gratis, and they'd be perfectly happy to pay other companies for replacement software if your library stopped functioning or ceased to exist.
The broad adoption of FOSS has nothing to do with ideology or community and it never did. FOSS is widely used primarily because it is gratis and frees up money to be spent on something else.
Uh, so they will be perfectly happy to pay for something (not to mention change their code and go through the fun of dealing with contracts) they were previously getting for free - rather than, say, send a nice email to a private address or some relationship manager. Yes, this makes total sense.
There sure are a lot of HN folks out there who apparently understand the ins and outs of corporate OSS way better than I do. Apparently I'm a wide-eyed naif who thought that OSS was all about community, and need to be set straight by one HN cynic after another.
I'm a board member of Clojurists Together[ct] who is trying to solve this problem for _just Clojure_. Obviously this is a generic issue and while most Clojure libraries are hardly core infrastructure underpinning 2/3ds of the servers on the Internet, every language community ends up with projects everyone uses and no-one maintains in earnest.
Clojurists Together asks maintainers to put together a proposal, then we vote on projects and give them money. Donors ("members") are both companies and individuals[members].
It works! I wish more communities had this. Stuff like the core infrastructure initiative is fantastic, but I think it's hard for them to identify or even justify "niche core infrastructure".
The labour was never free. The price of benefiting from that labour was paid, in part, by becoming a part of the community - through contributing back and giving others the choice to do so in turn. This fact is why it worked and continues to work so well.
I disagree. The labor was, is, and will probably continue being free. The community aspect of oss is not a form of payment, but a nice benefit. Ask any of the community supported and loved oss devs on twitter who constantly complain of being broke.
This is a bit like saying working unpaid for a few months wasn't free labor because you got a paid job afterwards. The company still took the monetary value of your labor.
At best, it can be said that the monetary value of the labor of open source contributors has been paid, to some degree, to everyone using the software, and the overlap between users and contributors is high.
Unfortunately many people seem to expect free software, free support, and features they want added for free, without expecting to contribute or join the community themselves. This imbalance (imho) puts extra burden on open source devs and is where the issues happen. :/
The expectation to join a community or to contribute as a cost for using FOSS code is a limitation on user freedom which goes against the free software ethos.
If one wants to contribute back, one is free to, but one is equally free not to. Developers are also free to support software however they choose, or fork and add whatever features upstream refuses to add themselves. If developers want to release code under a nonfree license that requires reciprocation then that's what they should do.
> The expectation to join a community or to contribute as a cost for using FOSS code is a limitation on user freedom which goes against the free software ethos.
It's really hard to argue with this. But I'm not sure "freedom to be an asshole" (to state the extreme case) is the primary ethical good that is being sought -- particularly since one could easily restate the freedoms of, say, the GPL in negative terms. You are not free to redistribute the program without its source, you are not free to use the software without accepting the terms of the license, you are not free to not indemnify the authors of the software against lawsuit over fitness for a particular purpose, and so forth.
But what this does imply is that however you slice it, fixing this problem involves ethical coercion. You can only try to persuade people (and companies) that it would be better to behave a certain way. You can't force them to do so.
From the article: "On the other hand, regulating the production of open source software (for example, establishing an organization similar to the National Science Foundation to distribute publicly-funded grants to open source software projects) undermines the main advantages of open source development. The stability afforded by regulation comes at the cost of efficiency, and in the fast-paced world of software development, this simply wouldn’t fly. Furthermore, regulation would also undermine the spirit of open source development insofar as it could result in gatekeeping that determines who can contribute and who can consume the resource."
This is a really good article, but this paragraph gave me pause. If there were something like the NSF for FOSS, is the threat really "regulation," "gatekeeping," and loss of efficiency?
If it were set up along the general lines of the NSF, then I understand that there would be "gatekeeping," in the sense that some group of people would be determining which projects are worthy of funding. I also know very well the way that writing grant applications can be a massively time-consuming task that might be better spent on actually doing things.
But neither of those seem like show-stoppers to me. And it's really the word "regulation" that is throwing me off. Perhaps gatekeeping is regulation per se, but the author seems to be using this term in a stronger sense: particularly with the idea that an NSF for FOSS would necessarily determine "who can contribute and who can consume the resource."
I'm not trying to argue that the idea is unassailable or somehow the obvious solution, I'm just not following this line of reasoning as an insuperable downside that "wouldn't fly" with the community. Particularly since the creation of such an entity would not eliminate the existence of the standard model in which people develop free software as they always have.
Perhaps it's the phrase "publicly-funded" that is the key one here. The author might be specifically imagining a taxpayer-funded entity, and not a private foundation to which large tech players contribute.
I think you have provided a very good list, but I think the list contains actual showstoppers.
I know several OSS ecosystems where grants and commercial funding already destroy the original OSS spirit.
You get a set of bureaucrats who control who gets to work on OSS and what is being worked on. Often they take the credit for the results.
I think OSS should be result oriented: If someone can demonstrate that a piece of software he wrote is used widely, there should be a possibility of retroactive public funding.
But results rarely count in the current OSS boiler room atmosphere.
> You get a set of bureaucrats who control who gets to work on OSS and what is being worked on.
So I get that a grant necessarily defines some kind of who -- even if the money is given to "the project," it will ultimately boil down to a person or persons who is receiving funds to work on the project. And there's also a what, in the sense that there has to be some kind of boundary to what is being developed.
But it sounds like you're thinking of scenarios in which the "what" isn't "working on OpenSSL" or "writing Git," but some more specific demand: paying someone to work on some particular feature or problem, as opposed to giving the project money and having the people on the project decide where to put their attention.
Maybe there's no way around that. Maybe there's no practical way to define the "who" precisely, while leaving the "what" ambiguous.
Here's a "free" startup idea if someone wants to run with it: an opt-in feature bounty service for open-source projects.
Essentially, project maintainers could join the service with their projects, and then users could offer financial bounty for specific features/bugs to be resolved. The core maintainers would have right to veto any bounty, and once the corresponding pull request is merged the payment would be released and distributed, following a formula, between the implementers (the majority), core maintainers and the service itself (a small, possibly fixed amount).
I can see something like this as a core feature of GitHub, but an independent service could include repos on other platforms.
>As Steve Marquess, the former CEO of the OpenSSL Foundation noted in a blog post after the fact, the cause of Heartbleed was attributable to developer burnout and lack of funding.
I don't agree that you can directly draw a line between security exploits like Heartbleed and lack of funding. In fact, it's even possible that you have the counterintuitive scenario of providing more funding to OpenSSL will lead to more exploits -- because you now have more paid programmers making new exploits.
As counterexamples to Steve Marquess reasoning: Apple funded Facetime with fulltime developers and yet they had a recent publicized audio security hole, and Intel with its billions funded x86 chip development and yet it still had Meltdown and Spectre holes. All the various CVEs constantly issued every day mentions commercially funded projects (e.g. Adobe Acrobat, Java runtimes, Windows zero-days, etc).
It's seductive to to think that paying developers will naturally lead to "better security". It does seem logical that if we set funded OpenSSL with $250k/yr to pay a salaried programmer whose only job is to look for security holes, something like Heartbleed wouldn't have happened. The problem is that there would still be security holes found by a teenager in Russia; possibly Heartbleed or a different security hole.
It's easier to directly connect cause & effect of adding programmers will lead to added features. E.g. if software widget doesn't have a PostgreSQL db adapter, add an additional programmer to code it. However, the effort of removing security exploits lives in a weird area of (un)measurable and (un)observable work. It's difficult to assess that the security holes were really removed.
Maybe there's some game theory thinking about how to best fund security bug hunting. Is a fulltime security auditor the best use of money? Or is it bounties? I don't know. Does the industry have any empirical data connecting amount funding to number of security exploits?
I loved this article. Disclaimer, I'm the founder of CodeFund (formerly Code Sponsor). As such, my focus is funding for open source.
To start, you should check out Nadia Eghbal's Lemonade Stand (https://github.com/nayafia/lemonade-stand). She lists many different ways to generate funding, along with the pros and cons. There is no silver bullet. I believe that real substantial funding must come from all directions. Also, funding sources vary based on the personality of the maintainers. Some may prefer to go the fund-raising path with Patreon or Open Collective. Some may prefer the TideLift SLA path. Some go the route of selling merchandise, training or books.
However, most paths of funding require the developer to take on the role of fundraiser, marketer, or even publisher. Developers may not want to do this and would prefer to focus on the code. This is why advertising fits most models. It provides passive, recurring and consistent income that does not require the maintainer to veer from their chosen path. It supports DHH's "fuck you" policy. The maintainer is not beholden to the advertiser with CodeFund, because there is no direct agreement.
CodeFund (https://codefund.app) is an open source platform that helps fund maintainers, bloggers, and builders through non-tracking ethical ads. We only display ads based on the context of the website, not the visitor profile. Our ads are relevant and non-obtrusive to visitors.
Open source software and open standards (all the RFCs) have made, and will continue to make, a significant contribution - but saying that 'The Internet Was Built on (the) Free Labour' is simply incorrect and positions open source advocates, who are trying to draw attention to real problems in the industry, as holier-than-thou shills that people stop listening to.
The Internet is a very commercial space, built on the backs of people that are well paid for their services, by companies that are the most valuable in the world. Some crucial infrastructure needs recognition and/or some way to share in the commercial aspects. Try and find a solution to the funding problem for OpenSSL without saying that the Internet exists because some people (thankfully) worked for free.
Myths and stereotypes aside, though, there is at least some subset of open-source software that has relied too much on altruism and needs to be put on a more sustainable financial footing. The example that comes to mind for me is not mentioned in the article: NTP. Here's an article about it.
https://www.infoworld.com/article/3144546/security/time-is-r...
The Core Infrastructure Initiative (mentioned in both that story and the OP) is great, but it's simply not enough. Maintaining a project like NTP is hard enough that acquiring the necessary domain and code knowledge is likely to mean years spent a long way from anything resembling a viable career path. Without guaranteed long term support that's a lot of sacrifice. This kind of thing needs a government-level (or Gates/Zuckerberg/Bezos level) benefactor to provide resources, salaries, and organizational support.
We developed a library for regex matching used in a lot of security products, and I was always blown away by how little support people seemed to want/need once it was open sourced. Support contracts? Follow-up? Feedback of any kind? "Nah, we're good".
As a corollary of this, companies that don't even acknowledge the open source that they use or provide feedback have only themselves to blame if the developers of those projects aren't recognized for their work. If you do OSS development at a BigCo, and no-one bothers to tell your management that they are using your stuff, it's pretty hard to make the claim that the development is still worth funding.
Paying a shitton of money to established company like Red Hat, on another hand, gives you a contract with liabilities and all other stuff that you'll be able to lean on - and cover your ass with, if need arises.
We started polyglot.network for exactly this reason. It's an external development agency that works on the FOSS features/bugfixes that you care about. By having multiple customers, it can distribute the costs (which would not be possible if you tried doing the same work in-house).
So, you essentially pay 1/3rd for a developer seat but get 2/3rd of a developer's output. The buffer exists because open-source projects have some inherent risks. You might want a library/framework to implement a feature, but the upstream may not be willing to merge their PR: Either to protect their commercial interests, or philosophical differences.
We've been working with a few companies and have started contributing to a few Clojure, Python projects already. We work with a community of developers working remotely, and hence, have talent available at almost all languages/frameworks (hence, "polyglot.network").
There are clearly exceptions. Red Hat is obviously one, as are many successful OSS companies. But a lot of those companies play hardball with dual-licensing - so if you want it for free, you better love GPLv3! :-)
And remember you are talking there about software, not infra. Software companies have tons of developers in-house. They probably don't need your support when they can figure out stuff themselves.
Maybe it was simply a bad business decision to open source a regex library and expect to get paid for giving "support".
To fill in: many security products put almost every packet on the wire past our library, sometimes multiple times. This wasn't a product used to, I dunno, validate user fields or something. Companies used to build hardware to do this, many of which are now pushing up the daisies (I like to think in part due to our work), and we got quite a nice acquisition out of it (while still open source).
I actually expected $0 from open sourcing it and was not surprised - the business reasons had absolutely nothing to do with direct revenue (which honestly would have been an enormous hassle to collect). I was still wowed at how standoffish a lot of our customers were (to the point of having 'secret' customers we found with detective work). My real complaint wasn't about money, it was about companies giving pretty much zero recognition to OSS groups at other companies upon use of their s/w - they shouldn't be surprised when, as a result, the infrastructure they depend on rots away.
But hey, they can "figure stuff out themselves". Maybe...
That’s not a statement of moral or ethical anything, just a impartial statement of a basic generalized truth.
Why would they care? Businesses were happy to pay these hardware companies that you deride for their devices, they're more than happy to use your library as long as it is gratis, and they'd be perfectly happy to pay other companies for replacement software if your library stopped functioning or ceased to exist.
The broad adoption of FOSS has nothing to do with ideology or community and it never did. FOSS is widely used primarily because it is gratis and frees up money to be spent on something else.
There sure are a lot of HN folks out there who apparently understand the ins and outs of corporate OSS way better than I do. Apparently I'm a wide-eyed naif who thought that OSS was all about community, and need to be set straight by one HN cynic after another.
Clojurists Together asks maintainers to put together a proposal, then we vote on projects and give them money. Donors ("members") are both companies and individuals[members].
It works! I wish more communities had this. Stuff like the core infrastructure initiative is fantastic, but I think it's hard for them to identify or even justify "niche core infrastructure".
[ct]: https://www.clojuriststogether.org/ [members]: https://www.clojuriststogether.org/members/
Another useful document on this topic is Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure (14 July 2016) by Nadia Eghbal [1].
[1] https://www.fordfoundation.org/about/library/reports-and-stu...
At best, it can be said that the monetary value of the labor of open source contributors has been paid, to some degree, to everyone using the software, and the overlap between users and contributors is high.
If one wants to contribute back, one is free to, but one is equally free not to. Developers are also free to support software however they choose, or fork and add whatever features upstream refuses to add themselves. If developers want to release code under a nonfree license that requires reciprocation then that's what they should do.
It's really hard to argue with this. But I'm not sure "freedom to be an asshole" (to state the extreme case) is the primary ethical good that is being sought -- particularly since one could easily restate the freedoms of, say, the GPL in negative terms. You are not free to redistribute the program without its source, you are not free to use the software without accepting the terms of the license, you are not free to not indemnify the authors of the software against lawsuit over fitness for a particular purpose, and so forth.
But what this does imply is that however you slice it, fixing this problem involves ethical coercion. You can only try to persuade people (and companies) that it would be better to behave a certain way. You can't force them to do so.
This is a really good article, but this paragraph gave me pause. If there were something like the NSF for FOSS, is the threat really "regulation," "gatekeeping," and loss of efficiency?
If it were set up along the general lines of the NSF, then I understand that there would be "gatekeeping," in the sense that some group of people would be determining which projects are worthy of funding. I also know very well the way that writing grant applications can be a massively time-consuming task that might be better spent on actually doing things.
But neither of those seem like show-stoppers to me. And it's really the word "regulation" that is throwing me off. Perhaps gatekeeping is regulation per se, but the author seems to be using this term in a stronger sense: particularly with the idea that an NSF for FOSS would necessarily determine "who can contribute and who can consume the resource."
I'm not trying to argue that the idea is unassailable or somehow the obvious solution, I'm just not following this line of reasoning as an insuperable downside that "wouldn't fly" with the community. Particularly since the creation of such an entity would not eliminate the existence of the standard model in which people develop free software as they always have.
Perhaps it's the phrase "publicly-funded" that is the key one here. The author might be specifically imagining a taxpayer-funded entity, and not a private foundation to which large tech players contribute.
I know several OSS ecosystems where grants and commercial funding already destroy the original OSS spirit.
You get a set of bureaucrats who control who gets to work on OSS and what is being worked on. Often they take the credit for the results.
I think OSS should be result oriented: If someone can demonstrate that a piece of software he wrote is used widely, there should be a possibility of retroactive public funding.
But results rarely count in the current OSS boiler room atmosphere.
So I get that a grant necessarily defines some kind of who -- even if the money is given to "the project," it will ultimately boil down to a person or persons who is receiving funds to work on the project. And there's also a what, in the sense that there has to be some kind of boundary to what is being developed.
But it sounds like you're thinking of scenarios in which the "what" isn't "working on OpenSSL" or "writing Git," but some more specific demand: paying someone to work on some particular feature or problem, as opposed to giving the project money and having the people on the project decide where to put their attention.
Maybe there's no way around that. Maybe there's no practical way to define the "who" precisely, while leaving the "what" ambiguous.
Essentially, project maintainers could join the service with their projects, and then users could offer financial bounty for specific features/bugs to be resolved. The core maintainers would have right to veto any bounty, and once the corresponding pull request is merged the payment would be released and distributed, following a formula, between the implementers (the majority), core maintainers and the service itself (a small, possibly fixed amount).
I can see something like this as a core feature of GitHub, but an independent service could include repos on other platforms.
I don't agree that you can directly draw a line between security exploits like Heartbleed and lack of funding. In fact, it's even possible that you have the counterintuitive scenario of providing more funding to OpenSSL will lead to more exploits -- because you now have more paid programmers making new exploits.
As counterexamples to Steve Marquess reasoning: Apple funded Facetime with fulltime developers and yet they had a recent publicized audio security hole, and Intel with its billions funded x86 chip development and yet it still had Meltdown and Spectre holes. All the various CVEs constantly issued every day mentions commercially funded projects (e.g. Adobe Acrobat, Java runtimes, Windows zero-days, etc).
It's seductive to to think that paying developers will naturally lead to "better security". It does seem logical that if we set funded OpenSSL with $250k/yr to pay a salaried programmer whose only job is to look for security holes, something like Heartbleed wouldn't have happened. The problem is that there would still be security holes found by a teenager in Russia; possibly Heartbleed or a different security hole.
It's easier to directly connect cause & effect of adding programmers will lead to added features. E.g. if software widget doesn't have a PostgreSQL db adapter, add an additional programmer to code it. However, the effort of removing security exploits lives in a weird area of (un)measurable and (un)observable work. It's difficult to assess that the security holes were really removed.
Maybe there's some game theory thinking about how to best fund security bug hunting. Is a fulltime security auditor the best use of money? Or is it bounties? I don't know. Does the industry have any empirical data connecting amount funding to number of security exploits?
I am not sure I would categorize that as a small change ...
To start, you should check out Nadia Eghbal's Lemonade Stand (https://github.com/nayafia/lemonade-stand). She lists many different ways to generate funding, along with the pros and cons. There is no silver bullet. I believe that real substantial funding must come from all directions. Also, funding sources vary based on the personality of the maintainers. Some may prefer to go the fund-raising path with Patreon or Open Collective. Some may prefer the TideLift SLA path. Some go the route of selling merchandise, training or books.
However, most paths of funding require the developer to take on the role of fundraiser, marketer, or even publisher. Developers may not want to do this and would prefer to focus on the code. This is why advertising fits most models. It provides passive, recurring and consistent income that does not require the maintainer to veer from their chosen path. It supports DHH's "fuck you" policy. The maintainer is not beholden to the advertiser with CodeFund, because there is no direct agreement.
CodeFund (https://codefund.app) is an open source platform that helps fund maintainers, bloggers, and builders through non-tracking ethical ads. We only display ads based on the context of the website, not the visitor profile. Our ads are relevant and non-obtrusive to visitors.
For example, go to https://jsbin.com or https://codesandbox.io.