OSCON 2009

The face-to-face meetings are a place for the people who try to Get Stuff Done at various open source projects and non-profits around open source to congregate, share information, and pick each others’ brains. This year we will meet in July in San Jose California (USA). The meeting will be held on the Sunday and Monday before OSCON 2009, partly overlapping and in co-operation with the Community Leadership Summit being organised by Jono Bacon.

Monday: Start at 10am in room B2.

Attendee map (in clockwise order):

  • Dave Neary (GNOME)
  • Sylvia Aimasso (FOSS Foundation for Africa)
  • Nnenna Nwakanma (OSI, FOSS Foundation for Africa)
  • Elin Waring (Joomla)
  • Larry Rosen (Attorney)
  • Henri Yandell (Apache)
  • Michael Dexter (Linux Fund)
  • Michael Tiemann (President of OSI)
  • Hiram Wright (Subversion)
  • Justin Erenkrantz (President, Apache)
  • Sander Striker (Exec. VP Apache)
  • Paul Querna (Apache VP Infrastructure)
  • Allison Randal (Perl Foundation, Parrot Foundation)
  • Gervase Markham (Mozilla Foundation)
  • David Mandel (Linux Fund)
  • Ilan Rabinovitch (SCALE, Linux Fund)
  • Tiki Dare (Sun Microsystems)
  • Donald Smith (Eclipse)
  • David Boswell (Mozilla Foundation)
  • Milton Aineruhanga (FOSSFA)
  • Joe Brockmeier (OpenSUSE)
  • Simon Phipps (Sun Microsystems)
  • Bradley M. Kuhn (SFLC, Software Freedom Conservancy)
  • Erin Williamson (SFLC Attorney)
  • Alolita Sharay (OSI)

Attendees: (add yourself here)

  • Dave Neary
  • Jeff Sheltren
  • Gerv Markham (Monday only)
  • Bradley M. Kuhn
  • Simon Phipps
  • Donald Smith
  • Allison Randal
  • Justin Erenkrantz (Monday only)
  • Elin Waring
  • Jacob Kaplan-Moss
  • Louis Suárez-Potts
  • David Mandel (LinuxFund.org)
  • Tiki Dare
  • Bruce Perens

Suggested books:

Dave Neary’s meeting notes

Notes from the meeting of the FLOSS Foundations group on Monday before OSCON 09 in San Jose.

Start with a round-table with brief introductions, and short statement of what people were looking for from the day.

(apologies to anyone not listed who came in late - please add people you see missing)

  • Dave Neary, GNOME Foundation
    • International affiliate organisations
    • The role of the non-profit leadership in setting tone and enforcing behavioral norms
  • Nnenna, FOSSFA
    • Fundraising
  • Elin Waring, Open Source Matters
    • Role of non-profit in project ecosystem
  • Larry Rosen
    • Wants to hear what we all need
  • Henri Yandell, Apache Foundation
    • Trademarks
    • Apache attic (retiring dead projects)
  • Michael Dexter, LinuxFund
  • Michael Tiemann, OSI
  • Jeff Sheltren, OSU OSL
    • Wants to hear what we need from OSL
  • Justin Erenkrantz, Apache Foundation
  • Milton Aineruhanga, FOSSFA
    • Getting support from other organisations for FOSSFA activities
  • Sander Striker, Apache Foundation
    • Consolidation of non-profits, umbrella organisations
  • Cat Allman, Google
    • Working better with communities
  • Paul (Apache Foundation, I think)
    • Scaling communities
  • Allison Randall, Parrot & Perl foundations
    • Maintaining energy in a project over time (bringing in the new blood
    • & renewing & revitalising the mission)
  • Gervase Markham
    • To listen & help out
  • David Mandel, LinuxFund
    • Fundraising
    • What can we learn from liberal arts models?
    • Incubating projects
  • Deb Bryant, OSU OSL
    • Learn about other communities
  • Greg Lund-Chaix, OSU OSL
  • Tiki Dare, Sun Microsystems (OOo & OpenSolaris)
    • Trademarks - wants to know where is the debate
    • International consequences & variations of trademark
  • David Boswell, Mozilla
    • Fundraising tools, CiviCRM
    • Tools for visualising community
  • Bradley Kuhn, SFLC & Software Freedom Conservancy
  • Aaron Williamson, SFLC
  • David Maxwell, NetBSD
    • Workflow tools for managing board tasks
  • Simon Phipps, Sun
  • Silvia Aimasso, FOSSFA
    • Fundraising
  • Danese Cooper, OSI
  • Lance Albertson, OSU OSL
  • Joe
  • Ilan Rabinovich, SCALE
  • Alolita Sharma, OSI

After the introductions (10:30), we split the day up, based on what people wanted from the day, into 4 major sections:

  • People ~1h
  • Legal ~1h (trademarks mostly)
  • Money ~2.5h (getting it & using it)
  • Tools ~1h

And we finished the day with a session summary, and suggestions for future sessions.

People & culture

Dealing with projects that die: the Apache Foundation presented their attic as a technical & social way to indicate that projects are unmaintained. Some questions around potential IP issues - agreed that for free software projects with no dual licensing it’s not necessarily an issue.

Allison pointed out that energy levels can tend to dissipate or go down in a project over a longer period, especially if you don’t get new developers coming in. We talked for a while about how to enable or encourage your project leaders to make themselves dispensable. Some tidbits I noted:

  • Leave a vacuum - sometimes it’s good to leave something small but obvious undone, to create an easy way for someone else to get started
  • Actively recruit partial replacements - ask people to do something small for the project which lightens your load
  • Set a deadline on the effort - ask someone to do something for a year, with a clear end date. After a year, it’s always possible to renew, but this allows someone to step back with no guilt.
  • Lessons from companies: leaders get replaced because of the company imperative to grow or die. No explicit recruitment usually
  • Be clear about what you’re not going to do. Sometimes saying “this is important, but I’m not going to do it” is enough of a nudge to empower someone to carry the torch.

How do you track developers in your projects?

  • Blogging about tools and hoping people add themselves (GNOME map, calendars, user group wiki pages, etc). This is the Field of Dreams model - if you build the infrastructure & communcate about it, they will come
  • Mozilla campus ambassadors program & Ubuntu LoCos were two successful outreach recruiting efforts that were identified. Model: Provide tools & infrastructure, but very few requirements for local teams, and then recruit through conference presence, friends network, etc. Mostly ad hoc, Ubuntu was map based, where they identified states & countries with no formal LoCo, and actively recruited when the opportunity arose. Distributed rules about becoming official LoCos with well described requirements helps.
  • Mozilla are working on a community CRM through a paid CiviCRM developer, Jay from Mozilla knows more
  • Michael Tiemann gave a book reference here: “Conversation capital” which talks about this subject. Described 2 essential motivators for people approching a project: impact & meaning.

Technical enablers

Someone mentioned that having a modular architecture allows developers to add value without learning the whole project. Goes with good module developer documentation

Volunteerism?

Simon Phipps suggested that talking about volunteers in the project is framing things wrong, and is a marker that something’s wrong already. “Volunteer” suggests to him someone who we can ask to do what we would like them to do. People join community projects because of personal motivations, that we must respect.

Nevertheless, it was remarked that the best way to have someone do a task which is not being done is to ask them to do it. Very few in our communities refuse requests for help.

One interesting suggestion I heard in the hallway: Build up psychic capital for your project by asking people to do favours for you very early on. Psychologically, you owe them, and thus they’re invested in the project. Or something. (Can the person who said this clarify and give the source, please?)

Other stuff:

  • Involvement is graduated. Getting a new core developer starts by getting him a little involved, then a little mroe, then…
  • Establish a trust pipeline. Make your project scalable by having trusted lieutenants whose judgement you trust implicitly for certain types of decision. Write down these lieutenants and the things you trust them for (Mozilla superreviewers, Subversion module owners, kernel subsystems all work like this)
  • Renew & revise vision regularly - to change your goals, or to plan a new path there from where you are currently.
  • Apache project incubator cited as a good example of a mentor programme which teaches people the project culture as part of the induction
  • Google Summer of Code credited with “forcing” projects to establish formal mentor programs.
  • Write everything down in this area. Make it easy to point newcomers to documentation on how the community’s social dynamic works.
  • Project bans: Open Source Matters has a theoretical ban capability, administered by the community in extreme cases of bad behaviour (illegal behaviour, threats of physical violence, hate speech). Currently 3 active bans, 1 under review.
  • Values to enforce to maintain harmony & nurturing environment:
    • Mutual respect
    • Consensus building
    • Respect for decisions once made

Trademarks

Yadda yadda same ol’ same ol’ (This is unfair to people involved in this discussion, I think some new ground was covered, but I am so not a lawyer).

  • Suggested trademark policy to base off: Fedora
  • Trademark policy: “what you’re letting people do without requiring a licence”
  • You may not get to decide what requires a licence or not. Then again, maybe you can.
  • We talked about enforcement, and what you need to do
  • There was some talk about international differences in trademark law, and the cost of internationally registering a trademark
  • Someone suggested using association with the mark & encouraging good behaviour. useful for valuable marks. “You can say you’re using Joomla! if you publish your changes”
  • Trademark essentially serves your brand. Some organisations will try hard to get some reflected glory through association with our brands which represent community, integrity, etc. Don’t sell ourselves cheap.

Money

Fundraising

  • Need money for stuff.
  • Basically two ways to get money:
    • Philanthropy (“we’re dong great stuff, help us continue”)
    • Value (“This thing we’re organising will rock, it’s well worth the registration fee”)
  • Ideas for ways to raise money:
    • Conference sponsorship and pricing (example: Boost has 60K in the bank of Software Freedom Conservancy through their annual conference - price ~$600
      • Nnenna reminded us that Idlelo 4 will be in Accra, Ghana from May 17 to 21
    • Self-published books (eg. FSF, Blender)
    • Swag - t-shirts, badges, etc.
    • Small donors (Friends of GNOME)
    • Corporate support (advisory board, membership fees)
    • Credit card fees (LinuxFund)
    • Donations of “stuff” (used books, cars, anything the non-profit can resell or scrap)
  • Suggestion: should we band together for a major fundraising campaign? (eg. Use Software Freedom Day to run fundraising drive where we encourage people to donate $100 to two of their favourite projects),
  • CiviCRM came up again as donor management software - ref. Karl Fogel’s post on the list earlier this year (reminder to self: get Donald Lobo on the list)
  • For some reason, in my notes 2 book titles appear around here: “Remix” from Larry Lessig, and “Good copy, bad copy”. I know Michael Tiemann mentioned them, I don’t remember the context.
  • Account for unpaid contributions where possible - value them with a dollar value, and record them as in-kind donations to the activities of the non-profit. This will boost your balance books, help you show public interest ti the IRS if the need arises, and make it easier to get big donations. “We have a $500,000 budget” and “We contributed $5,000,000 work to the community last year” don’t have the same effect.

Philanthropists like to contribute to causes which are having a big effect

Spending money

Question: Now that we have some money, how do we spend it usefully in the community? How do we prevent money changing community dynamics?

General non-staff expenditures people mentioned: bank fees, travel funds, bounties (not very popular), internships, funded work which isn’t otherwise getting done.

General staff expenditures people commonly have: administrative & support staff: system administrator, executive director, marketing & business development, community manager, conference co-ordinator

Mozilla: Brings people to conferences, buys hardware occasionally, invests in funded projects in areas like accessibility, through subcontractors, has lots of developers

Simon Phipps: Important not to spend money in your core mission, but to spend it in support functions, unless your community agrees & requests that you hire someone

LinuxFund: Asks developers to decide who will do the work for money.

Bradley Kuhn: Transparency is the key. If everyone can see the benefit coming from the expenditure, things go more smoothly.

Avoid directed funds if possible. In umbrella organisations, ensure that the things you want to spend money on are aligned with their mission. With directed funds, bill the administrative overhead to managing the fund to the directed funds (typical overhead between 5 and 10 percent normal).

Example of “failed” funding project: Debian release manager work

Tools

Conference management

  • SCALE Reg - SCALE’s free software registration app
  • Utah Open Source Conference has one too
  • Pentabarf
  • Conference module for Drupal (pain in the ass for multi-year conferences)
  • Don’t use WebERP. Someone recommended against it
  • OS Bridge used Open Conferenceware
  • OSCON = Expectnation, Edd still gives free licences for non-profit run
  • conferences
  • Badge scanners - sponsors like ‘em. Cheap systems possible (ref. SCALE)

Notes say “E-Learning Africa: “ICWE” management, but I don’t remember what that’s about

Foundation finances management

  • GnuCash still OK
  • Bradley Kuhn uses Ledger w/ ASCII text files
  • CiviCRM for donor management
  • Pledgie & Facebook Causes identified for campaigns
  • See what Wikimedia used for their campaign
  • Payment processing:
    • Google Checkout - still expensive, still possible to get cheap for non-profits if you sign up for Google Grants, more hoops to jump through, takes a year, pinging Leslie helps
    • Paypal
    • Donor’s Choice
    • Kiva
    • Trust Commerce
    • Advice: make payment fees transparent. If someone clicks on the “donate $10” button on your site, given them a choice of $10 for them or $10 for you, and explain what the charges are in each case.
    • No point getting set up as a credit card merchant, lots of pain.

Community tracking & management

  • Mozilla working on a “people” CRM - people add their own details, you convince them to add the details & let community peer pressure keep it current.
  • Based on CiviCRM
  • Mel Chua has similar tool for Fedora
  • djangopeople.net another example
  • Top-down CRM also an option, give accounts generously
  • Email & calendar integration is important for CRM to be successful in the community
  • Voting software: Everyone using home-rolled databases & web apps/shell apps w/ ssh auth, email based voting
  • OpenSTV can count STV elections (GNOME, Maemo)
  • See Derek Cockburn’s Internet Governance Project
  • See Proxyvote.com also
  • Board workflow software:
    • IssueTracker
    • Bugzilla
    • Wiki & email
  • Open board meetings with treasurer report (how much we’ve spent, where we are wrt budget) - good practice.

Suggestions for future co-operation

  • Common fundraising drive
  • Co-ordinate for pushing press releases - perhaps pool resources for press relations representative
  • Pool experience on conference organising to drop hotel room prices, lower event costs, and generally make a bigger market that people have an incentive to be nice to.
  • Work on an agenda before the meeting
  • Another suggestion I got after the conference: when working on the agenda for next meeting, start by publishing past meeting notes, to avoid revisiting old discussions without producing anything new
  • Maybe piggyback on the Community Leadership Summit again next year

Updated: