"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.<p>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.<p>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, <i>some</i> 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?<p>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.<p><a href="https://www.infoworld.com/article/3144546/security/time-is-running-out-for-ntp.html" rel="nofollow">https://www.infoworld.com/article/3144546/security/time-is-r...</a><p>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 <i>guaranteed</i> 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? <i>That's</i> the level of support that a lot of companies are willing to go for.<p>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".<p>As a corollary of this, companies that don't even <i>acknowledge</i> 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.
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.<p>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].<p>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".<p>[ct]: <a href="https://www.clojuriststogether.org/" rel="nofollow">https://www.clojuriststogether.org/</a>
[members]: <a href="https://www.clojuriststogether.org/members/" rel="nofollow">https://www.clojuriststogether.org/members/</a>
I’m pretty sure the folks at Cisco, Juniper, BBN, etc., are getting paid. Also, fun fact: more than 85% of Linux contributions come from developers with corporate sponsors: <a href="http://www.extremetech.com/wp-content/uploads/2014/02/02DataFlowBills3-1390852937757.jpg" rel="nofollow">http://www.extremetech.com/wp-content/uploads/2014/02/02Data...</a>
Open Collective (<a href="http://opencollective.com/" rel="nofollow">http://opencollective.com/</a>) is a donation platform for open source projects, they recently announced Back Your Stack (<a href="https://backyourstack.com/" rel="nofollow">https://backyourstack.com/</a>).<p>Another useful document on this topic is
Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure (14 July 2016) by Nadia Eghbal [1].<p>[1] <a href="https://www.fordfoundation.org/about/library/reports-and-studies/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/" rel="nofollow">https://www.fordfoundation.org/about/library/reports-and-stu...</a>
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.
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."<p>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?<p>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.<p>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 <i>who can consume</i> the resource."<p>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.<p>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.
Here's a "free" startup idea if someone wants to run with it: an opt-in feature bounty service for open-source projects.<p>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).<p>I can see something like this as a core feature of GitHub, but an independent service could include repos on other platforms.
<i>>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><p>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 <i>more funding</i> to OpenSSL will lead to <i>more exploits</i> -- because you now have more paid programmers making new exploits.<p>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).<p>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.<p>It's easier to directly connect cause & effect of adding programmers will lead to <i>added features</i>. E.g. if software widget doesn't have a PostgreSQL db adapter, add an additional programmer to code it. However, the effort of <i>removing security exploits</i> lives in a weird area of (un)measurable and (un)observable work. It's difficult to assess that the security holes were really removed.<p>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?
> The 43-year old British software developer had accepted a small change to the code for OpenSSL,<p>I am not sure I would categorize that as a small change ...
I loved this article. Disclaimer, I'm the founder of CodeFund (formerly Code Sponsor). As such, my focus is funding for open source.<p>To start, you should check out Nadia Eghbal's Lemonade Stand (<a href="https://github.com/nayafia/lemonade-stand" rel="nofollow">https://github.com/nayafia/lemonade-stand</a>). 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.<p>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 <i>advertising</i> 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.<p>CodeFund (<a href="https://codefund.app" rel="nofollow">https://codefund.app</a>) 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.<p>For example, go to <a href="https://jsbin.com" rel="nofollow">https://jsbin.com</a> or <a href="https://codesandbox.io" rel="nofollow">https://codesandbox.io</a>.