Microsoft, Please Open Source Windows XP

The day is now upon us. After a nearly 13 year affair, marked by manic periods of love and hate, we now face the inevitable conclusion of our relationship with Windows XP. We knew that our time together was only temporary, and many are applauding the end of an era that was probably several years past its prime. As much as I appreciated the time that Microsoft granted us, I recognize that it’s time to move on.

My acceptance aside, I believe that many others are forced to remain in denial. Consider that some reports continue to pin XP usage at anywhere from 10% to nearly 30% of all desktop systems. Combine these statistics with reports that 95% of all ATMs, many medical devices and cash registers run Windows XP. I’m not one to succumb to FUD (Fear, Uncertainty, and Doubt), but the numbers imply that we face a potentially catastrophic security condition once Microsoft ceases its support for the operating system. How many vulnerabilities are hiding out there, their hacker benefactors giddy as they wait for Microsoft to cease providing security patches for XP computers? I suspect that we’ll find out soon.

Microsoft can help by making the XP operating system core available as open source software. I think that it should.

The Mobile Security Failure

Mobile has substantially changed the security update landscape, driven in part by evolving consumer expectations that champion frequent, minor enhancements over stability and security. I first discussed the defect acceptance trend in 2012 as a way to explain how software companies have been able distribute flawed software while also handing responsibility for maintaining that software to the consumer. In the two years since, accelerated use of mobile, and by extension cloud, applications has worsened the trend by limiting end-user control and forcing the consumer to accept unwanted feature changes to receive security updates. Not only must consumers accept flawed software, they must now also trade flexibility for some semblance of protection.

I’ve recently had three operating system software updates that each provide new perspective on how software maintenance has changed over the last decade. I’ll take a look at how those changes reflect new cost to consumers.

Federal Contracting Part 4: Intervention and Rehab

The challenge faced by HHS and CGI Federal to build Healthcare.gov were exceptional. They attempted to tackle an extremely complex data integration and communications platform in the relatively short timeframe of just under two years. Even without the highly charged political environment that hovered over the project, threatening to rain down at every moment, I would consider the project to be as ambitious as any government IT project has been. Add to that the directives and regulations that the project had to be managed against and I would have though initial success to have been an improbable expectation.

Federal Contracting Part 3: The Definition of Madness

There is a common assumption in government IT services procurement that past experience is an indicator of future success. But, when working with an industry that benefits mostly from the efforts of individual performers, the idea of ‘corporate’ past experience is a logical fallacy. Not only does it put the government at an immediate disadvantage, it favors repeating inefficient activities that benefit large contracting firms rather than promoting the innovation needed to move into new technology areas.

Federal Contracting Part 2: Good to be a Contracting Firm

This is Part 2 of my Federal IT Contracting series. Please be sure to check out my Introduction posting that includes a disclaimer about my past relationship with CGI Federal, the primary contracting firm responsible for the Healthcare.gov project.

My previous Federal IT Contracting posting presented a jarring insider analysis of how contracting firms realize success from failure. Some may interpret my analysis as a shot against contracting firms, illustrative of a tainted industry that deserves more oversight. With recent movements to reduce how much firm executives can earn despite very limited direct involvement on any customer-facing project, I admit to harboring some animosity towards those firms. But, having also served as an executive in a startup firm for several years, I submit that the government is far from blameless. That government managers often channel an insatiable childlike appetite for wants without really understanding what it is they need leaves them susceptible to failures like that currently embodied by Healthcare.gov.

Federal Contracting Part 1: Lucrative Failure

This is Part 1 of my Federal IT Contracting series. Please be sure to check out my Introduction posting that includes a disclaimer about my past relationship with CGI Federal, the original primary contracting firm responsible for the Healthcare.gov project.

This Washington Post opinion piece is accurate in its success through failure assessment. Where it fails is in not going deep enough into the cause, focusing instead on the visible symptom of executive advancement despite failure. I want to go deeper.

What We've Learned About Federal Contracting Through Healthcare.gov

The Healthcare.gov roll-out has been an epic debacle. If media reports are to be believed, just about everything that the Department of Health and Human Services (HHS) did for the project was wrong. From the limited procurement process, to the management structure, the scope and requirements, and the final testing, HHS is suffering from poor execution at every level.

Most of the media coverage seems to imply that the failure conditions are exceptional. Federal contracting insiders will admit, albeit quietly in some circles, that the only difference with Healthcare.gov is visibility. Set aside the scrutiny, and the Healthcare.gov failure is, unfortunately, quite common.

Cloud Computing Dangers: Just Forget About It

This is the final posting (Part 10) of the Case Study in Cloud Computing Dangers.

By the end May 15, Day 7 of our outgoing mail Denial-of-Service on Office 365, on May 15, 2012, everything returned to normal. I was thrilled to find my VA email address flooded with test messages from over the preceding week.

Relief. And then, nothing.

We received no update from Microsoft, no communication from senderbase.org/Cisco, no satisfactory closure of any help desk tickets. Nothing, except for business as usual.

Introduction to Michael's World of IT

I'm not a professional blogger and this isn't a forum for absolute facts. Instead, I mean for this blog to present an unfiltered view of my IT philosophy and how it has and continues to evolve over time.

Why me and why now? This blog isn't some egocentric examination of self or a venue to simply expel all of my thoughts on the world (at least I don't really intend for it to be). Rather, I think that the industry takes itself way too seriously when it comes to its mission to improve business and there are too few voices out there willing to really conduct a detailed and extended analysis of whether technology really helps. Journalists are beginning to get it but few truly get IT and information security in an intelligent way. Beyond that, I've found that there is way too much FUD (Fear, Uncertainty, and Doubt) that drives IT decision making. I hope that I can help folks in some small way to make better decisions about their IT and security procurements.