Saving Microsoft

This post to /. is actually what lit the firecracker under me to start blogging. I wanted to expand on the idea a bit.

Of course, I could have done so on my /. journal. Mmmm, anyhow, I now have a blog here, so I'll use it and see if I like it.

Who on earth would want to save Microsoft? Okay, I know some people actually think they would want to prevent Microsoft from going away. They think they are dependent on Microsoft software, or something, I suppose. I can answer ever reason they can give logically, but, as I just admitted, humans are not creatures of logic.

I would not care to save Microsoft. Especially now that Open Office has (if you get good fonts) duplicated every essential feature of MSOffice, and almost all of the really important non-essentials, I cannot think of a single useful purpose in having Microsoft around.

No, keeping all the pseudo-engineers under one roof is not a useful purpose. The world would benefit greatly if they either had to learn how to do real software engineering, or get a job more suited to their talents.

(Did I say real software engineering? Heh. I know, I know, pipe dream. Not in this world.)

If, for some strange reason, I wanted to save Microsoft, I have thought of two approaches. (Did I say I have too much time on my hands? No, but sometimes on the train, my eyes are too tired to read anything I have with me.)

One approach, I thought of back when we still deluded ourselves that the government might have enough spine to split Microsoft up. Basically, split Microsoft down the product lines. So you'd have companies like

The Company That Supports the Software Formerly Known as Microsoft Word

and

The Company That Supports the Software Formerly Known as Microsoft Windows

And each company would be required to interface with the software of the others through a freely accessible, public API, so that if other companies wanted to compete, they could. Or, if that were impossible, simply require all the baby MSses to open up all their code under a license patterned after Apple's public license.

Eight years ago, such an approach could actually have saved Microsoft. It would have forced them to put the breaks on their unreasoning ambition to beat every feature list, and pursue a disciplined engineering approach.

But the cruft of eight more years of undisciplined programing has since accummulated. On top of that is the legal cruft of an undisciplined legal department that is seemingly in a race to make the US so dependent on their intellectual property that no one would dare defend the Constitution any more.

I don't think the APIs are possible to build any more. They would be so internally inconsistent that no one, including the theoretical baby Microsofts would be able to work through them, and if the courts required the baby MSses to not work together any other way, it would all fall apart.

(That might not be a bad thing, and might not be any worse, in terms of future lack of support, than the direction Microsoft is taking anyway, but the topic of this rant is saving Microsoft.)

And I doubt that opening the code up is possible any more, even if it might have, with a great deal of effort, been possible eight years ago. Too much legal funny business going on in the world of intellectual property, too many mutual destruction pacts signed by too many companies who seem to think they have no chance of making a living with real product, but that's yet another subject for yet another day.

The second approach also involves splitting Microsoft up, and also involves opening the code up, but I think it's a feasible approach.

Maybe. Human nature still stands in the way. Bill and Steve and all of us who have sucked up to them in the past. (Pardon my French.)

Anyway, the approach is a bit more direct.

Split Microsoft up into about five parts. Subdivisions? Probably not. Wholly owned subsidiaries would probably work better. As I posted to /.,

One company handles the legacy junk. Maintains it under current licenses (sans enforcement machinery) in more or less the way it is being maintained now. Maybe some necessary incremental improvements when there's no way to fix a vulnerability in the legacy framework. This company will ultimately be absorbed by the fourth company, but it is necessary for a few years.

Another company focuses on the various problems of open sourcing all the "IP" and "technology" in Microsoft's legacy products. This is important in establishing a way out for all of the customers Microsoft has locked in. This company also consults with the other companies to keep the whole operation clean on licensing. It will probably remain independent, to help it keep the other companies playing fair.

The third company focuses on hosting repositories of foss projects and on building Microsoft-specific distributions of Linux, BSD, maybe Plan 9, Apache, the Gimp, Open Office, PostGreSQL, and many other open source offerings. Oh, Wine, et. al., of course. But no funny business with the licenses. All strictly according to the open source rules, and all regularly feeding funding upstream from that huge capitalization. This company will also remain independent.

The fourth company puts the legacy stuff as unmodified as possible on top of solid foundations culled from open source. Again, no license shenanigans. Nothing from legacy is allowed here until the IP/tech group clears it. And it is kept as cross-platform as possible. This company will be absorbed into the the fifth company in twenty to fifty years.

The fifth company hunts for anything that was actually good from the legacy stuff and implements blue-sky projects to see what shakes out. The products will be primarily released under GPL3 or higher or Apache 2 or higher when implementing stuff that's really new, merged upstream or forked appropriately and without license conflicts when they borrow.

The bulk of the new income stream will be service agreements on the stuff the fifth company produces.

Why should they do this? Because it's their mess and they ought to clean it up, especially since they have all that money from making the mess.

Making such a plan work would require a small group of truly charismatic leaders dedicated to open source, with social skills to herd the cattle and the carnivores, with technical skills to keep the all the projects coordinated and on course, legal savvy to keep the frivolous, nuisance, and abusive legal activity at bay, and logical prowess to pierce the lies, damned lies, and statistics that would be generated.

And with bullet proof underwear, because somebody in the old guard would get in a panic about the intellectual property! OH NO! NOT THE INTELLECTUAL PROPERTY! every now and again.