“An aspen tree is not an individual tree; all trees in an aspen grove have common roots and a shared genetic code. Just like an aspen tree, libraries using Aspen have a shared software code base and support one another in their ideas and examples.” Mark Noble, creator of Aspen
Aspen is a suite of library software that started with the flagship Discovery and now includes additional modules such as the LiDA mobile app (Library Discovery Application) and Web Builder. As of 2025, Aspen is in use by more than 2,800 libraries worldwide and is supported by a community of hundreds of librarians.
A bevy of vendors have come together to support and develop Aspen– Bywater Solutions, Equinox, Grove for Libraries, Open-Fifth, and Theke Solutions among the top contributors.
I became involved with Aspen through my role as Executive Director at SWAN, which conducted an evaluation of the solution in 2019 and a pilot project in 2020. SWAN contracted with ByWater Solutions for support and development of the pilot, while SWAN hosted the system in its own cloud environment. SWAN outlined in May 2020 that the purpose of the pilot was an “Evaluation-based implementation of the Aspen discovery tool to integrate with the SirsiDynix Symphony ILS, providing select patrons and member libraries an alternative to the current Enterprise catalog interface. The evaluation will demonstrate the prospects of the Aspen Discovery tool in meeting the concerns of the Membership regarding discovery issues.”
The pilot lasted a full year and included configuring e-content integration for 7 libraries and SWAN sponsored software development with Mark Noble at ByWater. Several features were required in order for SWAN to consider a switch, the first of being integration with SWAN’s Symphony ILS which had never been done before, integration with EBSCO Discovery Service, and many web accessibility enhancements. The software development went very smoothly, with additional enhancements arriving with monthly releases of Aspen Discovery.
After the pilot phase it was decided that Aspen Discovery was ready for full adoption by the 100 libraries in SWAN.
A Need for Community Governance
Fast forward from 2021 to 2024, it was clear that the open source project Aspen was a growing success and that it needed a structure for setting strategic direction and decision making.
I reached out to 7 individuals within the community and invited them for a discussion on creating a governance structure within written bylaws and deciding what type of legal entity should Aspen be formed under.
Our first set of meetings were exercises to answer the following questions.
- What is the Aspen community?
- What are catastrophes that would have a significant impact on the Aspen project?
- What different types of governance for an open-source project exist?
- What was the experience of other library open source projects?

Throughout this initial series of Aspen governance task force meetings, the resources provided by Lyrasis “It Takes a Village: Open Source Software Sustainability” were invaluable. It Takes a Village is a toolkit for “practical use in planning and managing sustainability for open source software (OSS) initiatives.” We invited Laurie Arp, Laurie Arp, Senior Director, Community Supported Technologies and Hosting Services, Lyrasis, to speak about the toolkit and we shared its impact to-date on our efforts.
Catastrophizing
One significant exercise from It Takes a Village was to conduct a brainstorming session to generate a list of “catastrophes” that would have a significant impact on Aspen’s ability to fulfill its mission.

The exercise resulted in the following potential negative scenarios:
- Forking the code
- Security breaches, data encryption and privacy concerns
- Expertise being too centralized
- Keeping a stable vision of the Aspen project
- Lack of funding
“Forking the code” was noted as not necessarily a bad thing, as Aspen was in fact built upon a fork of the VuFind codebase, but that a code fork would split the community and dilute potential resources.
Once the potential negative outcomes were established, we had a common set of issues to address through our design of community governance.
Understanding sustainable open source models
The RedHat Blog “Understanding open source models” served as an initial discussion on models under which open source software projects operate.
We discussed the different governance models described, focusing on the benevolent dictator, meritocracy, delegate, and dynamic governance models. Members of the task force involved with software development expressed a preference for the meritocracy model, while others cited the need for controlled delegation within the benevolent dictator model, which was also critiqued for a lack of sustainability as it relies on a single individual. There were concerns raised about the potential for founder syndrome to hinder the growth of the organization. It was generally agreed that some of these models might not be suitable for their current stage, but ultimately were models for how software development could be organized within the Aspen project, and not the governance per se.
The task force explored options to incorporate the legal entity under, including the Software Freedom Conservancy, the potential of using a 501(c)(3), and the Open Library Foundation.
For Aspen, the nearest sibling open source project within the library community was the Evergreen Project, which had originally incorporated under the Software Freedom Conservancy (SFC), and then after a period of establishment, moved to incorporate under the 501(c)(3). Members of the Evergreen Project community were interviewed and the experiences of building its governance, relationship with SFC, and development of its bylaws were presented.
Ultimately it was decided that forming Aspen governance under a foundation would provide the legal, financial, and technical support required for a fledgling library open source project. The required steps from the Open Library Foundation were presented and the project milestones for finalizing governance were established.
Creation of Aspen bylaws
With the Evergreen Project bylaws serving as a model, it was decided to name our project “Aspen Library Software Foundation.” It was proposed that the board composition be only members of the community that were not employees of the companies involved with Aspen. This was, of course, a controversial proposition. Discussion within the task force naturally split between vendors wanting a presence on the governing board and those that wanted to establish clear separation between the software developers and the community of libraries. It was decided that the Aspen project should remain firmly in the hands of the library community and the “vendor ban” be put in place within the governing board structure.
Community feedback & clarification
The Aspen community meets monthly to review notably software development features and to provide updates from the groups of volunteers working on projects such as bug tracking and planning the annual conference. The governance task force provided updates to the community throughout the year and brought forward the draft of the bylaws and recommendation to apply for legal status under the OLF. The feedback obtained was helpful in providing explanations of the structure of the board and standing committees under the bylaws, particularly the Technical Committee under which the software developers from various companies and libraries would set direction and make decisions.
We conducted community endorsement vote where approval was overwhelmingly positive. This was followed by a collection of nominations for governing board, which already had a project slate defined to complete the required steps to join the OLF.
Conclusion
The Aspen Library Software Foundation nine member board was seated November 17, 2025. I myself decided to not participate on the Aspen governing board as I had other projects underway as my role on the Illinois Library Association Public Policy Committee expanded to be the Chair for the 2025-2026 legislative season.
Leave a Reply