Should IBM's SOM/DSOM Be Open Sourced?
Esther Schindler sends a note about two journalists for very different publications (herself one of them) urging IBM to open-source, not all of OS/2 — they've consistently refused to do that — but instead one of its most powerful features: SOM, the System Object Model. Steven J. Vaughan-Nichols writes at desktoplinux.com, "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." And Esther Schindler takes the developer angle in a blog post at CIO.com: "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." What are the business issues that would convince IBM to assent?
If the great innovation offered by SOM is basically a design pattern or interface technique, do we really need IBM's source code? It seems to me that the great thing about SOM is the idea of how something is done, and that we could pretty quickly write our own implementation of that idea. No?
The good things about OS/2 I described before is blessed by the wonderful SOM. I really can't tell you all the good things about SOM here, but during the time I wrote apps at IBM in C Set, SOM really save us a lot of time and efforts.
SOM implements a subset of the CORBA specification. Other technologies implement CORBA. Some already are open source (MICO). So... consider porting to another ORB.
And for the person who mentioned Apple... Apple implemented a subset of SOM specifically for OpenDoc. Though highly cool at the time, it was too castrated to be useful and has been surpased by other technologies for robustness (like J2SE/J2EE). Don't forget cool stuff like Spring... Lots has changed in 10 years.
/\/\icro/\/\uncher
Linux already has more more powerful D-BUS system (http://en.wikipedia.org/wiki/DBUS). It's already a base for PolicyKit, HAL daemons, soon it will be used in Upstart and so on.
It's MUCH MUCH easier to use than COM or SOM. And I still remember working with OpenDoc, so I don't really share good feelings toward SOM.
Yes, SOM/DSOM had some good points. However, it was also pretty horribly complex. Especially to implement, and even in many ways to use. As a result, almost all other approaches have gone for something simpler rather than trying to recreate it. One of the better ones IMO was NeXT's Portable Distributed Objects (PDO), which was so dirt-simple to use that NeXT engineers developed an infamous reputation in the 90s for writing letters to the editor in response to CORBA articles showing how to do the same thing in PDO in some ludicrously small fraction of the code. It was also incredibly fast. GNUstep has a reimplementation of PDO, though I don't think it's broken out into a nicely reusable library (I could be wrong).
Basically: weighing all the pros and cons, nobody else reached the conclusion that writing their own version of SOM/DSOM was the best option available, so they all did different things. I don't know if this was necessarily the right conclusion, but it's hardly that SOM/DSOM is some magical bit of code that nobody else could've reimplemented had they wanted to.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10