Linked by Thom Holwerda on Tue 8th Apr 2008 20:14 UTC
Microsoft "Microsoft will make available the preliminary versions of technical documentation for the protocols built into Microsoft Office 2007, SharePoint Server 2007 and Exchange Server 2007. This documentation, which defines how these high-volume Microsoft products communicate with some of its other products, is 14000 pages and is in addition to the 30000 pages posted when the software giant first introduced its new Interoperability Principles last month. They will be made available April 8."
Thread beginning with comment 308817
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: OpenOffice
by elsewhere on Wed 9th Apr 2008 03:27 UTC in reply to "RE[2]: OpenOffice"
elsewhere
Member since:
2005-07-13

With this being said, I think the problem with this (the reliant on Microsoft) will cause pain at a later date because there is no assurance that they'll continue to update the documentation when they update their protocol, change or fix a security issue within the protocol?


The one advantage the community has is that Microsoft's dependence on backwards compatibility with every previous version of Windows ever created is that protocol changes will still have to assume older versions. So even if they change it, they can't scorch the OSS community without either scorching their own customers, or forcing said customers to apply arbitrary patches that MS knows from experience they may be hesitant to (ie. in the enterprise space).

I think the more important way to counter Microsoft is to create our own ecosystem of open standards that address the issues which Microsoft products - so that future improvement isn't hamstrung to the whims of Microsoft.


Agree wholeheartedly, but we have our own ecosystem of open standards already, and it's not working. It's time for the community to do a little "embrace, extend, extinguish" of it's own. When 98% of the computing world is using product A, it's almost futile to try and convince everyone that switching to product B is better. Instead, product B should act like product A, but introduce improvements and benefits that product A doesn't. So an app like korganizer or evolution can adopt compatibility with MS server protocols, yet ensure that users can migrate those services to open-standards based ones without forklifting the front end.

Or something like that. Anyways, it worked for Microsoft and made them what we are, so instead of constantly taking the high road, maybe the community needs to start using Microsoft's strategies against them. It's, frankly, the last thing they would ever expect. ;)

Reply Parent Score: 4

RE[4]: OpenOffice
by kaiwai on Wed 9th Apr 2008 09:22 in reply to "RE[3]: OpenOffice"
kaiwai Member since:
2005-07-06

Or something like that. Anyways, it worked for Microsoft and made them what we are, so instead of constantly taking the high road, maybe the community needs to start using Microsoft's strategies against them. It's, frankly, the last thing they would ever expect. ;)


Easily done. Create specifications where by if any part of the specification is improved on, the specification has to be revealed. Lets say Microsoft implements an openstandards protocol and then extends it, they're then expected to reveal the specifications of that extension.

The benefit of that is that it would still allow proprietary vendors to develop support in proprietary products, whilst ensuring that if they do extend the specification they're only obliged to disclose the nature of the extension - not the code itself. Thus, they keep their secret sauce, and compatibility is still maintained.

Reply Parent Score: 2