Creating a community is a tricky business. Think of it instead as finding and nurturing a community that can naturally exist around your software. First of all, take a hard look at whether your software lends itself to an open source structure. You should be able to answer "yes" to the following questions:
- Will the software be used by people who will interested in either improving the code or having some influence over its direction?
- Will those users have the skills ncecessary to contribute successfully to the project?
- Can you structure your organization in such a way that participants will be encouraged to contribute?
- Can you maintain a relationship with contributors that makes them feel they are truly a part of a community (as opposed to free labor)?
If you answer "yes" to these questions, then your software is a good candidate for open source. You also need to be sure of your reasons for starting an open source project. If you're just looking for free labor to reduce costs, then you will be in for a surprise. People don't take kindly to that attitude, and it's likely to show. Management of an open source project frequently takes as much time and effort as a proprietary product, if not more. If your goal is to speed adoption of the software, and you fully recognize the effort you need to put into it, then you'll be in good shape.
Next, clearly define the structure. Who has final say over the code and the roadmap? Who owns the copyright? What license will you use? It's a good idea to create a non-commerical organization with clear rules on roles, code submissions and copyright assignments. Don't forget to appoint a press contact who will respond quickly to requests; this can make a huge difference in whether you get any free promotion.
Be prepared to compromise when you open source the project. If you can attract good contributors, then they will certainly have their own ideas. You will need to walk the fine line of accommodating them while serving your own goals. Having a clear structure will prevent (almost inevitable) problems in the future, and having that structure be non-commercial will ensure that participants don't feel like you're just looking for free coding.
I am assuming that you plan on making money from your association with the open source project. In that case, I advise you to make sure you have fully developed your business model. Will you be offering support, customizations, proprietary add-ons? Make sure you have considered that under most open source licenses, a competitor could fork the code at any time. Part of your relationship with your community is to try and prevent anyone from feeling an incentive to do so.
And finally, to answer your question about breaking out of the Catch-22: building a successful open source community is all about relationships. Large companies have offered up very well-known proprietary products as open source, and I didn't see any rush of developers jump on the projects. So developer awareness is only a part of the picture, and not the most important aspect. My advice to you is to contact users or potential users of your software. Tell them you are thinking of releasing code as open source, and ask for their opinion. This is the best way to measure your potential for success as an open source project. And if you decide to go open, work on establishing relationships with users that might participate. Many open source contributors start by submitting bug reports, patches then gradually more. Start establishing relationships early.
This was first published in February 2006