Open Source companies have various internet-based channels at hand to reach their community and prospective customers. The following approach has proven to be effective in reaching the various target audiences within and outside of an Open Source ecosystem.
The basic idea is to let information flow freely inside and across various communication channels so that information pieces can “bubble up” and be compiled into more comprehensive and valuable sources of information that serve a business purpose.
For example, a forum discussion could form the basis for a technical article that is supposed to be published by a magazine with the goal to attract new software developers to the community. In this case, the outlined information value chain serves the purpose of community development. The nice thing about it is, that the article author will save time when writing the tutorial, because the discussion that happened in the forum already allows him to understand all relevant aspects of the topic and might also provide useful information, links to other resources, etc.
To achieve far reaching and successful marcom, Open Source companies should set up or become active on all relevant channels.
It is first of all important that communication actually happens and of less importance that it happens in the right channels. For example, if Open Source vendors think of providing a public Wiki to the community, quickly fears of a chaotic information overload come up. In fact, I have never seen hoards of community members occupy a very young Wiki. The truth is that you will have enough time to restructure content as you see fit.
Of course, you should make sure that the Wiki has a basic structure right from the start so that it becomes clear what kind of information it will provide. Additionally, it should already be populated with important content such as information where to find mailing lists, forums, Weblogs, etc. Especially when it comes to discussion channels such as mailing lists and forums, they should only be established if you are sure that they will be used actively. Otherwise, your community will appear as if it were inactive, which again alienates new potential community members.
To avoid dead communication channels, I recommend to deliberately leave pain points for a growing community. For example, don’t set up a forum in a non-English language unless there are community members who ask for it. If you then set up a dedicated forum for them, they will appreciate that you listen to your community.
Above diagram gives a good idea of the most important communication channels that all make up for the best media mix to enhance the visiblity of your Open Source offerings.
- Twitter is today’s premier channel for teaser-style communication that creates incentives for the readership to learn more about you.
- Forums and/or mailing lists are a must-have from a community building and customer relations perspective.
- Weblogs are a perfect mean to achieve technical and business-oriented thought leadership.
- A Wiki is a great tool for collecting all relevant information at one place with full flexibility of gradually modifying and extending the information base. A Wiki is somewhere in between the ad hoc style of conversation through Twitter, forums, mailinglists and a rather editorial process that a newsletter or book requires.
- Newsletters seem outfashioned in today’s world of social media marketing, where it’s more about pull information (RSS) vs. push information (newsletter subscription). The great thing about newsletters is, that they require someone sits down and collects all information important to your developer or business community of let’s say the past 4 weeks. A newsletter makes sure that everyone within your company and community has the same basic knowledge of what’s going on.
- Presentations of technical or business talks also collect various information pieces and present them to a live audience at events.
- Articles, Screencasts, and marketing collateral can be produced much more easily if there is already a multitude of existing information, e.g. in a newsletter, Wiki, Weblog, etc. A newsletter for example might even trigger the idea to write a case study about a new customer reference that has been mentioned in the newsletter or to create a screencast about a nifty new feature that was mentioned there.
- Public and Analyst Relations are much more effective if you have further information that you can provide to journalists and analysts. It also makes it easier for your PR/AR agency to write press releases if they have something they can research. It’s also very handy to be able to harvest and reference related resources such as Weblog entries, Screencasts, and more when building landing pages for a campaign.
- Books and documentation are hard to write, because they require a lot of effort. Again, they become much easier to create once there is already valuable information, such as various articles that have previously been written for magazines and can now be reused and modify for e.g. a technical book. Books and technical manuals represent the most comprehensive type of information to offer for example to those who intend to thoroughly learn about developing with an Open Source software.
An Open Source organization’s marketing and communications very much benefits from uncontroled conversations happening within the related Open Source community. If a vendor tried to manipulate communications within “his” community, he would suffer from higher marketing costs, because the free flow of information that comes at no cost will dry up.
In a nutshell, Open Source communications should take care of the following points:
- Make and let communication happen.
- Avoid dead communication channels.
- Don’t control, don’t manipulate.
- Harvest and refine information pieces.
- Deliberately leave pain points for the community to remedy.
Sandro Groganz 
Very good points, thanks for writing these up!
I wholeheartedly concur with your assessment and summary. I would like to point out one more thing: it’s not enough to just set up a Forum or Mailing list and hope for the community to take care of it.
You need be become actively involved in the discussions in order to make it successful. Your community needs to know that you are approachable and the communication is in a bi-directional fashion.
Also, having a separate Mailing List and a Forum can be quite time-consuming to monitor and follow. It’s probably a good idea to set up a forum software that also supports posting and reading messages via email (or even NNTP), to have one focal point of discussions.
LikeLike
Hi Lenz,
thanks for your valuable comments!
Re forum/mailinglist involvement:
Very true! From a strategic point of view, the whole sense of having a community is to make your company and product better. Hence, you actively want to engage in conversations with your community. For example, someone who posts an issue with installing your software to the forum can help make the installation process easier or perhaps you might find out that there’s actually a bug.
When setting up new discussion channels such as forums or mailing lists, you should start the discussion by proposing e.g. new features, suggesting changes to the community portal, etc. to kick-start the discussion. This will show that you are serious about openly discussing a whole variety of topics. After about 3 months, community members start to help each other and you can gradually retreat from answering basic questions and concentrate on the more complicated issues. This means that setting up new discussion channels requires you to be very active for about 3-6 months until the community engages more actively and understands how to use the new channel.
Re focal point of discussion:
Are you speaking from a community manager’s perspective? It would indeed be great if there were an integrated communication environment that allowed community managers to manage mailing lists, forums, blog comments, Tweets, etc. Concerning community members, the idea of converging mailing lists and forums always comes up, but in the end turns out to not really be necessary. Usually, GMANE does the trick. Developers prefer mailing lists, users prefer forums. Forums might be better from an SEO perspective, but what good is a dev forum that no one uses because they prefer mailing lists?
LikeLike
Agreed, user feedback on discussion forums can definitely help to improve the product, if it’s treated accordingly. But for this kind of discussion I think it’s also imperative to have a good public bug tracking system – users need to know when it’s better to submit a bug report (which is easier to track and follow up) than a forum post.
If you want to be very proactive about it, you could even enter the forum discussion by stating that you submitted a bug report about this on behalf of the user. But this is of course a time-intensive thing to do and only works for the bootstrapping phase of a project. Therefore it’s probably a good idea to set up guidelines for users to know where to post what.
And yes, I was wearing my community relations manager hat when thinking about Mailing lists vs. Forums (and of course other communication platforms). Now that users can create their own discussion groups on so many platforms, it has become quite a challenge to stay up to date with the various conversations on all of these. I haven’t used GMANE a lot, thanks for reminding me of it.
And agreed, devs usually feel more comfortable with a mailing list. Having a platform that support both sounds like a Good Thing, but it may also cause a culture clash (e.g. discussions about quoting style may arise). It probably depends on which community you want to address first and foremost. Do you want to foster a developer community or rather build up your user community? Both may have different needs.
LikeLike
All good points!
Concerning bug reporting, there’s this additional issue of language: You might have a strong community in Germany for example, but of course want bugs to be reported in English to be useful for your development staff and your international dev community. There might be people within your German community who feel uncomfortable writing in English. Here again, you need to invest time and e.g. ask them to first post the bug in a German-speaking forum so that you can translate it and turn it into an English bug report. Later, there might be community memers who can help you with that.
When it comes to the type of community (dev or user), it’s often quite hard to draw the line. It should be quite easy when speaking about platform components such as a database, but a community that forms around a CMS or productivity software is much more diverse. Such communities need to take into account that developers also wear the hat of users while developing the core app or custom solutions. Additionally, there should be processes how to translate and transfer input from users e.g. in a forum (“this is really hard to use”) to the mailing list where the core devs need crisp information that allows them to understand how to actually solve the issue.
LikeLike