Handle patrons using your website, sending text messages, or using IM accounts on services like AIM and Google Talk.
UNC-Chapel Hill Undergraduate Librarian/and also Libraryh3lp
Who runs this thing?
President, Nub Games, Inc. Full-time librarian at UNC-Chapel Hill
Programmer Libraryh3lp support, testing, and
Chief architect Lightweight systems administration
Lead systems administrator Documentation
Works on projects besides Libraryh3lp
What does Libraryh3lp do?
Provides a flexible platform for building virtual reference services
What does it do?
XMPP Server with IM Gateways
•Duke, NCSU, and
UNC began night
•Relied on multi-
•By day, all libraries in the
collaboration had migrated to
Meebo and IM services.
These had significant
technical limitations and were
only suited to one librarian
user at a time.
•The night time collaboration
had completely outgrown all
•Eric helped the
•Usage stats more than
•Cost: 100 – 200 hours
time. Value: $8,000-
• Peer-to-peer: runs on PCs. No web
server to pay for.
• Peer-to-peer architecture not scalable.
• Overall service successful but needed
web-based architecture for growth.
• Great start, now re-do everything
Sustainability for web-based system
• Existing business entity: Nub Games, Inc. (LLC), from Eric’s contract
• How are we going to pay for this?
• Sell the users’ data?
• Get a grant?
• Make it really affordable
• Architecture, efficient code
• Amazon S3, Cloudfront
• Stick to the core system; avoid unnecessary work
• Radical notion: create a good service and charge a fair price for it.
• Contract work for special features needed by large projects
• Support expectations…?
• Programmer does not have time for support
• Librarian has full-time librarian job
•Eric helps the
•Usage stats more than
•Cost: 100 – 200 hours
time. Value: $8,000-
•Libraryh3lp is publicly
announced. Free live
trial registration open to
•Cost $50 - $300/yr
depending on institution
2008 - 2009
•Libraryh3lp reaches financial “break
even” point, meaning it no longer
actively costs Eric’s business money to
provide the system.
•Libraryh3lp starts generating some
profit in 2009.
• Libraryh3lp grows from a
side project to a primary
project for Eric.
Displaces other income-
• Many new features
added; code continually
reworked for increased
• Prices raised to $250
• Libraryh3lp has over 300
• Current architecture
working at maximum
• New trials temporarily
on hold to prevent
stability problems for
• Major new upgrade to
be released in summer.
• Approximately 1,250 trials registered
– Many libraries registered more than one trial
• Approximately 300 active customers
– Primarily in the US and Canada
– Also Spain, Sweden, New
Zealand, Australia, Singapore, Ireland, England, Germany, China,
United Arab Emirates, Pakistan, Russia, Poland
• Conversion rate about 25%!
• 286 paid accounts
– A few are freebies.
– Some still in trial.
– A few have not paid (alas).
• Top 75 account for 75% of traffic
Libraryh3lp pricing per year
Academic Libraries, per FTE Public Libraries, per population served
10,000 or fewer $250 100,000 or fewer $250
10,001 – 20,000 $300 100,001 – 200,000 $300
20,001 – 30,000 $400 200,001 – 300,000 $400
30,001 – 40,000 $500 300,001 – 400,000 $500
40,001 – 50,000 $600 400,001 – 500,000 $600
Librarian User Accts Patron Queues
Unlimited Unlimited Unlimited Unlimited
How we save time
(and so, keep Libraryh3lp inexpensive)
• Unmediated trial access
• Trial version is same as full version
– Live trial (using real patrons) expected
– Libraries know what they’re getting
– Programmer doesn’t have to spend time writing version with disabled features
• Default trial 90 days, can be extended
• Payment basically “honor system”
– We have started looking for freeloaders, but it takes time, and we don’t
automatically disable their accounts.
• For better or worse, we don’t spend time marketing or having vendor
• Support users helping users.
• Use third-party communication tools like Google Groups (support), User
Voice (feature requests), Twitter (system status).
• Refchatter via Altarama: supported version (more expensive)
More on saving time…
• Eric: wants to solve hard problems. He should focus on core,
technical infrastructure growth.
• What is the weakest link?
• Sometimes overall efficiency is gained by writing non-core
• Simple tools so I can do more systems administration.
• (Threatens to replace me with a small shell script frequently.)
• As Libh3lp grew, accounting/billing needed attention.
• BBDB, custom, integrates with admin site.
• Quickbooks for generating invoices and tracking receipts.
• Payment: small plea @ bottom of blog post, next day, 7 libraries
…but efficiency starts with the code
Presence: Online? Offline?
Efficiency starts with the code
• Presence calls 20x more efficient (thus, cheaper) using comet long-polling
over traditional polling. Comet long-poll provides real-time presence in
• 45 million presence requests in last 10 days.
• During busier times, there are 10,000 web pages simultaneously
monitoring real-time presence.
• During busier times, there are 100-500 new presence requests per second.
• What is more efficient: making system 10x faster through better code, or
adding 10x the servers?
• New system will handle thousands of presence requests per second.
Great things about working on
• Can move quickly.
• Very low communications overhead on
• Interesting puzzles to solve.
• Mostly very happy, kind librarians.
• Billing expectations
– Purchase Orders
• By the way, we write ourselves a 2.5% discount on all POs.
– Faxing things
– Getting things notarized
– “We need to get you into our system“
• ie, fill out these 20 forms…
• Training/support requests
• Requests for demos
– Seem to be expecting a sales pitch
• Weird local problems requiring intense tech support
• Growth walls (remember, it’s unlimited)
• Sometimes needs attention at inconvenient times.
• We need to have pretty constant Internet access.
– Monitoring, paging, can fix crashes from iPhone.
– Yes, even during vacations.
Challenges: Delicate Balance
• Full-time job at UNC.
• Deflect Libh3p calls away from my work
• Set low expectations among Libraryh3lp users
for non-emergency support.
• In real emergency, take annual leave time.
Typical Libraryh3lp Week (Pam)
Day of week Task Typical time needed
Mon-Friday mornings Routine system checks/tests 15 - 30 minutes
Mon-Thursday evenings Support, correspondence,
Varies (30 minutes - 3 hours)
Saturday Test/debug new code with Eric Varies (0 - 12 hours)
Sunday mornings Routine systems administration 1 hour
Sunday More code testing if needed Varies
Friday evening? Date night!!!
Future (the future is now)
• NCknows migration
– First Libraryh3lp state-wide collaborative.
– First backup staff experience on Libraryh3lp.
• My Customer Cloud
– Like Libraryh3lp, but flat rate per chat.
– Population size pricing model breaks down in private sector.
– New programming partner for Eric! (and she also does support)
– Unexpected finding: Libraries seem to be much more service-oriented than most
– Cheaper for lower chat volume libraries.
• Libraryh3lp costs at least $250/yr.
– Billing fully integrated into MCC architecture.
– Must be able to pay online with credit card.
– Most common question from libraries so far: “Will you invoice me for $20 of
• Summer release of Libraryh3lp upgrade