Just a Little SOM Thing for Linux Developers

Could the open-source community use a library packaging technology that enables languages to share class libraries regardless of the language an application was written in? I dare say it could, especially since the code to accomplish that goal was written (and shelved) more than ten years ago. All it takes to make that code available is to ask IBM to release SOM and DSOM as open-source.

System Object Model (SOM) and distributed SOM (DSOM) are technologies based on the interface defininition language (IDL) standard, enables a software developer to establish communication between disparate objects which may not be written in the same language. It fixes the fragile class tree in C and C++, though SOM isn’t limited to those languages.

There isn’t any technology available today that allows different libraries to freely interact with each other like that. Sure, there have been attempts (which one developer called “feeble”) to accomplish the same thing that SOM did (among them are XML-RPC and JSON-RPC), but those have annoying limitations. XMLRPC and JSONRPC target some of what DSOM does. But they don’t have the goal of linking disparate languages/libraries in an OOPy way. Please don’t think I’m disparaging what these technologies can do; they’re useful. My point is that SOM is at least another way to approach the task, and it could be argued (by people far more technical than I) that SOM could do it better.

As a practical example, imagine that someone created a C++ library that was the answer to all IMAP needs. A developer couldn’t access that library from Python, unless she wrote custom code from scratch. And that wouldn’t help a developer who uses Java. With SOM, the library would be available no matter which language you chose.

That example ought to give you a sense of the business advantages to SOM. Less code to write means faster, cheaper development. If SOM were part of the equation, you could avoid being marooned in the wrong environment to solve the problem.

I could continue about SOM’s technical advantages… but plenty of that information is already available online. Alas, IBM no longer lists the Redbooks for SOM and DSOM, and sorry—you can’t borrow my print copy.

Maybe you disagree that SOM will solve all sorts of problems for Linux. That’s okay. Even if it solved a few problems, it’d be a vast improvement… and the only thing standing in the way is IBM. Unlike OS/2, which has so many fingerprints on it that IBM can’t open-source it, IBM owns SOM. It’s already been ported to several environments, such as AIX and System/390. Although SOM was among the shiniest bits of technology in OS/2, it’s not tied to that OS. SOM was part of the foundation of OpenDoc and thus Mac OS X is a distant relative.

In fact, SOM is very much in the same position that REXX was, and IBM released Object Rexx to the community a few years ago.

I have a copy of the SOM/DSOM source code somewhere in the piles of CDs here at the bitranch. It was distributed to companies that signed up as OpenDoc developers (I’m tempted to add, “all three of us”). Without digging out the code for a full in-depth examination, I think I can safely say that it was clean enough at the time for IBM’s lawyers to let it be shared with OpenDoc partners, which then included Apple and WordPerfect Corp. (There is also an OpenDoc Bible book contract in that folder, too, but the reasons for OpenDoc’s market failure is another tale indeed… one that requires at least a couple of beers. Maybe three.)

Bottom line, though: SOM and DSOM could be a benefit to the open-source community, and to Linux in particular. If you agree, please ask IBM to investigate whether it’s feasible to let SOM go free. I rather expect the answer is, “Yes, it can.”