View
816
Download
2
Embed Size (px)
DESCRIPTION
Providing LibraryH3lp Pam Sessoms, Undergraduate Librarian, University of North Carolina–Chapel Hill, LibraryH3lp Libraryh3lp was created three years ago to solve technical problems associated with offering night-time collaborative chat and IM reference services between Duke, NCSU, and UNC-Chapel Hill. It is now a popular, low-cost virtual reference platform used by over 300 libraries around the world. Behind the scenes, Libraryh3lp was conceived of and continues to be provided by Eric Sessoms, President of Nub Games, Inc., with assistance from Pam Sessoms, a working librarian at UNC-Chapel Hill. Come learn more about the business and operational sides of Libraryh3lp, including the benefits and challenges involved with this unique model.
Citation preview
Providing Libraryh3lp
Pam SessomsUNC-Chapel Hill Undergraduate Librarian/and also Libraryh3lp
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