Avoid the tool trap when building communities

No readers like this yet.
A community building a barn

Opensource.com

Over the last few years, I've had the opportunity to work with many different organizations attempting to build successful communities inside and outside the open source world.

Many of them quickly fall into something I call the tool trap.

Meaning, they immediately jump into a conversation about what tool or technology they will use to support the community:

"Where are we going to put the wiki?"

"Should we build the website using Drupal?"

"What should we call the mailing list?"

"We should starting playing around with [new technology X]."

This is no huge surprise. Great community-building tools are now available to us that never existed before and it is very hard to resist the urge to start nerding out on new technology.

And tools are important. But tools alone do not create community.

People create community.

Which is why when I hear the conversation move too quickly into tools, I try to steer it back to the tried-and-true foundations of solid communities, the things that bring people together and make them want to accomplish great things.

I never hear folks say they want to be part of a community because it has a cool website or because it uses some whiz bang technology. People join communities to contribute to something that holds meaning for them.

So instead of falling into the tool trap, I try to start conversations like these:

What is the dream?

Almost every great community has a shared passion, dream, or  purpose. What great thing could this community accomplish? Does everyone agree? If not, what does everyone agree on?

At the core of the community there needs to be a source of energy that drives the community forward in good times and bad. Call it a dream, a purpose, a mission, a raison d'etre, whatever you like, but identify it quickly and then work collaboratively to ensure everyone shares in it.

What are the legends?

Great communities have stories and legends that provide color to the mission. In my experience it is extremely hard to effectively capture passion in the words of a mission or purpose statement.

But passion comes through clearly in stories. A picture is worth a thousand words, and if a picture of the mission can be painted through a story, it will become even more real to members and potential members.

What are the values?

In most cases communities emerge from a group of individuals who find they share not just a common purpose, but a common set of values. Sometimes community efforts fail because, although members share a common mission, they disagree on how it should be accomplished. Often, these differences can be traced back to differences in the personal values of the members.

Figuring out if there are common values within the community will help potential members decide for themselves whether they are a good fit for the community. If their values do not match the community values, they will opt out on their own.

For me, the architecture of participation in the healthiest communities will be built upon the answers to questions like those above.

Once the answers become clear, you'll be much in a much better position to make good decisions about the tools that will best support the community and you can nerd out on technology to your heart's content.

 

User profile image.
Chris Grams is the Head of Marketing at Tidelift and author of The Ad-Free Brand: Secrets to Building Successful Brands in a Digital World. Twitter LinkedIn Email: chris(at)tidelift.com

15 Comments

Period.

Mailing lists are not complicated. They're ubiquitous and trivial to set up, and they *must* exist in a *basic* form as a precondition to any "official" community business.

It takes literally two minutes to start a Google Group that provides this functionality.

I agree: *serious* decisions about *ongoing* infrastructure should be delayed until stakeholders have a better idea of what they're trying to accomplish. But if you want transparency from the very beginning, then you should be archiving all important discussions *from the very beginning* -- in a way that allows new participants to come up to speed.

And that means, at the very least, a mailing list.

Jorge Castro of Canonical did a great talk on this at Ohio Linuxfest in 2009. He called it "tool wankery" and it really struck a chord with my friends and I. We'd tried to start a few projects, but always got caught up on the tools.

http://blip.tv/file/2673817/

Hi Colin-- this is a great link! Thanks for sharing it!

Brilliant article! Thanks for writing it.

I've noticed that many of the tools you mention actually erode local community, which is what I'm focused on (and more interested in) building. They might be needed for geographically dispersed communities but we should always remember there's no substitute for face-to-face interactions.

So, if you can start locally, start locally.

Cheers,
Randall
Ubuntu Vancouver LoCo

I've learned the hard way that keeping it simple is most important for any tooling, period. Make your mistakes quickly, then decide whether/where further investment is needed. Rinse and repeat.

Keeping it simple can also helpfully avert one of the counter-points to the "tool trap": when the tool in some way represents the values, dream, or legend your community relate to. Even the most impassioned advocate for XYZ will find it difficult to argue against a mailing-list, etc.

The community's needs will evolve, but the same logic applies. Understand the goals/problems, pick the tech that will do the job, but keeps you in the most agile position.

I've noticed that a large fraction of my personal business community (e.g. clients / suppliers) are owner-founders of their own companies.

What would you say their common values are? Common stories?

hi Mark, thanks for the question!

My take: Most communities have roots in the vision of individuals.

Organizations of 1 have a big advantage in that values, mission, etc. don't have to be a conversation or a collaborative exercise-- they are simply what you personally believe. The stories are your personal experiences and memories. The values are your values, the vision is your vision.

But very few organizations, even organizations of 1, operate in a vacuum these days. And the challenge, even for organizations of 1, is to ensure that they *articulate* and *capture* their vision, values, and stories so when the time comes to interact with others or to grow into a larger organization, the roots and foundation are strong.

I'm not one hundred percent sure you're right. I do agree that we often waste too much time with wikis and mailing lists, cms, etc.

There is one tool however does truly enable an open and effective form of distributed collaboration that is unique, and that tool is git.

Git is a distributed version control system that makes heavy use of SHA sums. This means, amongst other things, that you can distribute your code widely, keep data integrity, and not rely on "commit bits".

Yes, there are other tools that do similar things, like bzr and mercurial, but git offers so much more than just a DVCS - for example, if your central git server fails and you lose the entire repo, you can recreate the complete code set if you have a copy of every commit somewhere.

Git is a turbo powered Open Source enabler.

...assuming it's an open source developer community you're building and not some other type of community (yes! there are other types of community out there)

<strong>Build value first</strong>. Then people will come to benefit from it and to help it go a step further.

Too many projects target a fancy envelope and miss the substance that users are seeking.

A project is inspiring others when it delivers its promise for more freedom.

The G-WAN Web server, with its ANSI C scripts, is such a tool.

Simpler than all others, faster than all others, safer than all others, not tainted by planned obsolescence, and free for all (open-source and closed source projects).

After delivering value you can bother to think about the envelope. A wonderful ceiling is pointless without walls.

I'm found that one helpful antidote to the "tool trap" is to insist on *not* running your own services -- at least not initially, and not without extremely compelling reason. After all, your great new idea is XYZ, so you need all your community resources working on XYZ. You do *not* want to siphon them off into: running a mailing list, installing a wiki, maintaining the wiki, performing upgrades, cleaning the spam filter, maintaining the centralized git repository, etc. Each of those tasks is a drain on your community's ability to actually Do Something Great.

So agressively refuse to install/maintain tools. If you use tools in the cloud, they are often less configurable. Great! That will keep tool-tuning from siphoning ever-increasing amounts of time. Convince yourself that "good enough" is actually the Right Thing, figure out how to make do with the basic tools available in the cloud, leverage the maintenance/upgrades/etc done by those magical forces which keep the cloud running, and save your community's efforts for the real problems.

Focus!

I am sad that I was never able to convince SugarLabs of this.

(For those who don't know: I'm also a Sugar Labs person, as is/was Scott.)

It's a half-implementation of the open source way of doing things that leads to tool-wankery. Since, by open source principles, you can't tell someone else <em>not</em> to use a tool, you'll have dozens of people with dozens of preferred implementations, all with the ability to implement them. Others can try them out, and eventually the best solution will gain more followers (er, ideally). This is good - "those who do, decide."

The community can decide to grant one person (project leader, infrastructure team lead, etc) the power to "bless" an implementation as "the right way," and this is also good. But it is also potentially dangerous - "those who do, decide" can turn into "those who decide, do" - with those leaders choosing an implementation based on personal idiosyncratic preference rather than consensus on the good of the project, not giving other ideas a fighting chance to take root, and making everyone who wants to participate use whatever they decide.

I struggle to articulate this, because both sides of the argument sound entirely reasonable from different perspectives... I think what we may have with SL's infrastructure is a failure to make it easy to fork, which leads to angst and struggles over tool-fu rather than productive work towards SL's core purpose.

But that's the heart of the argument, and I suspect the reason Scott and I feel the way we do - Sugar Labs' core competency is <em>not</em> setting up collaboration infrastructure. Actually, for 99.9999999% of projects and groups out there (open source software or not), the purpose of the project is not to host mailing lists, it's to get <em>something else</em> done (making a software environment for kids, in this case).

So yes. Let someone else do it. Use open tools so that the work that other people do can be modified if needed - but let other people do that work for you.

I'm not sure I quite agree with you.

I think that if you even *give permission* for people to set up tools/work on tools you're opening the door to the tools trap. Some people are going to get sucked in and waste time which could be spent more productively, and then they're going to suck more people into discussions and tool-tinkering.

I think a more extreme position is needed. Not just "sure, let anyone set up the tools they want" but instead "our position is that spending time on tool development hinders our mission" and the community needs to participate in discouraging such distractions.

Maintaining this focus is easier in a "company" environment, where a manager can say, "you're welcome to tinker with tools in your free time, but on company time you should be working on XYZ". But it's even more important in a volunteer community where *all* time is "free time" -- there needs to be social inducement to focus the work.

With volunteer groups, there's sometimes a weird financial twist -- we can't afford to use hosted service XYZ, so we need volunteer ABC to run our own server instead. With a realistic value on volunteer ABC's time (and opportunity costs), it is usually far more expensive to waste ABC's energy and enthusiasm this way. Good leadership should look for funding sources for non-core tasks, so that limited volunteer resources can be spent advancing the organization's real mission.

Basically, everyone involved needs to agree that "good enough" is actually good enough, and that pursuit of "the best" can inflict all sorts of collateral damage. You *do* need leadership to tell people *not* to use a sexy distraction (aka new tool), in order to maintain the community's focus. A more permissive attitude actually enables well-meaning tool fiends to subvert the energy of the community as a whole.

(This is why an "open" group is often more effective if they use "closed" tools -- like, say, Google Groups. The closed tools implicitly discourage tinkering. This is a social ill, but it can be reversed judo-like to maintain your group's focus.)

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.