Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

library h3lp

Sessoms gives an overview of the Library H3lp service

  • Login to see the comments

  • Be the first to like this

library h3lp

  1. 1. Providing Libraryh3lp Pam Sessoms UNC-Chapel Hill Undergraduate Librarian/and also Libraryh3lp
  2. 2. Who runs this thing? Eric Pam President, 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
  3. 3. What does Libraryh3lp do? Provides a flexible platform for building virtual reference services
  4. 4.
  5. 5. What does it do? LibraryH3lp XMPP Server with IM Gateways AIM Chat Widgets Yahoo! MSN Librarian Librarian Librarian Librarian LibrarianLibrarian Google Talk SMS Text msgs
  6. 6. 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.
  7. 7. 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.
  8. 8. 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
  9. 9. 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.
  10. 10. History, continued 2009-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.
  11. 11. 0 10000 20000 30000 40000 50000 60000 Apr-08 May-08 Jun-08 Jul-08 Aug-08 Sep-08 Oct-08 Nov-08 Dec-08 Jan-09 Feb-09 Mar-09 Apr-09 May-09 Jun-09 Jul-09 Aug-09 Sep-09 Oct-09 Nov-09 Dec-09 Jan-10 Feb-10 Mar-10 Apr-10 May-10 Jun-10 Jul-10 Aug-10 Sep-10 Oct-10 Nov-10 Dec-10 Jan-11 Feb-11 System-wide Libraryh3lp chats, April 2008 - February 2011
  12. 12. 0 50000 100000 150000 200000 250000 300000 350000 400000 450000 2008 2009 2010 System-wide Libraryh3lp chats per calendar year (Jan-Dec)
  13. 13. 0 10000 20000 30000 40000 50000 60000 70000 80000 90000 100000 2009 2010 2011 System-wide Libraryh3lp Jan/Feb chats, 2009-2011
  14. 14. 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
  15. 15. 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
  16. 16. 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)
  17. 17. 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.
  18. 18. Accounting integration
  19. 19. …but efficiency starts with the code Presence: Online? Offline?
  20. 20. 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.
  21. 21. 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.
  22. 22. 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. 
  23. 23. 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.
  24. 24. 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!!!
  25. 25. 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