Migrating to Linux: How much Windows-like functionality to give end users?

Last week the press, especially that segment least friendly to Novell and open source, headlined the fact that 3,000 out of 5,000 Novell employees had the capability to boot Windows on their computers. One typical headline read: “Novell’s shift to open source makes slow progress.”

Last week the press, even the tech press that should be friendly to Novell and open source, headlined the fact that 3,000 out of 5,000 Novell employees had the capability to boot Windows on their computers. One typical headline read: “Novell’s shift to open source makes slow progress.”

And while the emphasis was on how many could boot to Windows (no one had numbers on how many actually did boot to Windows), few noted the real news – every single PC at Novell can boot to a Linux desktop. There are few other corporations of its size that can say the same.

This is actually a rehash of a news story from October 2004 which I covered in “Report: Novell behind schedule on Windows-to-Linux migration” and “Novell appears to have trouble digesting Linux”. Except, of course, Novell did complete the rollout of Linux to everybody.

Still, this is a cautionary tale for everyone looking to move from Microsoft’s proprietary software to open source equivalents throughout their enterprise – some things simply aren’t “equivalent” just yet.

A major stumbling block, but one that can be removed with a little bit of effort, is the mistaken notion that an open source app must not only read and write existing Microsoft Office files but must also maintain a similar “look and feel” to Mr. Gates’ offering. The thinking is that this will reduce both the time needed to migrate as well as the cost of implementation (e.g., less re-training needed).

But if you actually survey the functionality that the majority of your users are taking advantage of in apps like Word, Excel and PowerPoint I think you’ll find that it’s a small subset of the huge number of functions offered. There might even be a “reverse Pareto” function involved – 80% of your users only take advantage of 20% of the functionality. Rather than look for a 100% equivalent open source app, find one that covers the 20% functionality and roll it out to 80% of your users. Let the 20% who need the greatest functionality stick with the Redmond product as long as they need to, or until a better open source app comes along.

The issues of backwards compatibility and training (or re-training) also deserve a closer look and I’ll get to that in the next issue.