Seven Reasons Microsoft Loves Open Source

tlockney writes "Next week at Microsoft's MIX, whurley will be leading a discussion on 'Open Source, the Web, Interoperability, and Microsoft'. To kick off a bit of pre-session discussion and enlist the help of others in putting Microsoft on the spot, whurley, king of all things open source at BMC has written an article entitled 'Seven Reasons Microsoft Loves Open Source'."

Comments

NT POSIX memories.

[EmbeddedJanitor]

As the parent says the NT POSIX was severely sucky.

In the NT3 timeframe (approx 12 years ago now), there was a big effort to sell NT to companies, such as the one I worked for then, supplying back office /server room style products. Many/most products of the time were running on Unix boxes or similar. We were using Unix x86 boxes (SCO etc) for compter tephony applications. NT had to check a few boxes to encourage people to switch: POSIX and streams driver support. This gave people a reasonable porting avenue to a cheaper OS (NT was about half or a third of SCO's cost at the time).

The POSIX and streams drivers were very inefficient, and were dropped within a short while (once the bait and switch had worked).

This ploy was very clever on MS's part. Using ourselves as a benchmark for people in this space, our customers were putting on some pressure to provide NT based products because they were eating the MS blurb and wanted to reduce costs. Our techies looked at NT and figured out what would be needed to port: POSIX-check, streams driver model - check. So we say that on paper it can be done with trivial architectural change. Marketing start hyping the NT-based offering. The business people say make it so, so we do. Unfortunately we find the POSIX and streams driver model are very slow on NT, so end up having to start doing native drivers and non-POSIX code. We start slipping, marketing starts screaming and the portability gets dumped in favour of getting shipping. The bait and switch has worked.

We never got any benefit from NT POSIX or the MS streams driver. Our systems went from requiring low-end (16-25MHz) 386s to 100+MHz 486. Basically a very bad case of bait and switch.