Are freeloaders helpful or hurtful to open source communities?

No readers like this yet.
People arranged in the shape of FOSS

Concerns are raised every once in a while in the broader free and open source software community about freeloaders. The attitude expressed is that if you're getting the benefit of FOSS, you should contribute. Building a business on a FOSS project you don't own, whether you're providing a service or product around a FOSS project should in return garner some sort of quid pro quo. In reality, freeloaders are desirable.

I think we need to look through the other end of the telescope. The people most often concerned about freeloaders and the free ride are actually the ones with the motivation problem—they expect free work (or "free" customers). I recently wrote about Making Open Source Software. One of the first things required is a motivation to share. One of the next requirements is an ability to collaborate. I believe the people most likely to express concerns about freeloaders seem to be uncomfortable with the idea of sharing their work.

You almost never see this concern expressed by a company that is participating in a community it doesn't own. They are obviously happy to be contributing and getting more than they give. They are themselves by definition not freeloaders, and clearly the community is evolved enough that they're probably not the only outside contributing company. Likewise, project founders and committers seem to be happy to see others using their work. All these folks already understand the dynamic. One tends to find the freeloader concern expressed by companies that "own" the open source project.

In a former life as a consultant, I saw companies that own projects raise concerns about contribution and about "giving away their software for free." This is really another way of saying, "we didn't receive the expected contributions in kind." Worse, there would be discussion about users that didn't convert into customers because this would be the only forgivable reason not to contribute. The thinking was, "somebody needs to pay."

Such companies confused customers testing the solution in the user community with genuine community users that aren't convertible leads. The company couldn't initially fathom that developing a community of users around a technology project would:

  • Create the knowledge, expertise, and experience necessary to provide a complete solution for the technology pitch to the customer. These proof points are invaluable when actual potential customers are self-qualifying themselves in the community and testing the strength of a solution’s community.
  • Create advocates and evangelists to spread awareness about a solution.
  • Create enormous inertia in the status quo around a technology they own or provide the dominant expertise around.
  • Anchor customers both in an engaged relationship as well as from a technology perspective.
  • Ultimately lead to contributions if they encourage and prepare for them. (N.B. This is still not a conversion to a paying customer.)

I have even seen a variation on the freeloader phenomenon in relation to the Google Summer of Code: projects that haven't participated before mistakenly want to get free labour for the summer. The Summer of Code is explicitly designed to enable computer science students to learn about open source software, to gain experience in real-world distributed software development work, and to hone their programming skills. It's about the students—not the labour. As the tagline says, "flip bits not burgers." The FOSS project itself certainly benefits with exposure, training their own project members as mentors, and if the project mentors do a good job, they gain committed new blood. But it's not about "getting free work."

It's really about the math of the situation. A number of people have observed over the years that contributions flowing into a FOSS project hold a particular pattern. For every thousand bug reports, a hundred developers will propose a solution in code. Ten will actually read the submission guidelines and fix the entire bug. One will provide a righteous fix and the contributor will have run the test harness provided, and their submission will include new test cases to prove it has been solved. This works for communities with large user bases like MySQL andSendmail, right down to very specialized communities around such things as graphics drivers.

These observations set the tone for how to think about the vector, because to get a thousand bug reports, you probably need ten thousand users in your community. If the observations are accurate, 90% of every FOSS community must be users that don't contribute so much as a single bug report, i.e. they're freeloaders.

So, it is really about the project motivation. Developing good software is hard work and liberally sharing the software under FOSS licenses and building a community is the best way to spread the economic costs of development and gain inbound domain expertise. Furthermore, if you're a company that owns the actual IP for the software project, you gain the additional benefits (defined above) around developing an engaged community.

Contribution is the lifeblood of the FOSS project, so it needs to be easy to install/configure and use the software to build a broad community of users. It needs to be easy for users to understand how and what to contribute to improve the odds of contribution. If code is the inbound contribution, it needs to be easy for users to become code contributors. Such people need to know what to do, how to get started, and how to contribute.  ll of these activities are the project's responsibility. From the contribution flow, a project will find its future committers and maintainers to renew the core development community.

As a project community grows and thrives it will attract businesses that want to use the software and contribute. If the project developers meet the commercial needs for legal risk management, then an ecosystem can thrive around the FOSS project. This adds even more users to the community as companies participate, pulling the project software into new places.

So in the end, it's all about freeloaders, but from the perspective that you want as many as possible. That means you're "doing it right" in developing a broad base of users by making their experience easy, making it easy for them to contribute, and ultimately to create an ecosystem that continues to sustain itself. Freeloaders are essential to the growth and success of every FOSS project.

Originally posted on the Outercurve Foundation blog. Reposted with permission.

User profile image.
I am a technical executive, a founder, a consultant, a writer, an international business person, a systems developer, a software construction geek, and a standards diplomat. I love to build teams and products that make customers ecstatic. I have worked in the IT industry since 1980 as both customer and vendor.


Excellent post. I <a href="">wrote something similar</a> back in 2008, so the debate has being going on for some time.

Almost everyone involved in open source projects starts off as a freeloader, and I hate the expectations that some people have concerning reciprocity. In our project, I'm just happy that folks find it useful, and if they want to contribute: be it code, comments, or just community - that's just icing on the cake.

I especially liked your comments about GSoC. We've be participating for years now and it is a lot of work. People often forget the mentoring side of things. However, it can be very rewarding (we have at least one amazing student this year) and the experience you gain through the program can easily transfer to working within an open source community in general.

Good point Tarus, I also feel like we value code contributions so much we forget about other valuable contributions including authoring docs, evangelizing - telling other people how cool the software is and any activity that gets more people involved e.g mentoring via Google Summer of Code.

I am happy it ain't FO$$, because good software can be obtained, used, shared and contribute to technology developing cultures that M$, Oracle, SAP ... have ignored.

Freeloaders start off using the software. Then, they find a bug. Then they are asked to test different cases for the bug. Soon they are no longer freeloading, but now active QA personnell :)

"Freeloaders" is a pretty insulting term to describe users.

If FOSS developers don't want "freeloaders" ruining their precious day, they just need to stop putting their code on public servers.

Less condescension would be welcome.

My complaint is not what you would necessarily call "freeloaders", but rather companies that use open-source, perhaps even contributing to the projects, but then turn around and spit on the OSS community when they're customers/users.

I would much prefer to see the use of the terms "Contributors" and "Consumers", where what I call consumers is probably equivalent to what you call freeloaders. As you say, consumers can sometimes be converted into to contributors when they have a problem. As such someone who consumes rather than contributes is not at all bad since not everyone can contribute either due to time, skills or whatever. However, my project has reached a point where it has gone well beyond what community contributors can provide because it involves very expensive enterprise hardware and very high-end techniques (SAN, fibre networks, clustering, replication, deduplication...). All this costs money and risks to run afoul of expensive patent suits by large commercial proprietary vendors. The only way I have found to drive my open source project into the big enterprise market is to create a commercial "open core" company around the open source project (now in existence 14 years). This is where there the problems began to appear -- at least for me. Many large consumers use the project's software, but most do not contribute. In order to attact these consumers to the commercial version to support more development of high-end features, which ultimately flow back to the community and the contributors, we must use the dreaded open-core strategy -- open source at the core but "non-free" source around for distinguishing features. This has one postive consequence: the open core company now contributes far more than what would other wise be possible from just the community. On the other hand, it has a number of negative consequences: the open source community may be upset; copy cats are likely to apear and create forks for their own commercial interests.

I am not worried about consumers (but do wish more would convert to contributors or at least enterprise customers). The real problem is how does one ensure the perenity of a high-end open source project? Is the solution, as I chose, an open-core company, or are there other solutions?

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.