Are freeloaders helpful or hurtful to open source communities?

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.