All things that can be observed and therefore assessed can be subjected to an analysis from two different standpoints - internal and external - or, the way things look and the way things work. This philosophy can be applied to an assessment of OSR projects.
Some OSRs utilise a 'ground up' approach in that the internals of the OSR mirror the internals of the IOS. One motivation behind this approach can be that, in the view of the developers, the design of the internals of the original OS were based on sound principles. The FAQ of the Syllable project states this as a design motivation:
"The BeOS API is undoubtedly a good design though. The Syllable API does use a lot of good ideas from the BeOS API, but we also design and add our own classes."
Another motivation behind a re-creation of the internal parts of another OS would be in order to maintain some degree of compatibility that OS. This compatibility may take the form of source code or binary compatibility. In other words, in the OSR may be similar enough to the IOS to be able to run programs or even drivers which were created for the OSI (binary compatibility) or it may simply be a design goal that programmers with access to the original source code should easily be able to 'port' their existing software to the OSR (source code compatibility).
There is a third, important aspect to the degree of correspondence between the internals of the IOS and OSR and that is architectural similarity. For this reason, it is often an easier job to port a Unix tool to an OS like AmigaOS than to an OS such as RISCOS. This is because AmigaOS shares greater architectural similarity with Unix than RISCOS does. Like Unix, AmigaOS is based around preemptive multitasking. AmigaOS also has a filing system architecture which was inspired by Unix file system concepts to a greater degree than that of RISCOS.
In the same respect, a window manager for Linux which resembled RISCOS wouldn't be a particularly good target platform for the task of porting RISCOS applications; the reason for this is that, this platform may increase the external similarities between the platforms but would do little, if anything, to increase the internal, architectural similarities between the two OSes.
Sustainability
Any appraisal of the prospects for the long term survival of an OS must include economic assessment. In the case of a FOSS OS, the economic factors are not monetary in nature but rather, concerned with the commodity that is manpower. To be a viable, sustainable project, the amount of manpower that the project can attract must be the same as or greater than the amount of work that needs to be done to maintain the project.
In the case of a purely commercial OS project, the most important considerations are monetary. In a commercial context, the manpower that the project requires has a monetary value attached to it. To be sustainable, the project must have available to it an amount of money that is equivalent to the amount of manpower that the project needs.
So, the question, "Is the project viable, in the long run?" could be reformulated as "Is the project sustainable?". In commercial or FOSS OS projects, any design decision that increases the amount of manpower needed has impact upon the sustainability of the project. In the case of living things, businesses or operating system projects, the amount that comes out is equal to or less than the amount that is put in.
Whenever I read about a new OS project, I want to know what their plan or model is going to be: I want to know how they are going to attract the amount of resources they need in order to do the work of creating the finished (or ongoing) product. If one guy says that he is going to do all of the work himself, can he? If the originator(s) of the project claim that other people are bound to join in, what is evidence that supports their assertion? Is this assertion backed up by precedent, for example?
Similarly, a design decision which affects the accessibility of the project to developers will impact it's sustainability. One way in which access ability can be limited is through decisions that tie the platform to unusual hardware. Particularly in the case of open source software, there is a relationship between the accessibility of the platform, the number of users and the number of developers.
In the case of any OS project, any such appraisal must take into account the creation or maintenance of the applications that people are going to want to run.
- "OS Recreation, 1/6"
- "OS Recreation, 2/6"
- "OS Recreation, 3/6"
- "OS Recreation, 4/6"
- "OS Recreation, 5/6"
- "OS Recreation, 6/6"
