Friday Jun 13

Understanding community is paramount to the success of your Open Source project

LugRa­dio recently fea­tured a section on “community” in their latest episode—Finding Emo—discussing how many indi­vid­u­als and com­pa­nies alike endeavor to form com­mu­ni­ties around their projects and prod­ucts, and how in the end many of these fail. In par­tic­u­lar with Jono Bacon on team it is a note­wor­thy listen (segment starts at approx. 27:00). I think the only thing that was missing at the end of the rather long segment was a con­clu­sion of thoughts by Jono. Here’s my take, in order:

  1. Don’t be a no-​one: in order to start doing some­thing your­self you’re the only one in need of con­vinc­ing and inspir­ing that that some­thing it’s in fact worth doing. Con­versely, acquir­ing a com­mu­nity of con­tributers (devel­op­ers, doc­u­men­ta­tion writers, usabil­ity nutters and crazy “orange-sunglass-wearing” artists like myself) requires a bit more. To ensure others will jump onboard when you launch your project build a pos­i­tive pres­ence in an open source com­mu­nity; being known for your work gives you an air of trust and com­mit­ment that inspires others to lend an ear when you have some­thing to say.
  2. Be involved and listen: this should almost come auto­mat­i­cally as part of having a pres­ence in a project and as part of a com­mu­nity, but the last part is what really needs point­ing out. Some­times you have more to gain from lis­ten­ing to others than speak­ing your­self (and this applies far outside of open source com­mu­ni­ties). Lis­ten­ing will let help you under­stand the com­mu­nity you are apart of and the people within it, who ulti­mately are the easiest and pos­si­bly largest pool of pos­si­ble con­tributers you can reach out to (at least at launch).
  3. Become part of the com­mu­nity and launch from it: it is easier setting a stage within your com­mu­nity and com­mu­ni­cat­ing directly to its par­tic­i­pants who already con­tribute to an open source project than from some­where outside. Still address the world at large and invite anyone who is inter­ested, but do it from a stage where you’re bound to have an audi­ence.

These apply as much to com­pa­nies that want to extend their prod­ucts and build their ser­vices whilst con­tribut­ing to open source as to indi­vid­u­als who just want to start their own project but could do with a few extra hands. Too many com­pa­nies simply put up a web page offer­ing links to a public version control repos­i­tory and hope a mad flock of devel­op­ers will form around their project.

Don’t be a no-​one, get involved, and listen so that when you’re ready to kick-​off your project close to the com­mu­nity you’ve become a part of you will pique the inter­est of con­trib­u­tors.

This entry was written on June 13, 2008 at 7:39 pm, and tagged under , , , , , , , , . Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback: Trackback URL.

2 comments

  1. 1. Tel
    Jun 29, 00:30

    I have a big problem with your method­ol­ogy, because it seems exactly the wrong way to look at the world. Mind you, it’s not unique to you, I see it from mar­ket­ing guys all the time — create the right “atmos­phere” and your product will be a great hit. I try to tell them, “maybe we should work on improv­ing the product”, but that tends to be the last thing anyone wants to do.

    Getting back to your list:

    1. Pick a project that is gen­uinely useful. It doesn’t have to be 100% main­stream, but enough with the photo organ­is­ers already. Iden­ti­fy­ing a genuine need and fig­ur­ing out what fills that need is the real break­through for any startup project (or startup company).
    2. Iden­tify with people who have similar needs to your­self. Those are the only people who really care about what you are deliv­er­ing.
    3. Never feel that success of this par­tic­u­lar project is the most impor­tant thing in the world. If the project starts to die a natural death then mosr likely nature is right and you should retry step 1. (which is the most dif­fi­cult step).
  2. 2. Pascal
    Jun 29, 01:57

    @Tel: Not being a mar­keter or a com­mu­nity manager, this was my sim­pli­fi­ca­tion into a list of what Jono Bacon revealed in the noted episode of LugRa­dio. I am some­what taking for granted that readers under­stand that they both need to have an itch to scratch—the more main­stream the itch, the better—and that in the case of a company, the primary objec­tive should be to build a good product to scratch that itch.

    Being a known and trusted member of the open source com­mu­nity greatly aids in attract­ing atten­tion to a project. The best con­trib­u­tors nat­u­rally are those who care about what you care about—share the same desire and goals—but you’ll have more luck with a track record and a stand­ing with an exist­ing com­mu­nity than start­ing your own iso­lated com­mu­nity from scratch. That is the “atmosphere”—if that’s even the right term for this—that I was think­ing of, less so what cor­po­rate mar­keters might con­sider. In fact my second and third point in the entry addressed this issue: in my opinion too many cor­po­rate mar­keters have the wrong idea about the “atmosphere” they feel they need to create to promote their project. Throw money at, launch big, flashy adver­tise­ment cam­paigns and the like is what comes to mind whereas what they should be doing is getting involved, pay several devel­op­ers to work on open source projects until they are trusted con­trib­u­tors, or hire exist­ing leaders. This is what Canon­i­cal, Novell, and Redhat already do. Ulti­mately poten­tial con­trib­u­tors will be more likely to hop on-​board if they see a well-​known and trusted project leader with several suc­cess­ful projects already under his or her belt than a company devel­oper whose name is new to every­one, but is ele­vated along with the company project onto a golden pedestal by adver­tise­mentz and money.

    Let evo­lu­tion take its course—if your project fails, figure out what went wrong along the way and start again is good advice. I think we’re actu­ally both arguing the same points—I just pre­sumed many of the ones you raised where given and shouldn’t be spelled out (plus it would have messed up my neat three point list, which is far easier to remem­ber than six or seven points).

    Cheers.

Post a comment

Please share your thoughts or add a note if I missed something.

Required fields are marked by an asterisk (*). Your e-mail address is never published nor shared. You can use common text formatting XHTML elements (e.g. a, acronym, blockquote, code, em, strong, …). If you’d like to directly respond and link to another comment, you can do that using the Twitter-style @reply (i.e., @Randy Bender: …).

*
*