Financing Volunteer Free Software Organizations: Problems and Strategy Benjamin Mako Hill Debian Project / Software in the Public Interest Talk Delivered: FISL V | June 4th, 2004 | Porto Alegre, Brazil More Information and Talks: http://mako.yukidoke.org/ === SLIDE 1: Title and Moneybag Picture Introduction: Defining Scope - Intro Joke: It's 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 - Mostly, just do good work === SLIDE 2: Overview Overview of the Talks: - Volunteerism is great! - Funding volunteer-based organizations is problematic - Solving these problems - No-Risk solutions - Low-Risk solutions - Managing Risk === SLIDE 3: Volunteer Organizations are Great Provides Background into Volunteerism and Why Volunteerism is a Good Thing == What I mean by Vounteer 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! - Ghostscripts is another one where you're one year ahead - mostly written by one person with a few copyrights assigned and he's very up front about the idea that he's gonna write a bunch of code and get rich - Debian *is* primarily a volunteer project even though many people get paid to work on it. Volunteer projects can become non-volunteer projects -- and vice versa (although I think that's much less likely). == 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. - Slapping a GPL in your source code directory is not enough to gain the pratical benefits. - Sticking your source on the web is not enough. - You need to bring in *lots* of people and that's not possible unless you ahve a ton of cash or a group of volunteers. We're talking about "Open Source" vs "Open Sourced"; "Free" vs "Freed"; Open Source fostered this misconeption that if you stick your code on the Internet, problems and bugs disappeared. We all know how true that is. = 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 commmunity is often more important than any single person. Everyone needs to decide if the volunteer model really is the correct model for your project. === 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 NOTE: (Brief overview of each) == Paid Labor Crowds out Volunteers == Transparecy Decreases == The nature of the product decreases === 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 controverisial 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 collasped 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, inadverternly 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. === SLIDE 6: No Risk Slide 1 When there's no money, there's nothing to go wrong. === 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. === 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 (annad 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) === SLIDE 9: Taking Strategic Risks Pick WHEN you fund a project. Funding too early canj 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 reponsible - For the most part: lists > IRC > phone > chatting in person These are all important. Phones and in person conversation. === SLIDE 11: Have other organizations do the work within your project - Debian and Credative, Progeny, HP, Skolelinux etc. - The key is to ensure the project's own institutional indepdence, in the minds of the volunteers === 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