As a user of Microsoft products and an employee of the company, I am of two minds about its entrance into the anti-spyware and anti-virus arenas. I agree with the sentiments Michael Gartenburg of Jupiter Research shared in his post Microsoft and Security - Demand if they do and demand if they don't

It's tough to be Microsoft. On one hand, folks insist that security, spyware and virus are issues that they must own. On the other hand, when they do own it and respond, they get dinged for it. Microsoft's decision to get into the business and make these tools available should be lauded. Security is a tough issue that I've written about before and users need to also take on a share of the responsibility of keeping their systems safe. The fact is, even with good solutions on the market, not enough users are protecting their systems and if Microsoft entering the game can help change that, it's a good thing.

Given that spyware is quite likely the most significant problem facing users of Windows I believe that Microsoft has a responsibility to its customers to do something about it. Others may disagree. For example, Robert X. Cringely attacks Microsoft for its recent announcements about getting in the anti-spyware market in his post Killing Us With Kindness: At Microsoft, Even Good Deeds Are Predatory. He writes

How can giving away software tools be bad? Look at how Microsoft is doing it. Their anti-virus and anti-spyware products are aimed solely at users of Windows XP SP2. This has very different effects on both the user base and the software industry. For users, it says that anyone still running Windows 98, ME, or 2000 has two alternatives -- to upgrade to XP/SP2 or to rely on non-Microsoft anti-virus and anti-spyware products. Choosing to upgrade is a 100+ million-unit windfall for Microsoft. That's at least $10 billion in additional revenue of which $9 billion is profit -- all of it coming in the next 12 months.That $10 billion, by the way, comes from you and me, and comes solely because of Microsoft's decision to offer "free" software.

Of course, you can decide not to upgrade to XP/SP2 and rely instead on third-party products to protect your system. But Microsoft has set the de facto price point for such products at zero, zilch, nada. By doing this, they have transferred their entire support obligation for these old products to companies like Symantec and Network Associates without transferring to those companies any revenue stream to make it worth their trouble. Maybe Peter Norton will say, "Screw this, I'm not going to support all these millions of people for nothing." Well, that's Symantec (not Microsoft) apparently forcing users into the same upgrade from which Microsoft (not Symantec) gains all the revenue.
...
Look how this decision transforms Microsoft. By choosing to no longer support a long list of products (is that even legal?), hundreds and perhaps thousands of developers will be switching to new duties. If this were any other company, I would predict layoffs, but a key strategy for Microsoft is hiring the best people simply to keep them from working elsewhere, so I don't think layoffs are likely. What IS likely is an exodus of voluntary departures. What's also likely is that those hundreds or thousands of reassigned developers will be moved to some other doomsday product -- something else for us to eagerly anticipate or fear.

Cringely seems to be confusing supporting old versions of Windows with providing applications that run on current versions of Windows. Windows 98, Windows 98 SE and Windows Millenium are old versions of Windows whose support life cycle was supposed to end about a year ago but was extended by Microsoft. At the current time, Microsoft will continue to provide critical security updates for these operating systems but new applications won't be targetting them but instead will target the current version of Windows for the desktop which is Windows XP.

Microsoft's anti-spyware and anti-virus applications are not an operating system upgrade but instead new applications targetting the current versions of Windows. Even if they were, Windows 98, Windows SE and Windows Millenium are past the stage in their support life cycle where they'd be eligible for such upgrades anyway. Given that Robert X. Cringely is quite familiar with the ways of the software industry I'm surprised that he expects a vendor of shrinkwrapped software to be providing new features to seven year old versions of their software when current versions exist. This practice is extremely uncommon in the software industry. I personally have never heard of such an instance by any company.


 

While playing Magic:The Gathering with Michael Brundage and a bunch of former co-workers last week he informed me that he had updated his Working At Microsoft essay given some comments and feedback he had seen. Some excerpts from the additions to his essay are included below

Unreality

As a parent, I've come to understand that there's a wide gray area between overprotecting your children and creating a nuturing environment in which they can develop. I think Microsoft struggles with a similar problem with its employees. Microsoft provides its employees with a nuturing environment in which they can be most productive. But like children, these employees also need to be grounded in reality and exposed to ideas that can be disruptive or even disturbing. Otherwise a sheltered monoculture can develop that's unhealthy for everyone involved.

It's hard for people who don't work at Microsoft's main campus to understand just how unreal the experience of working there can become. Some employees forget that most of the world doesn't have broadband wireless networking, high-end consumer electronics, luxury vehicles, and enough money that they don't need to live on a budget. Some employees spend so much time using Microsoft products, that they forget about the competition and/or lose touch with typical customers' needs

...

Microsoft's Not Evil

The reality is that Microsoft is made up of mostly honest, earnest, hardworking people. People with families. People with hardships. People with ordinary and extraordinary lives. People who make wise and foolish decisions. Some employees are bad apples, and some leaders make poor decisions (which their employees may or may not support). Both usually meet with failure. All the Microsoft employees I know are internally driven to "succeed," where success sometimes means outselling the competition but always means doing your personal best and improving people's lives with your work.

Although groups don't have intentions, it's true that group policies reward some kinds of behavior over others. So perhaps "Microsoft is evil" is shorthand for "Microsoft's policies are evil."

The thing is, I haven't seen any evidence of that on the inside and I'm usually very critical of these things. For as long as I've worked at Microsoft, ethics have been a real part of employee performance reviews. It's not just talk, but the way work goes each day. Most product designs revolve around addressing specific customer needs. No one ever says "Hey, let's go ruin company P" or other things that could be construed as "evil." Instead, it's "customers Q and R are having trouble with this, and I have an idea how we could fix it..." and other positive, constructive statements.

If anything, Microsoft seems to have the opposite problem, in which employees sometimes design or cut a feature or product without fully appreciating the huge impact their decision can have outside the company. When the media goes wild with knee-jerk reactions for or against something Microsoft did, often the employees responsible for the decision are caught off-guard by the disproportionate public attention.

I came to similar conclusions about Microsoft employees a year or two ago. The main problem with Microsoft employees is not that they are out to 'cut of the air supply' of their competitors. Instead it is that they often make decisions without awareness of the impact their decisions will have on the software industry as a whole. I have often been surprised to realize that some program manager for some new feature or component in some Microsoft product has failed to realize that the entrance of Microsoft in that space could potentially put partners or competitors out of business. This isn't to say that the execs don't realize that Microsoft entering markets usually decimates competition but that a lot of the rank and file guys implementing these decisions or coming up with some of these ideas often don't realize the impact of their actions.

One of the reasons I like working at MSN is that we aren't under any illusions about these issues. We aren't "adding a new feature to Visual Studio to make developers more productive" or "adding some new functionality to Windows to make it more useful for end users" which also happens to have been a thriving ISV market until we decided to enter it. Instead we are directly competing with folks like Yahoo, Google or AOL for a particular market. This situation definitely sits a lot better with me.


 

Categories: Life in the B0rg Cube

February 22, 2005
@ 05:36 PM

The next release of RSS Bandit is scheduled for next month. However we've hit a bit of a snag with regards to translations to langauges other than English. We currently have translators signed up for Japanese, Simplified Chinese, Hindi, Turkish, Brazilian Portueguese, and German. The problem is that in the previous version of RSS Bandit we had translations for a larger set of languages but haven't gotten any responses from the original translators for this new version. This means the next version of RSS Bandit may not be localized in Polish, French and Russion even though the previous one was.

If you'd be interested in translating RSS Bandit to your native language or acting as a proof reader for one of our existing translations please contact us at the email address provided below.

RSS Bandit development team contact email address
 

Categories: RSS Bandit

Saturday was musuem day for me. I visited both the Science Fiction Museum and Hall of Fame in Seattle and the Museum of Glass in Tacoma. The entrance fee for the Science Fiction Museum $12.95 which is a bit overpriced considering what one gets out of the tour. The musuem is primarily a collection of old science fiction books and magazines as well as props from various movies. Some of the props are quite cool such as the alien queen and Ripley's construction suit from Aliens while others such as the collection of phasers from the various Star Trek movies failed to light my fire. At the end it seemed more like I'd just been shown some geek's private hoard of science fiction memorabilia than I'd been at an actual musuem or hall of fame. I probably would have felt less ripped off if the cover fee was $5 instead of almost $13.

The Museum of Glass was more satisfying although it also felt like it was over too soon. The  Einar and Jamex de la Torre: Intersecting Time and Place was amazing although a bit gory. The artwork by the Torre brothers had demons, exposed human organs and catholic religious relics as a recurring theme. It led to some interesting artwork which I could see some of the parents with younger children had difficulty explaining to their kids. The Solid Cinema: Sculpture by Gregory Barsamian was also impressive. They were mechanical animated pieces illuminated by strobe light. There were only three pieces but they were extremely well done and I spent some time scratching my head trying to figure out how they worked. The Museum of Glass was definitely worth the $10.

The next local museum on my list is the Museum of Flight.


 

Categories: Ramblings

Michael Gartenburg has a blog posting entitled Is Google doing what Microsoft couldn't with their new search bar?  where he writes

As Yogi would say, "it's deja vous, all over again". When Google introduced the newest version if their toolbar, it seems they added a feature that sounds very similar to what Microsoft wanted to do with SmartTags. Apparently the new software will create links in web text that will send you back to Google sites or sites of their choosing. If I recall correctly, there was a huge outcry over the SmartTag feature. Even petitions. How come there is no outcry here? Is it because Google does no evil?

Like I said yesterday, who needs a new browser to do stuff like this when you can co-opt IE with a toolbar?

This is one of the key differences between Google and Microsoft; perception. I am glad to see Google imitating one of Microsoft's innovations from a few years ago. After all, imitation is the sincerest form of flattery. As can be expected Dave Winer is already on the offensive.

Personally, I can't wait to see how much cognitive dissonance this causes the Slashdot crowd.


 

Categories: Technology

February 16, 2005
@ 04:17 PM

From the first day we added the Search Folder feature to RSS Bandit, I've wanted to be able to create a folder that contained unread messages that are a week old which contain 'Microsoft' in the title from the Slashdot, InfoWorld or Microsoft-Watch feed. However the existing Search Folder feature did not allow you to restrict the targets of a search to particular feeds or categories. The back end code to do this has existed for a while but Torsten never got around to adding the UI for this, until yesterday. It's looking like the Wolverine release is shaping up to be the best release yet.


 

Categories: RSS Bandit

This morning I saw a post by Tim Bray entitled Another Loyal Oppositionist where he pointed to a post by James Governor stating that Microsoft is ignoring the demand for toolkits that support plain old XML over HTTP and instead focusing on SOAP-based XML Web Services and the WS-* family of specifications. Before I could respond I saw that Mike Champion had already beat me to the punch with his post  MS Ignoring developer demand for REST tools? where he writes

The long running PR battle is heating up again between those who advocate the implementation of service architectures [1] "RESTfully" using XML transferred via HTTP, vs those who work with SOAP, WSDL, and the specs built on them known as "WS-*".  The item that finally got me to blog about this painful [2] subject was James Governor's SOAP is boring, wake up Big Vendors or get niched

Evidence continues to mount that developers can' t be bothered with SOAP and the learning requirements associated with use of the standard for information interchange.  ...Developers are turning their backs on the standard. Folks that is, building interesting information splicing apps--semantically rich platforms like flickr and Amazon are being accessed by RESTful methods, not IBM/MS defined "XML Web Services" calls.

Yesterday my partner Stephen issued a wake up call for middleware and tools vendors - give developers what they want, not what you think they should have. ...

One big question is why haven't IBM and Microsoft responded? The obvious answer is vested interest. When you have "bet the company" on a technology stack its kind of a drag to have to respond to something else.

A few thoughts: For one thing, I'd note that Microsoft  has responded to this need ... in about 1999.  The XMLHTTPRequest object implemented since the second version of the MSXML library provides such a powerful and convenient way to use XML and HTTP together that this API has been implemented in competing platforms, and was featured in an XML.com article just last week.   Forgive us for not touting Microsoft's support for this newfangled "RESTful" approach, I guess people here thought it was old news :-)

When I read James Governor's post, I also wondered what he was expecting from a toolkit for supporting XML Web Services that just used POX (plain old XML). We've shipped multiple XML APIs and have libraries for working with HTTP in the .NET Framework. In MSXML, we shipped XMLHTTP which recently started making headlines again because Google has been using it heavily in their recent web applications such as Google Suggest. Microsoft has and will continue to ship libraries and tools that make it easier for developers to work with plain old XML over HTTP.

SOAP and the WS-* family of specifications target developer problems with more sophisticated requirements and needs than can be satisfied by simply using POX. As I stated in my recent post  On Interoperability and Tim Ewald's 3 Web Services Stacks

However context is everything. Replacing a world of distributed applications written with DCOM, CORBA, Java RMI, etc with one where they are written using the WS-* protocols is a step in the right direction. I completely agree that it leads to better interoperability across technologies produced by the big vendors who are using incompatible technologies today.

But when your plan is to reach as many parties as possible one should favor simpler Web services technologies like plain old SOAP or just plain old XML (aka POX). Plain old XML doesn't necessarily mean following the principles of REST either. After all a number of successful plain old XML services on the Web don't follow these principles to the letter. For example, Joe Gregorio pointed out in his article Amazon's Simple Queue Service that Amazon's Queueing Service violated these principles. In Sam Ruby's post entitled Vacant Space he points out that plain old XML web services exposed by Bloglines and del.icio.us aren't RESTful either.

Given that Don Box linked to the above post and commented favorably on it I believe this makes it clear that we at Microsoft understand that POX, SOAP, and WS-* each have a part to play in the world of XML Web services.


 

Categories: XML Web Services

For Her and For Him. Too bad I found about these after I got my gifts. I guess there's always next year.


 

February 11, 2005
@ 04:57 AM

Steve Vinoski has a blog posting entitled Focus on the contract where he writes

Tim offers some extremely excellent advice (as usual) regarding what really matters when you write your services. If I may paraphrase what he says and perhaps embellish it a bit, starting from the implementation language and generating your contracts from it is just plain wrong, wrong, wrong, at least for systems of any appreciable magnitude, reach, or longevity. Instead, focusing on the contracts first is the way to go. I've written about this for many years now, starting well over a decade ago.

When you start with the code rather than the contract, you are almost certainly going to slip up and allow style or notions or idioms particular to that programming language into your service contract. You might not notice it, or you might notice it but not care. However, the guy on the other side trying to consume your service from a different implementation language for which your style or notions or idioms don't work so well will care.

Although Steve Vinoski's argument sounds convincing, there is one problem with it. It is actually much easier to make an uninteroperable Web service if one starts with the service contract instead of with object oriented code. The reason for this is quite simple and one I've harped on several times in the past; the impedance mismatch between XSD and objects is quite significant. There are several constructs in W3C XML Schema which simply have no counterpart in traditional object oriented languages which cause current XML Web service toolkits to barf when consuming them. For example, the XmlSerializer class in the .NET Framework supports about half the constructs in W3C XML Schema. Most XML Web Service toolkits support a similar number [but different set] of features of W3C XML Schema.

This isn't theoretical, more than once while I was the program manager for XML Schema technologies in the .NET Framework I had to take conference calls with customers who'd been converted to the 'contract first' religion only to find out that toolkits simply couldn't handle a lot of the constructs they were putting in their schemas.Those conversations were never easy.

The main thing people fail to realize when they go down the 'contract first' route is that it is quite likely that they have also gone down the 'XML first' route which most of them don't actually want to take. Folks like Tim Ewald don't mind the fact that sometimes going 'contract first' may mean they can't use traditional XML Web Service toolkits but instead have to resort to SAX, DOM and XSLT. However for many XML Web Service developers this is actually a problem instead of a solution.


 

Categories: XML | XML Web Services