Monthly Archives: August 2007

Microsoft Flunked Comparing 101

By  | 

It’s the thing to do since everyone is linking to the page–I just read Microsoft’s new page comparing Windows to Red Hat (www.microsoft.com/windowsserver/compare/compare_linux.mspx). The marketing group at Microsoft does impressive work. They successfully got a large number of article writers and bloggers to keep their name floating on everyone’s mind (myself obviously included).

Nevertheless, if there was a school teaching how to compare products, Microsoft would’ve flunked. The first issue is a basic logical fallacy. You cannot necessarily apply a characteristic of one specific instance to the larger group and claim it to be true of the group as well. I happen to love spicy food, does that mean everyone named Josh loves spicy food? No. Microsoft’s link labeled “Compare Windows to Linux” goes to a page called “Compare Windows to Red Hat” so they’re comparing a specific linux distribution, Red Hat, with Windows but a visitor to the web site has clicked something leading him or her to think that s/he is reading information about Linux in general. Slimy as spam, that is.

The page is arranged like a large grid where the Y axis has a list of criteria on which the products are “compared” in two columns. The first criterion is total cost of ownership. In this criterion, Microsoft mentions Red Hat’s subscription fees for support (again Red Hat, not Linux distributions in general) but doesn’t discuss other costs that one would figure go into calculating total cost of ownership. The explanation glosses over how additional software components can be adopted in the first place, which may not require certain fees that would be present with Microsoft products. Though to its credit, Microsoft provides a report discussing support fees over time. I have not fully read that so I will not comment on it.

The more problematic issue is that when you read Microsoft’s own response to TCO it slants far from an apples-to-apples comparison of what it says about Red Hat. Even though it cites certain prices and issues with Red Hat it doesn’t offer parallel information for Microsoft. In other words, it is not a direct comparison and the reader is left in the dark about how the two actually compete here.

A well-constructed comparison would consistently and systematically compare the alternatives on the same criteria, using the same types of data so that the reader can understand what is similar or dissimilar. Forget that this is a marketing vehicle and forget that this is on Microsoft’s web site, which obviously has a strong interest to publish information biased toward its own products (I don’t mean to imply anything necessarily wrong with that). A critical reader of this comparison however, ought to be suspicious because it is constructed in such a way that it does not permit the reader to actually make a comparison on the terms it purports to. I think Microsoft would have a much more compelling page if it did a proper comparison rather than trying to trick readers with lousy logic and inconsistently responded criteria.

One last thing that interested me (I won’t go over these point-by-point), is at the bottom of the page. Microsoft states that open standards do not equal open source. Actually the page says

“Open Source is a software development and distribution model, which does not equate to how easily the software interoperates with other software or how open or standardized the interfaces are.”

I tend to agree with that characterization. I love that a typically proprietary vendor is saying this when so often I see proprietary software vendors flout their work on open standards as a method of deflecting the fact that their software is not open source. It’s as though they hope the similar sounding terms will stun questioners seeking open source.

Having said that, Microsoft talks about its own products in a way that attempts to make the reader feel the products are designed to be interoperable with everything. Reading carefully, Microsoft is not claiming so much to adhere to open standards as they are claiming that their products work with their own products and their partners’ products. They also mention competitors’ products and “engaging” in standards setting activities. Search news articles about open standards processes and they’ll be rife with commentary about Microsoft tactics at thwarting standards that don’t originate from a place sustaining Microsoft product dominance. Is that how it engages in standards setting activities?

I would argue that while open source doesn’t imply open standards, it could make developing open standards easier, since none of the software is locked behind proprietary secrecy. Rather, free and open source software enables anyone to study it and tinker so that common grounds can be engineered for standards–but then, from the outset, Microsoft also mischaracterizes free.

—

Addendum: nice comment from Barbara French, refreshing a good linux.com link to an article about the previous campaign. 

Corporate Wiki, a TWiki Announcement

By  | 

After a lengthy post yesterday about TEC’s internal use of a corporate wiki, I read an announcement today from TWiki about the launch of its enterprise wiki service TWIKI.NET. TWiki is a venerable open source wiki system, with a huge quantity of interesting and useful plugin functionality. The company’s press release says

“TWIKI.NET will provide premium support to a tested, reliable and secure version of TWiki. “We’re adding a professional company to a proven software platform so Fortune 500 companies and organizations of all sizes can feel safe, supported and secure while also accessing the innovation and flexibility of the TWiki solution,” added Beckström.”

Looks like they’re taking one of the common open source business models in hand, providing services to ensure dependability, upgrades, security, features, etc. A few years ago wikis seemed to be the little booth in the corner at trade shows, without a huge amount of people paying attention to why these would be useful in an enterprise context. Persistance seems to be paying off as these wikis continue to mature and gain acceptance, and most seem to be growing from their open source seeds. The list includes SocialText, Atlassian’s Confluence, XWiki, DekiWiki, and a lot of others.

One other thing of note, TWIKI.NET has a page with brief reasons why companies use an enterprise wiki–lots of interesting reasons.

Wiki While You Work

By  | 

The Globe and Mail published an article about using wiki applications in the workplace. While not a new notion, this is the first time I’ve seen it in a regular newspaper and not an IT business rag. A point the article touches on is the wiki’s security. I think wiki security may be one of the more misunderstood issues about using a wiki for work and an important differentiating factor in determining when to use an enterprise content or document management system (CMS/DMS) and when to use a wiki. In fact, I think it’s hard to beat a wiki if you need an application to capture and disseminate employee knowledge.

“One drawback is security. Much of the hype around wikis concerns their ability to place everyone from the receptionists to clients to chief executive officers on the same virtual playing field.”

The key phrase above is that it puts people “on the same virtual playing field.” Useful things take place when people are uniformly able to document their activities, collaborative or otherwise. Simplicity is a defining aspect of wiki applications–they make it incredibly simple to collaborate on developing, publishing, or otherwise contributing to company information, documents, in some cases products, etc. I’ll talk about an internal wiki only, as I realize that one open to clients as well may present a slightly different set of issues. Still, I’d argue that in most cases the somewhat loose security issue is more of a benefit than a drawback. Let me illustrate this with how the company I work for, uses one.

Some time ago, frustrated with the problems of repeatedly sending mass e-mails to everyone in our company, I set up an internal corporate wiki. A wiki is excellent for work that is in constant flux or must be accessible by everyone in the company.

  • communicate important news or announcements
  • inform about policies that must be adhered to
  • distribute documents
  • collaborate on work issues
  • capture and disseminate the day-to-day knowledge that employees develop

I think these things fail through e-mail but work with a wiki. I think most of these things are usually (though not always) too encumbered with hierarchy structures, metadata entry, and access controls to be the most effective for the types of things I mentioned above. Even when people save e-mail messages, they must make repeated archaeological expeditions through their e-mail histories. If announcements need to be referred to in the future, there’s no guarantee people will be able to find them in an inbox. Policies and problems that have been solved are likely to be forgotten if they’re not easily present and visible, as they are in a wiki. Ensuring that people always use the most up-to-date versions of documents means making them easily accessible and that is so nicely accomplished with a wiki. Using e-mail to collaborate on projects can become a nightmare of criss-crossing information, which often leaves people out of the loop. If people are in the habit of working with a wiki on all sorts of general day-to-day tasks, it becomes an automatic, company-wide storehouse of employee knowledge.

Using a wiki facilitates these activities. For example, at TEC, internally we use the fantastic, open source Wikka Wiki application. It’s simple enough that people can be productive with it after about five/ten minutes of instruction. It doesn’t confuse with over-sparkly and burdensome features. It’s fast–takes fractions of a second to access and edit in a web browser. It doesn’t require manipulating difficult access permissions. These are all important features because they make it at least on par, if not sometimes easier than sending an e-mail or accessing a DMS. If you want to change peoples’ work habits from constant e-mail use, then I think the alternative ought to be at least as easy and efficient or else offer something so incredibly good as to compel its use.

Before the wiki, people would forget what an important policy might be after six months. Now, even if forgotten, it can be easily found for reference. Before the wiki, frequently used documents were sometimes difficult to disseminate in their most up-to-date form. Now they’re updated, in short order, on their corresponding wiki page.

Before the wiki, information about projects that different groups in the company had to collaborate on, was spread across different people’s e-mails. There was the risk that someone wouldn’t get all the information s/he needed. Now it gets collaboratively updated on pages that anyone within the company can see, which has the added benefit that sometimes people without an obvious, direct connection to the project can discover it and contribute or use it in positive ways that nobody would have imagined previously.

I don’t think a wiki replaces a DMS or vice versa. A DMS might sound like it is designed to capture and better enable such collaboration but I don’t believe that is necessarily its strongest point. I think a DMS is probably better-suited to developing documents that require tight version control, traditional hierarchy structures, and cannot necessarily be developed as content within web pages. A DMS might be more useful for archival purposes or for documents that are sensitive and absolutely must have special access controls. But a DMS tends to be more cumbersome in the security and access area, and thus loses utility in the area of capturing and disseminating employee knowledge.

Spreading the wiki. In the past, people sometimes would tell me about some sort of project they needed to work on or information they wanted to store in an easily usable way. I’d recommend they try the wiki to facilitate it. So they’d ask of course, “what’s that?” and I’d spend five/ten minutes explaining it. The interesting thing is that then they go off and explain it to other people on their teams, then the different teams work on things with the wiki, word-of-mouth makes its use spread. I’m sure this isn’t a 100% effective way to promote its use but I was pleasantly surprised that after implementing the wiki and announcing it, people started pushing its use of their own accord.

A system that requires a lot of security, perhaps needing more of a top-down approach, wouldn’t permit this type of usage to happen. Setting up access controls, accounts, and maybe designing structures for how a company uses its systems of collaboration and knowledge sharing may be time-consuming and ultimately not do the job for which they’re intended. On the other hand, a wiki method allows this to self-organize. The chaos of knowledge that frequently gets developed and lost throughout a work place gains a facility in which to reside and that attracts use.