Comments on NOSI’s “Open Source Primer for Nonprofits”

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.

4 thoughts on “Comments on NOSI’s “Open Source Primer for Nonprofits””

  1. Many groups (Tides for example) don’t use the groupware aspects of Exchange, they just use it as a mail server. If they got *really* ambitious they might use it as a shared contact server which LDAP does very nicely (and which integrates very well with a the rock stable combo of Postfix/SASL/Courier-IMAP, which is what we’ve started deploying at Groundspring). Of course Outlook’s IMAP support is pretty weak, because MSFT wants people to use Exchange, but once you’ve weaned people from Exchange it isn’t that much harder to convince them to choose a better email client. And the upsides in terms of flexibility, and stability are huge.

    Calendaring is still pretty broken, but its getting closer, there has been real movement lately (the work Apple is doing on the Mac side has been matched nicely lately by Semaview for Windows, and a variety of web platforms). The real reason this field hasn’t moved forward more is people keep breaking their hearts trying to be compatible with Exchange, a software designed from the ground up to lock out attempts to be compatible.

    Too bad NOSI’s document is only in PDF.

  2. As the major author of the primer, I thought I’d post a couple of comments in response to Jon’s comments about the primer.

    I do appreciate the time Jon spent reading and thinking about the primer – we’ll certainly incorporate some of this in the web version, which is meant to be edited and changed over time.

    The first comment I have is about Jon’s primary problem with the primer: the omission of the issue of open source software development resources for the sector. I agree wholeheartedly with Jon that the “the development of custom nonprofit-specific software tools” is extremely important. But that was never the purpose of the primer. The purpose of the primer was to introduce people who knew little or nothing about open source software to the basic concept, and the tools available now, as well as to talk about TCO issues of implementation of OSS, and some specific case studies. I could easily write a treatise on the issue of software development, it’s been on my mind for a long time – but it was never intended to be part of this primer.

    That’s more the focus of Penguin Day which I’m helping to organize.

    As to his nitpicks – most are quite valid comments. (As to the ommission of the new resource – it was released after the final version went to press – it will be included in the HTML version of the primer that is being worked on as we speak.)

    I do want to focus on one nitpick I disagree with – that is the issue of support. The sentence that he quotes “[T]he open source community affords its users many more informal sources of support than are available with proprietary software.” is, for sure, based on the long experience of the author (me), in finding support for software of all sorts. It is not based on any empirical research, and perhaps it should be prefaced with “in the experience of the authors” or some such. But in any event, I have had far more luck with informal support resources for open source software (since when have you gotten an email response from the developer of a proprietary software product about a problem you posted on a mailing list?) than for proprietary products. Jon’s comment about consultants isn’t really relevant – I said informal sources – by that I meant community support – mailing lists, irc channels and the sort – not formal sources of support like consultants.

  3. Michelle-

    I think you make a valid point that theu *authors* of open-source software may be more likely to provide informal support than the authors of closed source software. But, my experience has always been that *informal* support tends to come from the *users* of the software. And there are, quite simply, a lot more users of non-open source software.

    My larger point is that I think there’s little ground for asserting that open-source software is better supported, and I think the NOSI report would have been stronger and more convincing without that assertion.

  4. Pingback: La Pastilla Roja

Comments are closed.