I. Everything will change.
This is the golden rule: The foundation system must be modifiable at run-time by the user. Therefore, all foundation's internal system variables, temporary variables, and other states, must all be accessible to the user to simplify upgrades. Upgrades should not require the standard halt-upgrade-restart cycle which looses memory references and states. By the use of genuine dynamic linkers to replace built-in routines, upgrades may be performed at run-time without having to restart the system, thus maintaining memory references, etc.
II. Allow anything, but more importantly, do not dis-allow anything.
We must allow for that which we cannot predict; therefore, we cannot force anything upon the user, and cannot restrict anything unnecessarily either. A careful balance must be made between allowing for anything and consumption of resources.
III. Provide uniform access to all resources.
Storage, function, and communication are the three basic resources available to all entities using the system. All resources, actual or virtual, which the native operating system provides should be accessible through a system-independent interface. Typical operating systems provide only a hardware-independent interface which varies from platform to platform. Also, uniform access means that low-level resources should be accessible via high-level routines, and high-level routines should permit control by low-level commands---all by-passing any intermediate layers in the communication stacks which typically exist.
IV. When in doubt, put the feature in a user-accessible location.
This follows from the first two guidelines but is worth stating even if obvious: There is no reason to hide features from the user, and security is not a reason at this level. Upgrading should be made as transparent as possible, and the distinction between different system versions should be blurred and definitely not rigid. Similarly to different versions, new and improved command libraries, for example, should be replaceable modules which the user has total control over.
V. We are in this for the long-haul.
Virtual operating environments for the masses is a nice idea but an unrealistic design goal at this time. More will be said when we evaluate performance; however, we expect hardware technology will lag behind such implementation designs. We are implementing for researchers more than applications developers and users.
VI. The design must last.
This is a foundation, not a single application. Any feature which might cause future compatibility problems or future implementation design compromises should be moved out of the system kernel and into the user (application) layer or be implemented as an external system service.
VII. Find the re-occurring design elements.
Recursion in design reduces complexity and ideally approaches a more abstract design. Overall, abstract designs require smaller amounts of code to implement. The less code there is, the less there is to break and upgrade. The less code there is to break or upgrade, the longer the foundation should last.
VIII. Learn from experience, both our own and those of others.
Research has already been done in many, many areas which our design can benefit from. Make use of that research and experience. For our own research and to gain experience, any code developed in the design stage should be considered disposable code. Of course, never discard code, but do not be afraid to put it aside to try a new path. Much of this design seems to be combining existing technologies in a new way. That is true, so take advantage of that and see what the results are.
IX. Build upon existing platforms.
We are not setting out to develop the ultimate system to end all systems, but rather, we are out to develop a platform which researchers and developers can be both functional and comfortable with. If our system is designed to work with other platforms, users will be able to exploit that and use platforms which they are comfortable with and might have an immediate application for.
X. The source code is the implementation document.
The technical implementation manual is the system source code. Books and papers are being written, but slightly more than fifty-percent of the source code files are comments explaining the inner workings. Documents, such as this one, are to educate client programmers with the background which the source code comments assume.