We are excited to share this guest post from MacKenzie Smith, Research Director at the MIT Libraries. At the joint NDIIPP/NDSA meeting this summer MacKenzie gave a talk titled “Exhibit3@MIT: Lessons learned from 10 years of the Simile Project for building library open source software” in our session on open source tools and communities. The talk sparked valuable discussions at the meeting, so we asked her to reprise her talk a guest post.
How is good open source software designed for the Library, Archives and Museum community to be sustained over time? Our community doesn’t much resemble those that created flagship open source software products. Those products have millions of users and hundreds of developers, so managing their evolution over time is more a problem of which developers to let in than it is about attracting enough of them in the first place. The latter situation is true of a lot of important software for the LAM market, e.g., software to manage digital archive workflows or digital collections. Institutional Repositories have come the closest to ongoing sustainability with two of the earliest – EPrints and DSpace – approaching their second decade of use, but we have plenty of other important software needs to worry about.
Of course there are exceptions, and one of them hails from an MIT Libraries project called Simile. The project started in 2003 so it’s seen the ebb and flow of funding, but managed to create software that is both popular and sustainable. Part of that success was due to ruthlessness. Of the ninety-odd software products that the Simile team created over the years, only a small number were allow to survive to adulthood and “graduate”, as we put it when they moved out of the house and took up separate residence. That moving out process required (and still occasionally requires) careful shepherding to create a culture for success independent from the original team.
First, build tools for the largest community you can imagine. Building software for your own group, library, organization, or niche community is a great way to get input and feedback from real users but can limit the pool of people and organizations that care about the code. We’re often left with too few developers to maintain the product without ongoing funding from the original source. Tools that solve both your problem and those of people from many other communities have a better chance of survival.
Second, it’s not enough to post your open source code on a well-known platform like GitHub or Sourceforge and tell friends. To gain adoption and support from other developers requires social engineering and good processes for getting them involved and making them feel needed and welcome. It’s also important to have teams involved that include not only developers but prototypers (innovators), socializers (writers), quality control geeks, and advocates among the managers who will fund the work. In other words, all the roles you’d expect from software companies, just not all working in one place. And all of this needs to be built into the project from the beginning.
Third, software maintenance can get tedious over the years, but in distributed open source development environments it’s a critical part of the software’s long-term usefulness. Having an active software management plan in place, and a continuous integration environment, helps avoid the code disintegrating over time.
Fourth, think about the run-time environment of the product. Web applications can be very popular and useful, but keeping them working in the plethora of Web browsers over time is a lot of work.
Over time, the Simile project recognized a pattern in its successful software efforts like Exhibit (a key component of the Library of Congress’s new open source Recollection platform). It’s a formula that you can apply to software that helps identify where open source has a change of long-term sustainability:
It’s a combination of the size of the potential adopter community and its diversity, the degree of proven need for the software, the technical sophistication of the adopters for product, their level of investment in it, and good timing (also called dumb luck). While you can’t predict that last factor, the others should be more measurable. If you have good scores for several of them then there’s hope. If you don’t, maybe a small change of plans would help build them up. And if you still don’t, make sure your original funder is prepared for continuing to invest in the software for as long as you need it.