Problems and Strategies in Financing Voluntary Free Software Organizations

Author:Benjamin Mako Hill
Date:June 24, 2005
Affiliation:Debian Project / Software in the Public Interest / Ubuntu


Talk Delivered at Linuxtag 2005 in Karlsruhe, Germany. More information available at

Introduction: Defining Scope


SLIDE 1: Title and Moneybag Picture

Intro Joke: This talk is about spending money not getting money.

If you're doing good work on a project, especially a large project, money ends up entering the equation eventually.

If you're a volunteer project that wants money, there are a few things you can do:


SLIDE 2: Overview

Overview of the talk:


SLIDE 3: Volunteer Organizations are Great

Provides Background into Volunteerism and Why Volunteerism is a Good Thing

Defining Volunteerism

What I mean by Volunteer Organization...

Not all FOSS projects are volunteer (nor do they need to be):

  • Cinepaint (AKA: Filmgimp) is not a volunteer project -- but it's still great!
  • JBOSS is not a voluntary driven project but is clearly free software/open source

On the other hand, some organizations are voluntary projects even though they incorporate a large amount of paid labor (e.g., Wine or Debian).

  • Debian is primarily a volunteer project even though many people get paid to work on it.

Finally volunteer projects can become non-volunteer projects -- and vice versa (although I think that's much less likely).

  • Blender and Mozilla are examples of projects that became free. X has gone from free to non-free to free again.

Fundamentally though, I am talking about projects in which the project is directed by non-paid labor and where the project itself is not paying developers to do or direct development.

Voluntary Projects Are Great

I think volunteer projects are good for a number of reasons

Volunteers are at the heart of the Free/Open Source development methodology

The "bazaar" style model and the benefits associated with it -- are easier to secure when there's no method of centralized control.

Open Source fostered this misconception that if you stick your code on the Internet, problems and bugs disappeared. We all know how true that is.

  • Slapping a GPL in your source code directory is not enough to gain the practical benefits.
  • Sticking your source on the web is not enough.
  • The key is that you need to bring in lots of people and that's not possible unless you have a ton of cash or a group of volunteers.

Free software has been successful on a pragmatic level because it's fundamentally voluntary nature has allowed all of those eyeballs to appear.

Institutional Independence

This means:

  • In many cases, the users get to define the specifications
  • No desire to "corner" or enclose the market for a piece of software
  • Multiple (competing) groups get to work together
  • More robust (no single company can kill the project), market for support

Good use in limited resources

It's easy to fund a project that doesn't require funding

Even in funded projects, resources are limited. Because there are dangers (which I will discuss soon) you may be able to fund one person but your entire volunteer community is often more important than any single person.

Everyone needs to decide if the volunteer model really is the correct model for your project.

Finally, it's fun, all of those things.

Problems With Funding Voluntary Projects


SLIDE 4: Dangers of Funding Volunteer Projects (Overview)
"The love of money is the root of all evil."
-- New Testament St. Paul, in 1 Timothy, 6:10


SLIDE 5: Examples of Dangers

Lessons from the world of non-software

General: Article by Bernard ENJOLRAS @ the Institute for Social Research, Oslo:

"Empirical results using cross- sectional data on voluntary sport organizations in Norway and on their members show a decrease in voluntary work from an increase in commercial income. Voluntary work and commercial income appear as substitutable resources."

Stories from Free Software Communities


The X11 Story (courtesy of James Gettys and a talk he gave at USENIX in 2000 [1]):

X11 started as a community driven project with developers from all over and X was one of the first major open source projects.

  • Releases nearly twice a year
  • Serious commercial interest

But limitations set in as well (the Internet broke (evidently)).

The X Consortium was founded to fix the problems.

  • In the words of Jim Getty's, this "Made some people "more equal" than others," and "Disenfranchised 'outsiders.'"
  • The "strings" attached to the money also put key controversial topics off limits to the X Consortium staff (e.g. Toolkits, Desktop environments, 3D)

Ultimately, many of the key contributors, including Guido von Rossum, were lost when X11 built the consortium.

A lot else happened, the X Consortium basically collapsed and lay X lay dormant for some time.


Mozilla threw the code out but Netscape kept development basically the same.

  • Coffee break problem (transparency): threads on introducing big design situations, inadvertently moved inside the company and the folks who started the discussion were no longer involved

Design decisions should not be made over a coffee break -- even though this makes it quick to make progress.

  • technical issues (code is optimized by and for folks who are staring at it all day every day)

Mozilla seems to have made it over that hurdle, but it took a couple years.

Ultimately though, the lack of volunteer labor eventually can translate into a marked decrease in the quality of the finished product.

Funding Solutions

No Risk Solutions


SLIDE 6: No Risk Slide 1

When there's no money, there's nothing to go wrong. No labor to crowd out.


SLIDE 7: No risk slides 2 (boy in bird cage)

The boy is safe from roving lions. But he's seriously his ability to get things done in the world.

Limits on scope and mobility.

Low Risk Solutions


SLIDE 8: Low-Risk Solutions: Spend Money on Things Other than Labor

  • Hardware (development servers, etc)

  • Software and things like "capacity"

    Explain capacity and explain the visual joke

    An accounting system. Software that helps you get the job done (bug tracking system, etc. but stuff that's outside of the core thing)

  • Conferences

    Debconf is one example but many projects can spend money to put on conferences (and fly people there)

  • Facilitating coding "sprints" and intense programming

    Python and Zope are the place where the term come from

    Skolelinux has describe funding example the same thing.

Caveat to keep in mind: When you're selecting some people and not others for a trip to Tahiti, it shows favoritism. Either do it transparently or fairly (first come, first serve; most active on mailing list, most commits to CVS)

Take Strategic Risks


SLIDE 9: Taking Strategic Risks

Pick WHEN you fund a project. Funding too early can be a problem.

Pick jobs carefully

  • pick jobs that no volunteer could do

  • non-technical things. funding applications, project manager. you need someone to do the project equivalent of the bookkeeping things

  • Offer focused jobs paid jobs should be focused and designed to tackle things that would not otherwise bet done by volunteers

    (either too strange, too quick a deadline, or a long proven and

    needed thing)



SLIDE 10: Transparency Transparency Transparency

  • open lists
  • have discussions in public forums and, when this is impossible, report back and take the discussion to the community (this means emails and such) and be responsible
  • For the most part: lists > IRC > phone > chatting in person

These are all important. Phones and in person conversation.

Outside Organizations


SLIDE 11: Have other organizations do the work within your project

  • Debian and Credativ, Progeny, HP, Canonical Skolelinux etc.
  • The key is to ensure the project's own institutional independence, in the minds of the volunteers



SLIDE 12: Summary^H^H^H Messages to Funders

If you're involved in funding volunteer projects: