Open Source Projects Must Market Themselves Better

The open source community is rich with alternatives for any need or framework you could possibly need. It is a veritable cacophony at times. While this richness is great, it can be a challenge to get your project adopted by developers.

This also presents a challenge for those architects and developers who are shopping around for a framework to solve a particular problem. Most projects have a web site somewhere (CodePlex, SourceForge, etc.), with a list of bugs, releases, notes, etc.

Most of these project pages have only a short description about the project. That description was likely written at the very beginning of the project when it was just a simple idea. The description is usually outdated, and never updated as the project moved forward.

If I am an architect/developer browsing your project site, and I see something that is vague, and hard to understand, I won’t likely check out your project. After an hour of only seeing poorly marketed and documented projects, I am likely to not choose any framework. That’s not a good outcome. Downloading, compiling, and playing with more than a few frameworks is just too messy and time consuming for an architect that needs to ramp up on a particular space, and make an informed decision on how to move his own project forward.

You need to market your Open Source project like any other product on the market.

Open Source project leads need to market their project, and help people understand why they should use your framework. If you are a persistence framework, you have to make that clear. You have to describe what your tool is like, and how it works (at a high level). You should also define what is required to use it (.NET 2.0, certain tools, etc.), and also what the process is for leveraging it in the developer’s project. Your site should also include walk through’s, perhaps webcasts around how to start a project with it. At a minimum, include some diagrams or screen captures. Let me know what I am getting.

If you really want to knock it out of the park, link to or provide information as to why you need to do what the framework does. For example, if you have a DI framework, provide information on when and why DI is a good idea. You could also link off to some resources that will educate the reader on DI. Informing that user will help them understand why they should use DI (in this case), and know why your particular framework is a good choice.

I had this discussion with Nate Kohari from Ninject at a Day of .NET a few months ago. When he released a new build (congrats!), he updated his site to help the reader better understand what Ninject does, how it is used, and how it differentiates itself from other frameworks.

Your project site doesn’t have to have fancy design like Nate’s (but that is great if you can), but it should include this basic information.

You need to make it easy for a visitor, within a few minutes, to understand the value of your project, and how to get started.