developers

Want to write some Koha Code?

Want to hire a Koha developer for your library or consortiaum?  Or perhaps you, or someone you know, is thinking she'd like to get involved in developing some code herself!

Well, here's the technical knowledge and/or skills that are needed in Koha developers:

If you are hiring someone, you may want to seek some help with that process as there are other skills that you should be looking for in your staff Koha developer (e.g. plays well with others). And you don't need all of these technical skills from the get-go.  Most developers have an area of expertise and then expand their skills as the need arises.  So, someone eager to expand their technological repertoire would be another characteristic to look for.

If you are looking to work on Koha, having a handle on any of these technologies could get your foot in the door (especially if you have the personality traits mentioned above.)
And FYI....much of this applies to Evergreen too.  See the Contributing Code page on the Evergreen website for more info on that.
Thanks to Galen Charlton who responded on the Koha mailing list with the basic technical skills required.  The rest of this commentary is mine.

Excellent Article about Building and Retaining Developers in your Open Source Project

Max Kanat-Alexander has written an excellent post explaining the three ciritical components of building an open source development community...and keeping it. Max is the Chief Architect, Community Lead, and Release Manager of the Bugzilla Project so he knows what's he's talking about.  Here's the start of his post, Open Source Community, Simplified:  

Growing and maintaining an open-source community depends essentially on three things:

  1. Getting people interested in contributing
  2. Removing the barriers to entering the project and contributing
  3. Retaining contributors so that they keep contributing

If you can get people interested, then have them actually contribute, and then have them stick around, you have a community. Otherwise, you don’t.

If you are just starting a project or need to improve the community of an existing project, you should address these points in reverse order. If you get people interested in a project before you do the later two steps, then people won’t be able to enter and won’t stick around when they do enter. You won’t actually expand your community. So first, we want to be sure that we can retain both existing and new contributors. Once we’ve done that, then we want to remove the barriers to entry, so that interested people can actually start contributing. Only then do we start worrying about getting people interested.

Read the full post...it's worth it!