Good Morning, Joann Ransom from Levin,New Zealand, home of the mighty All Blacks and the Rugby World Cup having just beaten France ( yes! ). ORThank you for that warm introduction … what you forgot to mention Is that NZ won the Rugby World Cup last week – we beat France!First may I say what a wonderful country you have here. Brooke and I took a week’s holiday before conference and spent it in Panaji, Goa. The food was glorious, the people couldn’t have been more friendly and a highlight for us was being invited home by the tailor of this fine saree and her husband to share a family Diwali.It is an honour to be have been invited to deliver this keynote address. When I look out at this audience, and see the many nations represented I am humbled to be a part of the community. I believe Koha to be an increasingly global phenomenon and I want to take this opportunity to consider how we will meet the challenges ahead as the Koha community grows.
I was one of the team who developed Koha back in 1999: essentially a couple of librarians (Rosalie Blake and me), a programmer (Chris Cormack ), a web designer (Rachel Hamilton-Williams) and a network engineer (Simon Blake). We were looking for a new ILS, Simon and Rachel suggested using the new web technologies, Chris asked “how hard can it be” (after all its just a database with rules.) And so off we went. Library staff described how a library works, Chris programmed it, Rachel made it look pretty and Simon made it work. When I think about Koha, I can't help but be proud of how far we've come. I've watched my children grow as the ILS did. My eldest is close to finishing a BScand will head out into the world soon, my daughter will soon start university and my twins, who were toddlers, are now footballers and lifeguards. The Koha code was as small as my children when the ball first started rolling and I care about Koha just as much as I do them. I am proud of Koha and I still want to support it even as it travels around the world, by providing solid support at home, just as I will for my lad when he heads off to lick rocks in Perth or Siberia.
Levin is really small, see the racecourse – that shows the scale of the place.Koha started on a really small scale, too. It was just the 5 of us. In those early years we all knew each other really well. We were all working from the samerule book and had total confidence and trust in the decisions we each made. However, like my children, Koha has grown into a totally different beastie altogether. From being a chubby little toddler that could just do the basics it has matured into a sophisticated ILS thanks to the many hands and that have guided and shaped its development. It takes a VillageKoha went through a rocky teenage phase, too. It was led astray by a fast talking-flash-harry in a shiny suit. It was pretty torrid for a while seeing our baby going off the rails under such bad influence. However, the community came together like strong parents and took positive action to bring Koha back on the straight and narrow. It wasn’t nice to live through, but now I am happy enough to put it down to growing pains. It was just a phase in Koha’ s life cycle. In some ways,my address today is written from the viewpoint of a protective mother hen who has sent her chicks out into the world. I want to make sure they are cared for on their way, treated with respect, supported into maturity and eventually become mature, confident and capable. Imagine: Koha could be the “the one true ILS to rule them all!”
I found this model, developed by Greg Siefert, which I want to use as a framework to talk about Koha and the community that is guiding its development.
The first group in our community is the Libraries and the patrons or end users whose interests they represent. They are the ‘people’ in Siefert’s model, they are the ultimate judges as to whether or not a product or service is desirable and they define a product or vendor’s success. The next group is the developers – the technology part of the model. This refers to the code, or tools for developing the code, and the developers who do the work. The fast pace of technological innovation and collaborative development means constant change, and makes thingsfeasible today that were not even imaginable a few short years ago. The business aspect is the third part of the model – the vendors in Koha community terms. The aspect effectively filters ideas and brings only the viable, potentially profitable and sustainable ones to market – well that’s how it should happen anyway Vendors are important: they hire developers, Libraries like being in a relationship with a vendor, They coordinate funding among a client base to fund development, and sponsor community roles and events ie Release Managers, Conferences, etc.
So we have 3 distinct elements in our model,
but I want to look at where they overlap and blend because it is at the intersections where some really interesting stuff happens.
Business and People — This is where emotional innovation occurs. When there is a real connection between Vendors and Libraries meaningfultwo way dialogue will occur. This will lead to Libraries becoming more and more loyal as the vendors listen and adapt their service in response. A great balance of desirability and viability are achieved through this relationship and customers become your greatest evangelists. This happened with Katipo and us; we follow Chris wherever he goes (yes even to LibLime). I see this happening with Bywater now in the States and for a while, in those heady early days, it happened too with LibLime.Libraries like a co-dependentrelationship with vendors for a host of reasons including having expertise on the end of phone, just in time technical support rather than just in case, it’s easy for budgeting, guaranteed high level of responsiveness etc.When the union is in perfect balance life is great. The relationship thrives, vendors get excellent input and feedback on feature development, exhaustiveusability testing for design and function, and oh truckloads of free promotion. Yet when it gets out of balance we get trouble:If the desire to have a congenial working relationship dominates over sound businessdecisions it stops being financially viable. This happened with Katipo. They poured hundreds of unpaid hours into developing our Koha because they wanted us to get what we wanted – and it was cool stuff they were working on. But we couldn’t afford to pay, they wouldn’t tell us no, we kept asking for stuff and they kept doing it. That was just not economically sustainable in the long run. If short sighted business decisions over-ride the needs and wants of the Libraries we get into trouble too. Liblime did this to its client base. It chose to ignore the open source philosophy of Koha. It locked its customers into a proprietary system in order for them to have a business model that could withstand the threat of PTFS entering the American ILS market. Its actually a really good example of how NOT to do it.
People and technology — functional innovation includes looking at the features of the products and services and figuring out how they can be improved. This could also be called the design intersection. It is important to avoid the pitfall of throwing bells and whistles into this intersection just because the technology allows you to. When it works well, in perfect balance, we get speedy development of solutions that do the job. A reality check informs technical development, developers don’t just develop something because it sounds cool but because it’s a ‘good’ solution to an existing problem or will add value. When it gets out of harmony we risk getting bad features developed at the initiative of either the Library or the developers. Alternatively Libraries may request really useful features but developers may not want to incorporate them for any number of reasons. Too many bells and whistles could get developed, sacrificing function over gizmos.Kathryn Greenhill from Australia warns “Beware the tyranny of small differences” in discussing library systems and shared systems. HLT fell into the trap of having a too tailored install with ‘quirks’ we held too dear. We had a lot of features which we loved in V1.x and which ‘broke’ in 2.x with the introduction of MARC … including the FRBResque functionality which was central to the development of Koha in the first place. So we didn’t upgrade for ages. When we did, we had to pay for a whole heap of what were ‘now’ customisations to be folded into 2.2.9 and we were still on a fork.To fully realise the benefits of Koha I do believe you need to stay as close to the trunk as possible, do the minimal number of customisations and wherever possible make them configuration settings which are sent upstream.
Business and Technology — Process innovation is where businesses spend much of their time. They are constantly on the lookout for cost savings, process improvements, efficiencies, quality control, etc. This pulls in the opposite direction of the emotional innovation described in the overlap of business and people. While emotional innovation is about doing something unique for the customer, process innovation is looking to standardise and create replicability. Many businesses fall into the trap of focusing most of their energy on this intersection instead of taking the time to focus on the people and the emotional innovation.
When pure business goals start driving development we get bad stuff happening due to corporate greed: I’m thinking of LibLime’s bait and switch tactics, bad forks etc. Forks aren’t bad per se; they are often beneficial short term organic solutions which afford agility. However,when a client thinks they have purchasedopen source Koha and they get given some falsely marketed closed source variety, they get a bit ‘pissy’ - and rightfully so.When the balance is right we get high quality, viable, rapid, and sustainable development of Koha.
Each of the intersections is important, but a holistic view is even more important . We need to focus on all three parts together keeping in mind the experience of the libraries and the patrons whose needs they represent. For example, ifyou ask: ”Do these new bells and whistles help the people accomplish something or do they just get in the way?” it helps you to avoid the “just because you can” syndrome.
Vendors ignore this middle bitat their peril!Koha is open source – many libraries choose Koha for that reason You are not selling a product – but a service, There are many vendors supporting Koha globally, Clients can change vendors without changing systems, Vendors really want clients who WANT to be their clients Clients should swap vendors if they are not getting the service they require, Vendors ignore the philosophy behind choosing Koha at their peril, The tight economy means libraries are LOOKING for areas to save money and will change vendors if they are not thrilled with the service they are getting.
Linus Torvalds in a recent interview said “The other thing …. that people seem to get wrong is to think that the code they write is what matters,” “No, even if you wrote 100% of the code, and even if you are the best programmer in the world and will never need any help with the project at all, the thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it.”And that neatly sums up my argument about the 3 parts of the community needing to work in balance, but at the end of the day it is the customers, the libraries who determine whether Koha is a success or not.The Koha community needs the voices of developers AND librarians AND Vendors contributing, and from Africa and Asia and Europe and America, and little old NZ too, and from public, special, school and academic libraries … it is our diversity that keeps Koha strong.
When any of the three elements in the Koha community model gets out of sync with the others we get into real trouble.
Those intersections are really troublesome; intersections always are. But together, we can navigate them safely.
And that’s why we have road rules
There are intersection rules for Koha although they aren’t written down anywhere. Remember we started small and we knew everyone in the Koha Community and we all played nicely. Somewhere along the line, when the delicate balance amongst vendors, libraries, and developers got out of kilter we got into a jam.There is an idea that maybe we need some rules now to ensure those tricky intersections stay safe, to help us ensure that Koha is treated with respect and is kept free on its journey into the world. We can’t know everyone personally and we don’t all work from the same rule book or code of ethics. I joke about raising my children with benign neglect. My Mum used to say “Kids are like weeds - don’t mess with them too much and they’ll grow straight and strong.” To some extent that’s what we’ve done with Koha. The Koha Community has held the code lightly without too much formality and with lots of trust. We all have a vested interest in treating Koha with care, in seeing it mature so that it becomes a continually evolving, world class ILS.
It really boils down to 3 simple rules:1. Start from the basis of trust: most of the people are good most of the time,2.Share the workload, share ideas, share code,3. Grow Koha: be proud of it, talk about it and promote it.There is another rule on which there seems to be general consensus, and I can’t remember who came up with it first – either Liz or Chris – but don’t be a dick : just be nice and do the right thing.
I want to finish with a whakatauaaki as is traditional by the native people of my land.He aha te mea nui o teao?He tangata he tangata he tangata.Koha is bunch of code but most importantly it is the people – the community. The Community is YOU. Every person in this room cared enough to come to this Conference to talk to one another. You spent your time and money in order to share your experiences. Carry the spirit of conference home with you. Look for things to build. Look for things to help on. It doesn’t have to be code. It could be graphics, it could be documentation, it could simply be convincing your locality to run Koha. Don’t hesitate, join us. Welcome to the family.
The Middle Bit Business People Libraries Vendors Technology Developers
Customer experienceKoha is open source,Selling a service not a product,Libraries can change vendors without changing ILS
Linus Torvald:“The other thing … that people seem to get wrong is to think that the code they write is what matters,”“…. The code itself is unimportant; the project is only as useful as people actually find it.”
Balance is crucial Vendors Libraries Developers
Navigating Koha intersections understand the philosophy of open source, and of Koha, discover the unwritten rules of the community, hover for a bit, contribute, diversity helps make us stronger, participate – we need you!
3 Rules Trust Share Grow and don’t be a dick!
He aha te mea nui o te ao? He tangata! He tangata! He tangata!What is the most important thing in the world? It is the people, the people, the people.