While a good idea, I also question the viability of such a project. It would only make sense in an academic context where the rationale would be to teach operating system concepts, queuing theory, network optimization, etc. But in terms of developing an OS for real use I'm afraid such a project would be dead in the water for the reason that there is no existing itch that it would solve viably. Building an operating system is not a trivial thing in terms of architecture, development & testing. You also need to consider things like applications that will run on said operating systems. It has taken Unix, Linux and Windows 30+ years to refine. There are many attempts to build yet another operating system that have died by the roadside. It would make much more sense to build from existing work (Linux/BSD) and either identify a need that has not been satisfactorily met by existing work or identifying something that could be improved and working on that (e.g. file system, network stack, scheduling algorithms, etc). I know techies are HEAVILY disposed towards coding but this is one project that requires a lot more ground work. On Mon, Oct 19, 2009 at 2:07 PM, Mworia Wilfred Mutua <wmworia@gmail.com> wrote:
IMHO...
Nice idea, the challenge in itself would be good to bring together tech geeks to build something worth it. I've had similar concepts from others as well. A few caveats however...
For people to commit requires that an individual sees value return. The most obvious here is financial reward. Good motivator. Otherwise people tend to scatter, you can't keep consistency and without that project may very easily fail.
For commitment you also need a centralized controlling team. I'm not suggesting a totally centralized approach as with proprietary dev but I think it is important to have a holding center and then other devs can come and go as they wish.
Secondly, why fragment (yet again)??? Why not get a team to work on an existing solid OS? - Ubuntu or PCBSD would be great, both have great direction and have sustainability. Or perhaps a hybrid approach, start something from the ground up, but commit to an existing body of code for whatever problems you solve that are shared with the other OS.