How Should a Library Evaluate Index Data for Custom Software or Open Source Projects?

Index Data is a library technology company that builds and sustains open source platforms, including FOLIO and ReShare, and takes on custom software development for libraries and the broader library ecosystem. It is worth evaluating if your library wants a partner to help build, operate, or sustain open source library services rather than only buy a finished product. The right fit depends on whether you need platform-level work (discovery, resource sharing, library management) or a bespoke development project, and you should confirm scope, support, and project fit directly with Index Data.

What Index Data actually offers

Based on its own description, Index Data positions itself as "operators, developers, innovators, and true partners" in the library space. Two things follow from that framing:

• Open source products and discovery tools. The company creates software products and discovery tools for libraries.
• Custom software development. It delivers custom development projects for libraries and the library ecosystem.
• Named platforms. FOLIO (library management) and ReShare (resource sharing) are the two platforms called out on its site, alongside "Additional Solutions."
• Partnership model. The site states it does not "just sell services" but works with libraries to "build and sustain" open source platforms.

That combination matters for evaluation: you are not choosing between a product vendor and a consultancy. Index Data presents itself as both a maintainer of shared open source platforms and a development partner for institution-specific work.

Decide which need you actually have

Before contacting anyone, separate your requirement into one of these categories, because each implies a different evaluation path.

If your need falls outside these areas, Index Data is likely not the right starting point.

Evaluation criteria that fit an open source partner

Because the offering is open source plus services, standard vendor checklists are insufficient. Use these dimensions instead.

1. Build vs. sustain vs. operate

Ask explicitly which of the three you are buying. "Build and sustain" implies ongoing involvement, not a one-time delivery. Clarify:

• Who operates the platform after launch?
• Who handles upgrades, security patches, and integrations?
• What happens if your institution wants to take over operations later?

2. Open source governance and exit

Open source reduces lock-in only if you can actually run it yourself. Confirm:

• Where the code lives and under what license.
• Whether your staff could operate it independently if the relationship ended.
• How community contributions and roadmaps are governed for FOLIO and ReShare.

3. Fit with your existing ecosystem

Libraries rarely run one system in isolation. Ask how the proposed work integrates with your current discovery layer, ILS/LMS, authentication, and consortial systems. Integration effort is often the largest hidden cost.

4. Custom development scope discipline

For bespoke projects, the risk is unclear scope. Insist on:

• A written definition of deliverables and acceptance criteria.
• Whether the custom work becomes open source, stays proprietary, or is contributed upstream.
• Ownership of the resulting code and documentation.

5. Support and accountability

The site emphasizes partnership rather than transactional service. Test that claim with concrete questions: response times, named contacts, escalation paths, and what "partner" means contractually.

A practical evaluation sequence

1. Define your requirement using the table above — platform, custom build, or sustainment.
2. Check the named platforms first. If FOLIO or ReShare already matches your need, your evaluation is mostly about adoption and support, not custom development.
3. Request a scoped conversation. The site's "Let's Talk" entry point is the natural first contact; bring your requirement definition with you.
4. Ask the five criteria questions above in writing so answers are comparable.
5. Pilot or phase the work rather than committing to a large engagement before you have seen how the partnership functions on a smaller deliverable.
6. Confirm commercial terms directly. Pricing, contract structure, and service levels are not published on the site, so treat them as open questions for Index Data rather than assumptions.

Common pitfalls

• Assuming open source means free. Open source refers to the software license, not the cost of development, hosting, migration, or support. Budget for services.
• Treating "partner" as a support contract. Partnership language suggests collaboration; make sure the contract specifies obligations, not just intentions.
• Skipping the exit plan. The main benefit of open source is optionality. If you cannot operate the platform without the vendor, you have not captured it.
• Underestimating integration. Discovery, resource sharing, and library management all touch other systems; scope integration explicitly.

Bottom line

Evaluate Index Data if your library needs to build, adopt, or sustain open source library platforms — particularly FOLIO or ReShare — or needs custom development grounded in the library domain. Evaluate carefully if you want a fixed, off-the-shelf product with published pricing, or if you cannot commit staff time to a partnership model. The decisive questions are scope (build, sustain, or operate), integration effort, code ownership and exit, and the concrete terms of support — all of which you should confirm directly with Index Data, since the site does not publish pricing or service-level details.