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.

An article on voting machine selection in the Boston Globe, caught my interest the other day. The infamous Diebold company seems to be suing the Commonwealth of Massachusetts for improperly selecting a competitor’s voting machines. Nevermind my opinion on the quality of Diebold’s voting products, the article caught my interest because of my involvement in complex software selection projects.

According to the article, Diebold claims the office of the secretary of state failed to choose the best voting machine. My first inclination is to assume that of course Diebold would say that, it’s the competition. Presumably the office of the secretary conducted some sort of selection process and based on whatever factors it defined for the decision found that the AutoMARK machines were better suited to its needs.

Assuming there truly was a fair and accurate selection process that led to the purchasing decision then Diebold appears out-of-line. However, what was that process? The article doesn’t discuss it. Wondering if it was made public, I did some searching but didn’t have much success finding any public record of what that might be.

Sometimes one can find public RFPs but there are many different methods used in government procurement processes. Perhaps if government selection processes are conducted well, with a verifiable trail of due-diligence, they should also be consistently made a matter of public record. That would ward off the impression that anything/anyone had undermined the selection process and improperly awarded a contract.

Chatting with one of my colleagues about this issue yesterday, he mused that our company often has an easier time offering our selection methodology services and tools to “developing” nations’ government organizations than to the “developed” ones. He came from a region that might yet be considered to have a developing nation status. I asked what he meant, and to paraphrase, he replied that often when you look at nations where the government has undergone a lot of upheaval, the public has a strong perception that government corruption needs to be brought under control. So these government organizations may be more easily willing to implement selection methodologies with well defined trails for due-diligence. Whereas countries with long-standing stable governments may employ officials that don’t feel quite the same pressures.

I suppose that’s only one person’s speculation but it reflects an important point: without a well-defined and documentable selection process, you open-yourself to the impression of bias or corruption. Based on information in the Boston Globe article, I don’t think we can assume anything corrupt necessarily happened within Massachussetts’ selection process. But it seems to illustrate a fine reason for why organisations (government or not) should carefully document processes, priorities, factors for decision-making, and respondents’ capabilities during their complex selection processes.

Novell and Microsoft, what are you doing? The news is out, Novell and Microsoft are partnering for the sake of office document interoperability, virtualization, and service oriented arch smoothness. After reading the press, I’m left with a few irksome thoughts on what this amounts to. In spite of the potential upside to what this agreement may result in, as well as the fact that it appears Microsoft is publicly recognizing a requirement to somehow support Linux based on real customer demand, it also sounds like a dodge of something that isn’t being explicitely said.

1) Virtualization. According to Jeff Jaffe, executive vice president and chief technology officer at Novell, “As a result of this collaboration, customers will now be able to run virtualized Linux on Windows or virtualized Windows on Linux.” But this is not accurate. Customers are already able to run virtualized Linux on Windows or virtualized Windows on Linux via applications like VMWare, Parallels, and others. So the virtualization hype produced in this announcement sounds a little much, at least on the surface. Perhaps the two companies will produce something exciting and effective but the customers’ ability to do what they’re saying is not coming as a result of the Novell/Microsoft collaboration since that ability already exists.

2) Web services. “Microsoft and Novell will undertake work to make it easier for customers to manage mixed Windows and SUSE Linux Enterprise environments and to make it easier for customers to federate Microsoft Active Directory® with Novell eDirectory.” Ok, that sounds good. Though what does it portend for the future? Mitch Ratcliffe comments from ZDNet:

“I’m not saying Microsoft is evil, only that it makes these interoperability deals to defeat its partner, not help them. In the 90s, when both Windows and Novell Netware were under assault by IP networks, they tried to co-exist. Microsoft started making Netware-compatible versions of its local area network management and operating system software.”

One wonders if this is a matter of history repeating itself.

3) Document format compatibility. This seems to focus on improving the compatibility between Microsoft Office and OpenOffice (as Novell distributes it anyway). Err the document formats these applications use. Considering OpenOffice defaults to the Open Document Format (ODF) standard and Microsoft has been under increasing pressure to adhere to that standard or at least support it in addition to its own formats, this doesn’t really seem like huge news. This move toward compatibility has been ongoing anyway.

4) The thing that gets repeated over and over throughout the press release is the mutual affirmation not to kill each other over patents. And this is what I find a little weird about the whole thing. For the number of times this was mentioned and the lack of detail in why this is so important, it feels like a red herring to me. I wonder if this was designed to ward off or compromise on certain actions the companies may have been considering against each other. Here is a point on the monetary side of things from the press release

“Under the patent cooperation agreement, both companies will make upfront payments in exchange for a release from any potential liability for use of each other’s patented intellectual property, with a net balancing payment from Microsoft to Novell reflecting the larger applicable volume of Microsoft’s product shipments. Novell will also make running royalty payments based on a percentage of its revenues from open source products.”

Jason Matusow writes in his blog:

“What it really means is that customers deploying technologies from Novell and Microsoft no longer have to fear about possible lawsuits or potential patent infringement from either company.”

I wonder how much customers really had this fear. It seems like such a fear surfaced for a little and a number of companies began offering indemnification programs for open source solutions. But that faded rather quickly. Perhaps because the threat isn’t real enough to pick up many clients. I don’t remember exactly how this went, but the last LinuxWorld Expo I attended, there was a session in which conversation shifted toward the legal aspects of just how real or likely such lawsuit threats were. The opinion seemed to be that they were mostly FUD. Considering how “successful” ones like the SCO case are, it doesn’t seem like this has had a huge impact to many customers. Yet here Novell is, apparently ready to make royalty payments to Microsoft based on open source solutions it sells and so I am reminded of Mitch Ratcliffe’s comments again (which I cited above), where he likens the agreement to Dracula’s modus operandi.

In all of this, nobody hesitates to point out that this may be, at least in part, a response to Oracle and its recent Red Hat move–competitors to Microsoft and Novell. Steven J. Vaughan-Nichols of Linux-Watch has an insightful write-up about this. If there’s going to be a dominant enterprise Linux platform, Novell would certainly rather have SUSE be the one and I’d expect Microsoft can only stand to gain by appearing aligned with a strong distribution that could give it comparable access to enterprise customers using Linux.

——

Addendum – 22:51

The red herring of this deal that I mentioned I suspected, may have been revealed by Bruce Perens. He theorizes that this is actually a means for Microsoft to set up the conditions for an environment, which enables it to sue. It would seem to need some “correct” paths available before pursuing patent suits against Free software systems.

“Even if everyone were to be protected regarding software that Novell distributes, there’s the tremendous collection of Free Software that they don’t distribute. A logical next move for Microsoft could be to crack down on “unlicensed Linux”, and “unlicensed Free Software”, now that it can tell the courts that there is a Microsoft-licensed path. Or they can just passively let that threat stay there as a deterrent to anyone who would use Open Source without going through the Microsoft-approved Novell path.”

That’s quite a strategy. Except there is some question as to whether Novell would still be able to even offer something under a GPL license. Furthermore, I have a hard time seeing how this could ever truly be that effective. A GNU/Linux system has many heads, which appear in a widely dispersed environment of physical and virtuals realms, governed by a multitude of laws that are not all US-based, and embraced by many people that just don’t need to care. I don’t see them all being cut off.

In a recent article from Harvard Business School’s Working Knowledge, Sean Silverthorne, does some Q&A with Ramon Casadesus-Masanell and Pankaj Ghemawat about their research on the competition between Microsoft and Free and open source software (FOSS). It’s detailed and raises issues on FOSS distribution versus proprietary in relation to user adoption.

The article notes that “By lowering the price of Windows, the demand for Linux shrinks to the point where Linux is not a threat to the survival of Windows.” If I understood correctly, I don’t think that their study was intended to look at issues outside the scope of their economic model. Thus, the following is not criticism but rather some extra thought on the matter. I think there could be other issues that might make Linux a threat to the wide-spread survival of Windows.

For example, perhaps this is unlikely but if Windows exploits, viruses, etc. increased to the point where nobody could realistically use the operating system safely I would imagine totally different sorts of reasons compelling people to adopt Linux, namely privacy or safety concerns. Some time ago, I presented an article on how I thought a lean OS delivery strategy could really impact user adoption. I don’t see Microsoft able to do this, I think it is something that only a FOSS OS could accomplish because of the nature of the FOSS development/community/business models.

And what does the study discussed in the article illuminate?

The article discusses FOSS “demand-side learning” in which the development cycle is shorter because users have the opportunity to improve the software by modifying the code or contributing ideas. This may give the impression that FOSS, by virtue of increasing demand-side learning, would displace the position of proprietary software. However, the study’s authors note that their economic model does not show that to be the case.

They point out that “…the value of an operating system depends critically on the number of users, traditional software has an advantage…” that is, its usage is already spread far and wide. This first-mover advantage seems critical, according to their model, in what would prevent Linux from overtaking Windows.

In spite of demand-side learning, technically better software, and cost advantages, they note that without strategic buyers (such as governments or large organizations that choose to do wide-scale Linux rollouts). It’s not likely that Linux will overtake Windows. Because of some those factors, they also note that Microsoft ultimately gains from people copying and distributing the Windows OS, even when MS doesn’t receive payment for the copies.

I also thought their points on societal welfare were interesting, in that they find “…a monopoly of Linux is always preferable…to a Windows monopoly…” but that it’s “ambiguous whether a duopoly Linux-Windows is better than a Windows monopoly.” I don’t think this takes into account issues like the importance of freedom within the context of modern technical societies. I would like to know more about what they considered in societal welfare.

Finally, among their recommendations for Microsoft, if it wishes to remain competitive (and I guess “remain” is the correct word since we do see sizeable Linux increases in demand-side learning as well as the key strategic buyers they identified, taking action) is one that MS increase its demand-side learning. The thing is, how could Microsoft do that? The study recommends a number of methods. However, I don’t see a way for proprietary vendors such as Microsoft to seriously increase their demand-side learning enough to be competitive with FOSS communities, unless they themselves go FOSS.

Even though some sites have reported on this study from the perspective that Linux cannot overtake Windows, rather I think that so long as MS stays proprietary, the study points toward the direction of Linux.

——

Update: Dana Blankenthorn at ZDNet commented on this study as well. Dana brings up some other ideas that weren’t addressed in the study, like “…the idea that open source isn’t filled with clever entrepreneurs…” which I suppose heads toward something I was trying to show, that there are outside factors, which may be unexpected and could contribute to the competition in wholly different ways.

However, Dana seems to argue that the Harvard article is filled with conjecture and overreaching conclusions. I didn’t interpret it that way. I had the impression that the Harvard conclusions were drawn for only a very specific set of parameters as defined in their economic model. I don’t believe the conclusion was that “Microsoft will always beat open source.” in fact, while I saw that quote in Dana’s commentary I can’t find it in the original article.

Rather the original article seems to provide conditions that could lead to either side gaining or losing ground. The article says “Ultimately, the authors believe, neither side is likely to be forced from the battlefield” which is a rather different conclusion. The authors also hypothesized the following if MS set the price of Windows to zero “…Thus, we conjecture that even in this case, there would be people developing and using Linux…” and I don’t believe that conjecture helps support Bankenthorn’s interpretation of the article.

Why do I bring this up? Simply because I don’t think the original article was prophesying the future so much as examining what might happen under different conditions.

The Canadian Association for Open Source (Clue) published a thought provoking letter to an ITBusiness.ca article today. The Clue letter says that “…What is needed is for the government to separate the pricing and procurement of the source product from the various value-add services…” which is an interesting reflection for current musings about Public Works and Government Services Canada’s proposed potential changes to government procurement processes. It’s certainly feasible to evaluate these separate areas in a sophisticated way that still allows for a comprehensive decision.

The point here is that with Free and open source software, frequently one is at a loss trying to get a development community to respond to particular business issues when the issues are peripheral to the development of the software. The reason is not because the development community is basking under the dream of an intoxicating four-leaf clover high grown in artificial pleasure pods, but because it’s outside the scope of what they’re pursuing and toiling at, namely developing the software. Such business functions are often taken up by other service organizations (which are generally a part of the development community too) that do focus on implementing, supporting, customizing, etc. the software.

Why address the letter to an ITBusiness.ca article? I’m not entirely clear on that, however I do see the sense in linking the issues. Various other ITBusiness.ca articles report on the change in procurement processes as involving a decrease in the number of qualified suppliers, perceived increase of barriers to SMB providers, and introduction of methods such as electronic reverse auctions, which some people seem to be claiming would emphasize low initial costs at the expense better long-term purchase strategies. If I understand correctly, I think that what the Clue article proposes fits with what would work well for the channel partners of large vendors (whether they’re open source or not). It recognizes that channel partners provide valuable services, which risk being slashed from the procurement process (if the ITBusiness.ca articles’ various representative quotes are accepted). These services actually may be valuable toward saving taxpayers’ money in ways that could not be accounted for if the government focuses on purchase costs with only a few vendors directly. So these channel partners are essentially the equivalent to the general open source type of business, which is about providing value-added services around a typically, zero-cost product. They naturally share a goal here.

On the one hand the proposed procurement process change sounds like it may favour FOSS solutions because of upfront cost factors. But if these solutions cannot even be considered because the actual providers can’t get the opportunity to be part of the process, it’s moot.

This is about consulting-in-the-world. :-) (excuse my weak, philosophy in-joke)

Paul Murphy posted a thought-provoking piece concerning consulting bias (plus), called Corporate loyalties and the temporal disconnect. He calls attention to the idea that people cannot really claim to be unbiased. We are wise to disclose bias so that we know how to deal with it and how it affects the decisions we make. I understood Murphy’s point to address more of the way people compare, for example, a product now with their experience of it in the past not taking into account the context of the comparison being “now.”

“…the memories haven’t changed, but circumstances have – and basing actions on comparisons in which one side is frozen in time is therefore intellectually dishonest.”

He elucidates this conclusion with several situations in which types of temporal bias would affect a decision. The post mostly is being asserted as the viewpoint of a consultant and clearly it is supposed to focus on a particular type of bias–the temporal sort, but of course there are other types of bias to take into consideration. That’s why I liked his point that

“The whole bias issue generally represents a fundamental mis-understanding of the problem evaluation process: open bias is often a positive thing…”

So, in thinking about these points, I had to reflect on TEC (the company for which I work). Our site frequently proclaims that we’re “impartial” and we attempt to present analysis of software data without bias. Is that really possible? On the one hand, I’d like to say yes because the way we evaluate the functionality of, say, an open source ERP vendor against a proprietary one is based (this is the most rudimentary way of saying it, actually it’s more involved) on a program that calculates features supported against those not fully supported. In other words this should take out the human bias that might be present in a consultant trying to recommend a system to its client. The consultant may be susceptible to the temporal situation pointed out by Mr. Murphy or, more likely, might be involved in a certain business relationship with vendors that provides an incentive for recommending those vendors’ solutions. Our company on the other hand, has no alliance to any particular vendor.

However, I have to think that using a program to weigh functional capability and a lack of alignment with specific vendors, do not necessarily equate to a lack of bias. At some level we could probably discover some form of bias. For example, as our analysts model the criteria on which to evaluate vendors because they rely on their research and experience they probably introduce, however innocently, certain biases. I can think of one simple example right away. Before open source software became a well-known enterprise commodity, many of our analyses did not include criteria for open source database support, thus in some ways, perhaps proprietary solutions had a form of advantage.

I would hesitate to call this criticism but rather I think this may highlight a reason why analysts, consultants, etc. have to be constantly self-critical, constantly trying to reflect on why they conclude certain criteria are applicable toward software comparisons and merit further research or recommendation. Thinking on the processes we undertake to form these analyses, comparisons, or conclusions may also be enlightening toward trends of the times. And that comes back to Murphy’s point on the changing circumstances of temporality.

WebCPA published an overview of some of the issues involved in Linux and open source deployments for the SMB crowd. It mostly focuses on some of the financial packages available, mentioning companies like ACCPAC/Sage, Open Systems, and InsynQ as offering their solutions for a Linux platform. The article, while providing what I thought was a pretty wide-ranging overview, seemed blurry on a few points though (noting, for example, that there would soon be Macs able to run Linux natively–actually that’s been possible for a long time, and mentioned freeware when I believe it probably meant free software).

The main thing that interested me was its discussion the companies that provide accounting solutions for open source platforms, most of those recognized in the article, actually seem to fall a bit short. Indeed, to quote a comment from an ACCPAC reseller presented in the article

“…Beck says most Linux installations involve running IBM DB2 database on a Linux server while running the accounting application on a Microsoft system.”

I wonder why that is? Shortly after, the article states the following

“Sage Accpac, which supports both Windows and Linux, estimates this year that as much as 20 percent of its installations were on Linux, up from 12 percent a year earlier.”

If that’s the case, I wonder why they’re not putting the complete system on Linux as opposed to setting up a mixed environment? Some of the arguments presented say that “the midmarket is not asking for it.” Is it that straightforward? I wonder if that means they’re only considering people that specifically say they want Linux. What if people want benefits, cost, support levels, functionality etc. that may be provided by a Linux platform but have not thought specifically to demand that via Linux? I have the impression that answering “the midmarket is not asking for it” seems a little incongruous with the rest of the stats about its deployment. I’d like to know how these match or do not match.

Finally, although the article highlights some proprietary financial apps that run with Linux or MySQL, it doesn’t mention a single financial application that is, itself open source. They exist though, perhaps I’ll follow up on this in the future.