The itch you started scratching some time ago has taken you on a strange and exciting journey so far: you’ve polished your code, picked an open source license for it, released it to the community, and even devised some ways to earn some money from it. It may be earning you a little bit of supplementary income, but you’re sure it has the potential to become a full-time job at some point, if only you could make more people aware of your product–after all, if your itch was worth scratching it’s probably annoying a lot of other people too. This is the point, in other words, where you have to give some thought to marketing your software.
Sell Your Service, But Market Your Product
In the most general sense, marketing an open source product is similar to selling any other product: you find a niche in the marketplace that isn’t being adequately served by the available offerings, and you make your case to that audience. The big difference in this case is that while you’re selling a service (e.g. support, customization, training, etc.), you’re marketing a product. Go back and read that sentence again, I’ll wait. The focus of your marketing efforts needs to be on the utility of the software itself, despite the fact that your business model derives no direct income from software sales.
Free Shouldn’t Mean Inferior
The challenge, then, is to get the word out there about your shiny new application, and get it into as many hands as possible. The good news is that “free” is a very attractive price, and it removes one of the key barriers to adoption as far as customers are concerned–they’re likely try out a free app that promises to satisfy their needs because there’s no up-front risk involved. That counts for a lot less, however, if your software is hard to install, has limited documentation, and has a confusing interface. Customers will typically prefer to pay money for a commercial application that’s easy to install and use, so don’t think that “free” by itself will always win the day.
To put it another way, “free” is most attractive when all other factors are close to equal. If your software is as good as (or better than) the leading commercial application in that space, then yes, your price point of zero is absolutely a selling point. But if you’re only offering a small subset of the features people are willing to pay money for, the value proposition falls away. At that point customers no longer see a bargain, they see an inferior product being given away.
To stress a key point here, don’t let yourself fall into the trap of thinking that because your application is free it doesn’t need to be as professionally built and polished as a boxed commercial application customers can find on store shelves. “Free” shouldn’t be a compensation for sloppy code, poor documentation, or missing conveniences that customers are used to from commercial software. That’s the sort of thing that gives open source software a bad name, and leads its detractors to quip that “you get what you pay for.”
Hitting the Big Time: Linux Distributions
Speaking of store shelves, though, it’s unlikely that your software is going to end up in a retail outlet–or even in a box, in most cases–unless it ends up getting included in a bundled Linux distribution. For a lot of open source projects that’s like winning the lottery, since your application gets put on CDs and DVDs and downloadable ISOs, and the installation process is managed for you by the distributor’s package manager. To a point, even some of the marketing gets done for you with the distributor’s package selection tool, which shows customers a blurb about your application at install time. It benefits the distributor to have a lot of attractive applications in its bundle, since it makes the bundle as a whole more valuable to customers, so the distributor has an incentive to make your application sound like a real bonus.
The hard part, of course, is getting your application noticed by a distributor like Red Hat or Novell or Ubuntu. Often these distributors have a suggestion box or a link people can use to recommend the inclusion of a new application, but they would much rather hear about your software from actual users. They want evidence of popularity first of all, so it’s a bit of a Catch-22. If you want to demonstrate grassroots support for your application, ask your users to nominate your software for inclusion in a distributor’s bundle; quite often happy users will do this as a kind of small contribution to the project, since it costs them nothing but a few minutes of their time.
Distributors also prefer that you be fairly stable, not likely to vanish after your 1.0 release, so it helps to have an established track record. The longer your application has been out there–and actively maintained–the better your chances of adoption are. Be accessible, too, either in a web forum or mailing list that can be used as evidence of interest and activity about your project. Mainly the distributor wants to know that your software is going to be around for a while and that you’re going to handle the maintenance responsibilities. Remember, the distributor is making promises to its customers, and if you drop the ball they end up having to clean up the mess.
You may also run into licensing issues with a distributor, depending on its policies. Debian, for example, includes only applications that it deems to be “Free” in the Free Software sense of the word (as opposed to free beer), so unless your application is licensed under the GPL (or a GPL-compatible license), you’d be better off spending your efforts elsewhere. In a more general sense, choosing a license that’s well-known and well-established makes it easier for a distributor to decide whether your app can be included with the rest of its bundle. If you devise your own custom license (or customize an existing license) to suit your needs, understand that a distributor would need to have its own legal counsel examine your license for compatibility with the rest of its licensed offerings, so you add more hassle to the process.
Until the happy day comes when your application is included in popular Linux distributions, you might consider hosting your project (or at least a project summary) on an open source development website like SourceForge. This can save you a bit of money on hosting costs, bandwidth fees, and provides a large network of mirrors around the world to help your customers get ahold of your code with minimal hassle. It also hooks you into a marketing framework, where your project becomes more visible and could be featured in one of their newsletters or on their site as a Project of the Month.
Don’t neglect your own website, of course–it’s your passive marketing tool, a way to convey to prospective customers that you’re professional, and that you’ve got an application that can scratch their itch just as it scratched yours. Gather user testimonials and case studies, and focus on solutions. Include screenshots and maybe even a walk-through example if it’s appropriate. Make it easy for new customers to download and install your application so they can try it out for themselves. Try visiting your own website with fresh eyes as a test, and ask yourself how likely you’d be to download the software.
Box? What Box?
In the end, just as the open source concept breaks many of the rules of conventional business, marketing open source software often means thinking outside the box. If you’re at a loss for creative ideas, Jay Conrad Levinson’s classic book, Guerrilla Marketing is a good place to start. Indeed, the guerrilla marketing concept suits open source projects very well, with unconventional approaches that generate buzz without huge outlays of cash for advertising. Attend open source conventions, and conventions related to your application’s market. Write articles for magazines, websites, and blogs about the subject you’re so passionate about. A little self-promotion isn’t a bad thing, and you can do much of it without spending a dime–free beer, with your logo on the glass.