Here's a few notes from my experiences of open-source projects.
There needs to be an "owner." This can be more than one person, but no more than a handful. The *only* authority these people have is when it is crunch time for a decision and the rest of the community cannot decide (split vote or such) so because of this, keep it at an odd number..

being democratic can help.. voting for members of this "board" etc.
Their responsibilities include:
Maintenance of repository. Does everything work? Does everything have tests? Is there anything that needs trimming (of "fat")? Resolution of disputes/disagreements/non-agreements (see above)
Otherwise the project should remain completely open, any one can contribute, any one can check-out a copy.
I highly suggest that there be two repositories. One for incoming changes, that can be reviewed and then merged with the "real" repository which will contain releases. (A simple branch in SVN for this.)
This will allow for submissions from those that are not so confident, without the risk of 'ruining' an entire revision of the project. Everyone has done it before.. submitted something they didn't mean to, or forgot to run all tests before commit and finding out something broke elsewhere in the project because of what they worked on, or someone else updates to find a change they are not in agreement with, etc.
For managing the project progress and so forth, I highly recommend
KanBan which, when summarised, simply means you have a prioritised list of objectives/MMFs (Minimally Marketable Functionality), and you swarm the MMFs in progress (and have a hard arbitrary limit of the number of MMFs in progress.)
It's also important for everyone on the project to realise and remember: Criticism isn't personal.
Good luck chaps.
