So, you want to develop a small operating system, then it starts to be popular and suddenly you are overhelmed, running short on time and eventually you close up shop. What happened?
Well, if you are like me what happened is:
- You attempted to support everyone’s machine; at least everyone that wanted to help. The problem is, you can’t possibly write drivers for all the hardware, hell even the companies making the hardware struggle to write proper drivers. What to do? Develop for your machine only, and let those contributor of yours come up with their own drivers, stick to your guns as you have no time to lose supporting other platforms. If you really want everyone to be able to run your OS develop for some virtual machine, like Bochs.
- You probably had the next great idea, but that required a partial or even a complete rewrite; this can be a sign that you either are making great progress or that you completely lacked planning. What you can do is evaluate if NOT doing these major changes would prevent your system from reaching its goals. Develop the system to reach your original goals first and only then consider rewriting it differently. Changing how the system completely behaves or how its designed affect the moral of your followers and contributors. All the work they put in will have to be redone (even if only partially), they will have to learn the new system and they may even disagree with the changes.
- Some fans or contributor comes along and they love your system, and they convince you to extend the original goals to do more; like you know, become the Next Big Thing or their new desktop. Well, Linux has been trying to do that for years and only started recently of getting a bit of hold on the desktop. Don’t try to play the big leagues right away; continue on your path until you have the system completed to your original goals (unless they really and truely don’t make sense anymore). Once your system is sufficiently developped to perform the duties you originally planned, you can sit down and start planning its expansion. Trying to develop the system for too many uses right away will only spread your energy too far and you are going to run out of time. Again, let your contributors contribute and let them come up with the modifications required to perform these extra duties.
- People hear about the system and they want to help you, but they require a little training… and then some more. Don’t try to guide everyone by the hand and teach them how to write for your operating system. Create documentation and when people ask a question, let other followers answer questions and concentrate on planning and developing. If you notice a repeating question, then feel free to update your documentation; you created documentation right?
- You know your goals, but the road to them is a white canvas. This could become problematic unless you have an innate talent for project planning and an awesome memory; but then if you are so good at project planning you probably would have a plan, wouldn’t you? Create a roadmap, you should have documented steps for every 40 hours of labor or so. Keep track at least a loose track of the time you spent on the various phase of each step and add them up; then re-adjust the remaining steps of your roadmap accordingly. By seeing those milestones go by will allow you to keep track of your progress and encourage you to continue. It will also allow your followers to have a better grasp of what’s yet to be completed (and maybe even help along).
Its no secret, writing an operating system is a very complex and long endeavour but you can get started really quickly with very little code. Unless you establish yourself clear goals and a proper roadmap to get there, your chances of success are limited.
The Internet is a big place and you can develop quite a following. A large following without proper planning can bring the project to a grind. If you aren’t a good project planner, then keep the team to a very small crew, potentially yourself only.
Overall, remember that your operating system is a project. As such, it should be managed like a project. Reading books on project and team management may be as important or more important than your ability to write a programming language.