Talk from Ed Veal on Open Source Community

Ed Veal, ByWater Solutions

Switching from Proprietary software to Open Source Software


  • Administrative
  • Mind set
  • Development
  • Resources

Front line staff don’t care as much about the switch; still have to learn new system. Get support from the same sources on staff.

Biggest difference? The community behind a a piece of open source software. Bug reported; community fixes; community pushes new releases. Things get developed because members of the community want things to be developed, funded, etc. The community drives, instead of the business plan; there is no business plan behind Koha. Proprietary focus on what business can sell.

Koha — open source — together because of community.

Question – if a lot of IT staff are Windows/proprietary supporters, and the staff who supports open source leave an organization and things go wrong, how do you keep open source packages in place? 

Need a plan to put together those transitions.

Concern of someone about to move to Koha: current cost for library is only Sirsi hosting [but LOTS of money goes to that]; will it require more staff time and talented staff? 1) If you go your own way, you can self-host — have to have knowledge, resources. 2) Can choose support company vendor to support, hosting, do migration. There are ways around this more easily.

Another library moving from III to Koha, biggest issue, cultural shift from proprietary to open source, switch in nomenclature — really an ILS issue, not open source. The cultural change is in administration; by using an open source product, especially one like Koha that is so community-focused, that’s where the transition will have to happen. Koha grows as you, the community, wants it to go.

Community to rely on for answers to questions. IRC channel; listservs; bugzilla.

Frontline staff at a library on Koha for awhile, they now ask if things can be done differently. They raise issues and make suggestions.

No matter what change/development you make to a system, someone has to sit behind a keyboard and write the code. Whoever is writing the code, developers whether they be in-house for a self-hosted library or through your support company, there are costs in doing that. That’s where the development costs come from. There is a shift from paying from software licensing to helping make the software better.

A lot of people are paying for the flashy, big developments but there are behind the scenes developments that are also needed.

Development process in Koha: someone finds a bug, wants an enhancement, report is placed on the community Bugzilla site. A developer (someone who writes code) writes a patch. Once that’s written, it’s added to Bugzilla. Community starts testing, it’s signed off on. Then it goes off to the Quality Assurance (QA) folks, who do a second layer of testing. Then the Release Manager (RM) checks it again, and decides if it’s going into master/next release. Everyone in the Koha community is volunteering to test.

One good way to give back to the community? Start testing patches in Bugzilla. The nos are more important than the yeses. Anyone can sign off on a patch; QA folks are checking other parts of Koha as well, to make sure it didn’t break anything; RM is checking to see if patch works; checking to make sure it doesn’t break Koha in other places and meticulously checks the code.

Need more Americans on Signoffs/QA team, especially QA team. Can volunteer to be on QA team. Say, “I would like to help.” And people want to help you!

LibKi Integration

Kyle Hall, ByWater Solutions

LibKi website

Kyle tried many, many different options that were available at the time his library (Meadville) was looking for a time management software package, and eventually developed his own, to meet his library’s needs — LibKi.

Staff interface, now shows live data (didn’t in the past). Simple interface (users; clients)

Koha works very well with LibKi. Version 2, now has support for SIP.

Does the client lock down the patron computer — can’t be bypassed? Kyle says yes. Auto-hot-key used for restrictions.

Can customize the banners on the client screen, with images and/or custom HTML.

Persistent user creation (if you don’t use SIP)

Guest pass creation

Goal: Librarian shouldn’t have to interact with system — self-sustaining.

Settings — pretty simple: default time allowance/day; default time allowance per session; client registration update delay limit — if computer is down/network issues, etc.

Client Behavior option — First come, first serve; reservations only; or combo of these two.

Automatic time extension: length; when to kick it in; exception to extensions.

Third party integration (like with Koha, to create a link to a patron in Koha).

Closing hours (not complete yet): 

Bare-bones statistics module; daily usage counts, date range, who logged on and when; can implement cron job to delete user history.

When using the client, gives time left messages, every five minutes.

Age limits now available, using Koha date of birth field. {Wonder if this could be extended to having a flag on if person has signed patron Internet use policy agreement}

Software gives options for what happens after patron logs off/time runs out: nothing; restart computer (DeepFreeze); log out of account (Cleansweep); works with Linux client, too.

Will there ever be a print feature, integration? Kyle would like this to happen, but it doesn’t have that right now.

Installing Koha

{I live-blogged this and have not yet checked for typos for all the commands below — will check later today; apologies in advance, until then}

Aaron Williams, Mercyhurst University, {}

Link to slides coming soon

Works as a web developer at Mercyhurst

  • responsible for main website at the university
  • Full stack developer
  • Linux experience; installing and maintaining various software stacks (Apache MySQL PERL PHP)
  • Polygot (know multiple languages)

Installing Koha — overview

  • Minimum hardware requirements
    • it works on a raspberry pi (runs slow):
      • 700mhz ARM processor
      • 512 MB of memory
      • 3.5 watts of power
      • SD card storage
    • Better hardware recommended for speed

Koha minimum software requirements

  • Linux — usually Debian or Ubuntu but other Linux distros are supported
  • Apache web server
  • MySQL
  • PERL Programming language: lots of Perl dependencies

Installation methods

  • From source/git
  • apt-get and pre-built packages [make everything easy]

Installing Koha [can use VirtualBox on your own computer to set up a virtual host]

Ubuntu/Debian package commands:

  • Add community repository
    • echo deb stable main | sudo tee /etc/apt/sources.list.d/koha.list
  • Add trusted repository key
    • wget -O- | sudo apt-key add -
  • Update Ubuntu or Debian using apt-get
    • sudo apt-get update
    • sudo apt-get upgrade
  • Clear the apt-get packager manager cache
    • sudo apt-get clean
  • Install Koha and dependencies
    • sudo apt-get install koha-common
    • [takes 5 mins on a reasonably fast internet connection]
  • Problem with Apache itk (errors on install; usually happens)
    • sudo a2dismod mpm_event
    • sudo a2enmond mpm_prefork
    • sudo service apache2 restart
    • sudo apt-get install -f
  • Edit initial config file
    • sudo nano /etc/koha/koha-sites.conf
    • Edit intraport, opacport, domain, and memcache [for database, makes Koha faster] settings depending on install
  • Install mysql-server dependence
    • sudo apt-get install mysql-server
  • Ensure rewrite and cgi are enabled
    • sudo a2enmod rewrite && sudo a2enmod cgi && sudo service apache2 restart
  • Setup the database for Koha
    • sudo koha-create --create-db library
  • Secure mysql installation (follow onscreen wizard)
    • sudo mysql_secure_installation
  • Add new 8080 port (for IP based install) to Apache
    • sudo nano /etc/apache2/ports.conf
    • need to add listen on 8080 (missed the details)
  • Enable vhost on Apache
    • sudo a2enmod deflate && sudo a2ensite library && sudo service apache2 restart
  • Test to ensure everything is working
    • In web browser, visit localhost or {Koha maintenance message}
    • In web browser, visit localhost:8080 or
  • Visiting localhost:8080 or
    • should prompt for username or password
    • username –> koha_library
    • password –>
      • sudo xmlstarlet sel -t -v 'yazgfs/config/pass' /etc/koha/sites/library/koha-conf.xml
    • Follow onscreen instructions/wizard

Resources: Ubuntu: Debian:

Open Source at Meadville Public Library

John Brice, Meadville Public Library Director
–33 separate FOSS (free and open source software) packages being used
–1000 sq miles
–175 plus clients
–3.5 FTE IT dept

Instead of spending money in packaged software license, we use FOSS and invest the savings in staff training and higher quality equipment.

Participation Strategy: we want to be a big fish in a small pond

  • we have limited resources
  • Every FOSS project deserves support
  • Active involvement is in two projects: Koha & LibKi

Development of MPL FOSS guidelines

  • We have small budgets: select FOSS if available (it’s cheap); host the software ourselves (reduces costs)
  • Test drive everything first through a proof concept (old hardware first)
  • DIY Library (we like to tinker) — build own furniture, lay own carpet, renovate building themselves
  • Leverage our knowledge of FOSS

Selection of OSS criteria

  • Technical details: programming language; packages used; what license does it use?
  • What is the community like? Single developer in mom’s basement vs Multiple developers for the Fortune 500

Passive Participation in FOSS

  • Do nothing (or small, donations)
  • Contribute to the project along prescribed guidelines

Active participation

  • develop documentation
  • answer support questions
  • sign off on quality assurance
  • submit bug fixes
  • finding bugs and reporting them
  • participate in development
  • participate in community discussions
  • submit new features

Active Participation — Financial

  • Attend community meetings/hackfests (travel around the world!)
  • Hire a developer/company to add a feature

FOSS Community members

  • lead programmer
  • independent developers
  • library developers
  • hosting companies
  • library management types
  • librarians

Community influence

  • influence in FOSS community is based on participation and supported development
  • You do not have to do both
  • The more you work with a FOSS community the more the community will listen to your needs

Active participation staff requirements

  • a good communicator
  • or good writer
  • or good administrator
  • or good IT support person
  • or good programmer

All can contribute to a FOSS community — all types are needed. You don’t have to be technical and know code to participate in the community.

Where to implement FOSS in a library?

  • Hire a host company
  • Support the software yourself <– Meadville’s approach
  • Self support and hire a company

MPL FOSS Development routine

  • Proof of concept — IT Plays
  • Alpha version — IT modifies/demos/approvals
  • Purchase hardware — best available and overspec, because not also paying for licenses and software. Investment goes into redundancy and specs. Pays off in liability down the road
  • Beta version — installed software/staff tests
  • production — go live with use
  • Debugging

Own FOSS customized version of Koha (starting 2007)

  • needed features: fines; clubs and services; rotating collection; different page layouts

Custom software disadvantages

Difficult to upgrade (missed the rest of his points)

Now, community Koha version for last three years, easier to manage

Expect the unexpected

  • no matter how much you test production setting can produce unexpected results
  • Need feedback system for staff (Mantis)
  • Need support of management when things go wrong

Support issues

Many channels of support available

  • Start with the idea: you’re probably not first one with the problem; search available FAQs/past questions
  • Community channels — usually responsive for help

Courage is being scared to death but saddling up anyway. –John Wayne — Meadville’s mantra

Library isn’t using the proven method that is taught in library school. But from John’s experience it is possible to do it, possible to succeed, and is possible to do it yourself, and have the courage to do it yourself.

Your mileage may vary

  • No hard and fast rules
  • Be flexible
  • Being stubborn also helps 🙂

Smells Like Teen Systems: DevOps Nirvana

Frank Wiles, @fwiles @revsys  Slides will be online later.

Smells Like Teen Systems: Advice for raising healthy happy systems and getting to DevOps nirvana

People are fearful of change. Must be small at first. Baby steps. Be agile — little a, not big A: be spiritual, not fundamentalist; mandating….just because you read it somewhere, doesn’t mean you must do it if it doesn’t work for your organization. Have ammunition: managers need data, explanations to make decisions.

Apply metrics mentality to:

  • change requests
  • trouble tickets and bugs
  • deployments
  • outages of the smallest magnitude
  • interoffice political fights
  • approved and denied requests for equipment or funds
  • hires, fires, and quits
  • $$; labor hours, etc

“We spend on average 19 hours per week requesting more information”

Guilt tripping — no other option to keep up.

“Once we put <insert system> in place, we realized we no longer needed that weekly meeting…”

DevOps: Develop Everything Visibly Automate Paranoid Services

DEV: Develop Everything Visibly: “Everything has to happen out in the open”

OPS: Operate/Automate Paranoid Services “Automate everything with ridiculous amounts of monitoring and metrics”

Everything is version-controlled. Log of why things happened.
Everything is tracked. Ticketing; Trello; Bugs; etc.

Even more visibility:

  • Level 1: Team Chat. Like Slack. Email is for outsiders.
  • Level 2: Chat Ops <– mmmmmbot!
  • Level 3: Have some fun <– Fun bots

Chat ops suggestions

  • Deployments and config changes
  • Status summaries: bot check load db3
  • Maintenance: bot start maintenance file-server-1
  • Display Alerts and Warnings
  • Server boot/shutdown messages
  • Ops logs: bot log Upgraded redis to 2.8.19
  • Resolutions: bot resolve ticket #8 Ended up just needing to restart Apache
  • Common actions: bot restart apache on production

Tools: This is how we do it

  • Python: scripting language {relatively easy to learn and readable; libraries for talking to everything} Lots of libraries: Fabric highly rec’d, shell scripting on steroids
  • SaltStack: master & and then salt (minion) code. as simple or as complicated as you want; fast communication even among hundreds of systems (zeromq +aes); extensible via python; ability to return data to the master for monitoring or metrics purposes; simple to crazy complicated orchestration between systems. Examples of uses: Targeting (/srv/salt/top.sls); Pillars (/srv/pillar/* (config differences as data such as); templating
  • Consul: service discovery and monitoring: health checks; discover services via DNS or HTTP REST apis; deadman health checks.
  • ELK: Elastic Search/Logstash/Kibano <– fast log searching for when you don’t.
  • “Logs that aren’t centralized are rarely checked and logs that aren’t searchable are never correlated” -Frank Wiles
  • Graphana: for metrics visualization; pretty graphs.
  • Don’t capture exceptions in your inbox; put in a system.; Rollbar. Rollbar also tracks deployments.
  • What to capture? As much you can store.
    • general collectd system stats
    • logins/signups/emails sent
    • failed login attempts/emails bounced
    • run time of crons and batch jobs
    • backup run times and file size(s)

Resistance. Route around it. If you don’t work with the process….

Maverick Ricardo Semler {1993}

Turn resistance back on others, sometimes so it’s so cumbersome that it burdens their way of thinking.