Maybe its just me, but lately I've noticed that many open source projects are out-marketing closed source companies. This is interesting because open source projects typically have no marketing teams, just a few engineers. Last week I was looking for a collaboration package to run on my startup's intranet. We want to share documents like PRDs and specifications, allow comments, and host blogs. I compared two options - microsoft sharepoint server and wordpress. Sharepoint server was attractive because we are running microsoft active directory so the authentiation would be integrated. Wordpress is well, free. There are lots of other alternatives, but these two illustrate the point. I wanted to get a quick feature comparison - typical thing you'd expect most potential customers might want to do. Like everyone else I start with Google and type in two queries - "wordpress features" and "sharepoint server features". I click on the first links that seem relevant on the first page here and here.
The wordpress page gives me one page of HTML that's easy to read in about two minutes and addresses the actual features of the product. The Microsoft link forces me to navigate a maze through several links before I'm presented with a link to a word document, which I then need to download and launch word. Then I need to weed through a 69 page long document to find the 1 page of features I want. The first 13 pages of the document try to convince me that I need to "Get started quickly" and "Collaborate Easily" - basically to convince me that I need a collaboration platform. As if I happen to be browsing the sharepoint server site for fun or something. And the requirement to have Word installed is a nice touch that says "We want to ensure anyone that is not already a customer never becomes one". In contrast the open source sites I read tend to provide fast and easy access to the information I want and broad platform support. When I'm evaluating a new piece of software or hardware I want to know four things:
1. What features does it have?
2. What's it going to take to get it running?
3. How much does it cost?
4. Who else is using it and what do they think of it?
I don't think IT departments evaluating products are much different. What proprietary hardware and software companies are getting wrong is they have forgotten who their customer is, they are not valuing the customer's time, and they don't understand where in the decision process the customer is when they arrive at the product website. Instead of giving me answers to the above questions, product literature tries to sell me the benefits of the general category of products. That's silly - especially for a product category like blogging software that everyone that hasn't been living under a rock already knows about.
What open source teams understand that many big proprietary software and hardware companies don't is the following:
1. Sell features, not benefits. Yes, this is the reverse of what you may have learned in business school, which probably explains why open source marketing is better - its written by engineers! Selling benefits is fine if you're selling a product or feature the buyer is unfamiliar with, or one they haven't decided they want. For most tech products the buyer is a technical person who is already convinced they want the category of product. They wouldn't be at your site if they didn't already want the type of product you're selling. Second, you're talking to another engineer, not a clueless consumer, so you don't need to explain the benefit of every feature - they already know. The only times to talk about benefits is when discussing the unique features of your product, which are going to be a very short list. Occasionally you may be selling a completely new category of products that no one is familiar with, and you have to explain why someone would want that category of products. Again, this is very very rare. One of the reasons why open source companies get this right is the engineer that wrote the software also writes the collateral. The moral is - the writer must be technical and understand what the buyer is interested in.
2. Keep it short. Each of the questions above should be addressed in 1 page of html, no more than two 15" screen lengths long. Expecting anyone to read a 69 page document to get a feature overview is just plain stupid. To keep things simple and short, ditch the document-by-committee method of creating documents that enterprises use - this leads to long meandering drivel. A document should have exactly one author. Editing is fine, but editors shouldn't try to word-smith the document.
3. Make trying out your product easy. People like to test things before they buy them. Most open source packages I've used from Linux to RubyonRails are dead simple to install, run on everything, and they're free to test out. Contrast that to most proprietary software which runs on 1 platform and is crazy hard to install due to lame downloader tools, poor compatibility, and broken DRM. The culprits are too numerous to name, but the guilty include Java and everything Microsoft.
4. Position yourself against other products. Potential buyers are interested in comparisons. Your literature must answer the question "how is this better than the competition?". This is also known as a positioning statement. There's no need to name the competition, but your feature list should highlight why your product is better. One of the best examples of this I've seen is the RubyonRails.org. Right up front in bold letters it explains why a prospective user should try Rails. Lets compare that to Sun's java developer site. Lots of words, but no reason why I should use Java. So, I don't.
5. Integrate testimonials and community into everything. Prospective users should be able to quickly get to a list of other users, see real testimonials and see what users are saying on other sites.