«
»

Building a Community Around Your Project

I attended a great talk at last weekend’s Ohio Linux Fest by Jorge Castro with Ubuntu about “Building a Community Around Your Project” based on his experiences with gwibber. My rough notes are below.

  • Meta-information
    • Talk: overview
      • Last year my friend Ryan Paul started the gwibber project, a client for Twitter/identi.ca for GNOME. Together we nurtured and grew a community around the project, but learned some tough lessons about how to run a project that no one ever tells you until you screw it up yourself. In this session I will talk about crossing that chasm from hobby to a healthy open source project – including things to avoid and things to experiment with.
    • Speaker: Jorge Castro
      • Jorge Castro (Building a Community Around Your Project) is an Ubuntu enthusiast and works on the Ubuntu Community Team on External Developer Relations for Canonical Ltd. He has spoken at Penguicon and the Ohio Linuxfest on multiple occasions. His weakness is being unable to write proper biographies.
  • “Nice Thread” – FAIL
    • funny image
  • So … you want to start a new project?
    • Don’t
    • But if you’re going to do it, you might as well (try) to do it right
    • There’s no manual
      • When a project forks: “The problem is that …” [missed rest of quote]
  • Scratching an Itch
  • History of Gwibber
    • Ryan Paul, Ars Technica
  • Starting small
  • Hosting your own infrastructure
  • “No one will see my crap”
  • “The Twitter Moment”
    • Jorge showed a graph with utilization of the facebook part of Gwibber
  • Then What?
    • Real users
    • Real bug reports
    • Distribution expectations
      • “Where’s your tarball?”
    • No pressure! (lol)
  • “But I was doing this for fun!”
    • We learned a bunch of stuff
    • So here we go…
  • Community: It’s the New Black
    • Let’s talk about classes of contributors
      • Developers vs. everyone else (old school)
        • Non-developers: “The software doesn’t work!”
        • Developers: “Send me a patch! Shut up!”
    • The new way
      • Collaborative clumps of people
      • More stakeholders
      • More stakes!
      • Not just developers, also documenters, evangelizers, testers, translation, etc.
  • Managing Contributors
    • Recognizing areas you are not good at
    • Appointing “Lieutenants”
      • Letting people rock (guide them through fail)
    • ASK FOR HELP
      • … in the right places
      • E.g.: internationalization is not well known in the US, but well known in other countries; find a non-US person who might have more clue than you
        • Once your project is “i18n”-able, there are “roving bands of translators” out there
  • Managing Contributors
    • Behavioral expectations
      • “Culture”
      • E.g.: Ubuntu conference vs. Debian conference
      • E.g.: At Ubuntu, they try to be inclusive while being respectful
      • E.g.: When someone does something stupid on the list, do you flame them or try to tell them nicely?
      • Figure out what the middle ground is in your group and then figure out how to deal with conflict, governance, etc.
        • Great resource: “How to deal with poisonous people” by the Subversion guys — video on YouTube — video
      • You can always inherit from other projects, too
        • Ubuntu has lots of examples for governance, contributions, resources, code of conduct
    • How do other projects do it?
  • Communication
    • Whatever medium you use, use it!
    • Don’t assume anyone knows what your roadmap is
      • When you chat about stuff, try not to do it in private forums (IRC, email) but in public, instead (email list)
      • You need to have discipline to do things in a public forum
      • Have a roadmap!
      • Be inclusive, not exclusive
  • Choosing the Right Platform
    • What’s best for you?
      • Not Adobe AIR?
      • “Adobe wrote AIR for nothing but twitter clients”
    • Popularity
      • I.e.: you probably don’t want to write an MP3 player in LISP with TK
      • Gwibber chose python and Gtk
    • Ability to find help
    • “Freedom”
    • Think of other platforms
      • E.g.: use gstreamer to support for MP3 app, don’t write your own stuff
      • Aim for writing high-level stuff, others have probably done the low-level bits, and they’ve probably done it better than you can
    • Think of distros
      • If you want to be in the default Linux distribution, you probably don’t want to be requiring Adobe AIR or a LISP environment
  • Platform
    • Working with “partners”, like identi.ca
    • Let me tell you about the decision to use webkit
      • Gwibber used webkit with python and gtk bindings
    • Question:
      • How to support users on older releases?
        • Gwibber broke if you are using a slightly older version of webkit (a single minor release back)
      • We don’t. We screwed them.
        • This was really a mistake. It sucked.
      • Probably should have kept running the Cairo back-end for another release of Gwibber to allow the newer version of webkit to get out.
  • Tool Wankery
    • Stop arguing about tools
    • Just do it
    • Don’t waste time
    • People who argue about tools all day should be killed
      • Not a recommended community building method
  • Tool Wankery Part II
    • Use a DVCS (distributed version control system)
      • DO IT NOW!
    • Merge requests and branches — oh my!
    • Invest time in learning the tools (but don’t let it get in the way of getting things done)
      • E.g.: Gwibber started using launchpad late
    • Tools don’t save you from being dumb
      • Tools aren’t crutches
      • “Doesn’t everyone …” [missed the rest of this quote]
    • Really enables users to do their own stuff
  • Spot Fail from Afar
    • See this blog post about common problems with OSS projects
      • That’s the guy that did the license talk this year at OLF
    • Gwibber
      • Does not announce releases on a mailing list [+5]
      • Does not do versioned releases [+20]
      • Does not do releases [+50]
      • Website doesn’t have any documentation [+30]
  • Results
    • 95-130 points of FAIL: HONK HONK. THE FAILBOAT HAS ARRIVED!
      • Gwibber scored 103
  • “Man, dude, making software is hard…”
    • Making good software is hard
    • Making bad software is easy [is this what he said?]
  • Polish
    • Users sick of ugly apps (like ours!)
    • We’re finally learning to design software
    • Design finally getting the attention it deserves
      • Pulling random people off the street and have them play with it
        • If 9 out of 10 users try to click on something after starting the app and it doesn’t work, FIX IT
        • Iterate and fix the most common problems seen by new users
        • E.g.: show a loader when loading stuff instead of failing in the background
        • “Last thing we want to do is stab users in the face”
        • If we make really awesome stuff, users will use it
  • User support
    • Bug wrangler
      • Regular bug days
      • Rotate people through the bug wrangler role
      • The more you take care of bugs, the more apt people are to help you
      • “I don’t know how to fix this, but let’s keep this bug open and maybe someone from the Internets will stop by and help.”
    • Release manager
    • “I have a big stick” person
      • Follow up on merge requests, patches, etc. and give people the courtesy of some kind of a response.
  • “If you’re so smart why does Gwibber 2.0 suck?”
    • Failed at explaining 2.0 roadmap to users and other contributors (my bad)
      • Early snapshot packaged by distributors in devel releases made people think gwibber 2.0 was out
      • Lack of any release process
      • Atmosphere of “nightly builds are supported”
      • It’s not done, gimme a break, dang
  • Negativity Sucks, Let’s talk positive
    • 30 solid contributors
      • ~60 branches on launchpad
      • Some in this room!
      • Learn from us and from other projects
      • Never, ever, give up: ignore stop energy
  • We all have bad ideas
    • “Maybe an ‘outbox’ in the tree view similar to mail clients.” (Ugh, I just went there)
  • Questions?
  • Q&A
    • How do you get user input?
      • Canonical walks out of their door in London and grabs random people, they watch and record how the users use the software.
      • Jorge tries to glean useful tidbits of user input from mailing lists, etc.
      • Be careful asking users to explicit input
        • “You better add more clocks or I’m switching to gnome!”
  • Other resources that look interesting (from me, not Jorge)

    • This entry was posted on Monday, October 5th, 2009 at 4:34 am by DJ and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

    Leave a Reply

    You must be logged in to post a comment.