Copyright (C) 2022 Index Data Aps.

These documents and this software are distributed under the terms of the Apache License, Version 2.0. See the file "LICENSE" for more information.

Project Firefly is an initiative to put FOLIO's foundational modularity to work, enabling a FOLIO installation in practice to support modular use of applications provided by third parties rather than being limited to the modules provided as part of a flower release. Getting this to happen involves both technical and social/political work. This project represents work on the technical aspect.

Note that this project was previously known as MAFIA (Modular Approach to FOLIO In Action). Some references to this older name may survive here and elsewhere.

• Manifesto
• Areas of work
• Practical steps
• Documents
• Software
• See also

Quoting from the abstract of Modularity in FOLIO: Principles, Techniques And Tools, the featured article in the FOLIO-themed December 2021 special issue 6(2) of the International Journal of Librarianship:

From its earliest inception, FOLIO was conceived not as an ILS (Integrated Library System), but as a true Services Platform, composed of many independent but interdependent modules, and forming a foundation on which an ILS or other library software could be built out of relevant modules. This vision of modularity is crucial to FOLIO’s appeal to the library community, because it lowers the bar to participation: individual libraries may create modules that meet their needs, or hire developers to do so, or contribute to funding modules that will be of use to a broader community — all without needing “permission” from a central authority.

But at the time of writing, organizational issues mean that it is not straightforward in practice for organizations running FOLIO to install modules provided by sources other than their vendor (most often as a part of a "flower release"). Module inclusion in flower releases is governed by the FOLIO Technical Council, whose remit is to emphasize maintaining quality in a curated set of modules. While this emphasis in some respects serves the community well, it does have the unwelcome side-effect of discouraging the creation of experimental modules, or making experimental deployments of works in progress.

The present project aims to remove technical barriers to easier packaging and deployment of FOLIO applications. In doing so, our hope is to make it easier for software developers to deliver FOLIO applications, and for system administrators to install those applications.

Setting up and running a FOLIO instance entails three quite separate areas of work.

1. Obtaining and running a minimal base system, including Okapi and Stripes.

2. Obtaining and installing all the modules that will be needed for any tenant to run on the installation.

3. For each tenant, selecting which modules are to be included in that tenant's setup.

(In setting up a Stripes development platform, task 2 is captured by the platform's package.json, which specifies which front-end packages to install -- and, by implication, which back-end modules ought to be installed to support them. And task 3 is captured by the stripes.config.js, which specifies (among other things) which UI modules should be included in the bundle built for a specific tenant. In principle, there should be many stripes.config.js files for each platform -- one for each tenant -- but because development systems tend to run a single tenant, the distinction between the purposes of these two files is often overlooked.)

Improvements are there to be made in all three of these areas:

1. At present, a "minimal" FOLIO system is uncomfortably large, due to a maze of dependencies that should be optional but are not. For example, the login process involves service-points, a concept that ties together users and inventory and so requires both user-mamanagement and inventory modules to be pulled into the system.

2. A FOLIO application is typically composed of multiple modules, some on the front-end and some on the back-end. At present, there is no good way to install all the components of an application in one shot. This means there is in some sense no such thing as an application -- only aggregates of modules -- and therefore no simple way to install an application.

3. While Okapi provides extensive and well-documented WSAPIs for managing which modules are available to a tenant, there is no UI to these APIs, meaning that maintaining tenants is a job requiring devops skills.

There are several technical and social facilities that would need to be provided for a fully general FOLIO ecosysem to come into being. These include but may not be limited to the following:

• Addressing task 1 above, work has begin, but is currently stalled, on ways to fix at least some of the "modular monolith" problems (FOLIO-3253, stripes-core pull-request 1101), so that a minimal FOLIO becomes small enough to function as a sensible platform for non-ILS application suites.
• Addressing task 2 above, we need a FOLIO-app "package" format -- a single concrete thing, broadly analogous to a Debian package, that a vendor can create and deliver, and that a FOLIO implementor can install. This may end up simply being a structured metadata file that points to other release-artifacts packages and includes information about how to deploy them. See Thoughts on the Firefly package format. We will need some notion of module certificaton and assessment, so FOLIO implementors who want to install an app can have a degree of confidence in it. This will likely entail cryptographic signing, but also perhaps some form of independent QA, reviews, scores, etc.
• Addressing task 3 above, it would be helpful to have a simple UI to basic Okapi operations such as enabling and disabling modules. This is currently prototyped as a page in FOLIO's Developer Settings, but might eventually develop in to an "app store" that can be used to install packages.

The following in-progress documents represent the current state of this initiative, and should probably be read in order for historical context.

• Firefly meeting agendas (only for some meetings)
• What actually is a FOLIO app?
• How we add apps to FOLIO
• Thoughts on the Firefly package format
• Supporting FOLIO's cluster architecture in the Okapi Console
• Towards an FOLIO module ecosystem
• CI for Index Data's FOLIO registry
• Towards a GitHub-based Index Data CI system
• Where to keep CI build artifacts of FOLIO modules
• Separation of roles in module publishing and deployment
• Platforms and tenants
• The FOLIO App Metadata (FAM) file format
• FOLIO app metadata in module descriptors.
• Philosophy of the Firefly project
• Roles in the creation and use of FOLIO apps
• Representing platforms with FAM files
• Installing the Harvester Admin app from the FAM file
• EXTERNAL. FOLIO modularity in practice: seamless deployment of modules from multiple sources, my talk presenting the Firefly ideas at WOLFcon 2022 in Hamburg.
• An aspirational scenario
• Deploying and enabling modules in multi-tenant clusters

We have in-progress work on folioctl, a command-line tool for administrating FOLIO.

• Mike Gorrell's draft document OLF Release/Package/App Store.