Slashdot Mirror
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?
IBM has been pretty good at taking sucessful closed source technologies and open sourcing them (think eclipse, webspere community ed, jikes and all the patents they've made available to the os community). I think IBM's genius has been in fostering communities to ensure that the technologies are well supported.
That said, SOM & DSOM are old tech from the dinosaur mainframe days. With so many distributed apps using more flexible interoperating technologies (SOAP, XMP-RPC etc) I don't really think open sourcing D/SOM will make that big of a difference to most new application developers.
fsckr.com - go fusk yourself!
One of the advantages of SOM is that it allows a closed source environment to be extended. Don't like the file dialog, subclass it with a better one. Or a recent example, need transparent png bolted on your 10 year old OS, well create a few new classes and use Cairo to display them. Suddenly you have modern transparent icons, transparent widgets on the desktop etc.
Unluckily with GPL you can get into issues of whether closed source or just incompatible licensed libraries can be added. One of the ideas behind SOM/DSOM was that anyone could write a DLL and extend the WPS. Now it seems that in free software land you often have to worry about incompatible licenses.
If IBM ever does open source SOM/DSOM I hope it is with something liberal like the LGPL. Don't have to think about issues with linking and the important source stays open.
https://en.wikipedia.org/wiki/Inverted_totalitarianism
I dunno. IBM isn't really in the OS market anymore, at least, not the regular mass-produced OS market - the big-machine Z/OS UNIX mainframe stuff and the like is an entirely different matter altogether (and probably wouldn't be substantially affected by such an offering anyway). Giving something like this to Linux+friends, if it helped, could boost Linux and be seriously annoying to Microsoft. And IBM likes Linux - certainly a lot more than they like Microsoft. It could happen. Maybe.
The World Wide Web is dying. Soon, we shall have only the Internet.
Its called .NET or Mono
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.
Ignore IBM and OS/2 and everything, just for a second, and review this hypothetical situation on its own:
A Big Computer Giant (BCG) purports to be very Open Source friendly. They defend OSS products and licenses, even using their own lawyers, and make a lot of money using/supporting OSS, in their own hardware, and in huge consulting contracts. It turns out they have this collection of source code that they aren't really using anymore, and they have complete rights to at least part of it. Let's just say they only have 2 real options when archiving the source code they own the rights to:
1. Keep it locked in some internal media or shelf, never to see the light of day, unless an internal developer finds it interesting and digs it up for an internal-only project. The internal project may never see the light of day either.
2. Put it on the Internet, and Open Source License it, preferably with an existing OSI license. Not only could the online repository be considered the source "archive", but it also leaves the possibility of growing a redundant, living archive. The source could then be provided by various OSS repositories and mirror hosts.
I know I'm preaching to the choir here, but shouldn't #2 always be the default, or at least the first option considered? Even if you're not an OSS nut (like me), you have to admit the hypothetical company looks pretty darn hypocritical if they don't choose #2, when given the choice, early and often.
So am I using a hypothetical situation to say that IBM (BCG) is a big hypocrite if they DON'T release and apply an OSI License to SOM/DSOM source, ASAP? Why yes I am! How could you tell?...
You must mean AIX - or you are predicting the future when IBM open sources SOM so your statement comes true...
and so has Apple, however Steve Jobs ended that "idea" when he returned to Apple...You mean Taligent? Which was an IBM & Apple co-project?
Microsoft has a very similar concept COM+You mean MS markets something they pretend is very similar, but any programmer who has used both will tell you they are light years apart, and that no matter how many ++++++++ MS adds to the end of COM, or how many times they change the name of OLE, it still will be light years behind SOM/DSOM.
You ARE on the right track with all of your comment - your just heading the wrong direction...
StarTrekPhase2 - The Five Year Mission Continues!
All should be open source. Source should never be hidden. It violates all ethos, it violates all truth, it violates my first GPL right to see the code!
It's not hypocritical because they didn't tell other people that they must open source everything. Also, you are somewhat familiar with the logistics involved by projects, archives, etc. You might consider that open sourcing is far from a 'default' choice, there are plenty of considerations:
1. it takes time to look over something to make it ready to see the light of day. You have a reputation to uphold.
2. you might want to make money off the software, now or in the future. as much as i love and support and contribute to open source, there's nothing wrong with that.
3. thanks to certain lawsuits, there is some perception in the industry that open source is risky. someone might sue you because you use linux. So, it takes work (lawyer time) to make sure code is clean
4. open source needs a community to really thrive. interested contributors, maintainers, etc. you would really like to see it 'picked up' by someone if it is going to be thrown over the wall
5. i don't think the safety of archiving is a major concern. probably more true for small companies that are not as likely to be around for the long term
demanding (not asking) that something on someone else's shelf be released is not really going to give co's a warm feeling about putting anything out there. you might reconsider your statement in terms of damage it could cause to open source...
just some things to consider.
The following quote supports the parent's point The most notable difference between SOM and COM is support for inheritance -- COM does not have any. It might seem odd that Microsoft produced an object library system that could not support one of the most fundamental concepts of OO programming, but they did have their reasons. The main issue is that it is difficult to know where a base class exists in a system where libraries are loaded in potentially random order. COM demands that the programmer specify the exact base class at compile time, making it impossible to insert other derived classes in the middle (at least in other COM libraries).
SOM instead uses a simple algorithm, looking for potential base classes by following the inheritance tree and stopping at the first one that matches; this is the basic idea behind inheritance in most cases. The downside to this approach is that it is possible that new versions of this base class may no longer work even if the API remains the same. This possibility exists in any program, not only those using a shared library, but problem can become very difficult to track down if it exists in someone else's code. In SOM only solution is extensive testing of new versions of libraries, which is not always easy.
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.
Because in real world companies exist to make money, not please OSS crowd.
- Arwen, I'm your father, Agent Smith.
- Well, you're just Smith, but my father is Aerosmith!
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
Linux Desktop environment use bonobo implementing some of its services to achieve reusability and that too is not universal. (Gnome uses it).
No, Bonobo failed and is being phased out: http://live.gnome.org/Bonobo
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
I did two contracts with IBM in the early 90's, one on the OS/2 2.1 change team. In both I "got" to deal with SOM and its implementation source code. It's a giant nasty C macro & function pointer hack. OS/2's Workplace Shell was very cool but the underlying implementation was pretty nasty stuff. One of my fixes was dealing with how slow it was populating icons in folders. SOM is a good example of the "Prototry" anti-pattern where one does an initial implementation of a cool trick then ends up shipping & extending it rather than ever bothering to architect it right in the first place. I can understand why IBM doesn't want this source out in public. FWIW - I also had to deal with some of the Microsoft source code, especially device driver stuff. Was the worse C code I've ever seen in production...
If you like SOM & Workplace Shell features you'll find it far easier to implement on top of Qt/KDE or wxWidgets or a smart functional integration of some Boost library features & a GUI than you'd ever have hopes of getting that code to work with anything modern or useful today. I loved OS/2. Borland had a Beautiful C++ compiler for it and CSet/2 was one of the better standards compliant compilers at the time as well. They're all bit rot by now though. Appreciate the memories but let this one die.
Online petition http://www.petitiononline.com/sombsom/