This isn’t tested research- just a gut feeling, but after watching several open source software projects grow or go bust- I believe there are some key factors in successful open source software projects- and they parallel marketing issues for other projects.
There are an overwhelming number of tasks for a software project to succeed, typically requiring a dedicated core team. This is the basis of open source- in that the core team can be as large as there is interest. A lot of people use or have need for your project- a lot of different people get involved. However- depending on the type of project you are working on- you may not get a good cross pollination of talent. Coding geeks often have narrow skill sets- that can leave some critical parts of the development process lagging.
I’m going to try to outline some key areas for you to consider:
Installation ease
After having struggled with installers for several open source projects, I can’t stress enough the need for a stress free install. One of the key WordPress early bragging lines was a 5 minute install process. Even after doing many installs of the early versions manually- I wouldn’t call it a five minute install process for the non-geek.
The inclusion of your open source project in a software installation script wizard early is key. This improves the likelihood of sampling, adoption and even awareness.
Some installation script packages are : Fantastico, Installatron, Softaculous, SimpleScripts.
Including data import tools from your main competition was also a brilliant strategy employed by WordPress - making it easy to import from other major platforms like TypePad and Blogger.
I’m also going to venture to say that worrying about installing on Windows or Mac servers should be a non-worry for open source projects- if you don’t run on Linux Apache MySQL PHP (LAMP) you aren’t an open source project.
User Interface
It wasn’t until WordPress turned 2.5 or so that a User Experience design professional (or User Interface) was engaged by the core team- with usability being a key factor in the early success of WordPress- the dev team probably felt they had it covered. They didn’t.
The success of open source projects requires easy adoption- which means intuitive interfaces should probably be a key focus.
Documentation
Too often, it’s code first- and worry about documentation later. Or let the users write the documentation for you in true open source fashion (FLOSS manuals come to mind) after you code and release. This may be the biggest failure point- unless your user community is so large- all answers are just a google search away.
Instead- consider the documentation the true road map of the project- starting with a manual outline may save your project a lot of problems because if it’s too hard to explain- it’s probably too hard to use. Clear goals and directives on where the project is going can make the going that much easier.
Think of Stephen Covey- “Start with where do you want to end up” and the path will seem that much clearer to all.
Versioning- Releases
There are two schools of thought to release cycles- fast and furious, as soon as a new feature is ready- ship, and a more ordered process. While the fast and the furious may keep the geeks happy- it plays havoc with those involved in implementing and maintaining it in a business environment. Explaining to your boss why you had to update the software 6 times in one month can be a bit difficult. Only release serious bug/security patches like this.
Set a release schedule, with milestones and stick to it. Mature packages do this.
Standards
Adhering to industry standards is critical. If you don’t, you risk being marginalized. Take accessibility, microformats W3C standards seriously- and don’t mix open source with proprietary code (ever). Standards are the way to gain a solid foundation of functionality- no matter how dumb you think they are- they were set by a whole bunch of people and that’s what you need to be successful.
Architecture
There are three areas where WordPress got it right- and then perfected it- and they got is by studying Mozilla.
- Updating- a one-click internal updating process will guarantee the largest number of updates and less compatibility issues. If it’s hard to update- you’ll be fighting a versioning compatibility hell. Mozilla doesn’t even give a choice anymore- the updates within a major release are mandatory.
- Extending- again, WordPress is a model of success. Both themes and plugins are maintained in a central repository with ratings, reviews, bug trackers, FAQs. If you hope to have a large community, you have to grant easy access to your user base.
- Customization of interface: While plugins and themes are great- and allow for infinite tweaking- the fine control of an interface using AJAX may be the ultimate brilliance. Users like easy- and reordering a UI via AJAX is the true WYSIWYG experience. I can’t think of any technology that makes me as a user happier in using software.
Of course, you’ve separated content from presentation, built in search functions, RSS feeds and paid heed to what makes Web 2.0 what it is.
Community support
The size of your installed base will only grow if you make it easy for them to connect and work together. If you don’t have a well moderated and managed forum you are doomed. Unanswered questions, spammers, and the same question asked over and over are good indications that your project isn’t on track for greatness.
It’s also impossible to move forward if you don’t have a good handle on what your user base wants.
None of this is done in a vacuum, and there is nothing wrong with empowering people to make a living with your product- enable some kind of rating system for your contributors as well as a donation system, reminding people that even small donations are key to keeping the project going.
Even if you don’t agree with an approach taken by a plugin developer- don’t ostracize them or their methodology- build bridges not walls, and look at the communities acceptance of their project. WordPress alienated a coder named Dr. Dave who had developed an open source Spam solution that competed with their own Akismet- eventually forcing his Spam Karma II plugin into deprecation.
Marketing
While the project may be open source- and the software is free- you still need to make an effort to get your product name out and to let people evaluate it.
If you have created your product to replace something you feel is inferior- make sure you find some bloggers to do some comparison reviews. If you are in a brand new space- get some press coverage- and ask thought leaders to evaluate your business model. Google started out with a great service- but had no clue of how to make money until Bill Gross came along with his idea of sponsored search. Who will give you the impetus to get your strategy on track?
In most cases there are people already evaluating options in your field- make sure to reach out to them and get some press and ask for assistance to get the project seeded.
Your project website
I’ve been evaluating Customer Relationship Software (CRM) packages for a while- in fact, it’s what got me to write this post. The difference between packages- and what they do, is key to your business model and where the user first decides on if your project will be a viable option.
There are some critical things you must have in order to put your project on par with your competition:
A feature list- even a comparison to your competition. There are no secrets- if you don’t do it- someone else will. As a developer you should know who your competition is better than the others- and in Open Source- the idea is to create the best version possible- not ownership. Cooperation and integration with other projects should be the goal.
The SugarCRM vs vTigerCRM split is interesting- and why the two forks can’t work together more is embarrassing. One is targeted toward enterprise the other toward small business- there should be no need for acrimony.
The real competition are the closed source companies - that develop slick products that might lock a user experiencing great growth out of needed features. This is where we have to decide which platform makes sense as users- do we go with Salesforce because it’s a leader- or do we invest in an open source project because it will give us ownership of our business model?
Look at the closed source/proprietary software sites- you see an intro video on the home page, a clear feature set, support options, cost of ownership information, user testimonials and case studies, user forums, tutorials, documentation and even a blog- if you don’t have a site that answers questions about your project- you will end up relying on someone else who may not fully understand why your project exists.
If you want to see a comparison- look at the open source Ruby on Rails project- FatFreeCRM site- and then compare it to Highrise a commercial product based on the same technology. Of the open source sites- Feng Office may be one of the better front ends- simple, clean - not confusing. Compare it with the Magento site- which you’d almost not know was Open Source.
Getting paid
While Open Source software is free- there doesn’t seem to be any reason not to build a way to get paid into your model. Google makes a lot of money with a free service- there is no reason why your code expertise shouldn’t be able to support you. The current model seems to be offer a free unsupported code base and have a hosted, supported version in parallel.
While this may support a small core team- what about the rest of the contributors? Think about your project as an ecosystem that requires both user and developers and build a community support tool that will give your experts the ability to generate revenue from their work. After all- maintaining the pace of progress can have a toll.
I’ve yet to find a project that has built a system- for instance, WordPress has been through several rounds of venture capital and Automattic now owns a bunch of other properties- there should be some kind of revenue share for the most popular plugin package developers. They’ve done a good job of allowing premium theme and plugin developers into their hub- but, there are still people working for love on what has become a decent sized business.
Google and Amazon have both built in opportunities for the small guy with affiliate systems- this model should be integrated into any open source development project.
The structure of cooperative software design sites
While the developers can talk endlessly about the advantages of codebases like SVN, GitHub, SourceForge, Google Code etc as repositories for code in development, the real problem may be that what is needed is a CMS designed for software collaborative construction and deployment.
I’ve seen software communities use all kinds of tools for their own hawking of wares - Drupal, Joomla, are the ones I notice first- yet it seems there is still room for a dedicated package to handle all parts of a successful open source software project.
Learning how to do it right
One of the things I’ve been searching unsuccessfully for over the last 2 years is an institution of higher learning that is actively teaching how to build and manage open source business models. I’ve found lots of places willing to share their courses- led by MIT opencourseware there are more and more universities offering classes you can audit classes from your home- but, I’ve not found a collegiate program focused on this growing business model.
The University of Advancing Technologies has an “Open Source Technologies” program- but it doesn’t mention the business side of the equation in the description.
For Students looking on how to get involved in Open Source Projects- see this post: http://stackoverflow.com/questions/2151999/how-to-get-started-in-developing-student-opensource-projects
If anyone has any information to share- please include it in the comments.
Some resources:
Here is a link to an academic paper I found when doing some research on this subject:Defining Open Source Software Project Success PDF
Found a short list on being successful with Open Source software: http://jwage.com/2011/02/28/tips-on-being-successful-in-open-source
A post about Open Source Business models- and a case for Open Source vs. Proprietary software: http://window.punkave.com/2010/09/16/open-source-business-models/
A kinda snide “Top 10 Reasons I won’t use your open source project”
An overly corporate post from Vmware on “Open Source Governance”- http://olex.openlogic.com/wazi/2009/create-an-open-source-governance-process/ Written in 2009- it has zero comments- but, the part about the code license checkers is interesting and a part I left out.
Check into this FAQ on Governance by FOSS Bazaar https://fossbazaar.org/openSourceGovernanceFundamentals
If you find others- again, please contribute in comments.