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?

Who needs the code?

[DoofusOfDeath]

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?

Re:Who needs the code?

[RobertM1968]

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?

Sadly no - on all counts. In over a decade and a half, no one (but maybe Apple) came close. DSOM/SOM hasn't been worked on in many years, and still, with kludge after kludge, MS cant come close. (some of) The Linux community wanted the WPS open sourced just because of how powerful it was - even though I dont think they even realized that it meant also open sourcing SOM/DSOM. With many attempts at numerous windowing environments, though the Linux community has made both some pretty and some pretty useful windowing environments, they still haven't come close...

And of course, SOM/DSOM is far more than the WPS... (just a requirement for the WPS to work).

Also, saying SOM/DSOM is just "the idea of how something is done" is like looking at cars, bicycles, sneakers and skateboards and calling the car engine "an idea of how something moves" - it is far more than that. It is a technology that allows anyone on almost any language, to interact with and integrate with any other device, network resource, app, GUI or OS that is SOM/DSOM enabled. Almost 8? 10? years of little to no development on SOM/DSOM and there is still nothing half as powerful for any PC based operating system. Yeah, MS can keep writing inelegant, bloated (which is a massive understatement when compared to SOMObjects of better capabilities) kludges to achieve some of the functionality on a limited scale...

SOM/DSOM is truly what most OO programmers truly want - even if they dont know it (which would simply be because they dont understand it, or love VB that much).

It's the best outcome

[jsse]

The good things about OS/2 I described before [slashdot.org] 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 = CORBA 1.0

[micromuncher]

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.

Linux doesn't need it. It has D-BUS

[Cyberax]

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.

nobody has really tried

[Trepidity]

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.

Re:Linux doesn't need it. It has D-BUS

[sjvn]

D-BUS is great. D-BUS is wonderful. But, DBUS and SOM do entirely different things. DBUS is meant to be a universal IPC (interprocess communication) mechanism for the Linux desktop. See http://www.desktoplinux.com/news/NS4449390454.html [desktoplinux.com] for more details. SOM's a set of object libraries. You would use them together. In fact, D-BUS, since both the GNOME and KDE communities have embraced its use, would make an ideal interface for SOM. Or, in other words, DBUS would enable applications to more easily access the power of SOM objects.

Steven