Scaling community support

Over at his weblog Earl Miles wrote:

The user base for Drupal has been growing exponentially, and even though the number of people who stick around and are willing to spend their time giving support are growing at the same pace, it's an exponential comparison, not a linear one. Which means the gap is growing. Compare the graphs of 10^n and 2^n. Where n = 1, 10 users per 2 support people, that is 20%. But where n = 8, that is 10,000,000 users and 256 support people, or .002% (give or take a decimal point).

I disagree with this assessment and the mathematical projections. I think that new developments, and not a growing user base, are the main cause for the quality of community support to degrade. Allow me to explain ...

To me, it looks like community support follows a Zipf distribution. If we apply Zipf's law to the Drupal documentation, it says that in a distribution of support requests, there is a huge number of requests for a small number of answers and a small number of requests for a large number of less common answers.

Applied to the Drupal handbook, this means that a relative small number of pages in the Drupal handbook, satisfy a large fraction of our users. People who don't find a quick answer in the Drupal handbook, might post a support request in the forums. Here too, Zipf's law applies. A huge number of support requests can be answered by a large number of people, and only a fraction of the forum topics can be answered by one or two people in the Drupal community.

As our user base grows, more and more questions get answered and more and more questions go unanswered. Fiddle with the parameters of the mathematical equation and you'll observe that as the popularity of support requests grows, their relative popularity remains the same. In other words, if Zipf's law applies to community support, the quality of support won't degrade as the community grows.

However, that is not what people perceive. People will focus on the increasing number of support requests that go unanswered and incorrectly conclude that the quality of support is going downhill. The truth is that, while we see more support requests, we are also successfully answering an increasing number of support requests. Thus, the problem is one of perception. As the user base grows, the long tail of Zipf's distribution becomes more visible ...

Clearly, these observations only hold for a static project. Drupal is a dynamic project as the community continues to add bells and whistles to the software. By doing so we introduce new support requests to the system. These new requests alter the relative popularity of the existing requests in the Zipf distribution, and therefore, can impact the quality of support. So what does this mean? It means that as long all developers do a good job documenting all the new aspects of Drupal, the quality of Drupal's support can only improve. It also means that if developers don't document new aspects of Drupal, or document them poorly, the quality of Drupal's support will degrade. At all cost, new developments and documentation updates need to progress at the same pace.

Anyway, my point is that (i) it is not the growing user base but the growing developer base that is to be held responsible and that (ii) the problem is one of perception because the relative quality of support can easily remain constant. Of course, perception matters a lot and it is not something we can ignore. After all, the (perceived) quality of support will be a key differentiator in the future. To solve the perception issue, we need to make Drupal easier to use so we can turn new users into contributors more easily. The lower the barrier, the faster you're an expert that can help others.

Comments

Dominik Lukes (not verified):

This is an interesting analysis but I think there might be a practical lesson to be learned from it, as well. I try to help in the forums as much as I can and as much as I'm able to. I can field many of the easier and more basic questions. However, it is sometimes difficult for me to slog through all the questions on the forums because it is not always obvious if the question is regarding something basic or more advanced.

Maybe it would be worthwhile adding another category to support posts regarding the level of difficulty or a self-assessment of the level of the person asking the question. It would then be possible to subscribe to the level I feel comfortable at through an RSS feed. The levels could be: New to Drupal, Administrator/Non-coder, Administrator/Coder, Module Developer, Core Developer. Or possibly there could be a category for the content: Looking for a module, Looking for a snippet of code, Module not working, Theme not working, etc. I know some of these already have a place elsewhere but they still appear on the Post-Installation forum which is very broad. Or maybe just adding an autotagging field to posts and display a cloud somewhere might be good. But maybe that would just make things even more complicated.

Dominik

December 7, 2006
ChrisKennedy (not verified):

Jakob Nielsen confirms the Zipf distribution in this insightful-as-usual article: Participation Inequality: Encouraging More Users to Contribute.

He recommends the following for improving the contribution distribution:

  1. Make it easier to contribute.
  2. Make participation a side effect.
  3. Edit, don't create.
  4. Reward -- but don't over-reward -- participants.
  5. Promote quality contributors.

In Drupal terms, this suggests that improvements to the development/testing infrastructure (api.drupal.org, project.module, installation system, etc.) could have a multiplier effect on shifting users toward more advanced contributions.

December 7, 2006
Amy Stephen (not verified):

Interesting observations, Dries.

Jakob Nielsen's research is good. Basically, he states that one out of every 100 people will seriously contribute. So, if you want another contributor, you have to increase your population by 100. (He has also found if you want 100 more people, enlist one more contributor.)

Which raises the question, how large can the social network before it fails to function adequately? Christopher Allen has great research on this question using the Dunbar number which basically states that due to the size of our brain, human social groups limit at 149 people.

And, that is the very maximum size obtainable in “survival groups” where members spend at least 40% of their time together in social grooming activities (speaking, listening, communicating, interacting) in order to maintain unstructured trust. Allen also goes into some of the abnormalities that present themselves absent unstructured trust.

I think the blogisphere is starting to evolve into a constellation of loosely linked "special interest groups" assisting one another and the nucleus spot (formerly the forums) focus more specifically on software distribution, sharing a directory of experts / community support possibilities and keeping information flowing freely.

Community forums are already outgrowing the Dunbar number and it our challenge to evolve into the next support structure.

December 8, 2006
Amnon Levav (not verified):

To improve the level of support, it's important to improve the social content of displaying the user's details in drupal.org's forums and issues. We should improve Drupal's forum and project managment mechanisms to allow to see some details about the user WITHOUT going to their user page. This is also the standard practice in other forums (Joomla, phpNN).

Some suggested fields: # of new posts, # of comments, # of (core) contributions, # of contributed contributions, picture, date joined.

December 8, 2006
Jansky (sorry, ... (not verified):

The issue of Drupal-users-asking-support versus Drupal-users-giving-support ratio is very interesting. To be honest I am not so skilled in statistics and I will not focus my attention on the choice of the best equation to describe such ratio, but on the problems related to the perception of a weakening support in Drupal community.

Before I go into further details I must say that I do not consider so relevant the variable “number of members” (please note I prefer the term “members” to “users”) of the community because, even if I pretty much agree with the theory of the Dunbar number, I think that it should be better contextualized: if in major size groups such as the ones built around MMORPG games, the subgroups (call them tribes, guilds, whatever) are rather small, the overall communities can become fairly big. So I would not parallel Drupal.org to the smaller guilds, but to the broader main group, in which you do not really need to have the same kind of emphatic relations between all of the members that you could reasonably expect in the subgroups. For instance the Italian photo4u.it digital photography community has to the date 12.950 registered members! Of course only a part is active, but it’s a common situation. The point is that there is a great activity going on, constant support and, most of all, constant informal learning going on for everybody. The subgroups do exist and are mostly related to the different photography topics (nature, architecture, street ...).

Let’s now move to a more general and theoretical approach: what are the key elements for a good sustainable “community of practices” which I believe Drupal is?

I would say that amongst many different variables the ones I would consider to be of uppermost interest are:

  1. Extent of the informal learning going on.
  2. Efficacy in cooperative problem solving.
  3. Personal gratification (check out the belongingness theory cited by the above mentioned Christopher Allen).

Forgive me if I will skip explaining the single items and their importance in detail. I’m already writing a far too long post.

Now I can finally get to the crucial point: what's missing in Drupal.org's support dynamics?

Well, I would say that in all the previous comments there are very valuable hints, but I am afraid that none of them would singularly be the solution to either a perceived or a real decrease in support, and I also feel that even if combined those tools would still represent smaller improvements. Let’s say that so far I have read good suggestions about tools to be used but there is also a need for a strategy, for a bigger picture.

I believe that what we are lacking in Drupal right now is the “social” side of the community meaning the empathy and the personal dimension. There are the Drupal meetings here and there, but they represent a chance to socialize for a far too small part of the community.

I think we should foster a more informal and personal touch in some way: dedicated forum threads, events on line, name it!

And there should be a system to give positive feedbacks (the reward and promote ideas proposed by Chris?) to those who contribute most. A very simple tool is to create the figure of voluntary moderators in the forum sections and to set up a system to diversify the status of members relating it to their contribution to the life of the community.
To finish I will also put my little contribution in the “suggestions box”:

I think that a better support could be fostered also by structuring specific forum threads related to the single modules. It would reduce dispersion of Knowledge and make it a lot easier for those looking for specific solutions to find them!

Anyway, we are talking of how to keep up the good work, not really of how to solve a crisis, so… cheer up! Drupal.org is still one of the strongest points of Drupal.

December 13, 2006
Jan Lai (Post S... (not verified):

... and this seems an interesting post on the matter: How to build a user community, part 1

December 15, 2006
Bockereyer (not verified):

Less is more. Growing is a good thing but for me there is something like "growing to death". Many modules are great in functionality but lack documentation and support. Sure the contributor is proud of his achievement but I understand that he lacks time to write documentation and to give support. The best placed person to provide this is the contributor, after all he knows his brain child best. I prefer less modules but better documented and supported. Not every member/user is a php-programmer. Nothing is so frustrating than abandoning a marvelous product due to unsatisfactory support.
I would suggest that modules are rated for quality, security, documentation and support.

December 18, 2006
bertboerland (not verified):

No, less is less! Not more or less. Saying "less is more" meaning "less is better" means one still thinks "more is better". Which doesn't have to be the case and which I think is your point.

I only recently read The Paradox of Choice: Why More Is Less which addresses this issue in a very good way.

December 19, 2006

Add new comment

© 1999-2014 Dries Buytaert Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License.
Drupal is a Registered Trademark of Dries Buytaert.