Blogs

RedMonk

Skip to content

The Trials and Tribulations of Community Building

Although I can’t say that followed Dan Gillmor’s citizen journalism venture particularly closely, having acquired a respect for Dan from his writings I’m sad to see it come to the end of the line. One of the lessons learned from the experiment that was Bayosphere, however, struck a chord with me given the number of discussions we have that are related. In what was clearly a sincere and genuine take on what went right and wrong, Dan said the following:

Tools matter, but they’re no substitute for community building. (This is a special skill that I’m only beginning to understand even now.)

While we happen to do a fair amount of consulting with our clients on community related topics, I sympathize fully. Knowing how to interact with communities is relatively straightforward – mostly common sense, and definitely learnable for all but the most intractable corporate types. Knowing how to build them, however, is another task altogether.

Despite the often monumental difficulty of the task, however, it’s virtually imperative for software vendors to build communities around their products – because it’s becoming increasingly obvious that community is a critical ingredient to longevity and sustainability. This isn’t news, of course, as notions of software communities go back decades: just look at Lotusphere.

But as Dan notes, community building requires both skills and time that may be in short supply. Where does a software organization with already stretched resources begin? Here are a couple of suggestions that I’ve been imparting to our customers:

  • Give the Community a Chance:
    Just as you wouldn’t sow a bunch of seeds on top of asphalt and expect much, so too should you avoid limiting the community by giving them no foundation to build from. While many of the vendors we speak with recognize the obvious value of larger communities – such as those developing around the various Apache or Eclipse projects – few take the necessary steps to build even modest communities. This would be understandable if it took tons of cash to build communities – but that myth has been sufficiently invalidated at this point, I should think.

  • Don’t Worry About Community Size:
    When I talk to aspiring or new bloggers, I often hear complaints that no one’s reading/commenting/participating/etc. It’s the same deal for communities; more than one vendor we’ve spoken with has decided not to create a user forum, for fear of suffering from the embarrassment of ‘empty-forum’ (at which point I usually recommend a wiki, but more on that later). While that may or may not be true, it’s besides the point. I’m not going to tell you that having a large community isn’t beneficial, because obviously it is, but even small communities can have huge benefits. We’re living proof of that, I think; we’re just two people, but our community has shown real benefits in our research, visibility, etc.

  • Help Connect Users w/Users:
    This one surprises me on an ongoing basis: vendor X devises a product Y that includes some sort of extensibility framework, or maybe is just the type of product that would benefit from generic templates, code samples and such. Vendor X, being comprised mostly of intelligent folks, has put up some form of very basic user help site with some soon-to-be-outdated tutorials along with a bunch of confusing patches. This is the point in the conversation where I usually ask: do you have any mechanism for a user to share an extension/template/code sample/etc with other users? Almost invariably, the answer is no, and I think this is a big mistake. Users helping users is one of the most important trends within software support. Yes there are questions of IP ownership and potential economic conflicts, but not actively giving users a chance to make your product more valuable for whatever motives drive them is silly, IMO.

  • Dedicate Time and/or Hire:
    One of the things that we occasionally have a difficult time doing is explaining why dedicating part or full time resources to community fostering and the like is important; fortunately, there are enough high profile folks doing this now that it’s less of a challenge than it once was. But we’ve gotten significant pushback from a number of folks who contend that they simply don’t have the time for anything community related. Given how busy we all are, it’s an understandable argument, but one that I think overestimates the time required to, say, blog. There are enough bloggers with full-time responsibilities that manage to find a half hour or so a couple of times a week to make that argument weak. Communities can benefit you, but they require time and input: and if you can’t make that time, it’s not really something easily outsourced like, say, bookkeeping.

What suggestions do you guys have? What do you tell people trying to build and foster communities?

Categories: Trends & Observations.

  • http://blogs.sun.com/jimgris Jim Grisanzio

    You make a lot of good points, Stephen.

    Community building is not easy, but it's not necessarily more difficult than any other job at a company. It's just different, that's all.

    I think companies need to realize that the concept of community building has already occurred within their own firewalls — it's in their engineering departments. Engineers tend to form internal communities and participate in external communities more easily than other groups within a company. So, it's just a question of expanding that community outside the company and then to more levels within the company (and in that order, too).

    Here at Sun on the OpenSolaris project, we have a "community building" position (me) working out of the kernel engineering group. Some vendors view community building as more of a marketing function, but it's not. It's a very different perspective and very different operationally. I came to this job from marketing, so I clearly see the distinction and have come to believe that the best place from which to do active community development is engineering because it simply comes more naturally to those guys. Over time, however, all groups within the company should migrate as much of their operations to the open as possible and join the community because their talents and skills are needed and will be rewarded. We are *all* doing community building when we interact with people outside the company in an open way.

  • http://duckdown.blogspot.com James

    Do you believe that enterprise architects in corporate America also have some duty towards community building especially if they want "free" software?

    How does one sell this notion to IT executives?

  • Ian Skerrett

    Stephen,

    I think you make some good points. However, I think one key thing is that everyone needs to be part of the community building exercise, marketers and developers. To often I hear developers say it is a marketing problem. Developers want to talk to developers. I think the Cluetrain Manifest really drives this home.

    The other thing I have observed is that you really need to have something concrete for the community to participate around. For Eclipse and most open source communities, it is the code. The code is the beginning to all conversations and community buildings.

    btw, I happen to be doing a presentation next week about this very topic. I've posted my presentation at http://ianskerrett.blogspot.com/2006/02/building-

  • http://www.redmonk.com/sogrady stephen o'grady

    Jim: couldn't agree more. to me, the engineers make the best community reps b/c they are not obsessed w/ "staying on message" or spinning their products – they speak honestly, and that comes through. learning to leverage that, however, is a difficult exercise for many.

    James: not necessarily. i don't really believe that anyone has a "duty" to build a community, though i do believe they have a responsibility to help sustain the communities they draw from.

    what i do believe is that anyone seeking outside collaboration on some open sourced code should be thinking about ways to encourage participation.

    Ian: good lessons both. first, i very much agree that it's critical to realize that everyone's a marketer these days. as the quote mike cited at the board meeting goes: you're all marketers now, deal with it.

    also fully agree on the point of having code to develop from. it's always difficult to get people buy into vaporware, something that exists only conceptually. the inertia against widespread participation is simply too great.