Cost has many aspects. TCO isn’t “total,” at least not the simple pecuniary formulas I’ve seen.

TCO for Apache right now, incredibly low. TCO for Apache if you were one of the original core apache developers, using it the first year or two they were developing it? Quite a bit higher.

Whatever the TCO is for a given library using Evergreen now (and if there’s a clear certain way to calculate this, I don’t know it)–it will be significantly lower in 2 or 3 years than it is now, don’t you think?

I’m confused about your comments about TCO.

“I had been bracing myself for Breeding’s oft-repeated suggestion that the total cost of ownership (TCO) for open source could meet or exceed proprietary products.”

Certainly in theory, TCO for some particular open source project at a particular institution COULD meet or exceed TCO for another particular proprietary product at that institution. No? It depends on the products, and the institution.

So, we an take issue with people’s particular determination with particular product alternatives, or we can take issue with how people approach estimates of TCO in general (and ideally, help them develop better tools to do so). But it would be equally errant to suggest that TCO for open source _can’t ever_ meet or exceed TCO for a proprietary alternative, wouldn’t it?

“TCO can be a problematic argument. It teeters dangerously close to the rationale that OSS is “poor people’s software.” (Or as one speechifying vendor put it last year, OSS is only good for third-world countries — as if third-world countries were not deserving of good software.)”

I’m confused. Isn’t the “TCO for open source is too high!” argument, actually the reverse? If you believed this, it would be the _opposite_ of “open source is poor people’s software”, it would be “open source is only for rich libraries that can afford to put lots of staff toward it’s high TCO,” right?

I do think there are _some_ open source projects which are not wise investments for _all_ libraries. That is, for any particular library, there exist open source projects that it would not be wise to adopt. And others it would be wise to adopt. There is indeed _such a thing_ as TCO for an open source project, and depending on the project and the library, it may be too high, or may be higher than a commercial alternative.

Jonathan, I didn’t want this to be a tome (though it ended up as one… my bad…) so I elided some related thoughts that had been part of my “open source” presentation for CAVAL/VALA this fall, about the history of library automation. (You can see where this post could have become much, much longer.) In my presentation I talk about what you’re discussing — how prior to the Internet, people built library systems that became very bespoke, to the point where they were unmanageable. This was to a large part an accident of history;

I’m not the first person to point this out, but in a slightly different time-track for networking and libraries, libraries might have invented open source. (Almost makes me want to try my hand at science fiction!) In any event, the ethos of open source (as I understand it) is to point toward the trunk and away from the fork — in other words, to encourage and reward central development and put in negative incentives for localized efforts.

I’ve been involved in implementing several major MRP/ERP proprietary systems over the years, including the current leading ERP system. You are right, it is a fantasy that any of them are implemented “out of the box”. Most of them scale up fairly well but NONE of them scale up AND down as Evergreen can do. From a single PC server installation to the 270+ library implementation of PINES it seems that the same software works “out of the box”. There is no way that I could do that with an SAP implementation even if my wife would agree to “warehouse managment” of the kitchen ;-). First, the license is expensive for “home” use and it doesn’t work without extensive “configuration”.

I think that what really scares the companies building closed source is that with the economic crisis they can no longer afford the legions of implementers and consultants on staff. Companies can no longer afford the 15-20% of purchase cost per year for support/warranty. Their only hope is to spread fear among their clients. SCO tried and failed. The others will too.

By necessity, the world is going back to the “good ole days” where neighbor helps neighbor.

This has happened with lots of library-used open source software. One prime example is.

Why does this happen? Because, in the short-term, it’s easier and quicker to get something up and running this way that meets your perceived local needs. To maintain a common codebase capable of accomodating diverse local needs takes both more _initial_ time, and, significantly, some software development expertise. Library developers are frequently short on time, pressured by their bosses to meet local needs as quickly as possible–and are also frequently self-taught and not very experienced in complex coordinated software projects.

In the long-term, this is a very inefficient use of programming resources, which leads to the negatives outlined in the report. Everybody’s got their own copy of the code, enhancements and bug fixes can not be easily shared, we are not collaborating.

Indeed, this is not an inherent part of open source, and it is probably counter-indicative of _successful_ open source. But to change this is not trivial. The first step is acknowledging the problem—rather than either pretending the problem does not exist OR incorrectly believing it is inevitable with open source software.

That statement also underplays the central role that community support can serve users of an open source product. So big deal that a conventional corporate model may not be too viable for this or that project, that doesn’t mean that the community model can’t succeed!! And the corporate model isn’t the only model available, but Business Week isn’t supposed to lead readers to that revelation.

Further, support is one thing, but development is also related here. Paying for annual support and maintenance is one way to manage your risks and also support a core group involved in the development and maintenance of the project. For this reason, I think that the majority of open source ILS users will engage someone for support — I wouldn’t be surprised if well over 80 percent of open source ILS users continue to maintain “annual support and maintenance” of some kind.