Woo hoo: Koha Con 2010 bus trip

So I am thinking it would be really nice to meet people coming into Auckland for Koha Conference and drive them down to Wellington. We could take a few days for a quick detour through Rotorua and heartland NZ, driving down through the North Island via Levin.

Current thinking is:

Day 1: arrive in Auckland, dinner at the harbour area.
Day 2: travel to Rotorua (3 hours ish) afternoon at Te Puia thermal area, Maori cultural night in the evening, spend night in Rotorua.
Day 3: drive down the island, afternoon tea / civic reception at Levin (4 hours drive), travel to Wellington for evening meal and the night.
Day 4: either a spare day in Wellington or day 1 of Koha Conference.

So what do you reckon? If there is enough interest I'll grab some indicative pricing together.

Users vs developers : not in my universe!

Today I went to Wellington to have lunch with Bob Birchall, CEO of Calyx, and Chris Cormack from Catalyst IT. Through a serendipitous crossing of paths we were joined by Simon Blake from Citylink; Rachel Hamilton-Williams, CEO of Katipo Communications; Mason James, CEO of KohaAloha and Brenda Chawner from Victoria University.

Thats 1 user, 1 Academic / FOSS commentator, a network engineer and 4 Koha vendors. Driving back home again I got to thinking about this group in relation to the discussion on the Koha list about users vs developers.

Owen Leonard has written very eloquently about this and I have used below big chunks of his email to the Koha list made in response to a comment made that Koha "users" and "developers" are at opposite ends of a pole.

Owen:

"I'm a Koha user. And in using Koha I saw that I could make Koha better, and in time became a Koha developer. There is no Koha developer out there who is developing Koha features just because they think it would be cool to do. Koha developers are doing their work because they *see* a need, in an actual user or an actual library. Or developers are getting paid by libraries to develop the features the libraries need."

He goes on to list the occasions when users and developers are in opposition:

• "When a company decides to develop a feature that they think will help sell a product, even though the feature doesn't meet any actual need,
• When a company throttles or cripples a feature in a product because they want to charge extra for a particular feature."

Now I have been around Koha for a decade now and I agree with Owen that no self-respecting Koha developer or Koha support company is doing that kind of stuff.

The LibLime experience has hurt the Koha community in the States. I get the distinct feeling from reading various blogs and help requests on the Koha list that LibLime clients have been having a hard time of it, hence their very valid wish to gain more of a 'users' voice than they have had in the past. I suspect this applies more specifically to Liblime clients than Koha users in general though. It is also a real risk when Libraries abdicate responsibilty for their own systems by handing it over to a vendor: a traditional client-vendor relationship.

Brenda mentioned today that her research is indicating that contributing to FOSS projects has a direct correlation to satisfaction levels. This is a critical point and one which I raised in the presentation Chris and I made at LIANZA 2009.

As librarians we are comfortable with a traditional client-vendor relationship. But the times are a changin folks and as librarians we have to change to. We need to be taking back control of our industry tools; Dewey and Ranganathan were both librarians and the originators of Evergreen and Koha were librarians too.

We have to learn new ways of working if we are going to maximise the value of Koha to our organisations:

• think about what you WANT not what we are given,
• learn basic system admin skills and take responsibility for your own Koha 'settings' to customize it for how YOU want it to operate,
• become comfortable with irc as a networking and community meeting tool,
• become skilled at identifying, describing and reporting bugs, and then testing the fixes,
• think 'what if' and log enhancement suggestions,
• and then join the discussion to ensure the developers understand what you want and how you want it to work, and work out how to make it fit into the main development trunk,
  
• fund a developer to 'do' if if you aren't a programmer yourself,
• learn to ask for help and give help to others,
• share your thinking and decision making processes, tips and tricks and inhouse resources like staff training tutorials or videos,
• become adept at collaborative working on wikis,
• fund work for the 'greater good' not holding it selfishly to yourself,
• and co-fund significant developments with other organisations to share the cost so we all benefit.

I'll leave the last word to Owen:

"Let's get together as users and/or developers and figure out how we can get some stuff done. Let's put together a structure by which Koha users can spec out new features and get them funded, collectively. Let's put together a structure by which Koha users can communicate with their vendors without fear of exclusion or reprisal. Let's not talk about a users group breaking down some barrier that isn't really there; let's talk about strengthening and leveraging the connection that we already have!"

Personal MBA reading list

I came across Josh Kaufman's Personal MBA site on Lifehacker a few months back and I'm thinking it would probably be a very good personal goal to read my way through his recommended book list one title at a time .... or at least 1 book from each section :)