Is it just a PR move?

It goes deeper than that. Everything in Microsoft's strategic behavior for the last two years, as far as I'm concerned, can only be accounted for by the hypothesis that they know their packaged software business is doomed.

They're moving from a product base where selling Windows CDs is their major revenue stream, to where they're telling everybody where they want to be is in a business where they're the world's biggest ASP. Now people haven't really thought about this, but being an ASP is harder than being in a product business. It's more difficult: the staff requirements are more demanding, the margins are lower. Why would Microsoft go from being in an easy business to being in a hard business? I think the right answer is that they know the easy business is doomed.

Bill Gates said as much in his famous 1995 e-mail saying the Internet was the future.

They have a strategic problem, which is that somehow they have to make the transition to a Passport and .Net business model before Wall Street figures out that their current business model is screwed. If the investors figure that out before they've changed horses, then they're going to discount the future value of the stock, and the whole financial pyramid that Microsoft is built on will just collapse.

[an error occurred while processing this directive]

I wouldn't be sleeping too well if I was a Microsoft strategist right now, because that's a really hard job, especially considering that they don't even have the technology in place for the new business model yet. Even if they had the technology in place, they would have a very hard job persuading corporate managers to buy into this, simply because of the control issue. If I have all my business processes farmed out to an ASP, I don't control them any more. It's not just a matter of being dependent on somebody else's downtime as well as my own. How do I know that my core business secrets are still protected?

Speaking of security, the Internet Engineering Taskforce (IETF) recently released a draft protocol for reporting security flaws in software, which was criticized by some people as being too slanted in favor of the software industry.

That was very good, that was very well done. I skimmed it and I didn't feel that way. I remember reading it and thinking that they had chosen the time-outs for reporting requirements just about right. They chose just about the same time-outs I would.

Is there a danger of software companies exercising too much control over how and when software bugs are reported?

There's the obvious threat from the DMCA, if that kind of control is written into the license, but under current software licenses they can't control that kind of disclosure. And in fact if they tried, they'd probably run into serious legal problems. So I don't see that as a major issue.

I'm not worried about that for two reasons. One is that there are very articulate and capable people who have press exposure and credibility in the security community, who are prepared to go out there and say, "full disclosure is the only way you can get decent security" -- I'm thinking for example of Bruce Schneier at Counterpane (Internet Security). He's done an excellent job of educating the trade press on this, and there are other people who are almost as capable as he is in that way. So I think they'll keep that issue alive.

Also, one of the reasons I'm happy about that RFC (request for comment) you just mentioned is because anyone who comes under corporate pressure not to report bugs, can point at that RFC and say, hey, this is Internet best practice here, so get off my back.

Would the IETF proposal make any difference?

In that political sense, yes. I don't think that draft RFC does anything more than just slightly formalize the unwritten guidelines that already exist, as witnessed by the fact that they chose the same time-outs that I would have (laughs).

Managers have a superstitious respect for documentation and procedures, so being able to point at a document does help.

Previous page |   1 2 3	| Next page

[an error occurred while processing this directive]

[an error occurred while processing this directive]