Addressing open source's free rider problem

To make open organizations sustainable, we'll need to solve the free rider problem. Here's one place to start.
426 readers like this.
A person holding on to clouds that look like balloons

Opensource.com

Nadia Eghbal, in her major report on the state of our digital infrastructure, and Jonathan Lister, in his response describing our digital ecosystem, both point to a tragedy of the commons in open source software. While some projects are sustainable, many still struggle with "a free rider problem." As Nadia puts it:

Resources are offered for free, and everybody (whether individual developer or large software company) uses them, so nobody is incentivized to contribute back, figuring that somebody else will step in.

Heartbleed revealed an extreme case of this phenomenon: a single developer, working for peanuts, bearing the weight of more than half the web.

For advice on addressing this problem, Jonathan suggests we look to ecosystem management, "an industry in itself, with its attendant experts, who write books and speak at conferences." I recently read one of the seminal books in this area, Governing the Commons, by Nobel laureate Elinor Ostrom, and I'd like to offer some initial thoughts on how it might apply to open organizations and open source sustainability.

Ostrom on the commons

Ostrom observes that some groups clearly have overcome the tragedy of the commons, while others have not. Her first lesson for us is to focus on institutions as the deciding factor between success and failure. Through a careful review of case studies, she distills principles for designing institutions to manage what she calls "common-pool resources," or CPRs:

The term "common-pool resource" refers to a natural or man-made [sic] resource system that is sufficiently large as to make it costly (but not impossible) to exclude potential beneficiaries from obtaining benefits from its use.

CPRs include things like fisheries, groundwater basins, and forests. "Appropriators" are those who take from a CPR, while "providers" and "producers" set up a CPR and keep it going.

Now, open source software is not technically a CPR, but rather a so-called "public good." The two are similar: it is difficult (by design!) to prevent someone from appropriating open source software, just as it is difficult to prevent people from fishing in a certain area. Economists would call them both "non-excludable." But while you and I can't both catch the same fish (when you catch one, I can't catch the same one), you and I can both use the same software (when you download and deploy it, I can do the same). In technical terms, then, economists consider CPRs "rivalrous," whereas public goods like open source software are "non-rivalrous."

This distinction means that ecosystem management such as Ostrom describes does not apply completely or neatly to open source software. However, CPRs and public goods do both suffer from free rider problems, and Ostrom herself says:

A study that focuses on how individuals avoid free-riding, achieve high levels of commitment, arrange for new institutions, and monitor conformity to a set of rules in CPR environments should contribute to an understanding of how individuals address these crucial problems in some other setting as well.

Free-riding in open source communities leads to overworked and underpaid individuals, and eventually to burnout. It's bad for people, and it's bad for projects. It's a problem we need to address. Ostrom shows us how to tackle the problem with a methodical approach to institutional design and analysis. Open organizations that steward open source software projects have much to learn from her, while recognizing that we will need to adapt her recommendations to fit our situation.

User profile image.
I'm the founder of Gratipay, an open organization with a mission to cultivate an economy of gratitude, generosity, and love. We help companies and others pay for open source—and we're funded on our own platform. Offline, I live outside Pittsburgh, PA, USA, and online, I live on Slack, IRC, and GitHub.

22 Comments

It seems that what this wants to do is to change the concept of what open source is. To me, open source projects by their nature put something out to be freely available, to allow people to contribute to, but it's their choice whether or not to contribute, and you accept that as someone who is contributing. By the same token, those who do contribute are not employees, they're not involved to answer commands from the outside.
The challenge for organizations is to find the methods to encourage people to contribute by being helpful, being encouraging, by trying to flesh out the ways in which that help might begin, and then show appreciation when help comes, because there is no entitlement to it.

I do find it distasteful when open source developers express a sense of entitlement and resentment at not being paid for their work. Open source to me is about intrinsic motivation! If you don't want to do open source, then don't.

What I'm trying to point towards is the possibility of open organizations as an *economic* entity that combine the intrinsic motivation inherent in open source with economic vitality. Can we have our cake and eat it, too?

In reply to by Greg P

I appreciate this column very much, as I really do believe that the various explorations of "free riding" will illuminate something critical about open culture and economics. I don't think I'm quite ready to jump to the conclusion that it's a "problem" for open source projects and communities, something "bad for people" and "bad for projects." I've dabbled in it before and done some reading here—just not enough to render any kind of definitive judgment.

The truth is that I'm finding conflicting opinions on the effect of free riding in open source projects and communities. In The Success of Open Source political economist Steven Weber doesn't seem to think it's the same kind of problem that the folks Chad cites here do. In fact, he argues that open source defies conventional economic thinking because is exists (successfully) despite the presence of free riders. I'm certainly not insisting that he's correct—just pointing out the complexity of the discussion and the work that remains here.

My guess is that free riding's status as a "problem" depends on the metaphors we use in our descriptions of open source goods, projects, and communities. We haven't settled on these, either. For example, Lister's piece advocates for adoption of "ecosystem" metaphors in discourses about open projects (he wants us to stop using the old, tired "infrastructure" language). Ostrom appears to like the language for framing a certain kind of problem, but Chad points out here that "ecosystem management such as Ostrom describes does not apply completely or neatly to open source software." So perhaps the roads-and-bridges tack is more appropriate after all. The language we use for building alliances with other movements and sources of support will need to emphasize the approach to code-goods we want those allies to adopt. If that's roads and bridges—because we eventually decide that these do fit the "rivalrous/excludable matrix" in the most appropriate and productive way—then so be it.

Bound up in the notion of "free riding" are so many of the issues surrounding openness that continue to ignite our fascination with it. That's why I'll continue to read anything anyone has to say about it. Thanks, Chad.

indeed, we can't even properly define what a free-rider is. to get to a just definition we have to consider the context of the whole society. what does the supposed free-rider do with the software?

would it be fair to call someone a free-rider if that person uses Free Software and Open Source to save money for their company, so that they in turn can make more profit, giving that person a bonus, never give anything back to the project, but then spend all their free time to care for homeless people in the streets?

the point is, we do not know if a supposed free-rider is truly a free-rider for personal gain, or used the benefit to do good elsewhere.

in other words, what is a free-rider needs to be seen on a global social context. among all 7 billion people on this planet how many contribute to society, and how many receive from society.

and how can we turn receivers into contributors.

the issue about funding infrastructure is of course an important one, but i would not reduce it to a free-rider problem. instead it needs to be included among the many social causes that deserve our attention.

greetings, eMBee.

In reply to by bbehrens

I use "free rider" narrowly according to its standard definition in economics: someone who uses a public good without paying for it. So yes, I would call the person in your example a free rider with reference to the software they use without paying for.

P.S. Sometimes *I* free ride! The "problem" is not so much any given instance of free-riding, as it is the aggregate effect on the good in question. In the case of software projects, the effect is burned out individuals and unmaintained projects.

In reply to by eMBee (not verified)

you are expecting that for use of a public good we should pay back directly?

you are not allowing that use of one public good can be paid for by creating another public good?

you consider not paying back directly a problem?

but is that really necessary?

look at other public goods, like streets, public parks, public artwork, education, homeless shelters, charities. almost none of them are paid back for directly by their users. most of them are paid for by taxes, and some of them are paid for by other volunteers.

do we have to pay back directly, or is paying forward ok?

i am looking at Free Software and Open Source products not isolated but as part of the larger pool of all public goods that exist.

i am expanding the "use" and "paying" for a public good to the whole pool, so that any use of that pool of public goods is paid for by putting anything else back into that pool.

i am using "contribute to society" as a form of "social currency", so i am claiming that the person in my example is indeed paying for the use of Free Software and Open Source products.

i think streets are a good analogy. initially streets just happened through continued use. eventually they were enforced and bridges were added by those who needed them. as communities grew, it was recognized that the community as a whole needed to take care of the streets and local public funds were used to build and maintain them. finally a network of national highways was built, paid for by national taxes.

Free Software and Open Source follow a similar development. it started with people creating software for their own needs. communities are growing and funding their own development. and finally we recognize that there is a set of global infrastructure that is used by almost everyone and now we are trying to figure out how to pay for that.

maybe, like national highways, it could be paid for by taxes?

btw: the term "free-rider" also implies taking advantage of something for personal benefit. anyone who produces a public good, is most certainly not taking advantage of anything for their personal benefit.

greetings, eMBee.

In reply to by whit537

When I reach this point I get fuzzy and dial back out: the point in the future at which more money is circling in the opposite direction (push instead of pull) and ... we wake up one day and realize we don't need money anymore? Do we reach that point? How does the transition work? What the h*ck does that look like? I haven't gazed that deeply yet.

I think whatever you do to be able to fill your days with gratitude and generosity and fun working together is awesome!

What I'm smashing my face against (one of the things) out here in San Francisco at the moment (I'm visiting from Pittsburgh), is less of an individual mindset, and more of a *corporate* mindset that one doesn't pay for things unless one has to in order to get some value. It's *really easy* for firms to pay for value ex ante, and *really hard* for them to pay for value ex post facto. In the case of free software, corporations harvest a lot of value. How do we evolve our corporations to pay for this value ex post facto? Is it sufficient to say that free software developers benefit non-monetarily from the goods that the corporations themselves produce? Does that bear out in practice?

In reply to by eMBee (not verified)

I actually haven't read /The Success of Open Source/, so thanks for introducing that to the discussion here! I will have to look into it.

By "various explorations" I sense an allusion to Stephen Walli's recent provocations that, "freeloaders are essential to success," in his talk at All Things Open, and in Meme #6 here:

https://opensource.com/business/16/4/12-memes-explain-open-source-softw…

He and I actually had an interesting exchange about this after his talk. I think he's right that existing "open source business models" are really not open source business models per se, but are rather business models that harvest value from the ecosystem of the open source community (witness the connection with Lister's framing), add additional value, and sell *that* on the market.

As I mention in another comment, what I'm trying to point towards is the possibility of a genuinely open source economy entity. Something that combines the intrinsic motivation and highest levels of personal agency that we find in open source projects, with the economy vitality of the traditional firm.

We've figured out how to produce value in open source projects that exist in a sort of bubble inside the market. What would it look like to dissolve that membrane separating the two? What would a genuinely open source economy look like?

In reply to by bbehrens

This is a classic false premise. Heartbleed happened because users are indifferent to security. If there was an expensive (that paid for plenty of security) and a cheap (that didn't), you can expect users to go to the cheap one. If the expensive one was well marketed, there would be no reason to bother with security. Go look at all the major virus centers: Microsoft Windows, [formerly?] MS Office, Android, Flash, etc. All of these are backed by extremely deep profits and are critical to mission success. But nobody could possibly take security seriously until the customers expected it (Office might have managed to be somewhat more secure, but it was far too late for Windows).

Look up "lemon economy". That is the problem, not open source. Open source doesn't have a "free rider" issue because free riders have zero strain on the project. If the free riders don't like what they are getting, and still refuse to contribute, that is a classic lemon economy. Lemon economies work just fine with proprietary system as well.

Also, I was careful not to say that free-riding *caused* Heartbleed. It may or may not have, but either way, the event did uncover an extreme case of free-riding.

In reply to by wumpus (not verified)

With open source it's more a matter of degree, and perhaps focus. It's fine if lots of people free ride. It's even fine if MOST people free ride. In fact, it's impossible for it to be any other way--the laptop I'm typing this comment on has thousands of open source packages. I could be a genius programmer devoting every waking moment to open source software and I'd STILL be free riding on most of the software I use. That is one of the beauties of it, really; as long as a certain proportion of people contribute, all of us get all this wonderful stuff. And if you look at Linux and its ecosystem, there have clearly been enough people NOT free riding to make it dominant in a lot of spaces. Even in the desktop, the number not free riding has been enough to make some pretty dashed usable, even spiffy, systems--even though the use share is in the 1-2% range. Just imagine how amazing the Linux desktop would be if 10% of people were using it! Sure, it would be nice if the proportion were a bit higher, but the whole thing works surprisingly well overall.

The problem is when EVERYBODY free rides. And there are always going to be a few things that don't get the visibility, that seem boring or fly under the radar and everyone just sort of assumes everything's OK. What things like Heartbleed point us to is more that we can't completely rely on a sort of purely attention-based approach to contribution. I think there's room for a bit of planning around the edges, for things like foundations or governments to step up and look over the entire ecosystem/infrastructure and help with those important niches/pieces that are being neglected.

great point.

it's not free-riding that's the problem, but the lack of attention to critical tools that we all rely on.

In reply to by Purple Library Guy (not verified)

Let's be careful to distinguish between free-*riding* (not paying) and free-*loading* (not working). Free-loading is fine and healthy, as long as we're not also all free-riding. We've got to give back one way or another!

In reply to by Purple Library Guy (not verified)

" We've got to give back one way or another!"
What stone tablet is that written on? It may be the moral/ethical thing to do but it is not an absolute requirement.

Your differentiation between free-'riding and '-loading' is an artificial one based on your personal definitions. You are just playing with semantics.

As a programmer, I was paid to develop payroll applications. However, I also happened to develop various software tools to make the process of programming easier. Software tool development was not part of my job description. Soon other programmers on the staff were using the tools I developed. Were they free-riding? I never expected or wanted to be remunerated for creating those software tools. I had an itch and I scratched it and others benefited by it.

The situation with open source software is similar. A lot of it is developed because somebody scratches an itch, not because they are told to develop a specific application. The concept of 'free-riding' was invented by mercenary programmers who expect to be paid for each and every line of code they write. To them programming is just a job, not a process of creation.

In reply to by whit537

I think this is an excellent comment by dragon.

And while I believe this article is an excellent, thought-provoking, conversation starting, piece... I generally call BS on it's main point about free-riders.

While I strongly agree with Dragon's "itch" analogy, I would also re-label "free-riders" as "significant feedback apparatus". How much time and money does a major software producer spend on coders to debug and polish their final release version of their product (yea... no cracks about MS never being enough)?

Someone else mentioned that there is a difference between OS with 3 users and OS with 300 users. While they went a different direction, I maintain that the OS with 300 users is on it's way to becoming more stable and more successful. That is 300 "free" beta-testers, finding bugs or broken code to help that given project advance and thrive. Sure, decent viable feedback is probably a fairly low percentage (let's assume 5%) of users... so by that math, you need all of the free-riders you can get to increase the level and amount of useful testing and feedback. (back to the 5% of 3 is effectively 0 vs. 5% of 300 is 15 beta testers who have provided a valuable service - again for free - to the programmer's project).

Thus we have value. Thus we have significant more value with MORE free-riders. Thus free-riders are a GOOD thing for OSS.

In reply to by dragonmouth (not verified)

I have to respectfully disagree here. What Heartbleed exposed was not a problem with 'free-riding' or 'free-loading' to use Chad's terms, but a problem in project management. The sole project contributor /chose/ not to actively solicit any help for a very long time. He clearly never read "The Open Source Way:"

https://www.theopensourceway.org/wiki/Introduction

If he had, he would have had the tools to grow create and grow a community of active contributors. I regard this resource as required reading for anyone who wants to run an open source project.

P.S. It's also clear to me that the evidence is overwhelming that there is no problem with either free riding or free loading. For example, my only contributions to OSS have been posting on message boards for a handful of projects plus some very occasional bug reports. By Chad's measurement, I'm part of a very large problem. I contend that there IS no problem. There are only very isolated cases where someone screwed up growing their community.

In reply to by Purple Library Guy (not verified)

Very thought-provoking Chad. This made me think it's helpful to define what we think the problem with free-riding is. Because open source costs nothing to replicate, it is not a problem per se for people to use code without contributing back. I would say the problem comes from what you could call, "net-negative contributions" i.e. contributing in ways that are not helpful overall. This is something I've been guilty of myself - the half-baked pull request, or asking for a new feature with a feeling of entitlement coming from highlighting a new use case. There's also the problem of depending on something that simply becomes out of date relative to other dependencies and security risks.

Which is a good point to think about incentives. As Bryan's article[1] discusses, people are contributing for a variety of reasons, not least to make a change they want to see or scratch an itch, and it is seems natural that not everyone is interested in developing this past their initial achievement. This is not the attitude you would choose if you were looking to hire someone to create, maintain and improve a new software project, but I think that for people who start to use and rely on an open source project, they can easily suffer from a case of mistaken identity.

[1] https://opensource.com/open-organization/16/1/employees-wont-work-paych…

First a quote from http://www.thondomraughts.com/2009/03/making-money-with-free-software.h…

"Software industry as we see today did not exist in the 60s and 70s. During those days software development primarily happened in academic and research institutions. People who developed software were academicians who shared software and its source codes like they did with traditional knowledge. For them software was just another form of knowledge. People developed software, shared sources, shared fixes, made fixes and updates and then shared them as well. Software grew just like science did through sharing and accumulation of contributions. "

Now, if the free software developer is not working at a university, there's this advice in the article

"... there are quite a few established ways of making money with Free Software. A few notable ways are 1) Offering Support 2) Multiple Licensing 3) Dual Versioning 4) Customization Services 5) Hosted Services. "

Finally an interesting remark

"It might be worthwhile to remember that one of the recent Free Software company acquisitions, that of MySQL by Sun Microsystems touched a billion dollars. "

Yes, some companies successfully harvest value from the open source ecosystem, add their own value (support, legal assurances, etc.), and sell their value-add at a profit. As Stephen Walli pointed out at #ATO2016, this is not really an "open source business model," it's a proprietary business model that uses open source for raw material.

What if there *were* a truly open source business model? What if we could teach companies how to pay money for open source software *itself*?

In reply to by Máté Wierdl (not verified)

Interesting article, Chad. Three things that occur to me reading it and the comments above.

The first is that even free riders offer value. An open source project that has three users that don't contribute directly to the tool vs. an open source tool that has 300,000 users that don't contribute directly are not in any way cut from the same cloth, if only because it's very difficult to imagine an open source project with 300,000 users and only one contributor.

The second is the amount of effort and knowledge that is required to contribute to an open source project can require the project's originator to spend a lot more time making the project truly open to contribution and not just to use. I imagine most of us know of open source projects out there that are, if not contributor-hostile, at least contributor-indifferent. I imagine most of us have decided to switch to open source solution B when the alternative was contributing to open source solution A to make it better, whether because A was contributor-indifferent or whether the learning curve just seemed too monumental given the expected benefit to be achieved by contributing.

The third is how much contribution is enough? If I hit the "Donate 10€" button, is that enough? Should the project owner accept that I'm contributing in a meaningful and direct way after that point? What if I contribute one patch? or one "good idea"? And since I have contributed in my mind, what sort of recognition should I expect?

how much is enough, depends on the needs of the project. for openssl for example the contributions flowing back into it clearly were not enough.

how much is enough, is going to be different in every case, dependent on the other contributions the user makes to the community (either the world community at large or the project community, or anything in between, take your pick) and it is dependent on the needs of the project itself, as well as the needs of the users.

some projects are doing fine, and they don't need any contributions. and some are starving for resources.

it is up to the community of users to find out if their needs are met, and if they aren't, to then go and increase contributions until their needs are covered.

in the case of openssl this happened with the appearance of additional funding to support its development.

the question that remains now is what other projects do need more resources to satisfy the needs of their users? this also contains the hidden question, of whether all users know that they are relying on software that needs better support. with openssl most users (and i am counting anyone with a linux based mobile phone here) did not (and still do not) know about it.

In reply to by clhermansen

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.