Software Ecology, or Why Does OS/2 version 5 Exist?
Someone I don’t know personally, but whose open source work I take advantage of quite a bit, is an evangelist for what he calls “software ecology”. Tudor Girba’s basic premise in the use of the term is that software developers barely think far enough forward to consider program maintenance, much less the eventual need to retire software. Since retiring software usually requires that it be replaced, Mr. Girba has spent decades developing software analysis tools to that end.
So, what does this have to do with OS/2 version 5? OS/2 was considered officially dead in 2004, when IBM announced that it would no longer be developing it. The latest release at that time was version 4.5. Officially, the version of OS/2 released a couple of years ago is called ArcaOS 5, while the company involved is called Arca Noea. However given that there was no previous release of “ArcaOS”, and Arca Noea was a new company formed by IBM employees and OS/2 community people, the version number quite obviously is intended to indicate a new release based on version 4.5, and is referred to by most people in the OS/2 community as simply OS/2 version 5.
Arca Noea, interestingly, has a double meaning, both of which are relevant to the release. It means “new box” or “new container”, but colloquially most often refers to Noah’s Ark. “New box” appears to imply that it is nothing other than OS/2 in a new box, while the colloquial meaning, Noah’s Ark, has interesting implications in terms of software ecology.
Software eventually needs retiring, if for no other reason that that the hardware and software platforms on which it runs eventually become out of date and quite often unavailable. While there exists a small community of OS/2 users who simply prefer it to newer alternatives, that community is hardly big enough to warrant a new release of a software platform IBM had officially killed off. The new version, while its look and feel has been updated (largely by adapting code from KDE and other open source projects), the main thing that necessitated a new release was the fact that over time version 4.5 had become less and less compatible with newer hardware.
While there had been updates released to accommodate newer hardware under the Ecomstation name between version 4.5 and version 5, and various drivers for newer hardware that could be found on sites that catered to OS/2 users, Arca Noea brought all those upgrades and some newer ones, added the open source Unix subsystem that supports ports from Unix and Unix-like operating systems, primarily Linux, and upgraded the look and feel with larger icons, more suitable for todays screen resolutions, from KDE.
You may be thinking while this is all very interesting to that small community, why is the continued existence of a platform most people I know barely remember, much less still use, in any way relevant? My answer is due to the reason it needed to be released at all: too much software, some of it crucial to systems that we use daily, still runs and only runs on OS/2.
The reasons for that are various. It may be financially impractical to migrate certain software to more common platforms; it may be that the time it will take to do so requires that the software remain running on OS/2 while the migration is effected (hence the Noah’s Ark reference); in some very specific cases, numerous attempts have already been made to migrate the software but have failed for various reasons, usually because they depend on aspects of OS/2 that haven’t been replicated on more common platforms. In the latter case, which is the most serious of the three, the most common culprit is the Distributed System Object Model. While the System Object Model, on which DSOM is based, is itself unique to OS/2, and makes certain types of object programming easier on OS/2 than on other platforms (because much of the base operating system code can be easily reused and modified by application code), DSOM makes distributed object programming much easier, and software that was built using DSOM can be extremely difficult to make work reliably without it. Since DSOM remains closed source and proprietary to IBM, there’s also no easy way of porting DSOM itself to another platform.
That software, obviously, needs to be replaced and retired, but there’s no obvious way to do so now. As a result, the platform it runs on must be maintained at least to a minimal level. Fortunately, OS/2 was designed to run on hardware that current hardware remains by and large backwards compatible with, which makes maintaining it much easier than, say, VAX, DEC Unix, or any of the other dozens of operating system platforms that have existed. The problem is that there is also software on those operating systems that is still in use, and on many of the less well-known platforms such as Data General Unix, many of which cannot run on any current hardware. Even worse are the number of systems and subsystems that were designed as embedded systems and rely on processors, boards and other hardware that can no longer be easily, if expensively, custom produced, since fabs that no longer exist would literally have to be rebuilt.
In order to replace that software, it needs to be analyzed, and the MOOSE code and data analysis platform, which Mr. Girba is the primary author of, is a fantastic tool kit for that type of analysis. But going forward, perhaps we should begin thinking about code retirement as part of new code projects.
Unfortunately, one of the most powerful and widely used innovations over the last 20 years, Agile software development, while it was never designed to help such concerns, actively makes it more difficult, since it prioritizes code over documentation. Without documentation analysis can only be more difficult than it already is, and in some cases it can be nearly impossible. Tools like MOOSE work well when the source code is easily accessible, but in many cases it’s entirely inaccessible, since it consists of proprietary code written by companies that have long since disappeared.
Reverse engineering that kind of code, in an embedded system, that uses proprietary boards, controllers and other hardware, is virtually impossible. But hardware doesn’t last forever. The cost of rewriting from scratch, from the original requirements, can be huge, but it’s a cost that more and more companies and other organizations are finding they must find ways to cover.
