Creating online community the open source way | Opensource.com

I presented “Creating online community the open source way” at the Triangle Drupal Users Group (TriDUG) on the evening of Thursday, July 22 and thought it would be a good idea to share with a broader audience. For this post, I'll use the opensource.com online community as my case study.

Opensource.com is a community for exploring how open source principles like collaboration, transparency, and meritocracy are influencing innovation beyond technology--shaping education, law, business, government, and everyday life. Opensource.com is a platform to share, discuss, and discover how people are applying the open source way, even if they don't call it that.

Many people are familiar with how the

open source development model became successful by using principles of sharing, collaboration, rapid prototyping, and many others. The term “open source way” is the collection of all those principles.

One of my favorite open source principles is failing faster. You may have heard the phrase “release early, release often.” Another version of that is “fail early, fail often.” To me, that means iterative course correction. DeLisa Alexander goes into greater detail about this in her post, “Fear of failure? Embrace it by failing fast.”

How did the opensource.com project team go from an idea to a deployed website with a growing community? We needed what I call the 3 C's: content management system (CMS), content, and community participation.

How we chose our platform

The first step was to identify our goals and audience. Once we determined what we wanted to accomplish, we started looking at open source platforms that would fulfill our goals. Our final decision was Drupal. Some of the factors that led us to Drupal were the hosting and administrative options. But the factors that made Drupal stand out were the community modules available as add-ons allowing us to customize our deployment and the job trends, which for us, mean that the platform and support for it will be around for a while.

How we get content

The site is divided into five channels: business, education, government, law, and life. Each channel has moderators who actively write and search for others to write posts. We also invite our community to send our moderators stories they find or to contribute blog posts themselves.

Aside from that, we are always keeping an eye on current events and trends. We conduct interviews with subject matter experts on a variety of topics and invite guest bloggers to contribute their thoughts.

How we build community

We used a multi-pronged approach to building our community. Our approach includes social media, traditional (“old school”) ways, events, and participation on opensource.com.

Social media

First, we decided on a name: opensourceway, laregly because it was descriptive and available across most of the popular social media outlets: Twitter, Identi.ca, Facebook, Flickr, YouTube, and LinkedIn, all of which we now use.

Traditional (“old school”) ways

Some of the traditional tools used to build online communities include email marketing, Internet chat rooms, and mailing lists. Our community asked for an IRC (Internet Relay Chat) channel—you can now find us on Freenode in the #opensource.com channel. We have a large mailing list that receives a monthly email that highlights some of the content published on the site. We also use smaller mailing lists both for content dissemination and smaller, collaborative work within channels.

Events

We've attended a variety of events, and we continue to learn how events can help us drive awareness and grow our community. Each event is different with different audiences and opportunities.

Within four months of launching the site, we hosted our first virtual event. The Open Your World forum was a day-long webinar that brought in speakers from around the world. The presenters were compelling, and it was a great learning experience for us.

Participation on opensource.com

The final part of our multi-pronged approach to community building was what our users could accomplish on the site. We thought it would be best to have some low barriers to participation, such as rating articles and voting on polls.

One of our goals is to encourage visitors to join a conversation and comment on the articles. This is extremely valuable to us because we want to start conversations around the articles we are posting.

Wrapping up

There really are no right and wrong answers to the open source way, but we're trying lots of things. It's important to remember that the principles of the open source way should be used as guidelines when making decisions. But you should always be as transparent as possible with your community.

The “Creating online community the open source way” slides are available below.

Thank you for the article, I'm contrasting this against, and apply some concepts to a reassessment (reboot) of an open source game development community-building project I'm coordinating. We suffered some significant setbacks and ended up with a FUBAR site, badly stagnated community, and failing project. I'm certain its still salvageable though.

From experience I can definitely say both "fail early, fail often" (small manageable failures), and "fail spectacularly, and don't forget to take notes" (huge failures) works well as part of an iterative process. The problem I encountered is failing in a community building initiative tends to present a unique set of challenges. To fail in a development initiative is expected, if there is any "baggage" it usually resolves itself when the recovery phase starts. What I was entirely unprepared for is how emotional and "political" baggage can have a lasting impact which is difficult to overcome. Even if the underlying failure is resolved the side effects can fester into a bad reputation, or stigma, and tends to create a negative feedback loop which rapidly stagnates the community.

The serious danger here for community coordinators, and core of the problem I encountered, is if the community becomes large enough that recovering from a failure requires a community effort, then the negative feedback loop effect can result in the community loosing the capacity to recover. From there the only solution seems to be essentially restarting from scratch, magnifying the impact of both the original failure and accompanying baggage several times over.

For now I can only point that out as a hole in applying the open source way methodology to community building, perhaps its a quirk of human nature. I have yet to find a solution, other than persistence through sheer force of will. Do not take spectacular failures personally, else it can become demoralizing, and the accompanying frustration is just unnecessary stress, or needless suffering.

The risks of failure, I believe, are not wholly different for open source communities than they are for any other group or entity. Lost time, morale, effort to pick up the pieces and regroup? Those are all problems that I've experienced in other domains as well. The difference with an open source community, I think, is not in what you risk, or what you have to do to cope with the failure -- it's in the requirements of performance, and what you stand to gain by following through on them.

When you fail, provided you're working in the open source way, everyone will (and arguably should) know it. There's no sweeping it under the rug when the project falls apart. Possibly the worst response is trying to obfuscate or hide what's happened. That's simply erecting a barrier to recovery, and in a healthy and scaling community, recovery is meant to happen quickly. Fast recovery can enhance morale, or at least stem its downturn, and ensures that unnecessary resistance to change doesn't build up. This is why objective criteria are so important in open source, just as in any other successful project. Everyone can use the same yardstick and understand when a plan is working, and when it's not. Making those criteria or whatever quantitative measures you're using part of a transparent process is important.

Owning up to failure when it happens also has a side benefit, I believe -- perhaps small, perhaps intangible, but certainly vital -- that balances out (hopefully) a bit of the inevitable pain. By being up front about risk and consequences before, during, and after a failure, you stand to enhance your reputation as a plain dealer, a straight shooter. Community values honesty, because the openness and transparency it engenders is the bedrock upon which the relationships that bind the community together are built. Anyone who's trying to run an open source project, large or small, benefits from providing an environment of honesty. It attracts good contributors, and breeds an atmosphere of mutual respect and dedication among them.

Another one to consider is how restarting from a failure can offer new found agility. A chance to try a new approach with the added benefit of hard earned experience on a community level, without many of the barriers seen in starting entirely from scratch. Its often impossible to explore new ideas when a project has significant momentum, to-do lists a mile long, and roadmaps going out for years. While that is not unique to open source, the capacity for a community to do this through collective force of will alone is definitely a unique benefit.

Its also an opportunity for the most dedicated, often selflessly committed "hardcore", community members to take a vacation....

Vote up!

0

Vote down!

0

Jason Hibbets is a senior community evangelist in Corporate Marketing at Red Hat where he is a community manager for Opensource.com. He has been with Red Hat since 2003 and is the author of The foundation for an open source city. Prior roles include senior marketing specialist, project manager, Red Hat Knowledgebase maintainer, and support engineer. Follow him on Twitter: @jhibbets

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Shadowman logo are trademarks of Red Hat, Inc., registered in the United States and other countries.