The complicated business of funding open source software development
motherboard.vice.com
motherboard.vice.com
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...
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.
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.
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.