Thanks for the inside thoughts. About 1) and 2), these are things I was looking for and I hope they may be put into wiki, so all the users and developers will understand it and stick on it. Some additional thoughts: a) What's the definition of the versions with odd number, like 1.1 and 1.3? Reserved for dev or same as even number? b) About the major releases, my personal opinion is, please try not to put all new fancy features into one version and release as early as possible once a feature is ,completed and tested. If a huge change affects all the modules and need significant time to develop and test, it might need a new project version number (major number). c) Stable releases with same major/minor number do not have to be strictly limited to bug fixes only. They may contain small improvements as far as the new version is a drop-in replacement to the old one, say, not breaking any existing installation. In this way, it will save some minor numbers for really big features. I believe in release early release often. To me, if I don't see a new version released in two years, most likely the project is dead. About 3), I'm a little confused about "release branches rather than tarballs" part. For me, each release has a version number and refers to a static point of the repository. A branch is just for developers to organize patches and can not be released to any one. I think if a software has easy installation and excellent compatibility, a user will have no problem to upgrade it. Anyway, if there is a bug, he has no way but to patch it. I think the best way to reach an audience is to build package binaries, deb, rpm and exe. About 4), I completely understand the concern and actually had similar feeling in some projects. The way I did/does is, I put everything to wiki if it doesn't fit a code comment. Everything is build-able by scripts and built automatically by cron. When there is a new comer, I ask him to review all the documents before he asks any questions, and add the answers to new questions to the documents. For anything new that affects other developers, there should be a document base upon the agreement, so it becomes an idea of the project instead of an idea of somebody.