Near the end of the 1990s, IBM shut down SOMobjects download sites and never put them back online. SOM 3.0 DTK for WinNT can't be found on IBM FTP, despite much other legacy stuff lying around freely. Despite general availability of SOM 3.0 for WinNT, it was nearly impossible to locate until the end of 2012. Finally, IBM never open-sourced SOM (as done to Object REXX), despite several articles and petitions. Alternative implementations Two projects of open-source SOM implementations exist. One is Netlabs Object Model (NOM), which is technically the same, but binary incompatible. Another is somFree, which is a clean room design of IBM SOM, and binary compatible. Comparison of support for compiled class libraries Historically, SOM was compared to Microsoft's Component Object Model (COM) by IBM. However, from some points of view there is no place for COM at all. From the point of view of release to release transformations, COM is on procedural level, thus, the table 1 in RRBC article (Release-to-Release Binary Compatibility referenced earlier) does not contain COM column at all. Instead, SOM is being compared to: compiled Smalltalk compiled Common Lisp Object System (CLOS) generic C++ SGI Delta/C++ Sun Object Binary Interface Objective-C Java Most information in this table is still applicable to modern versions (as of 2015), except Objective-C 2.0 getting so called non-fragile instance variables. Some solutions remained experimental: SGI Delta/C++ or Sun OBI. Most approaches based on one programming language were phased out or were never used actively in the same way. For instance, Netscape Plugin Application Programming Interface (NPAPI) browser plugins were written using Java API initially (LiveConnect), but Java Virtual Machine (JVM) was later excluded from the chain. It can be seen as Java replaced with Cross Platform Component Object Model (XPCOM). Common Lisp Object System (CLOS) and Smalltalk are not known as being chain links like Java in LiveConnect. Objective-C is also not known much in this role and not known to be marketed this way, but its runtime is one of the most friendly to similar use cases. Generic C++ is still being used in Qt and the K Desktop Environment (KDE). Qt and KDE are notable for describing efforts it takes to maintain binary compatibility without special support in development tools. GObject only aimed to avoid dependence on C++ compiler, but RRBC issues are the same as in generic C++. Without special runtime many other programming