Showing posts with label mary jo foley. Show all posts
Showing posts with label mary jo foley. Show all posts

04 December 2008

Microsoft's Tired TCO Toffee

Those with good memories may recall a phase that Microsoft went through in which it issued (and generally commissioned) a stack of TCO studies that “proved” Windows was better/cheaper than GNU/Linux. Of course, they did nothing of the sort, since the methodology was generally so flawed you could have proved anything.

I'd thought that even Microsoft had recognised that this was a very weak form of attack, so I was surprised to come across this....

On Open Enterprise blog.

23 April 2008

How Will Microsoft Cope with Clouds?

One of the central questions for future computing is: How will Microsoft cope with clouds? In other words, when the PC platform becomes almost an adjunct, how will the company maintain its vice-like grip on the market? A typically thorough post here from Mary Jo Foley about Microsoft's Live Mesh provides some important clues. Here's one part that I found particularly interesting:

Even though the Live Mesh team went out of its way to emphasize that Microsoft sees Live Mesh as an open platform, and not just one designed to appeal to the Windows/.Net choir, both Windows Presentation Foundation (WPF) and Windows Presentation Foundation Everywhere (Silverlight) are key elements of the Live Mesh developer stack (a diagram of which — here on the left — can be enlarged to full size by clicking on it). Support for Flash, Cocoa, JavaScript and other non-Microsoft-centric technologies is there, too. But given Live Mesh is from Microsoft, I’d wager Silverlight applications and services will look and work better as Live Mesh endpoints than apps/services built on and for Mac OSX/Safari, Linux and Mozilla ones.

This is standard lock-in: provide a nominally "open" platform, but make sure it works better with Microsoft products - a variant on the old "DOS ain't done 'til Lotus won't run." Some things never change....

21 January 2008

Fighting Words

Here, take this spoon:


In spite of their public opposition to Microsoft’s attempt to get the ISO standardization nod for its Office Open XML (OOXML) document format, IBM and Google quietly are supporting OOXML.

That’s according to two blog postings from the end of last week by Microsoft execs involved in the OOXML vs. Open Document Format (ODF) standards battle.


Update: Rob Weir offers the customary razor-sharp analysis to sort out what's really going on.

09 February 2007

Microsoft's "officelabs": Damp Squib in Waiting?

Given that her sources are normally impeccable, what Mary Jo Foley has heard about Microsoft's new "officelabs" is likely to be correct:

Tipsters say that Microsoft is encouraging the officelabs team to make use of open-source concepts in order to make better use of developers across different divisions within the company. Don't be limited by organizational hierarchy. Release fixes more quickly. Get new innovations into the hands of testers and users before they've been tested ad nauseum, to help build excitement for products — instead of waiting for orchestrated mega-launches like the Vista/Office 2007 one that finally happened at the end of January.

This is an inevitable development, for all the reasons I wittered on about before. You just can't write today's software - let alone tomorrow's - using yesterday's development methodologies.

But that doesn't mean that officelabs is the answer to Microsoft's prayers. Open source isn't just about getting "new innovations into the hands of testers and users before they've been tested ad nauseum" it's about engaging users - and giving, not selling, to them. In particular, you've got to give them the code.

There's money enough to be made from satisfying users' needs in ways other flogging software, but unless Microsoft learns to let go as well as to loosen up, I expect officelabs to be as much of a damp squib as its earlier pseudo-open source efforts like Shared Source.

15 March 2006

Microsoft Goes (a Bit More) Open Source

Many people were amazed back in 2004 when Microsoft released its first open source software, Windows Installer XML (WiX). But this was only the first step in a long journey towardness openness that Microsoft is making - and must make - for some time to come.

It must make it because the the traditional way of writing software simply doesn't work for the ever-more complex, ever-more delayed projects that Microsoft is engaged upon: Brooks' Law, which states that "Adding manpower to a late software project makes it later," will see to this if nothing else does.

Microsoft itself has finally recognised this. According to another fine story from Mary Jo Foley, who frequently seems to know more about what's happening in the company than Bill Gates does:

Beta testing has been the cornerstone of the software development process for Microsoft and most other commercial software makers for as long as they've been writing software. But if certain powers-that-be in Redmond have their way, betas may soon be a thing of the past for Microsoft, its partners and its customers.

The alternative is to adopt a more fluid approach that is a commonplace in the open source world:

Open source turned the traditional software development paradigm on its head. In the open source world, testers receive frequent builds of products under development. Their recommendations and suggestions typically find their way more quickly into developing products. And the developer community is considered as important to writing quality code as are the "experts" shepherding the process.

One approach to mitigating the effects of Brooks' Law is to change the fashion in which the program is tested. Instead of doing this in a formal way with a few official betas - which tend to slow down the development process - the open source method allows users to make comments earlier and more frequently on multiple builds as they are created, and without hindering the day-to-day working of developers, who are no longer held hostage by artificial beta deadlines that become ends in themselves rather than means.