Open Source Enterprise Solutions

Open Source Journal

Subscribe to Open Source Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Open Source Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Open Source Journal Authors: Elizabeth White, Patrick Hubbard, Matt Davis, Jyoti Bansal, Liz McMillan

Related Topics: Ubuntu Linux Journal, Open Source Journal, Open Cloud Collaboration, Open Source ERP and CRM


The Math of FOSS Freeloaders

Why freeloaders are essential to FOSS project success

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." 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 and sendmail 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.  All 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.

More Stories By Stephen Walli

Stephen Walli has worked in the IT industry since 1980 as both customer and vendor. He is presently the technical director for the Outercurve Foundation.

Prior to this, he consulted on software business development and open source strategy, often working with partners like Initmarketing and InteropSystems. He organized the agenda, speakers and sponsors for the inaugural Beijing Open Source Software Forum as part of the 2007 Software Innovation Summit in Beijing. The development of the Chinese software market is an area of deep interest for him. He is a board director at eBox, and an advisor at Bitrock, Continuent, Ohloh (acquired by SourceForge in 2009), and TargetSource (each of which represents unique opportunities in the FOSS world). He was also the open-source-strategist-in-residence for Open Tuesday in Finland.

Stephen was Vice-president, Open Source Development Strategy at Optaros, Inc. through its initial 19 months. Prior to that he was a business development manager in the Windows Platform team at Microsoft working on community development, standards, and intellectual property concerns.