Getting Involved in Developing Features for ArchivesSpace

One of the advantages of using ArchivesSpace is that it supports a range of archival functions, from accessioning to processing to preservation to public access. These functions are supported through a variety of features in the application. Features may be something as big as the new assessment module or as small as changing the location of a button on a form. As you would expect, there are always additional features that could be included, or ways to make existing features better. Our development catalog (http://development.archivesspace.org) includes information on many features the ArchivesSpace community has requested or considered over time.

ArchivesSpace membership dues support ongoing maintenance and upgrades for the application, as well as much of the most complex or highly prioritized feature development requested by the community. But we are always looking for community members interested in contributing additional features to the application, whether by developing the features themselves or subsidizing targeted development. Feature development for a community-supported application like ArchivesSpace can be very rewarding, as it will not only improve the ArchivesSpace you use, but also potentially benefit many people outside your institution and offer the opportunity to collaborate with other users. If you are considering developing a feature for ArchivesSpace, on your own or by contracting with a developer, we strongly encourage you to consider early in your project whether the wider community could benefit as well.

When thinking about feature development for ArchivesSpace, we think it’s useful to consider a few questions:

What is the feature? Does it fit within the expected functionality for an archives information management application like ArchivesSpace?
How common is the need for the feature, and how much agreement is there on your idea for the way to meet that need?
Do you have a specification that lays out in detail how the feature should work and what it should look like? Has there been community involvement in writing the specification?
Are you referring to any particular standards, archival or otherwise, when designing your feature?
Is this feature most appropriate for the core code of ArchivesSpace, a custom build, or a plugin?

The last question requires some understanding of the different options for development for the ArchivesSpace application, which we lay out below.

1. Developing for the core code of ArchivesSpace

The ArchivesSpace core code is the code underlying the distribution version of ArchivesSpace. It is what it is included in a standard download of the application. The core code consists of all the functionality that has been generally agreed upon as essential to the ArchivesSpace application and developed up to the present time. It is maintained by the ArchivesSpace program and supported through the dues paid by ArchivesSpace members.

When developing a new feature, there are a number of advantages to developing it for inclusion in the core code, including:

Supporting the feature and ensuring compatibility with later versions of the application will become the ArchivesSpace program’s responsibility.
Making the feature available to your own users will not require deviating from the standard distribution of the application; you will be able to take advantage of upgrades to the ArchivesSpace application as others would.
Everyone in the community will be able to use the feature (your custom build may only be accessible to you and some IT providers do not support or frown upon the use of plugins).
Because ArchivesSpace is used by so many in the archival community, your feature may help guide and solidify archival practice in the area it supports.

There are some disadvantages to developing for the core code, including:

Your code must meet community standards.
You will not have complete control over when the feature is first made available since the ArchivesSpace program determines the release schedule for ArchivesSpace.
You will not have sole say in future development of the feature; as with any community endeavor, future developments will usually require the participation of the community.

For features that are likely to be widely wanted by the ArchivesSpace community, the ArchivesSpace Program Team considers developing for the core code to be the best option. See ArchivesSpace Process for Evaluating Potential Feature Contributions to the Core Code for the process ArchivesSpace uses to consider whether a feature is appropriate for the core code.

2. Developing for a custom build of ArchivesSpace

A custom build of ArchivesSpace uses the core code of ArchivesSpace as a starting point but adapts it to local needs by making changes in the code itself.

Advantages to making a custom build, or situations in which you may want to do so, include:

You will be able to customize your local installation however you wish.
You want to design and maintain your own archives information management system, but want to use ArchivesSpace as a jumping point. You don’t expect to continue to upgrade your system using standard ArchivesSpace releases.
You do not have to worry about multiple plugins potentially interfering with each other.

Disadvantages to a custom build include:

Writing code for and making a custom build takes greater technical knowledge and greater familiarity with the code base than writing a plugin.
When upgrades to the core code happen, you will either need to recreate them in your custom build, or recreate your customizations in the new version of ArchivesSpace.
Your improvements will be available to few or no people outside your institution.

3. Developing plugins for ArchivesSpace

A plugin is an enhancement that overrides or extends functionality of ArchivesSpace without requiring changes to the application’s own code. ArchivesSpace’s architecture is designed to support a range of plugins, and plugins can be a great introduction to developing for ArchivesSpace.

Some examples of use cases that may be best served with plugins include:

You want to use your own colors and branding images in your site beyond the standard configuration options, but don’t want to have to make your own build of ArchivesSpace each time a new version comes out.
You want certain fields to export in EAD according to your local practices, which differ from the practices of many other institutions.
Your users want the fields in the ArchivesSpace data entry form for accessions (or any other kind of record) to be in a different order.

Some advantages to writing plugins include:

There is a lower technical barrier than for writing for the core code or a custom build.
Plugins can support many different ways of doing something, or ways that deviate from the practices supported by the ArchivesSpace standard distribution.
Plugins are optional; only those that want to use a particular plugin will be affected by the changes it makes in the application.
Writing a plugin can often be quick and requires little consultation with others or adherence to the standards of others.

Some disadvantages to writing plugins include:

You will need to maintain and support the plugin yourself.
Enabling a plugin requires access to the ArchivesSpace server and some IT providers limit or restrict the use of plugins. This will limit the audience for your feature.
There may be duplication of effort across the community, as you may not realize that someone else has already written a plugin that does the same thing yours does.

Christine Di Bella, the ArchivesSpace Program Manager (christine.dibella@lyrasis.org), and members of the Core Committers group would be glad to talk with you about any of these options. Christine would also be glad to talk with you about feature development that has already been prioritized by the community if you’re looking for ideas for projects. Please get in touch with us if you have any questions or interest about getting involved in feature development for ArchivesSpace.