Let me share some of my analysis of Drupal marketing efforts while getting prepared for my talk Marketing Open Source Software at Drupalcon. Comments are highly welcome, be it to this blog entry or during my talk or any day while I am at Drupalcon.

Drupal is a great brand

The Drupal brand is highly visible: For example, a Google search for Drupal generates 19 million results. Compare this with Alfresco, generating just 1.8 million results (including the Alfresco Grill).

The Drupal brand is vivid: A big part of the Drupal brand is in the people in the community.

Drupal is a registered trademark: That allows VCs to justify a $7 million investment.

Drupal is successful

There will be a whopping 800 attendees at Drupalcon – sold out – wow! That’s double the amount of the previous conference. Nice growth rate.

200 000 registered users at drupal.org, 300 signing up each day, Drupal downloads approaching 100 000 a month, and more impressive Drupal statistics.

Comparing this with the statistics of other Open Source CMS, it clearly places Drupal in the top league.

Drupal marketing is community-driven

Drupal joined the forefront of Open Source marketing. Not only is the product Open Source, but marketing Drupal is itself being managed and performed like an Open Source project. Everyone is invited to contribute to Drupal marketing by helping craft a marketing strategy, positioning statement, marketing collaterals and all.

This leads to a load of valuable information created by enthusiastic volunteers which would typically cost tens of thousands of dollars. For example, take a look at the Drupal 6 landing page and you will be greeted by plenty of information and many videocasts.

Drupal is not the first when it comes to community-driven marketing. The Typo3 Communication Committee and its members such as the excellent Daniel Hinderink are doing a great job in volunteer-based marketing. The Plone community is also following that marketing path.

Balancing interests of Drupal stakeholders

Drupal Association and Acquia, the VC-backed startup of Drupal lead Dries Buytaert, are the backbones of Drupal’s success. Both organizations are being lead by Dries, which is good, because it ensures a balanced strategy. In Dries’ own words:

Since the health and vitality of the Drupal project at large is extremely important to us, we’ve taken great pains to make sure that I am able to continue to act for the best interests of the Drupal community at large as I have done for the past 7 years.

Drupal marketing challenges

Sounds like the sun always shines in Drupal land, but there are severe challenges ahead for the Drupal community.

Let’s look at the issues from a strategic point first:

• Does the Drupal community want to grow? I guess so.
• How do they want to grow? I have no clue and did not find any public information or discussion yet. Do they want to appeal more to business professionals (e.g. system integrators) now that there is a Red Hat style support subscription for Drupal within eyespot?
• What are the means for growth? Drupal Association invests what they get from donations and sponsors. Apparently, they can raise quite some money e.g. for Drupalcon. Will they be able to raise money for marketing if necessary?

It is clear that Drupal needs to focus its marketing if they wanted to communicate to business professionals. This is presumably in the interest of Acquia. It is of course also in the interest of Drupal Association and all other members of the Drupal community, because clear messages will attract more pragmatists to Drupal’s Open Source market place – this is where the money is.

Some concrete suggestions from my perspective, which is somewhere between a visionary (I still feel young-at-heart) and pragmatist (I do have some experience):

The impression I have of Drupalcon up-to-now is: chaos.

The schedule was made available only two weeks before the event happens – much too late! A friend of mine who wants to meet with me at Drupalcon asked me a few days ago: “Sandro, I would attend only two days, which days would you recommend?” Well, I could not tell him, because there was no schedule available.

I was happy that I knew very early that my talk was accepted, but I felt uncomfortable that I did not know the exact day and time. Drupalcon is not my only concern, I have an open source marekting company to manage and some work to do myself. I rather book flights late, because some urgent work or customer meeting might require me to depart later or return earlier then planned.

Furthermore, I did not receive an email telling me that my talk was accepted. Maybe this is because the organizers told me in advance in private email. What about other speakers? Did they first hear that their talk was accepted from the various blog posts? If so, then I recommend that Drupalcon organizers don’t assume that potential speakers read their blog, because some people might simply not have the time to do so. Just send them an email and make all other necessary information available on the Drupalcon Web site.

Speaking about the Drupalcon Web site … too much information at too many places and not properly organized. The most important piece of information, the week at a glance schedule is even unavailable right now. Similar issues exist with the Drupal 6 landing page, which provides too much information and makes it hard to grasp the major benefits of Drupal 6 in ten seconds.

In fact, there is also important information missing or hard to find (at least, I did not manage to find it quickly enough). For example, how can I get an idea of the Drupal business environment, because I want to make sure that there is enough support I can get for money? There is a list of Drupal hosting companies, but that is only a fraction of all businesses. What about system integrators, media agencies, training providers, and so on?

Community-driven marketing is a mixed blessing

All of the above issues show that community-driven marketing can have its downsides. What looks like an highly dynamic community from the inside can easily look like a chaotic bunch of volunteers from the outside. To avoid this impression, Drupal marketing needs to better take care of the limited time available to professionals who “just” do business with Drupal.

This means two things:

First, at the top entry levels (e.g. Drupal 6 landing page), always provide only very necessary information. This information should help the audience to decide:

1. This is not of interest to me
2. I will take a look at this later
3. I want to jump right into it

Second, don’t mix up pull information (e.g. Weblogs) with push information (e.g. speaker confirmation), make sure you adhere to best practices, so that your audience is not being confused by unexpected behavior (i.e. there is no alternative to sending out speaker confirmation emails).

Wanted: Drupal marketing lead

Please, Drupal marketing volunteers, don’t get me wrong. I think you are doing a tremendous job, I think you stand out from the crowd and do your best with fantastic results. What you do need now is a marketing strategy as the basis for consolidation and a leader in Drupal marketing who thoroughly takes care of focusing the brand.

The saying goes that a good software developer can boil down 100 lines of code to at least a third, providing the same functionality with higher performance. This is what the Drupal marketing lead is supposed to do with Drupal’s marketing collaterals: Have her boil down information to a third or fifth to make the message clearer and Drupal marketing will perform better.

The tough part for the marketing lead will be to drive consensus among the Drupal community, such as picking the best slogan from a myriad of suggestions. Unfortunately, marketing is not like software programming. The wrong slogan will not throw an error if you run it, at least not immediately. The risk is that marketing-related discussions can last forever – with let’s say 20 000 community members having 40 000 opinions – if there is no accepted authority or biased skepticism against marketing amongst community leaders.

Mailinglists are quite useful as a part of daily project management. The way I use them at work is that I post rough ideas to the relevant internal mailinglist. Then my colleagues contribute with their ideas, comments and critique.

If the outcome of all the discussion is that we agree on actions and I am the one in charge to do and/or manage the implementation, then I simply group all emails in my Thunderbird inbox by the subject of the mailinglist discussion. This allows me to extract tasks from the discussions, which I store in the task tracker.

Now, I can keep track of every single issue by assigning each task to a category, giving it a priority, defining a due date, etc. Certain tasks might require some more discussion or consulting with other team members, which is done in the relevant mailinglists again – and this is where the process starts again.

In a nutshell, the approach is:

1. Post an idea to the mailinglist.
2. Keep the discussion going until a decision for or against actions has been reached.
3. Extract tasks from the discussion.
4. Discuss single tasks in the mailinglist if necessary (go to 1.)

Communication Skills

This seems to be quite simple and obvious, but in fact requires some sensitivity. The inital idea you post to the mailinglist, or the single task you want to discuss in more details, needs to be focused – otherwise you will end up with broad discussions that have no or too many results.

Then again, even a focused initial posting can lead to general questions. Either you moderate the discussion to become focused again, or you take up the raised issues because they might be critical, e.g. being a showstopper, or unclear responsibilities, or being of higher strategic importance.

As you are the one who raised the initial issue in the mailinglist, you should always feel responsible for the thread to be of value to others. Then you will automatically only post stuff which is important. On the other side, you can well invite others to help you become clear about certain problems if you got stuck.

Exchange of Information

Mailinglists are an excellent mean to distribute information within a team or even accross teams. In an ideal situation, they help to find solutions and make decisions jointly, something that fosters the support by each team member to actually implement his tasks.

The problem lies in a potential information overload, that too many people discuss too many issues in a mailinglist. The best way to avoid the overload is to apply the above mentioned communication skills.

As “overload” is also a subjective impression, it can help to learn how to quickly scan emails without reading them in details, to first spot whether they are actually of interest to me. The more subscribers are able to apply this skill, the more quality the conversation will get, as irrelevant postings will not get attention.

If in doubt, it is always better to have communication, even if too fuzzy and too much, instead of cutting it off. The question is how to canalize it in a productive way.

Other Channels

Of course, you can also apply the above said to other communication channels, e.g. forums or IRC chat. They all have their own characteristics though. A forum servers like a knowledge base automatically, similar to a mailinglist archive. Quite different compared to mailinglists, forums are not a push medium, but rather a pull medium, because you don’t get the information automatically to your email client’s inbox.

Open Company Culture

Using mailinglists as a part of project management requires an open company culture to be of benefit. This includes team members who are not afraid of telling their opinion with the risk to be challenged by others. In other words, they need to be adaptive.

In the end, being adaptive is the key of successful communication when implementing a project. Just remember that as a little baby, you were basically only able to screem. Today you can read (I asume so, because you read this blog) – and there’s always more room for the improvement of your communication skills. The main problem seems to be though, that most of us don’t remember the times when they were a baby and think that they’ve been born with ready-made communication skills

In a company based on hierarchical authority, it is much easier to have a strong opinion when you’re on a high level of the food chain. If you’re on a lower level, the problem is that you might be wrong or that your honest opinion might be something your boss does not want to hear. Thus, you act in an opportunist way and only say what’s mainstream in your company.

Knowledge companies cannot afford to have this kind of behaviour, they need everyone to have a clear opinion. Or put it like this: knowledge companies need to provide the freedom to their employees to have or form their own opinion and communicate it within the company.

An egalitarian organizational structure and predictable working conditions are thus a prerequisite for a successful knowledge company. They cannot afford to have the management rule by verdicts and fear. Instead, it needs to be trust and mutual respect, what drives the management to motivate the staff.
The more quality the opinions have, the better the decision-making within the company, and the more it can act realistically in the market.