As I’ve worked in the museum technology field for the past several years, I’ve come to really appreciate the need for museums have for good easy-to-use software tools that we can each share and extend. We’re simply too small of a market to do it all our own way.
So, at conferences and parties, I invariably end up on a soapbox talking about how museums need to build tools to give away to each other. I’ve done this more times than I’d care to admit. (I know, not the best way to spice up the party!) Chris Mackie from the Mellon Foundation gives this spiel better than almost anyone I know. Maybe Chris or others will chime in and help me refine my list.
I decided to take a crack at it myself – and to work it into 100 words or less.
OK, so I cheated by only doing this in outline form, but if you care to read the explanation behind the spiel click through for more.
So, next time your stuck in an elevator with your museum’s director and want to convince him/her about why your museum should use open-source software – whip this little baby out of your pocket-protector, and try not to get fired! -Rob
Museum Software: The Case for Shared Tools
The Situation
- Museum software problems are hard
- Museums have small amounts of money for technology
- Being a good client is challenging
- Most museums do things their own way
The Opportunity
- Museums don’t compete with peers like businesses do
- Museums have long traditions of collaboration
- Museums endorse the wisdom of common standards
The Solution
- We find better solutions when we collaborate
- Shared tools let us take the same road to different destinations
- Vendors need our help to build better tools
- Museums should act sooner not later in adopting open standards
The following is a brief statement which attempts to articulate both the frustration and opportunity which exists within the museum community regarding the current state of tools available to help us make a difference in the world. Many museums seek to make an impact in ways that often have little to do with technology, yet we are witnessing how quickly culture is being shaped and influenced by the web. The fact that museums are increasingly dependant on technology to achieve the impact they desire is unavoidable. The poor quality and availability of tools to support museum professionals in this effort should make us feel uncomfortable
The Situation
Museum software problems are hard
Many people assume that software for museums is simple and straightforward. But given more thought, they soon discover that the tools that museums need reflect a complex set of workflows and information that needs to be managed. Couple these requirements with preservation issues and an institutional mission which mandates public access and you have a recipe for a class of software problems which rivals many enterprise business systems.
Museums have not historically been early adopters of new technology, but that fact is changing as the use and integration of social media tools becomes an area in which museums would like to make advances. It should not surprise us then, when we struggle to find tools that fit our needs. Some of the tools we use have been built from the ground up to support our particular industry, but many of these have been poorly supported and updated since their creation. Certainly the museum community has benefited from the quality work of a few notable software vendors; however the resources of these companies are necessarily limited due to the small size of this particular vertical market. Others tools we use, were initially designed for different industries altogether and museums have customized and put them to use in new and sometimes unanticipated ways. In both cases, software quality and ease-of-use leave a lot to be desired. Museums should not just accept that this is the case.
Museums have small amounts of money for technology
If you survey museums across the country, you will notice that they come in all shapes and sizes. Some have annual budgets in the hundreds of millions of dollars, and others have almost no budget at all. In most cases, it is fair to say that technology spending typically accounts for a small percentage of the overall budget.
That doesn’t mean that museums don’t spend money on software, just that the typical investment made by museums during a given year is small compared to many other industries. From the perspective of a commercial software vendor, this makes museums a relatively small and specialized vertical market.
Being a good client is challenging
Vendors do not bear all the blame for the bad experiences many of us have had with software projects. Museums share a good portion of that problem as well. One aspect that has been so refreshing about working in this community is being surrounded by experts from a thousand different subjects. As brilliant as they are, it’s fair to say that museum experts are not often technology experts. Most museums do not have software professionals on staff to help them to create or managing technical projects successfully. Even those with years of technical experience find it challenging to effectively communicate all of the specific requirements needed by a software vendor to successfully pull off “the next big thing”. Consequently, museums are often not very good at being clients. We have a hard time expressing exactly what we need and we don’t share a common vocabulary with the creative professionals actually producing the software we pay for.
Most museums do things their own way
Because the work of running a museum from day to day is a complex task, museums tend to fall into patterns and ways of working which often pre-date the tenure of many current staff members. We love our idiosyncrasies and often seek to adapt our software tools to our working methods and not the other way around.
This predilection for customized tools has an impact on our technology projects too. Integration costs are the bane of any museum software project. In addition to the price paid for the purchase of a particular piece of software, museums frequently pay additional costs to customize these tools for their working environment. These integration costs can easily approach 25-30% of the total project cost. Integration software has a very low degree of reusability and makes version upgrades and support troubleshooting much more difficult.
Is it possible that museums could find efficiencies in operations and at the same time reduce software costs if we could standardize our workflow requirements?
The Opportunity
Museums don’t compete with peers like businesses do
In business, a competitive advantage over your rivals is often the difference between success and failure, between paying your staff and laying them off. The same is not true of the museum industry. Significant revenue streams for most museums bear no direct relationship to any perceived competitive advantages that may exist over peer institutions. In fact, it could be argued that donations, grants, memberships and even attendance may be bolstered by effective and strategic collaborations not competition. Leisure tourists are just as likely to visit a museum in New York as they are to visit the museum in L.A on their next trip west. Lovers of art, music, history, etc… are arguably more likely to visit whatever museum is close by than to hold any particular affinity for one museum brand over another.
This is a very different situation from that of the small or medium sized business. The argument extends to software tools as well. Why wouldn’t museums seek to share resources, tools and requirements in a way that provides the most “bang for the buck” for the entire community?
Museums have long traditions of collaboration
Museums have a leg-up on collaboration given the long standing networks of institutional relationships that have developed as a result of shared exhibitions, loans and other collaborative projects. In many professional disciplines within museums, there are vibrant communities of experts who share information and practice with each other on a regular basis. The same is true in the museum technology community. We have well established conferences and professional venues where we share information and case studies about technology projects. We see many similar efforts in museum technology, but only a few good examples where several institutions actually choose work together using the same tools and practice. What is the cause of this? Could this be due to a lack of standardized practice? Or is there still a perceived competition between museums to see who is best?
Museums endorse the wisdom of common standards
The ground work for shared tools and standardized working methods has already been started by our collections professionals. Museums generally see the wisdom and long-term benefit of standardizing data description and cataloging practice. The museum technology field should leverage those prior efforts, by taking advantage of existing standards as a medium of exchange between museum software products, and by creating new standards which can represent those common workflows and operational needs that we all share.
The Solution
We find better solutions when we collaborate
Museums do not have the time, financial resources, or technical experience to “go it alone” and hope to achieve quality software tools that are easy to use and maintain. Given the lack of competitive necessity described above, collaboration between peers seems to be an obvious way forward. Collaborative platforms and shared tools leverage the experiences and talents of each museum and result in a vigorous and robust supply of expertise and resource from which the best results can be drawn.
Open-source technology projects owned by a community of invested stakeholders, offer one particularly fertile ground for this type of cross-institution collaboration to take hold. The absence of licensing fees and the ultimate flexibility for integration and enhancement mean that a museum’s dollars of investment can more directly impact feature enhancements and underlying requirements.
In a strict financial sense, shared tools are a better investment than proprietary solutions. Instead of spending $50,000 every time we want to deploy a new enterprise platform in the museum, why not leverage someone else’s investment and use our money to enhance the tool for both of us? This strategic shift, taken to its logical conclusion, would have a correspondingly significant impact on the smaller institutions in our field. Suddenly a small museum with no budget for technology has equal access to tools with hundreds of thousands of dollars of investment and the combined planning the forethought of the best minds in the business. This is the strategy advocated by grant funded projects for many years, buy why should museums shy away from doing this with our own money too? The closed nature of proprietary software from museum vendors will never match the dollar for dollar value of investment in a successful and well supported open-source tool.
Shared tools let us take the same road to different destinations
The key to shared tools and platforms is the recognition of the inherent and historic individuality present in museums as discussed above. Open source software and open access to tools enable museums to benefit from each other’s investments while supporting their more individual needs themselves with a smaller investment required to do so.
Vendors need our help to build better tools
Museum professionals need to become more active and invested in helping to shift the economy of museum software away from customization and support driven business models and towards models which result in enhanced feature sets, better user interface design, adherence to emerging data standards, and open access to API’s which help museums to integrate these software products in more meaningful ways.
Museums should face the facts that the software vendors in our community have an incredibly hard job to do in building quality software. At the same time, they are responsible for sustaining a viable business and a happy place to work for their own employee communities. Unlike museums, the only way to ensure long-term viability of a museum software vendor is to maintain and enhance a competitive advantage over other vendors in the field.
Why is it then that so many of the tools in our field are based on 10 year old software platforms and antiquated software design practices? Many seem to have been poorly cobbled together from a set of disparate requirements over the course of many years. Could it be that many of the “modules” that we see in these tools are actually vestiges of integration requirements initiated and paid for by the needs of a single museum with the money to make it happen? Integration software projects and maintenance contracts are the core business models for many of the vendors on our field, but are a primary distraction to the continued development and enhancement of a high-quality and well designed core product.
Museums should act sooner not later in adopting open standards
It’s time for museums to act on our words and start actually implementing tools which use and depend on open standards for data interchange and integration as well as the core business functions of the museum. Several notable and well documented standards are available and ready to be used. Surely many will point to isolated examples in which this is already happening, but more often than not, museums lack suitable tools to implement these standards. It’s time that museums put our collective foot down and began working to incrementally make adoption of these standards a reality. The benefits of open standards will never be realized if museums don’t begin using them in daily practice.
September 15th, 2009 at 8:54 pm
I agree wholeheartedly, Rob! And if I may introduce one such possible software collaboration, how about Synchrotext? See my guest blog at http://futureofmuseums.blogspot.com/2009/09/toward-multi-museum-multi-media.html
September 16th, 2009 at 3:33 pm
Glad I was riding the elevator today–good ideas, Rob. Open standards = yes, and not just at museums!
September 16th, 2009 at 4:02 pm
great article Rob. One of the first big proprietary software expenditures many of the large (and small) museums spend on is Raiser’s Edget (Blackbaud). It would be a big savings to be able to redirect some of that money and use one of the newer open source constituent based CRM’s (like Orange Leap).
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
September 18th, 2009 at 11:00 am
Rob; thanks for the kind mention! Next time, if you want a comment, just ask — you won’t believe how many different people brought this post to my attention
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.
September 18th, 2009 at 11:48 pm
Fantastic discussion, ripe with possibilities as well as an obvious but nonetheless overdue re-framing of how museums can address problems and get work done. I’ll be giving this some expansive and extended thought. Also passing along to my colleagues! Thank you, all
September 21st, 2009 at 11:12 am
Thanks Chris for what might amount to the longest comment we’ve ever had on our blog
(just teasing)
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?
September 21st, 2009 at 3:36 pm
Yes, sorry about the length–I’m a recovering academic
Trackbacks
Leave a Reply