I will not offend you by mentioning commonplace ideas in this article. You already know you need lots of time, lots of patience, lots of datasheets and books, and the capacity to debug with your hands tied in your back.
Choose your own camp
You need to decide early on what category you are in.
Are you a low-level hacker who wants to write a fully working OS in assembler, because those damn C people don't see how much speed they lose?
Do you want to learn how kernels are written, by copying an existing design (unix, whatever?) or make up your own from a hodge-podge of concepts? That seems to be the trend lately. Or a convenient excuse.
Do you want to advance the state of the art? Create a new architecture with a lot of advantages nobody has seen before?
Pick one, and stick to it. Software hates inconsistency. In the middle of the project, don't decide to rewrite everything in C because assembly is a bit much to chew after all, or to publish papers on something everybody already knows (like, say, programming the PIC on x86) just to show the world you can read a datasheet.
Choose your audience
Who is your user? Not the fellow hackers you will hire for help on coding your dream. But who is the end user?
Billie, a middle-aged house wife with three kids, who does the accounting around the house, and also chats a little bit online once in a while when everybody is at work and at school?
John, a thirty-something guy writing unix banking software for a living, currently using NetBSD on his desktop, switching on a regular basis, trying out FreeBSD or Linux, because he needs the unix environment and will not mind a new OS as long as he has gcc, nedit and windowmaker?
A person known as DaMan, a 21-year old sysadmin/programmer who compiles every new linux kernel on his company servers, as soon as he hears they are out on the kernel mailing list? And who will be willing to try any new cool server OS, as long as it has perl and vi?
Fellow hackers in the OS development community, who will eagerly read your papers about thread migration and protection through artificially software reduced instruction sets?
Yourself, who will be the only one to ever see your OS?
Be honest about your goals
When you know your camp and your end user, the killer question is: can you do it? Be honest with yourself. Give yourself credit - you will never know if you can write a fully debugged preemptive scheduler, until you have tried it, but be realistic about how much you can do. Either you will decide it's more fun to play cricket, or you will have a better idea of the profiles of people you need to enroll on your site. Either way you win.
My company is happily employing a guy best known in the open-source world for writing a mono-tasking OS all in assembler. It was limited, and for x86 only, but hell, it worked, and it fulfilled the original goal. One day he told me he received an email from a fan, who said something like: "I just want to know how to decompress the kernel, because I can't figure it out. But the rest, the writing the kernel thing, that's easy. I just want to know about the unpacking".
Right.
Publish your goals and your own capabilities with honesty. Smart people don't like arrogant people anyway.
You are the god of your project
If you go the open-source route and enroll fellow hackers, they will come up with their 130 ideas they want in your kernel, plus their 200 itches to be scratched (such as "semaphores suck!"), and their own idea of your project. If you let people hack away merrily, you will end up with the opposite of efficient.
You create your project - you own it. Be sure that contributions are consistent with your vision. Don't hesitate to ask people to rewrite something so it fits your goals and your architecture.
Do not bait people on purpose, though. Make sure that as much as possible is written and published on your site. You can't bash somebody because he doesn't know something is not in line with your thinking. If they’re good, they will move on to another project. You don’t want to lose good people.
Version control is great and mandatory. Letting anybody commit code, no matter how focused and smart they are, is the best way to have your project go in all directions and try to be a distributed server OS as well as a RTOS that fits in 64K, at the same time. Be sure people send patches to you and you commit them when they are OK. After a while, when you have grown to trust a few people like yourself, expand to a core team with commit privileges. Make people own the task of integrating, validating and committing.
Conclusion
If we go back to AtheOS, the goal of learning and cloning was well defined. The target is the power desktop developer-users who like to try out cool new things. Kurt, the creator, never claimed to dominate the world and has been going at it piece by piece, slowly. He did most of it by himself, not encouraging external contribution, enforcing consistency.
Taking these decisions right away also helped me a lot.
If you're engaging in such an adventure, I hope this helps take the frustration out and make it much more fun. In any case, good luck, and I would love to hear comments on the article, as well as experience of anybody who already went down that path, successfully or not.
About the author
Emmanuel Marty is the Chief Technical Officer of
NexWave Solutions, the supplier of a new software
architecture, OS services, and telecom stacks, for consumer electronics and telecom. He has been working with
computers since the age of 10. Currently aged 26, he lives in Montpellier, France, with his fiancee. He can
be reached at emarty@nexwave-solutions.com.
- "The roots"
- "The OS writer playbook"
