Until about ten years ago, "free as in speech, not as in beer," was an often repeated expression heard in open source circles. These days, the same sentiment is usually phrased as "free as in freedom." Even though it's fallen out of favor, I prefer the former. I think it more clearly explains the philosophy behind the open source development model. At the same time, it explains a problem that many essential open source projects face finding funding.
Open source software is free to use, but as another old expression points out, there's no such thing as a free lunch. Open source or not, software doesn't get written for free -- nor can it be maintained without cash flow. Another old saying that fits here: If you're going to dance, you have to pay the piper.
As a general rule, Enterprise users of open source realize the importance of paying the piper and pay for the software they use in various ways, starting with contributing code upstream. They also help fund large open source projects by signing support contracts with organizations such as SUSE, Red Hat, MongoDB or with other software projects that are essential to their day to day operations. Enterprise users also donate development funds to large projects like Hyperledger that are not yet but will be useful to them down the road.
This mostly works, but unfortunately there is a lot of code that falls through the cracks because it's hidden. This isn't code that's seldom used or that could be easily replaced, but code that in many ways is as vital as operating systems, databases or customer relationship management platforms -- often acting as the glue that holds everything else together. It's hidden because it's only on the radar of the folks working in IT departments, who rely it so often that they perhaps take it for granted while never even considering its need for funding.
In open source circles, this has become known as the "free rider" effect, and while taking a free ride might we fine in a rock 'n roll anthem, the consequences in the tech world can be devastating. The truth is that underfunded code is almost always dangerous code.
This problem came to light in a big way in 2014 with Heartbleed, a vulnerability in the Heartbeat Extension used by OpenSSL affecting an estimated 17 percent of the Internet's secure web servers. It turned out that funding, or the lack of it, played a central role in the vulnerability finding its way into the OpenSSL ecosystem. When Heartbleed was discovered, the OpenSSL project consisted of only two maintainers, working -- overworking, actually -- to keep a crucial aspect of Internet security up and running on an annual budget of around $2,000. Another old cliche might be appropriate here: It was a recipe for disaster.
Since then, much has been done to address this "free rider" issue. Most notably, the Linux Foundation created the Core Infrastructure Initiative to fund open source projects that are critical to the Internet, as well as other widely used systems. This has been a big help, but the Linux Foundation can't do it all. There remain many widely deployed open source projects that are in danger of failure due to funding issues.
There are solutions, but they'll only work if enterprise users know about them and take advantage of them. They're based on the concept of crowdfunding, but fine tuned for the funding of open source projects. Most notably, there is OpenCollective and Gratipay, with the later getting the most attention, mainly from the publicity and moral support it's receiving from Opensource.com, Red Hat's community website.
Although Gratipay's website works much like any garden variety crowdfunding site, it has a unique business model. Unlike Indiegogo, GoFundMe and other popular crowdfunders, it takes no cut from the funds collected. Projects, which must be approved before being listed, are charged card processing fees at cost, but otherwise receive all the money donated. Gratipay funds itself just like the other projects on the site -- through it's own listing on Gratipay.
So far, using specialized web services to fund small but critical open source projects seems to be paying off. This might be because many of the projects listed on these sites are not in need of large amounts of money, with a quick glance indicating that most are seeking to fulfill annual budgets of $6,000 or less -- enough to purchase and maintain some equipment, maybe pay rent and perhaps pay core staff.
IT shops using open source might want to think about taking a look to see if any mission critical tools or apps they use are are looking for funds.