A few weeks ago I answered a call for stories about mentoring in open source. I wrote in and told the author all about my amazing experiences in the Koha community and about my Koha mentor Chris Cormack. I mentioned that if it wasn’t for him I wouldn’t have gotten involved in Koha in the first place and that it’s because of work like his and so many other patient Koha community members that I have been able to participate so much.

The article with my quote (and my others) in it has been published on ITWorld.

One delicious example of a spontaneous relationship that worked is the one between Koha’s Cormack and Nicole Engard (http://web2learning.net), Koha’s documentation manager and soon to start a new day job as director of open source education at ByWater Solutions. Engard joined the Koha community in 2008. “I was excited to be a part of something so awesome — and rare in the library world — but a bit nervous about jumping into something that was so well established,” she says. Cormack, one of Koha’s original developers, took Engard under his wing. “He taught me the ropes, he never, ever said I had a stupid question. He never ignored me. He has always been patient and willing to walk me through things.” Distance didn’t matter; Cormack is in New Zealand, and Engard is on the U.S. east coast. “There is a huge time difference for us; he is often helping at midnight his time,” she says with heartfelt appreciation.

Read the entire article on ITWorld.

There is a great post over on Perlbuzz that talks about the importance of mentoring in open source communities. As I work on compiling open source stories and experiences I find that what Esther says is right on point.

Open source offers amazing opportunities. There are almost no barriers to entry. If you want to try creating a new-to-you kind of application, or to learn how to write bright-shiny documentation, or to use the latest technology that your Day Job doesn’t give you access to — you can just barrel right in with an open source project and get involved. Once you become proficient (or demonstrate that you already are), you can apply those skills in the next phase of your career. Even better, you can choose which community you want to be a part of, and find a comfortable culture where your contributions matter.

However, because open source is so personally driven and self-motivated, there aren’t always a lot of opportunities to consciously improve your skills — except on your own. While that’s certainly valuable, it relies on you recognizing what needs improvement and then knowing what to do about it.

One of the biggest concerns I hear from librarians when I talk to them about open source is their lack of technology skills. While there are ways around this (support companies, freelancers, and even local students), I try to encourage people to let go of their fear and just jump in. I spent a year simply answering questions as I could on the Koha mailing list and then at KohaCon I decided to stay for the Developer’s Post Conference and I am so excited that I did!! I learned so much and that made it so that I was able to submit my first series of patches.

My point is that most open source communities are about … well … community People will help you out – they want you to succeed and they want you to help them succeed so just jump right in and ask for help – you never know you might end up adding a tiny enhancement that people have been asking for for ages

Also – make sure you read Esther’s entire post.

David Eaves has an awesome post on his blog that takes a talk by Angie Byron a step further. I don’t just want to repeat his entire post, but it was so well written that I have been holding on to it to figure out a way to summarize it without repeating – and I couldn’t. So here’s what I’m going to share – and the rest you’re going read on David’s blog.

David takes this figure from Angie …

… and points out that while this is probably true, only a small amount of people have the skills necessary to participate in fixing open source applications we can change that by making community participation easier…

I can only speak for the one community I’m part of – but this is certainly something the Koha community tries to do. I have been submitting patches recently because of the patience of several experienced developers. The time they took to help me understand what I was doing made it so that I could patch bugs (I can do something about it) and add new features (things I thought were dumb the old way).

Read David’s entire post here.

Okay, so I’ve never used the products that William Shields mentions in his blog post, but the theme still applies. One of the biggest worries about open source is the lack of documentation. I attended a conference last year where one of the attendees asked the speaker about documentation and open source – her concern was that there wasn’t enough documentation for many of the products she wanted to use. Of course I had to follow up after her and say that Koha has amazing documentation (no – I’m not saying that cause I wrote the manual – there are actually a lot of docs that I didn’t write for Koha as well). Anyway, William Shields expresses his frustration with lack of documentation on open source products:

RTFS

This one is predictable. Some will argue that the source code is sufficient documentation. Bollocks to that. While at some point it is inevitable you will end up reading or stepping through the source code of any framework or library you use for any non-trivial purpose, the fact that you have the source code is no substitute for high-level documentation that describes the overall architecture and design principles as well as how to get started and how to do common tasks.

DIY

Another popular defence of poor OSS practices is you can get involved and do it yourself. While theoretically true it is typically completely impractical. For one thing, before you can document something you have to know it. How do you learn it without reading the (non-existent) documentation?

I’m with him on this – it’s bollocks! Not everyone using open source is a programmer – some are just average folks and they need documentation – documentation written in English (or their native language) not programmerese. For that reason, I try to only recommend products that have readable documentation

Yesterday I read this awesome post by Kirrily Robert about being a woman in open source. This post is a summary of her talk from OSCON about standing out in open source as a woman.

So what does it feel like to be a woman in open source? Jono Bacon, at the Community Leadership Summit on the weekend, said — addressing the guys in the room — that if you want to know what it’s like to be a woman in open source, go and get your nails done at a salon. He did this a week or so back, and when he walked into the salon he realised he was the only man there, and felt kind of out of place.

Another example someone suggested is walking into a sports bar on game night wearing the wrong team’s jersey. It can be the most friendly sports bar in the universe, but you’re still going to feel pretty awkward.

So as a woman in open source, it can be a bit like that. You walk into a space, and you feel like you stand out. And there’s enormous pressure to perform well, in case any mistake you make reflects on everyone of your gender.

I haven’t felt this way in the Koha community – which says something great about the people involved in Koha – but I do sometimes feel like I know less than the others on the project because I can’t program in Perl and submit substantial patches. One way Kirrily recommends making women and community members in general feel welcome is to thanks them for even the smallest of contributions – once again – something I have seen done in the Koha community plenty of times!!

Value all contributions.

Large or small, code or docs or bug reports or organisational tasks. All are valuable to your project. Say “thank you”. You don’t have to be the project leader to do this; anyone can do it, and it makes a big difference.

The entire post is well worth reading even if you think your project is creating all participants equally.

A few months ago, I was excited to read that the amazing developers at Biblibre were working on integrating Koha into John Blyberg’s SOPAC. Well, Biblibre has announced a demo of their SOPAC/Koha installation on their blog. The post was in French, so I’ll summarize for you.

You can access their very awesome demo online at: http://demo.sopac.biblibre.com/. It is important to remember this is just a test install for us to test and for them to play with – so if you have comments as you poke around, be sure to contact them and let them know what you learned.

Technorati Tags: sopac, koha