Really, your thoughts are very insightful… I hadn’t really thought about the risk argument before, but it’s a really compelling point if we’re honestly concerned about a long-term view on progress in technology and new media…

RG – thanks also for your comment… I too would love to see more open CRM systems for museums… whether that is in the form of a true open-source platform solution, or just more openness from the existing vendors to develop and support APIs that museums can use to do their own system integration… Perhaps the field could use at least one compelling open-source solution here to prod the commercial software vendors into action on this point. CiviCRM anyone?

I’m not sure you need any help–this is as succinct, clear, and judicious a summary of the major issues as anyone could want. Still, in the spirit of continuous improvement, I’m happy to share some of my reactions to the points you make. It’s a long set of comments, but I hope it’s useful. –Chris

First, under “Most museums do things their own way.” I don’t think there’s anything at all wrong with museums doing things their own way; in fact, that’s exactly what I think we want to encourage. The integration costs you mention are real–if anything, you are too kind to them, as I can point to integration projects that are at least several times more expensive than the original purchase price of the software in question. However, those costs are not immutable facts, they result from conscious design decisions by software vendors. Often, such design decisions are driven by a deliberate intent to increase the costs of integration, in order either to “lock in” customers to a particular vendor or to ensure a steady stream of additional revenue to the vendor from making the needed changes, or both. If one instead builds the software to anticipate and facilitate the need for institution-specific adaptation, many of those costs (though not all) disappear.

The primary objective of any truly effective, strategic technology should be to get out of the way of the people trying to get the work done. You make this same point yourself, under “Shared tools let us take the same road to different destinations.” Consequently, a better strategy from the museum point-of-view, and one that is embedded in every enterprise software project supported by Mellon’s Program in Research in Information Technology, is to design software to support affordable tailoring to the needs of each adopting institution. This allows museums to collaborate together on those aspects of the technology they share while still adapting the software individually to the way they work, and not vice versa.

Under “Museums have small amounts of money,” it has recently become possible to quantify the sorts of savings that these projects can provide. The data are taken from collaborative projects in higher education, and are based on pricing by vendors from both the collaborative projects and their traditional-model competitors. They show that the largest institutions tend to save 50-60% as compared to traditional software options, while smaller institutions often achieve savings of 90-95% (keep in mind that the largest museum in the world has the budget and staff of only a medium-sized college). These data are for mature projects in a different non-profit sector, and we do not yet have comparable data for the museum world, so it is impossible to know for sure what savings museums may realize going forward; however, the higher education data are certainly suggestive, and there is no known reason to believe that museums should save any less as their own collaborative projects mature.

For “Museums don’t compete with peers like businesses do,” I would add one further argument in favor of collaboration. Even in those comparatively rare cases where museums do compete directly in some sense, it is almost never the case that they compete directly on information technology. Patrons are not going to choose one museum over another because of the collection management system, or the brand of audio tour device; at most, they choose based on the quality of information generated by that system or delivered through that audio tour device. Consequently, institutions that do compete arguably have even stronger incentives to collaborate than those that do not–because collaboration drives down their technology costs faster, freeing up resources that can then be allocated to the activities (e.g., generation of better-quality expository content or better scholarship or better educational offerings) that really do offer a competitive advantage. That’s one reason why we’re starting to see the same sorts of technology collaborations forming in the business world as well: firms that join these collaborations free up resources that allow them to compete better against the firms that don’t.

For “Museums have long traditions of collaboration,” I would only add my hearty endorsement. A few years ago, when my program first started looking at investments in museum technology, I was told by almost everyone I met in the museum world that museums “weren’t ready” for the kinds of collaboration that our projects require. What we’ve seen since those projects were launched has been something much closer to what you describe: many museums, large and small, have embraced the projects, usually joining even before the projects’ benefits were fully realized in order to have a say in shaping their direction. The quality of community deliberation in the design processes for the CollectionSpace, ConservationSpace, and Fluid Engage projects has been tremendous–easily as powerful and effective as those in any other domain in which my program works. That ability to collaborate is particularly important because museums lack some of the “federating” institutions that are common in other domains, such as regional library consortia, which can foster and facilitate inter-institutional collaboration on technology. Consequently, the burden of collaboration tends to fall more squarely on individual museums. So far, at least, the willingness of museums to shoulder that burden in order to realize the substantial benefits of collaboration has been everything that anyone could ask.

Under “We find better solutions when we collaborate,” I would encourage you to incorporate the issue of risk as well as of cost. Building software alone, either in-house or through a vendor, is surely expensive, and gets more so as the software ages; however, it is also risky, and the more sophisticated the software, the greater the risk. There are at least three major dimensions of risk: the risk of initial failure (“we didn’t know what we needed to know to build this successfully” or, “we didn’t have the resources we needed to get it done”); the risks of ongoing failure (“we got it built–but now we need to maintain it, and it just keeps getting harder and more expensive”); and the risks of excessive dependence on scarce or irreplaceable resources (“Bob built us a great system, but what if Bob gets hit by a bus?” or, “our vendor got bought, and the new owner wants to double our maintenance fee and force us onto a new system”).

In my job, I have the luxury of working at times with non-profits having IT organizations of more than 1,000 full-time technologists on staff, with budgets exceeding a quarter of a billion dollars annually. These are IT units that any large firm would envy for their size, sophistication, and quality of talent and execution. Not long ago, I sat in a room with CIOs from three such organizations, each of which is a participant in several of our collaborative projects. When asked why, each CIO said some variant of the same thing: “we collaborate on software development because it is unsustainable for us to go it alone.” When pressed, each cited the risks of solo development as dwarfing even the costs in shaping their decisions. But if the risks are too great for these huge organizations, with their deep financial pockets and immense pools of human resources, then how can they possibly be more manageable for organizations having only a tiny fraction of those resources and very little margin for error? Software collaboration not only amortizes cost, it also amortizes risk by pooling the resources needed into quantities adequate to ensure the immediate and long-term success of a software project. It’s one thing to accept risk because you have no choice; it’s another altogether to forego an option that reduces risk when it is readily available.

Under “Vendors need our help to build better tools,” it might be worthwhile to consider also the issue of ownership of intellectual property. One of the most important reasons for museums to collaborate on technology is to preserve their ownership of the intellectual property they generate regarding the performance of their work. When you help a commercial vendor to build a system to suit your needs, you are basically handing ownership of your own intellectual property to that vendor and allowing the vendor to sell it back to you at a profit. That’s a great deal for the vendor, but less often a great deal for you. When you collaborate with other museums, on the other hand, you can pool your intellectual property and preserve ownership (e.g., via a software foundation with a participatory governance model). This protects your institution’s agility and self-determination going forward in ways that traditional software business models find very difficult to match.

Finally, it might be interesting to talk about the value of forming a community of practice. Before institutions join one of the Mellon-supported “community source software” projects, they tend to focus on the costs and benefits of the technology: they want to know how much they’ll pay, where they’ll get support, whether the technology performs this or that function, whether it will still be around in a few years, and so on. However, time after time, when I talk to the same institutions 2-3 years after joining a project, these issues have dropped almost completely off their radar, to be replaced by discussions of the value that the institutions have found from participating in the communities of practice that form around a project.

Something like CollectionSpace isn’t just a collection management system, it’s also a “community of practice” consisting of collections managers sharing, not only similar interests and concerns, but also a common way (i.e., the software) of addressing those interests and concerns. Collaboration around the software spawns discussions of practices at different institutions that quickly become conversations about best practices for various situations–and these conversations tend to generate transformative changes in the participating institutions. The result is that institutions participating in the communities rapidly accelerate away from those that don’t participate in the sophistication of their thinking about the problems and opportunities that they face. The larger and more vital the community, the greater the transformative power, and the more diverse the opportunities for the sharing of potentially transformative information. That’s why institutions already engaged in such projects spend more time talking about the community benefits than the technology benefits; it’s also why institutions that join one “community source” collaborative project are highly likely to join a second (and sometimes even a third) within a year or two. In the testimony of the participants themselves, the most compelling long-term benefits of the projects, dwarfing even the financial and risk-management benefits, tend to be the less-obvious, human-capital-building capabilities of the communities of practice.

while we are on the topic of fundraising, someone ought to create a grant to hire an “open source museum CTO” to go around the country training and evangelizing the benefit and savings as you so nicely wrote. The museum industry as a whole could save a huge amount. You seem perfect for the job