B) How freeloaders build your community

Jan 14

Written by: Staff
1/14/2014 9:23 AM  RssIcon

This post is the eighth in a series that will explore why businesses should become active participants in open source communities. We’ll explore what open source is, the economics of OSS (open source software), who uses it, how to make projects successful, and how to participate in external projects. It will also taken a deep dive into more complex topics such as the commercialization of FOSS, community vs customers, managing inbound IP, licenses, software hygiene, and when NOT to publish a project.

Read the previous post: Which open source license is best?
Start from the beginning: Intro.  What is it?

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. 

One needs to look through the other end of the telescope to understand the issue better.  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).  As discussed in earlier sections, one of the first things required in building an open source community is a motivation to share.  One of the next requirements is an ability to collaborate. 

One almost never sees this concern expressed by a company that is participating in a community it doesn't own.  They are obviously happy to be contributing and living in the economic space of 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. 

This concern over freeloading often comes when companies that own projects raise concerns about a lack of inbound 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 seems to be, “somebody needs to pay.”  This is generally a strong indication of a company that doesn’t quite understand why it wanted to share and collaborate on a software project, and the benefits of community development. 

The right way to view the freeloader problem is 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 users of a project, a hundred will file bug reports, of which ten will provide a solution in code.  One of the ten will actually read the submission guidelines and fix the entire bug.  This works for communities with large user bases like MySQL and Sendmail right down to very specialized communities around such things as graphics drivers.  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 around developing an entrenched community, hard-to-measure as they may be. 

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.  All of these activities are the project's responsibility and require an investment from the project.  From the contribution flow, a project will find its future committers and maintainers to renew the core development community. 

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.

 Read the next post: Constructing open source software

Blog Roll

Indent Example
Sam Ramji
Thoughts from the President of the Board of Directors
Indent Example
Paula Hunter
On the business of OSS and Non Profit Foundations
Indent Example
Stephen Walli
Guest Blogger
Indent Example
Phil Haack
Project leader: NuGet
Indent Example
Bradley Millington
News from the ASP.NET Gallery Manager
Indent Example
Bradley Bartz
WebsitePanel Project Leader
Indent Example
Guest Blogger
Posts from Guest contributors
Indent Example
Posts from DLSI Gallery Manager
Indent Example
Rob Mensching
WiX Project Leader
Indent Example
Eric Schultz
Developer Advocate
Indent Example
Bertrand Le Roy
Orchard project updates and news
Indent Example
Posts from Outercurve Staff