Every time I see a multi core CPU I think Be Inc was right. :) Anyway, I think you should set deadlines. Arbitrary dates give the unfocused a clear limit and can keep people from straying to far off into speculative fun programming. I remembered the other day why I stopped writing applets for Haiku. While developing Alert I looked at the argument parsing and decided "there must be a better way". So I looked at getopt and getoptlong and decided they were the old way. And then got lost investigating rule based ways to specify how to pass and parse arguments and how to define an arbitrary chain of interoperating applets. And by the time I stopped I had wasted months. If I had a deadline I would have looked at a looming code freeze and been less inclined to wander. But take the middle ground. IMOSHO, after working as a Software Engineer for eight years ... Create a future branch so long term features can still be developed; without blocking the alpha and without it blocking more major works. Once a month create an Alpha Candidate. Set the 10th as the code freeze. Branch and accept only bug fixes onto that branch. Release an image on the 14th. Regression Test till the 18th. If it is usable then the observers on the list (like me) can run it and file bug reports. Then on the 24th, depending on the bug list and the release managers opinion, decide if the image was alpha quality. If it wasn't then create another candidate. If it was then build another images from the candidate branch with any specific fixes, regression test, system test and then all going well announce a release. This will keep people interested and on track. And demonstrate progress and give outsiders a month to test the candidate for bugs. Make the switch to the world's best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail