Get over it. We’re never going to see OS/2 open-sourced. If you want to run OS/2 today, the closest you’re going to get is Serenity System’s eComStation. But, it just might be possible for Linux desktop users to get one of OS/2’s best features: SOM (System Object Model).

IBM, I’m told by developers who should know, still has all of SOM’s source code and it all belongs to IBM. It’s because IBM doesn’t have all the code for OS/2 and some of it belongs to Microsoft that IBM open-sourcing OS/2 has proven to be a futile hope.

Of course, many of you are asking, “SOM, What’s the heck is SOM?” I’ll tell you. It’s a CORBA object-oriented shared library. Those of you who aren’t programmers are doubtlessly staring cross-eyed at the screen right about now. For you: SOM is an easy-to-use universal programming library that both KDE and GNOME developers could use to create programs that would work in any Linux desktop environment.

The closest many users ever got to SOM was OS/2’s Workplace Shell, its desktop interface. What made SOM so powerful in the Workplace Shell was that it made it so easy to customize the desktop and its applications. With SOM, getting an application to look and act like a KDE, GNOME or what-have-you desktop program is almost trivial. Instead of delicately playing with APIs to move an application from, say, Ubuntu GNOME to OpenSUSE KDE, an SOM-aware application simply needs to call on the WinReplaceObjectClass API to use the KDE set of classes instead of GNOME’s.

If this were adopted, it would be much easier for developers to create, if I may borrow Java developers’ pet phrase, “Write once, run everywhere” applications. However, unlike Java applets, which are often slowed down by the need to be run in a Java interpreter, SOM-enabled applications and desktop environments wouldn’t face such delays.

Technically, it would work by GNOME and KDE using gtk and qt bindings to one common SOM library. Thus, today’s desktop developers really wouldn’t need to learn anything new about how to program for this new desktop environment. They would need to learn enough about OOP (object-oriented programming) to use SOM effectively, but that’s nothing compared to the kind of hoop-jumping needed currently to move an application from one desktop interface to another.

SOM wouldn’t be good just for hooking applications to the desktop. You can also use it with other programming languages. For example, SOM-aware Java, PHP, Python, Ruby or what have you would give Mono and Microsoft .Net some interesting competition on both the Linux and Windows platforms.

The other advantage of course is that OOP tends to create more stable and flexible applications from the very first version. The best example of that today is Apple’s Mac OS X’s Cocoa and Carbon. Now, while the debates over which of these is better than the other continue to rage in the same way that old-school Unix and Linux users still argue over vi vs. EMACS, one thing is certain. Mac OS X applications are stable and they always work in the same way.

Linux, while it uses OO languages like C++, really doesn’t have a universally accepted OO library. If Linux were to adopt SOM for that purpose, it could avoid the Carbon versus Cocoa arguments, and become — dare I say it? — the best desktop programming environment of all.

Another plus for SOM is that IBM designed it to work on any architecture, from mainframes to PCs. It’s also already been ported to AIX, IBM’s Unix. Put this together and it means that porting SOM to Linux should be simple.

If this is such a great idea, why hasn’t Linux already had its own OO system? Well, actually, there have been such attempts. The best known of them was probably GNOME’s Bonobo. It didn’t really go much of anywhere.

Bonobo ran out of steam not because the idea was wrong. The idea was fine. Indeed, like SOM, Bonobo was based on CORBA. The problem was that creating an OO framework is enormously time-consuming and difficult. Once an OO framework and its libraries are built, it’s easy to use, but the upfront costs can be a killer. With SOM, of course, that’s not a problem. That work has already been done.

Of course, for any of that to make a difference for Linux, SOM would need to be open-sourced. That shouldn’t be a problem. IBM hasn’t used SOM in a product in ages. Since SOM is just collecting virtual dust, why shouldn’t IBM open-source the code?

Heck, IBM doesn’t even need to release or clean up the development tools. Linux is loaded with developer tools. Just open-sourcing SOM alone, with perhaps some demonstration widgets, would be all that it would take.

Would the result look anything like OS/2? No, not at all. But what it would do is give Linux an outstanding OO framework that would go a long way toward making desktop Linux much more attractive to ISVs, and those applications would help make Linux even more interesting to desktop users.

Oh, and, IBM, since SOM can also be run in a network-aware DSOM (distributed mode), it would make integrating Linux desktop and IBM middleware running on IBM servers, especially the AIX and z/OS hardware, very easy for enterprise customers. Need I say more?

A version of this story first appeared in DesktopLinux.

Categories: Development, IBM, Open Source, Operating System | Permalink