The Math of FOSS Freeloaders: Why Freeloaders are Essential to FOSS Project Success
3/13/2013 9:25 AM
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.
3 comment(s) so far...
By Donnie Berkholz on
3/13/2013 10:10 AM
There's another approach worth considering, which I've written about (redmonk.com/dberkholz/2012/04/18/adoption-of-software-is-a-funnel/) and Kohsuke Kawaguchi of Jenkins talked about last year at Monki Gras (redmonk.com/tv/2012/04/06/building-an-oss-community-and-ecosystem-based-on-my-jenkins-experience-kohsuke-kawaguchi/).
You're basically talking about increasing the input into the funnel, which is clearly of value. It's also important to work on optimizing those participation ratios wherever possible and decreasing barriers at every step; I don't believe projects have reached the natural limit yet.
By David on
3/13/2013 8:14 PM
Re: The Math of FOSS Freeloaders: Why Freeloaders are Essential to FOSS Project Success
There's also a backstory behind the math of the project. In some communities, developers take bug reports seriously. While they realize they may not be able to address every reported bug, they do recognize that when someone takes the time and effort to report a bug, it should not just be hand-waved away with a tag of "wontfix" or something equally obtuse, unless perhaps the bug report is so incomprehensible that no one can understand it. The reason is that people who are capable to providing clear and comprehensive bug reports tend to stop bothering if their bug reports are ignored, or treated in a condescending and dismissive manner.
One of the worst things you can say to a bug reporter, and I have actually seen this happen, is that if they don't like the way the software works they should code the solution themselves. There are some developers that seem to think that if a person has received a piece of software for free, they should then put in the effort to learn to write code and take a hand a fixing any bugs they find, and if they aren't willing to do that they should just shut up and live with whatever the developers have provided. When you take that attitude, you ignore the reality that not everyone is a proficient coder, just as not everyone is a car mechanic or bricklayer. Once again, if you take that attitude people will tend to just stop reporting bugs, but in the process you will lose a lot of people that might otherwise have been evangelists for your project. No one wants to help promote the software of a developer they consider to be rude or condescending.
Then there is the flip side of the equation. There are projects where people do fix entire bugs, but may not understand the process that the developers would like them to use when submitting a bugfix. Not everyone's mind works in the same way, and what may seem like a clear and reasonably easy process to one person may be clear as mud to another. The problem occurs when the developers or project leaders won't even acknowledge a bugfix that's not submitted exactly the way they want it, except perhaps to tell the submitters that they haven't done it right. I've seen cases of bugs that have existed for years, and if you look in the bug tracker someone has submitted a fix that actually works, but because they did not use the ever so precise process that the developers wanted, both the bugfix and the bug were ignored. The person who originally submitted the bugfix just walked away, and probably never submitted another bugfix to that project, but at the same time no one else would submit someone else's bugfix the "proper" way, so the bug simply went unfixed - despite the fact that there was a working fix right there in the tracker!
The sad fact is that some developers and some project managers start to think a bit too highly of themselves, particularly when they have created "free" software. They start to develop what is sometimes termed a "god complex", which is something that occurs in many professions (doctors in particular are noted for it). While some users will put up with it because they are so appreciative of the free software, many of the more technically proficient people - and that includes people capable of writing intelligent and informative bug reports - simply will not. You insult them once or twice and they are gone.
If I were running a project I would say that any developer that closes a bug report with a "wontfix" tag should have his tracker privileges revoked (that is, he should be given the same privileges as any other user, with no rights to modify the status of other people's reports). The exception would be if all the developers agreed on it AND at least two or three sentences of explanation were provided. At least then the submitter might feel that he was heard, rather than in effect being told to take a long walk off a short pier. I've seen this happen so often in different projects and yet few people are willing to openly criticize the developers and their policies, in the same way nurses and patients are reluctant to openly criticize a rude and condescending doctor. In such cases people tend to practice avoidance when possible, just staying away. And that can be the beginning of the end for an open source project, particularly when the bugs start multiplying and the only ones that are getting fixed are the ones that the developers themselves happen to care about.
By Stephen Walli on
3/14/2013 10:30 AM
Re: The Math of FOSS Freeloaders: Why Freeloaders are Essential to FOSS Project Success
@Donnie and @David: Yes to both of you. (I saw Kohsuke's presentation and it was brilliant.) That was the backing point. Anyone complaining about "freeloaders" isn't doing it right. There are a collection of things that need to be done to make it easy to use/participate/contribute. They are ALL the project's responsibility. And yes, they're work. But then I've seen 30+ years of folks developing good software and it's always "hard work" regardless of the licensing. Without certain practices in place a FOSS or IT project can't scale to a user base, and a product-for-sale can't scale to support customers. That's just a function of the complexity of software.