My colleagues over at NOSI (Nonprofit Open Source Initiative) just released their first big “think piece” called “Choosing and Using Open Source Software: A Primer for Nonprofits.”
This is an admirable effort on an important topic by some outstanding folks, but there are some critical points the authors overlook, as well as some factual errors that should be corrected.
My most substantial critcism is that the NOSI primer focuses too heavily on basic computing infrastructure such as file servers, email servers, desktop operating systems and office productivity software. In doing so, NOSI ignores what I think is the the single most important area where nonprofits should be exploring open source solutions — the development of custom nonprofit-specific software tools.
Over the years, nonprofits have invested millions of dollars in software development projects to build a vast array of custom software to conduct their business. While much of this software is either of low quality or is so specialized as to have no value outside the organization for which it was written, there’s a lot of software out there that needs to be shared more widely. While open-source platforms provide a potential framework to do this, I think it’s far more important for nonprofits to focus on building open-source nonprofit-specific applications, which as Jonathan Peizer has pointed outwill require substantial investment in the tools and methods for collaborative software development. I was rather shocked to see that NOSI mentioned Jonathan’s paper without showing much evidence that they had absorbed the main thrust of his argument.
On to the minor nitpicks…
Another factor to keep in mind is that with proprietary software, you may have to pay for separate software tools
that are not needed with the OSS solution. For example, separate software is available to perform automated backups of Microsoft Windows servers, whereas with the Linux operating system, automated backup tools are included. (Page 9)
I’m not sure I buy the general principle, but the example cited is simply not true. Windows servers do include automated backup tools. Backing up networks of desktop machines — of any platform — requires either expensive add-on software or fairly complex and hard-to-maintain scripting.
In the midst of a larger — and generally valid — point about the relatively greater security and reliability of Linux systems, the NOSI paper states that
[C]omputer viruses have not affected Linux,
while they are prevalent on Windows. (Page 11)
While viruses that infect Windows systems are indeed common, a quick search of the Symantec Antivirus Response Center’s Virus Encyclopedia turned up 2391 hits for viruses, worms and other nasties that have infected Linux systems over the years.
The vast majority of vulnerabilities these virsues exploit have been patched, but so have most of the vulnerabilities that Windows viruses/worms exploit. The main reason systems get infected is because users and administrators fail to patch known vulnerabilites.
I believe that much more nuanced points should be made about how the open-source community may be able to more readily identify security vulnerabilities and may be able to offer faster and better fixes to identified vulnerabilities.
[T]he open source community affords its users many more informal sources of support than are available with proprietary software. (Page 11)
Huh? What hard data is this assertion based on? Especially when in the same paragraph, the authors admit that finding qualified consultants for open source solutions is a big challenge! Last time I checked, the Internet was chock full of “informal support resources” for both proprietary and open source software. Some of them are excellent, and some are not. But I’ve never seen a single study that suggests that either the number or quality of informal support resources depends on the licensing terms for the software. In fact, I would tend to suspect that the vastly greater number of people who use proprietary software would lead to a greater variety of informal support resources, not fewer.
Later in the study, the authors offer a sample TCO comparsion in which the only significant cost difference between an open source email solution and a Microsoft Exchange solution is the authors’ assertion that the open source solution requires half the maintenance time of Exchange. This assertion, the authors write, “is based on the information in one of the case studies, and is borne out by the experience of four of the authors of this primer who have experience with both operating systems.” I don’t think this is the most convincing evidence to base a TCO analysis on.
In addition, comparing Exchange as a mail server to the common open source proudcts such as Postifx/Cyrus/etc is really comparing apples to oranges. Exchange is far more than just mail — it’s also full-fledged groupware and collaboration software. Despite a number of efforts, there still is isn’t really a true open source substitue for it. If the authors wanted to make a fairer comparison, they might have compared the open source platform with a widely used proprietary SMTP/POP/IMAP server such as Communigate or iMail.
Finally, one helpful resource that was omitted from the NOSI Primer was the Commons Group recent article at Choosing Open Source. It sounds many similar themes.