Constructing a Converged Open Source Museum Platform

Tommy Wilson, Independent, USA

Abstract

Keywords: open source software, museum integration, digital learning

Convergence and OSS

Throughout the history of information technology, convergence has been part of the dream. Going all the way back to the early 1990s when Oracle founder Larry Ellison discussed the convergence of media, including the Internet, into a single stream of information. Today, we see convergence in the form of integrated streaming appliances, artificial intelligence platforms, which interface to control systems in our homes, and even the media companies that Ellison spoke about so many years ago have now become multi-modal conglomerates. So, what does this have to do with the modern museum? With the modern patron consuming information and experiences in so many ways in everyday life, the museum must prepare itself to mimic this consumption. Before you think, “Well, we have always done it (x) way,” consider for a moment that the museum has always truly performed one major function, that being to conserve our past, reflect our current, and prepare for the future. To reflect our current climate, the museum must become a multi-modal experience engine. This transformation begins with a great technological foundation.

The open source software (OSS) idea has been around for decades, dating to the original generation of computers, where programmers would actually print source code in magazines, and users would have to enter this code to play a game or use a productivity app.  Most people think of OSS as free software, though this is a bit of a misinterpretation as there can be free, closed source software. At its core, OSS is about sharing and extension, pushing a system to do its best job. It is through OSS that museums can build this technological platform, as well as streamline internal operations to better serve our patrons. It is the intent of this article to begin from the building blocks, then move through interoperability and convergence.

Where to Begin?

Almost all of the systems referenced in this article were built on “commoditized hardware.” Commoditized hardware is a name of my own invention to refer to hardware which has served its “useful” life in another place. A basic server from a systems manufacturer such as Dell or HP can cost many thousands of dollars. However, stepping back one or two generations from those brand new systems opens up a world of cost savings because many large corporations are hounded into upgrades by salespeople from these manufacturers. This generates a secondary market for servers and systems which those upgrades replace. These systems can be purchased for pennies on the dollar through online marketplaces. They typically come without hard disk drives or operating systems, which is perfect for our purposes as it allows either for the hard drives to be replaced new or upgraded to a solid state and the installation of an OSS operating system, such as a flavor of Linux, BSD, or Unix. For those who do not have on-site IT staff, these systems can actually be ordered customized to your needs through the same marketplaces and ready to have software installed out of the box. I have also had great success by contacting the computer science or management information systems departments of local universities and asking if any student would be interested in doing the integration and setup as a term project or internship.

At this point, you should consider your domains of museum knowledge. The Fabric Workshop and Museum (FWM) is an oddity in the art museum community in that it has both a museum program and an active full-time studio. At FWM, the knowledge domains begin with three basic categories, art-making, programming, and business operations. These three domains can be broken into further sub-domains such as accounting, operations, and the museum shop on the business side; archives, collection and studio in art-making, and exhibitions, apprenticeships, and education in programming.  However, once these basic categories are established, you should begin looking for points of convergence. The easy way to construct this is to draw the domains out on a large sheet of paper, then think about the overlap. Think of exact examples and draw connecting lines between the domains. Where the lines cross is a point of convergence and should be listed on a separate sheet of paper.

An example of this from FWM is the simple staging of an artist-in-residence program. This involves an artist coming into the institution up to two years before their exhibition. A thread can be drawn through these two years where the idea is discussed with studio staff, which most likely happens through email these days. This is a verifiable record. This seminal idea works its way through development for fundraising to make the idea a reality. This is a point of convergence as it involves studio, development, and accounting.  Another would be if the artist wanted to create either multiples of an artwork or a secondary artwork for sale in the museum shop. This one would involve studio, accounting, and the shop staff. Of course, all of this creates a massive amount of data. The idea of collecting, organizing, and utilizing this data is the central tenant of a converged system. Taking the physical knowledge domains and translating them into a virtual domain system is surprisingly simple. While there is some substantial overlap, keeping the interoperability of these two domains as a central design philosophy, while acknowledging the differences, is the key to designing the converged system.

Beginning the Build: The Nuts and Bolts

Central to any converged platform is the datastore. This is not to be confused with a database, as a database is essentially a system of interconnected spreadsheets and data fields, and a datastore is a place where data is stored. This data is “freeform,” it can be photos, documents, notes, or even multimedia recordings. While a simple network share can be used as a datastore, building a true converged system requires something a bit more robust. One of my favorite systems to use for datastores is a file and operating system called ZFS, which is not widely known, but is very flexible and powerful. It is fully journaled, and the file system actually operates at the OS level as opposed to above it, like most file systems. Disks are directly accessed by ZFS without abstraction, and the data is written across multiple disks, providing redundancy. It would require the bulk of this article to explain the absolute fiery witchcraft of ZFS, so it is recommended that some further independent research is done.

Implementation of this system is fairly simple, as it requires only a server with multiple hard disks and a controller. My personal favorite flavors of this system are either FreeNAS or Nas4Free, both of which are effectively the same software with some differing design philosophies. They both come as complete systems on a CD/DVD and can be installed through a point-and-click interface. One other great thing with these ZFS distributions is that they both support VirtualBox, a basic virtualization system which can have the server serve a dual purpose for storage but also for basic computing. Virtualization is also the next step in our build.

So, at this point, you have a datastore. What would you like to do with it? If you wish to have a 1990s era file server, which is almost bulletproof, you are there. However, this is nothing more than a blank canvas to begin imagining. Refer back to your information domains and points of convergence. This document is your roadmap for the build.

Look at your staff. What repetitive tasks do they perform that a system could speed up? What type of services or engagement would you like to provide for your patrons? Decide on a few key services to begin with.

In years past, servers served one function. You would have a file server, maybe an anti-virus server, maybe a database. Of course, there was also the spaghetti server, a veritable dumping ground where one physical device would have several, if not tens/hundreds, of services installed on it, each competing for resources and processing time. Many times, these services would conflict with each other, causing untold issues. It was truly a jack of all trades, but master of none. Virtualization seeks to organize the spaghetti server. It is a system which creates a number of virtual environments, where you can install another operating system and then run multiple servers on one physical device. While there are a number of players in this market, and more are joining all the time, the biggest player is VMWare ESXi. ESXi is very mature software about which a number of books, websites, and services providers are dedicated. A basic version of ESXi can be obtained for the cost of simply registering at their website. This basic version runs on up to two physical processors, which is fine when using commodity hardware from the leasing channels. ESXi sets up very easily and is largely configured through a web interface. ESXi itself is based upon Linux, an open source operating system, but you can add any flavor of OS with which you are comfortable inside of the virtual environments. At FWM, we have a mixture of Windows (Desktop and Server), FreeBSD, and Ubuntu Linux running on the same physical server.

The Complete Picture

Hopefully, by this point, you have considered what you would like to do with your new open source platform.  The canvas is primed, and the basic sketch is drawn. Let’s make that first brushstroke. Most of the software discussed through the remainder of this paper have easily readable instructions for installation or will auto-install for you! Do not be afraid of the command line! Also, remember . . . this is community software, which means you have a community backing you, which can answer questions and help troubleshoot. The added benefit is that there is also a complete ecosystem of people who can answer the question, “I want this software to do X. How does that work?” Also, there is a resource you can tap into in the form of independent programmers, who can help you get where you are going, even if you do not have the time or technical skill. Simply search the web with the name of the software and “programmer” appended! Finally, most open source software packages have paid systems integrators, which will build everything for you.

At FWM, we began with the art-making domain and with the installation of CollectionSpace and ResourceSpace in our environment. CollectionSpace is a collection management software akin to PastPerfect, Embark, or TMS while ResourceSpace is a digital asset manager which holds photos, videos, and audio files. Both have the benefit of being web enabled, which means you use them through a web browser. The third part of the art-making domain is documents, which will be handled by Mayan Document Management. Mayan is a complete solution for documents which uses the most common business document formats or Optical Character Recognition for PDF/scanned files to create searchable word clouds.

ResourceSpace and Mayan act as points of convergence with the business operations domain, as marketing needs AV resources, and development and accounting need access to historical documents. CollectionSpace is also a point of convergence in that exhibitions and curations need quick access to collection objects.  The next step in our plan at FWM is to develop a portal which will index the resources from all of these systems into an easy-to-use meta search that will allow staff and researchers to quickly find data that, until now, was buried in mountains of banker’s boxes.

In the business domain, we began with accounting, then branched out and looked for points of convergence. Money, despite being the dirty part of museology, is the grease that makes the wheels run. We chose a piece of software called Odoo, which despite having a funny name, is very powerful.  Its original intent was to run large enterprises such as Toyota, but with some tweaks, it makes a great platform for non-profits. It powers our accounting, purchasing, invoicing, and the POS for our museum shop. It synchronizes information in real time, so everyone is on the same page and reporting is very simple. We developed our online museum shop in WooCommerce, for which there is a commercially available connector that ties our website to Odoo, allowing physical inventory and shop sales to be constantly updated and maintained.

For development, we paired Odoo with CiviCRM, which is a fantastic alternative to costly packages such as Raisers Edge. We also had a connector developed which synchronizes CiviCRM to Odoo, allowing the rapid exchange of information between development and accounting. CiviCRM also powers our online giving forms and handles paid events, our mailing list, and memberships.

Exhibitions are where the rubber really hits the road. This is also where you can be the most creative with the platform you have constructed at this point. We have developed tablet-based interfaces based around our business and art-making domains which present historic archival information, upcoming and in-process information, and also solicits patron feedback and membership sales. Taking all of this information, we are also in the beginning stages of development on augmented and virtual reality solutions to re-stage historic exhibitions. We are also planning to data-mine our space through heat mapping and anonymous metadata collected from our security and surveillance systems, which report to our datastore. All of this is possible by laying the foundation with a good technology platform to power the museum.

This entire platform is also possible without having a single server inside of the museum. For the past few years, Microsoft has offered Azure cloud credits and support to non-profit organizations. At FWM, we have migrated many of our servers to the cloud, leaving only the most critical on-site for business continuity. As part of our business continuity plan, these on-site servers are mirrored to the cloud. A number of other vendors such as Google or Amazon Web Services also provides low or no-cost cloud computing resources to non-profits.

While this article is a basic primer on the building blocks of open source platforms, I hope it has inspired you! Open source is a constantly evolving system which is also looking for inspiration. Join the community even if you do not have the time or resources to build a platform at your institution, though if you are reading this, I expect that you are interested. Ask questions and form relationships, you never know if you might inspire a programmer or engineer to create something which will benefit your peers or resolve a problem that you never knew you had. The possibilities are endless, and all it requires is discussion and imagination.