So each release can have a structured number to please the geeks and a high number of please the marketing people.

So many bad open source projects come from the author underestimating the work in making a project work. It's easy to think "hey I wrote this, somebody gotta find it useful" It's a huge amount of work to make it an effective project. And you have to ask WHY you want to do this - it's a similar amount of work to making your software a viable commercial prospect, which would have the added benefit of putting food in your cupboard. His suggestions are a good start, but in this day and age you need to do more. For example, you really need video tutorials of your software. And once you start putting them together, you start to see more shortcomings in your software, so you stop the video, make some coding improvements, and continue. This is a long process! A lot of people think "hey, when people see this, I'll get contributors to help me" But if you really want things to work out, you need to project manage the contributors. Everyone has their own priorities, and the project lead needs to get everyone working in the same direction. And you've got some tough decisions. If someone sends you a useful patch that's lacking in tests and documentation, what do you do? It's a pain to reject it, but a pain to accept it too. What the project really needs is leadership, and that is a massive commitment.