Problems and Strategies in Financing Voluntary Free Software Organizations ============================================================================ :Author: Benjamin Mako Hill :Contact: mako@atdot.cc :Date: June 24, 2005 :Affiliation: Debian Project / Software in the Public Interest / Ubuntu .. Note:: Talk Delivered at Linuxtag 2005 in Karlsruhe, Germany. More information available at http://mako.cc/ Introduction: Defining Scope ============================= .. Note:: 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: * Grant Writing * Strategic relationships with governments, organizations and companies * Mostly though, the "secret" is just about doing good work .. Note:: SLIDE 2: Overview Overview of the talk: * Voluntary organization (mostly just defining scope) * Volunteerism is great! (There are many benefits of volunteerism) * Funding volunteer-based organizations can introduce a wide number of problem * Solving these problems - No-Risk solutions - Low-Risk solutions - Managing Risk .. Note:: 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 ========================================= .. Note:: 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 * Paid Labor Crowds out Volunteers (will return to this in a second) * Transparency Decreases * The nature of the product decreases .. Note:: 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 **************************************** X11 ---- 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 -------- 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 ******************* .. Note:: SLIDE 6: No Risk Slide 1 When there's no money, there's nothing to go wrong. No labor to crowd out. .. Note:: 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 ******************** .. Note:: 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 ********************** .. Note:: 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) Transparency ************* .. Note:: 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 *********************** .. Note:: 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 Conclusions ============= .. Note:: SLIDE 12: Summary^H^H^H Messages to Funders If you're involved in funding volunteer projects: * Realize the difference between free and proprietary development models * think hard before you spend money by paying individuals * stay critical, stay creative, and stay transparent .. [1] http://www.usenix.org/publications/library/proceedings/usenix2000/invitedtalks/gettys_html/text13.htm