Our Methodology: How We Research Library Technology

Who I Am and Why That Matters

My credibility comes from experience, not opinions. I've been:

• A vendor employee: I worked in library technology at major vendors. I saw how pricing decisions get made, how features are prioritized (spoiler: not by what librarians need), and what gets cut when margins matter more than functionality.
• An implementation consultant: I led multi-year implementations of major library systems. I've managed vendor relationships when things go wrong. I've negotiated contracts and fought for libraries when vendors tried to upsell features libraries didn't need.
• A library technologist: I've worked on the library side. I know what it's like to manage underfunded IT departments, work with systems that vendors say are "working as designed" when they're actually broken, and try to protect patron privacy with tools designed for surveillance.

This background means I understand the vendor perspective and the library perspective. I'm not neutral about that - I'm biased toward libraries. But I understand the constraints vendors work under, which means my critiques are specific, not just angry venting.

How We Research Topics

When I write about library technology, here's what I actually do:

1. Primary Source: Experience

Most of what I write about, I've experienced. I've configured the systems, I've dealt with the problems, I've negotiated with the vendors. When I say "Koha has this limitation," I've hit that limitation. When I say "most libraries don't know they can negotiate that," I'm saying it because I've seen libraries surprised by what vendors will agree to.

2. Secondary Sources: Published Data

I cite:

• Library research: IMLS, ALA, Library Journal, research institutions with library science programs
• Academic research: Peer-reviewed papers on library equity, privacy, technology adoption
• Policy documents: State library policies, federal legislation, vendor contracts (when available)
• Industry reports: Gartner, Forrester, vendor-specific case studies (with critical reading)
• News and journalism: Library news outlets, tech journalism, public records requests

3. Verification: Testing and Interviews

When possible, I:

• Test systems myself: I set up demo instances, configure features, find limitations
• Talk to librarians: I conduct interviews with library staff who use these systems daily
• Review public records: RFPs, contracts, board meeting minutes when they're available
• Track changes: I watch vendor product releases, contract changes, policy updates

Conflicts of Interest (What You Should Know)

I have no current vendor employment. I don't receive sponsorships or advertising. But I do have financial interests you should know about:

• Consulting: I work with libraries as a consultant. I help them evaluate technology, negotiate contracts, and implement systems. If I write about a tool and libraries start using it, that could theoretically benefit my consulting business.
• Speaking: I give talks at library conferences. If my writing builds my reputation, that helps my speaking income.
• Newsletter: I maintain a newsletter. More readers means more email subscribers (and potential consulting leads).

How I manage this: I disclose these interests upfront. I try to write what's actually true, even when it doesn't benefit me. If I recommend a tool, it's because I think it's good for libraries, not because someone paid me. If I criticize a vendor, it's because they deserve criticism.

But you should know: I benefit when libraries invest in solving problems. So I'm biased toward action. If you read something here that suggests you should buy a tool, spend money on implementation, or invest in staff training - that bias exists. I think you should do those things. But you should know I benefit when you do.

What We Don't Do

Here's what I deliberately avoid:

• Vendor partnerships or sponsorships: I don't accept money from vendors for positive coverage
• Affiliate links: I don't link to products where I get a commission
• Paid promotional content: I don't write articles that are secretly ads
• Anonymous criticism: If I criticize a vendor, I use my name and explain my reasoning
• Data from deleted articles: If I change my mind about something I've written, I update it visibly

How to Evaluate What We Write

Don't just trust us because we say we're credible. Here's how to verify:

Check the Sources

Every article should cite where information comes from. Look for:

• Links to published research (not just links to vendors)
• Specific data points with sources (like "21 million Americans lack broadband - Pew Research, 2021")
• Quotes attributed to specific people or organizations
• URLs to public documents (contracts, policy, legislation)

Look for Nuance

If everything we write is "this vendor is terrible" or "buy this tool," we're not being honest. Reality is more complicated. Look for:

• Acknowledgment of what vendors do well
• Trade-offs (this tool is good at X but weak at Y)
• Context (this works for large libraries but might not work for small ones)
• Limitations (here's what we don't know about this topic)

Check the Date

Library technology changes. A tool that was bad in 2023 might be better in 2026. If you're reading something old, check if it's been updated. Look for:

• Publication date
• Last updated date
• References to recent events (if they're referenced as current and they happened 3 years ago, that's a problem)

How We Handle Disagreement

If you disagree with something we've written:

• Tell us directly: Send us a message. We read feedback and respond to substantive disagreement.
• Show us your data: If you have sources that contradict what we've written, we'll look at them. If they're good, we'll update our article and credit you.
• Ask us for clarification: If what we wrote was unclear, that's on us. We'll explain or rewrite it.

We're not trying to be the final word on library technology. We're trying to be a resource you can trust because we're transparent about how we work.

Why This Matters

Library technology decisions are expensive and difficult to reverse. You need reliable information from someone who understands both the promise and the reality of these systems.

I've seen libraries spend millions on systems that don't serve their communities. I've seen vendors overpromise and underdeliver. I've seen library staff exhausted by technology that was supposed to help them.

This methodology exists so you know: when I write about library technology, I'm trying to help you make better decisions. Not by telling you what to buy, but by telling you what I know, showing you my sources, and being honest about why I'm telling you.