History of FLOSS
Before the age of the personal computer, software was heavily hardware-dependent and not available to the general public. Although banks and other technical businesses purchased proprietary software licenses, a lot of important development happened in academia where free sharing of software was more common.
The GNU Project
Richard Stallman worked at the MIT Artificial Intelligence lab which had a strong sense of community. Over his time there, the lab acquired more computers that had proprietary software where source code was unavailable, obscured, and/or restricted by non-disclosure agreements. The lab that had previously been free to solve their own problems became helplessly dependent on the companies providing the proprietary systems. Frustrated with the restrictions and the slow deteriorating of the lab’s ethic of collaboration and sharing, Stallman founded the GNU Project in 1983 and the Free Software Foundation in 1985. GNU had a mission to create a complete operating system free of proprietary restrictions.1
By 1991, the mostly complete GNU project was struggling with final pieces. Independently, Linus Torvalds produced a functioning kernel and licensed it with the GNU General Public License.2 By combining Torvalds’ Linux kernel with the GNU user space tools, the first fully free, general purpose computer operating system became available to the public. Many variations or distributions of this GNU/Linux system now exist, a few of which remain completely free of proprietary restrictions, although most use some proprietary elements.3
The Free Software movement has continued to face great challenges over the years. With limited resources, much development relies on volunteers, some of whom care especially about the relevant ethical and political concerns while others take interest primarily in the technology but still enjoy open collaboration. The rapid growth of the Internet in the 1990s helped lower the barriers to participation and expanded the ideas and development of Free Software, but the general public remained largely unaware of these options and continued adopting and funding proprietary operating systems.
Free vs Open
Many people misunderstand the term “Free Software” because of its ambiguity in referencing freedom versus price. Some partners of the Free Software movement have chosen the clearer term “Software Freedom” but still use “Free” as an adjective as needed. In light of this confusion, a group got together in 1999 to determine a better marketing term. Most of the participants were business-oriented technologists who valued collaboration and decided to downplay the overtly political rhetoric of software freedom.
Because most “Open Source” advocates do not focus on the political aims of software freedom, there has remained a significant divide between the Free Software and Open Source camps. Today, many people use terms with combinations like “F/OSS” or “FLOSS” (for Free/Libre/Open-Source Software). We use FLO as a general adjective here at Snowdrift.coop. See our article about Free/Libre/Open for more on the terminology issue.
FLOSS funding today
In the 21st century, businesses have indeed embraced “Open Source” where it serves their interests. Today, many FLOSS projects have substantial funding and corporate support. At the same time, most businesses continue making and supporting proprietary software as well. Despite the valuable efforts of volunteers and adoption by some commercial entities, FLOSS struggles to compete in the many areas where it is less aligned with corporate interests — especially the downstream public-facing products.
Thanks to distributed version control systems (DVCS), such as git, amazing collaboration among disparate communities is possible. More people are involved in FLOSS than ever, and many developing projects show promise. But while it’s easy to start new projects, it’s still hard to sustain and grow. In 2013, more than 35% of projects registered on Sourceforge had never produced a first release, and almost two-thirds appeared to have ceased activity.4 Of course, there will always be lots of trials and hacks that don’t continue long-term, and that’s fine — it just indicates healthy creativity. But surely a great number of valuable projects get abandoned because of lack of resources and could succeed with more funding and/or with more coordinated community effort to support them. Many projects are still essentially lone developers “scratching an itch”, and so development is weighted toward their individual interests which may or may not rve the public in other ways.
For a great and frank overview of the struggles in FLOSS development and the single-developer dominance, see Ben Mako Hill’s lecture When Free Software Isn’t Better. Aral Balkan calls this situation trickle-down technology — the premise that enthusiasts tinkering on their own things will necessarily deliver usable and meaningful FLO technology to the public. While that may work at times, we need real funding for FLO projects designed for the general public.
Along with the corporate support from mixed FLOSS/proprietary businesses, some business models focused on FLOSS exist, but each has its drawbacks. We have an overview page about existing FLO funding mechanisms, but below we discuss some details with both historical focus and software-specific concerns.
One niche business model involving FLOSS: selling hardware as a main product but run it using Free Software. This so-called widget frosting puts the software as frosting on top of the hardware widgets.6 This harkens back to the origin of FLOSS, as the first computer programs were freely distributed in order to make the computers themselves usable. Although widget-frosting can sometimes support significant FLOSS development, if the hardware does not itself have open plans and unrestricted terms, we can still get stuck with closed proprietary ecosystems.
Distribution of software
Though FLOSS is generally free to access, the licenses all allow the selling of copies of the software (it remains FLO as long as the buyer has full freedoms including the right to sell or give away new copies to others). Today, as software transmission by physical media is no longer common, selling copies of otherwise FLO software is a less viable business. Despite its legality, pay-for-copies is ineffective today at best, and, at its worst, it undermines the promotion of FLOSS and promotes the proprietary cultural mindset.7
Sale of trademarked merchandise
While the FLOSS community opposes the abuses inherent in the present copyright and patent systems as well as excessive enforcement of trademark rights, profiting from trademark recognition is considered benign and even desirable. A project with a good reputation and a well-designed logo can sell t-shirts, decals, and other merchandise bearing its trademarks. Of course, merchandise sales don’t much help smaller or back-end projects that don’t have adoring fans or slick marketing. Merchandise revenues also typically cover only a small fraction of total operating costs.
Support, customization, and consulting
Since most FLOSS licenses explicitly disclaim any liability or fitness for purpose (meaning if the software destroys your computer, you cannot blame the developers), businesses can charge users for warranties and support, just like proprietary software. Furthermore, many businesses and specialty users want custom versions and other special services. With FLOSS, customization and support can be done by any service whether or not connected with the main project, although, understandably, the primary developers will probably understand the program best and do the best work.
Red Hat’s Enterprise Linux makes software comparable in specifications and capabilities to the freely-available Fedora OS, but RHEL comes with guaranteed technical support; and the corporation also generates revenue through training and consulting services. Red Hat both relies on the Linux project for its livelihood and is itself the largest corporate contributor to the kernel. For subscription fees, Appsembler provides support and hosting for FLOSS web apps with royalties paid to the main developer. While often more lucrative than distribution or merchandise, selling support does push development decisions in favor of paying customers over the rest of the community. Service business may also create a disincentive to making software easy and reliable enough or well-documented enough to work without support. More importantly, not all software has a strong market for this type of paid support.
Some companies release a basic product under a FLO license but keep more advanced features proprietary. Alternately, a company may use a copyleft license like the GPL (which blocks derivatives from being proprietary) but offer an additional proprietary license option to those who want to build a proprietary derivative. Besides reinforcing the traditional licensing fee model, dual licensing favors the concerns of paying customers over the users of the freely licensed version. This can be especially problematic if the initial development was open-source but the code was then placed under proprietary license as soon as it was ready for enterprise use. While much FLOSS today uses this dual-licensing, it does a poor job of serving the goals of FLO ideals because it keeps promoting proprietary software as well.
Ultimately, FLOSS projects minimize their costs and otherwise ask for donations. In some regards, this is the most ethically sound way of supporting projects, as it allows supporters to determine for themselves the value of the project vs. their ability to pay.8 Donations may sometimes come in the form of government or private grants, from membership dues in organizations with open membership (such as the Free Software Foundation), or as unscheduled donations collected from the user community (Wikipedia is primarily funded through small individual user donations). Donations have traditionally been solicited via links on the project homepage and often through a message on the page displayed once download has started, which can make solicitation difficult for systems that use package managers, like GNU/Linux.
Donations are often unreliable, depending heavily on visibility (a major disadvantage for non-user-facing backend software) and on external economic forces (overall charitable giving dropped by more than 10% during the Great Recession).9 The term “charitable giving” gets at another problem with relying on donations: the IRS regards FLOSS projects as potentially profit-making (or as serving for-profit interests) and some FLOSS organizations have struggled to obtain 501(c)(3) tax-exempt status.10
Specialized types of donation include tipping and threshold crowdfunding campaigns. We have specific details about such systems along with our reviews of other crowdfunding sites.
Bounty sites allow FLOSS users to define a bug or feature that they want to see fixed or implemented and set an amount of money they are willing to pay for that to happen. The first developer to submit an accepted patch that addresses the issue can claim the amount promised. This approach has had only minor success along with lots of failures and wasted resources.
The Bounty section of our reviews of other crowdfunding sites mentions the few functioning platforms. None seem to have any major impact. The most successful platform, Bounty Source, uses a hybrid system offering threshold, subscription, and bounty options.
Many bounty sites have been tried over many years. Some sites that have come and gone: Freedom Sponsors, The Free Software Bazaar, CoSource, Fundry, Public Software Fund, BountyOSS, BitKick, COFundOS (which alled users to place bounties for new applications as well as for changes to existing programs), Opensourcexperts.com, Donorge, Bountycounty, Bounty Hacker, microPledge, FundHub (some unrelated site uses that name now, not surprisingly), GitBo, Catincan, DemandRush, and Open Funding (broken though the main domain openinitiative.com still exists) — and probably others we never discovered. GNOME and Launchpad each made attempts at supporting bounties but that never came to anything substantial. FOSS Factory (which is still live but has had no activity for years) bothered writing their own essay on the history of other failed bounty sites.
Bounties can work against collaboration
As FOSS Factory noted, bounties do not incentivize collaboration. Bounties might lead to single developers working on their own and keeping secrets from others so they can claim the bounty. Otherwise, we can face crazy arguments about who deserves credit on top of the already inevitable arguments about whether a bounty has been fully claimed. For a specific historical example of struggles and arguments in the placing and claiming of a bounty, see http://dneary.free.fr/gimp_bounties.html. Some have suggested bidding on claimed bounties to avoid the need for secrecy and wasted duplicate efforts, but that still does nothing to encourage collaboration. Splitting the project into the tiniest pieces may reduce wasteful competition, but most potential project sponsors don’t want to get into the tiniest details, they just want the project funded overall.
At best, bounties provide another way for end users to communicate with developers about their priorities, but they seem unlikely to solve deeper funding dilemmas.
A few other variations of feature-specific funding that aren’t strictly bounties have been tried. For example, Feed Open Source was an attempt (now defunct) at sustainable bitcoin donations tied to bug tickets. That didn’t invite outsiders to claim bounties but just put a financial incentive on how existing developers prioritize work.
A much more successful and significant movement, quite distinct from general bug-fix or feature bounties, has been general security bounties. In this case, there have not been any general platforms. Big entities (Google, Mozilla, Facebook, GitHub etc) independently offer significant bounties for anyone who identifies security risks and tells them about it. Generally, these bounties are specific to those companies and to the issue of security.
Hacker One provides a proprietary service to handle these bounties for all sorts of smaller projects.
Ransoms are the opposite of bounties. Also known as Street Performer Protocol, the ransom system involves the developer deciding on a price for their work and offering to release their code as FLOSS if the community comes up with donations that total the ransom price. This approach ignores the concerns of software freedom and turns the FLO license into a perk rather than an ethical choice. At the same time, ransom systems also usually preclude the collaborative benefits of the open development model.
Open AV Productions had a system that tweaked the ransom concept slightly by setting a predetermined FLOSS release date with the option to ransom an earlier release. Given modest ransom levels, the initial campaigns succeeded, but the amount raised in successful cases never reached enough to support a living wage, and a couple other projects trying this were not successful. The original author ended the Open AV release system after acknowledging its problems (see also their video explanation).
Incidentally, the ransoming of earlier release has some similarities to the concept of “Open Source Eventually” (such as the Transitive Grace Period Public Licence). That approach sets a fixed future date for FLO release and sells proprietary licenses in the meantime, but those sales have no effect on the eventual FLO release.
Never launched, Fund I/O was a proposed compromise involving both proprietary sales and ransom (with no guarantee of ever having a FLO release). Fund I/O would start out as a Kickstarter-like pledge to determine a “fair” price split between all the initial backers and then becomes a ransom as later purchasers pay to partly refund the original backers and partly give profit to the project. If a predetermined amount of revenue is reached, the project is ultimately released under a FLO license. Like other ransoms, this system would not reap any of the benefits of open community collaboration and does not guarantee a FLO final product.
Ransoms have had mixed success, depending on the interest in and quality of the product and the reasonableness of the demand. The powerful 3-D graphics software Blender was successfully ransomed in 2002 and is now fully FLO.11 On the other hand, Bryan Lunduke (a developer of small GNU/Linux media apps and a prominent speaker and podcaster) tried to get his users to ransom his works for a GPL license and failed to raise the money he wanted (and damaged his revenue stream going forward).
The Rational Street Performer Protocol is variation of the ransom system where potential patrons make bids on matching pledges, specifying the degree to which they are willing to match other contributions up to a certain total amount. Once the bids are made, the maximum support available is calculated and compared against the minimum the developer requires to take on the project. This provides an assurance contract for the donors but no iterative support for or accountability from the artist.
Fairware was a “soft” ransom system created by Virgil Dupras. He created a tracking system for the number of hours a developer logs on a project multiplied by an hourly wage. Each program contained a pop-up message that informed the user of how many development hours had yet to be compensated by donations. Any user who contributed (or who emailed Dupras stating financial hardship) would receive a code to turn off the popups. After all developers had been compensated, popups would turn off for all users. Because the source code was BSD-licensed, everything was fully FLO from the beginning, and the popups could be removed by hand if the user wished (most users didn’t bother to do so). Although he achieved a revenue stream comparable to shareware, Dupras abandoned the system in 2013 after starting a full-time job and ceasing major development on most of his projects.
Subscriptions and tipping
Many systems have tried variations on donations, such as tying donations to project updates. Various schemes connect tips to code-commits, for example. Some have had modest success, but none have substantially changed the FLOSS funding situation. For further discussion of these systems, see our reviews of Subscription sites and Tipping sites.
We have seen so many services come and go. Most were easily predictable failures based on ideas unlikely to work out. In other cases, the challenges of starting and sustaining the service was too great. Some defunct services are mentioned above. The changes to our services overview include many removals as services disappeared. For example Flossbank was an attempt to get developers to either see ads or give a flat monthly donation to a packaging system. Then, they split the pool of funds among whatever packages (and their dependencies) get installed each month. Of course, this metric captures neither the degree of use after installation nor the varying need for funding for the packages. That followed a troublesome history of other services that collected donations on behalf of projects that didn’t solicit them. The problems were obvious from the beginning, but they went ahead with running the service for a while until realizing that it wasn’t going to work out enough.
How Snowdrift.coop could change FLOSS
Snowdrift.coop aims to go beyond simply directing more money to FLOSS projects. We also want to make sure that funding is distributed in a way that encourages ethical, sustainable long-term development. Crowdfunding works for funding FLOSS because it uses the same “many hands make light work” principle as the open development model that produces some of the most successful software. The solutions listed above may have a place but address only part of the problem.
The Snowdrift.coop matching pledge system aims to provide projects with regular income and encourages using these funds to pay core team members a fair salary. Our pledge system works partly by consensus, enabling the community to coordinate their support around the projects they find most worthy of support. Instead of one-time payment models (which are often all up-front or at final product delivery), the community can use Snowdrift.coop to provide ongoing support for projects with a good track record and future potential (and can withdraw funding from projects that do not use their resources well). Projects are thus held accountable and are also enabled to better stay connected to and respond to the needs and concerns of their users.
As a non-profit co-op funded through our own pledge mechanism, our interests are aligned with the community. Any excess funds beyond our operating budget will go toward capital improvements or upstream projects. In short, we apply the same values to the way we’re organized as we do to the software projects we support. In the long-term, we believe that our approach could provide a truly robust economic basis for FLOSS development.
Linus Torvalds and David Diamond, Just for Fun: The Story of an Accidental Revolutionary, 2001.↩
The GNU project maintains a list of fully-free and actively maintained GNU/Linux distributions. Of the hundreds of other distributions, some, notably Debian, can also run fully-free, depending on user settings.↩
Some small businesses today sell FLOSS via platforms like eBay, but they do not provide any development funding. Generally, these listings aim to deceive the buyers by hiding the origin and original name of the program and hiding in small print any reference that the programs are FLO. A simple search for phrases like “office suite software” or “3D modeling software” or others will show eBay listings for LibreOffice, Blender, and other FLOSS programs (sometimes with altered names), ranging from $4-$25 (commonly around $10). Despite the questionable tactics, these sales remain fully legal and will remain effective as long as pay-for-access remains normal for software. Some developers may actually use this same tactic themselves: Keep the programs as FLOSS, but avoid mentioning that publicly and instead promote sales to the general public implying pay-for-access as the only possibility.↩
Pay-what-you-can has also proven to be a successful proprietary business model, such as with Humble Bundle.↩