Marketing an Open Source Product - The Product Literature

Marketing an Open Source Product : The Product Literature

It’s a poorly understood aspect of the Open Source (OS) world that marketing actually matters.  I know that we all really want our code to be appreciated for its elegant perfection but such is not always the case.  Marketing greatly helps an OS product to push beyond its initial user niche into a larger and more diverse group of customers.  In this article I’m going to talk about marketing for an OS product and specifically the Product Literature that you need.

Note: This article was inspired by Dries and the Drupal project, one of my favorite OS projects.  I made the mistake of commenting on their marketing recently and have now been pulled into a) documenting the process of product literature and b) helping to write the feature list.  [AD]Drupal is an OS community platform with an absolute weath of features – blogging, discussion forums, themes, taxonomy engine, analysis / statistics tools, caching and more.[/AD]

What is Marketing?

As I’ve cited in prior essays, marketing has this definition:

Marketing is the creation of demand for a product or service.

What is Product Literature?

Product literature is a set of written materials that help a “purchaser” make a “buying” decision.  Now since we are talking about open source here, there is not really a purchase decision but a committment decision.  No matter, product literature is still important.  So what kind of product literature is there?  Here are some of the basic types:

• Feature List.  A document which lists all features in the product.  Should be hyperlinked to more detail where appropriate.
• Feature Tech Note.  A detailed look at a single feature.  Think about security for example.  Security is too complex to be really addressed in a feature list so you write a fewature profile which talks about it in depth.
• Case Study.  An example of how a particular customer has solved a particular problem with the product.
• White Paper.  A detailed look at the product.
• Application Profile.  An overview of how to use the product for a particular application.

Now what types of product literature do you need?  How much product literature do you need?  Here’s a simple guideline for creating product literature:

The amount of product literature you create should be in direct proportion to these factors:

• Price.  Oracle has more product literature than Microsoft Access.
• Complexity.  Drupal has an absolute buttload of features.  Therefore it’s going to have a lot of product literature.

If you have an open source product that does one thing, say a utility, then you may need only a feature list.  But if you are building a larger product or, worse, a platform then you need a lot of product literature.  A lot.

Writing the Feature List

The problem that Dries confronted me with was writing the feature list.  Here are the guidelines I gave him:

• Break your feature list into categories.  You don’t have 1 feature like web server support.  That’s a platform group of features along with db independence, etc.
• Organize your list of features the way users care about it. The first isn’t Apache support (although what you had was alphabetic which is understandable)
• Write your list of features in a way that people that aren’t engineers can understand.  Express things in terms of benefits.  Example: Database Abstraction Layer isn’t a feature.  Support for multiple databases is a feature.
• Within each category of features put the most important features at the top – unless you are alphabetizing and that’s very clear.
• Link each feature to more details.   Linking to the documentation or FAQ is fine if there isn’t a feature tech note.

I’m currently working on a before and after version of the Drupal feature list based on these guidelines but I haven’t had the time to get back to it.  If you want to see the current drupal list, [Click].

This Page was last update: 4/6/2003; 3:13:57 AM

Copyright 2003 The FuzzyStuff

Theme Design by Bryan Bell