Keitsha - you facts may be right, but they are not relevant:
- COM is successful, but OLE is not used as it was intended to. Unless you rewrite history, of course. COM does have a problem though - it made Windows applications slow down seriously in performance because more files need to be accessed.
- Exchange can interface some information via some open standards. That's not interesting here. What would be interesting, is if the communication between Outlook and Exchange would be an open standard.
- Microsoft's Kerberos implementation followed the embrace and extend philosophy, which violates the idea of using open standards very much. Publishing their extra specs as an .exe file with license terms was ridiculous and proved how MSFT tried to avoid interoperability with Kerberos.
- I do understand XML very much. Please note how I wrote that my points were to be applied to protocols, too. This includes SOAP etc.
A product that really supports open standards, does this:
- Implements open standards according to the documentation and doesn't embrace and extend.
- Does not use proprietary APIs or protocols where open standards could have been used or created.
- Does not define the standard by implementation (i.e. "market standard").
Most Microsoft products don't fully support open standards, because:
- They embrace and extend standards, sometimes interpreting standards to Microsoft's strategic benefits.
- They implement their own APIs and protocols for cases where open standards could have been used (for instance, Outlook doesn't normally use SMTP to deliver e-mails to an Exchange server).
- Many products serve as implementation reference and future versions are made backwards compatible, breaking the written documentation. It is ok to make products compatible with other software and other software versions as long as it doesn't break the specs, but as soon as it breaks the specs, it's wrong. |
