Providing Libraryh3lp

Pam SessomsUNC-Chapel Hill Undergraduate Librarian/and also Libraryh3lp

psessoms@gmail.com

Who runs this thing?

Eric PamPresident, Nub Games, Inc. Full-time librarian at UNC-Chapel Hill

Programmer Libraryh3lp support, testing, and troubleshooting

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

http://www.flickr.com/photos/beglen/148214514/sizes/m/in/photostream/

What does it do?

LibraryH3lpXMPP Server with IM Gateways

AIM

ChatWidgets

Yahoo!

MSN

Librarian

Librarian

LibrarianLibrarian

LibrarianLibrarian

Google Talk

SMSText msgs

History

2001

• Like many libraries, UNC began Virtual Reference (chat) service.

2003

• Duke, NCSU, and UNC began night time chat collaboration.

• Relied on multi-user chat software.

• $10,000/yr• $3,000/yr

• Per-user fees made growth difficult.

2006

• 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 available systems.

History, continued

2007

• Eric helped the collaboration with Pidgin4Lib, Libraryh3lp’s early peer-to-peer prototype.

• Usage stats more than doubled.

• Cost: 100 – 200 hours donated programming time. Value: $8,000-16,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 differently.

Sustainability for web-based system (Libraryh3lp)

• Existing business entity: Nub Games, Inc. (LLC), from Eric’s contract programming work

• How are we going to pay for this?• Ads?• Sell the users’ data?• Get a grant?• Subscription

• 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• NCknows

• Support expectations…?• Programmer does not have time for support• Librarian has full-time librarian job

History, continued

2007

• Eric helps the collaboration with Pidgin4Lib, Libraryh3lp’s early peer-to-peer prototype.

• Usage stats more than double.

• Cost: 100 – 200 hours donated programming time. Value: $8,000-16,000.

2008

• Libraryh3lp is publicly announced. Free live trial registration open to all libraries.

• Cost $50 - $300/yr depending on institution size.

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.

History, continued2009-2010

• Libraryh3lp grows from a side project to a primary project for Eric. Displaces other income-generating work.

• Many new features added; code continually reworked for increased traffic.

• Prices raised to $250 min/yr.

2011

• Libraryh3lp has over 300 active libraries.

• Current architecture working at maximum efficiency.

• New trials temporarily on hold to prevent stability problems for existing users.

• Major new upgrade to be released in summer.

Apr-08

May-0

8Jun-08

Jul-08

Aug-08

Sep-08

Oct-08

Nov-08

Dec-08Jan-09

Feb-09

Mar-0

9

Apr-09

May-0

9Jun-09

Jul-09

Aug-09

Sep-09

Oct-09

Nov-09

Dec-09Jan-10

Feb-10

Mar-1

0

Apr-10

May-1

0Jun-10

Jul-10

Aug-10

Sep-10

Oct-10

Nov-10

Dec-10Jan-11

Feb-11

0

10000

20000

30000

40000

50000

60000

System-wide Libraryh3lp chats, April 2008 - February 2011

2008 2009 20100

50000

100000

150000

200000

250000

300000

350000

400000

450000

System-wide Libraryh3lp chats per calendar year (Jan-Dec)

2009 2010 20110

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

System-wide Libraryh3lp Jan/Feb chats, 2009-2011

Basic stats• 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(entry points)

Widget loads/Presence requests

Chats

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 tables.• 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 software.• 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 paid.

Accounting integration

…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 most browsers.

• 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 Libraryh3lp

• Can move quickly.• Very low communications overhead on

technical end.• Interesting puzzles to solve.• Mostly very happy, kind librarians.

Challenges• 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

phone.• 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, paperwork

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

organizations/businesses.– 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 chats?”

• Summer release of Libraryh3lp upgrade