A few things you can do:
- clarify your role within each project. Just because you open sourced the code does not mean you opened your schedule.
- lower the barrier for contributors i.e make sure
- you have a clear roadmap listing the major milestones. What has been accomplished and what needs to be done.
- review your HOWTO guides for contributors
- clear instructions on how to install and develop locally
- review and simplify your codebase
- pick technologies that are more likely to attract contributors
- have small tasks identified either in the code or the site that anyone can take
- be very responsive to discussions about patches and encourage them
- get to know your users (the ones who log issues). Maybe you are not targeting enough users with the right skills to make changes?
- raise awareness of the work being done and the stuff being requested e.g Here are out top issues, or most viewed bugs or most commented discussions.
code patches are not the only type of contribution. Identify other roles in the project e.g bugs triage, marketing, packaging, testing new releases, forums etc. and again lower the barrier
continue your efforts in attracting more users. Contributors will be a small percentage of that user base
- start measuring the installs, usage, traffic etc.
- add a website and make sure your install, configuration, requirements etc. are well documented and actually work on all supported platforms
- focus on users who provide feedback and have skills. They are the most valuable resource.
It all depends on what you want and how you envision your projects.
Also, review the language and tone. People can sense if you are aiming small or big.
Finally check the alternatives and related projects. What are they doing right? or are they struggling in this area too?
Two excellent books to check out:
- The art of community
- Producing oss
