----- "Weinheimer Jim" <j.weinheimer_at_aur.edu> wrote:
> Jonathan Rochkind wrote:
> > If you have any programmer/software engineer staff at all, you
> should be
> > looking for other universities to collaborate with on _shared code
> base_
> > open source solutions. And allocating resources to that. That could
> be
> > Evergreen or Koha, or it could be something other than an ILS (say,
> the
> > SOLR type solution you mentioned before).
> >
> > But what I think we need to progress is more shared codebase true
> open
> > source projects. Koha and Evergreen count. But what I'm
> particularly
> > meaning to exclude are the sorts of solutions: "Here's something I
> put
> > together for our own specific situation; you are welcome to take
> the
> > code and modify it however you want." In the open source world,
> that
> > ends up being one kind of what's called a "fork"---in the end,
> > everyone
> > is using similar code, but not the same code, so improvements made
> by
> > one are harder to share with others. It takes more up front effort
> to
> > have code where everyone is really using exactly the _same_ code
> > (configured differently; the more time up front is building in the
> > proper configuration support), but gives you serious dividends down
> the
> > line. It's that kind of effort that will give us seriously better
> software.
>
> This sounds like a great idea, but would you clarify this a bit more
> for me? For example, for my own catalog, I have modified Koha,
> building on their work. Would this count in your scenario or not? If I
> had built my own catalog from scratch (ouch!), would this not have fit
> in? But mine is not a modular type of addition, at least not now.
>
> A concern of mine in this scenario is something that I am considering
> now. My catalog is built on Koha 2.2.7, but the 2.2.9 version includes
> Zebra capabliity, similar to Lucene. I very much want to use the 2.2.9
> Zebra, but I also don't want to lose my editions. So, I'll be looking
> at a lot of work. Are you suggesting that a modular system with
> plugins, similar to Firefox, would be possible? If it were, it would
> be the best of the worlds.
Well, you should be contributing your solutions back to the Koha
community, and building them in such a way that they fit in with
the existing 'plugin' architecture (system preferences) so that
libraries that want them can turn them on and those that don't can
turn them off.
You'll also want to make sure your developers are plugged into the
Koha community so you know what's coming up next, and how it's going
to fit in with what you've done ...
Koha developers, like most programmers, use a 'Version Control System'
that allows folks to submit patches that contain new functionality, or
enhancements, and the patches merge the new code into the original code.
In Koha, we use Git (the same one that the Linux Kernel uses) and you can
see recent changes at our public version control interface:
http://git.koha.org
... the more in touch your developers are with the 'core' Koha community,
the more likely your patch is going to be accepted ... so ultimately, for
this to work, you have 'budget' for the sustainability costs.
The other option, of course, is to hire an existing Koha developer/company,
who already has the infrastructure in place to make the community sustainable
to do the work you want. Such a company may also be able to tell you who
else among their customer base is looking to do something similar, and how to
share the cost. Possible companies to hire are listed on the Koha
support page:
http://koha.org/support/pay.html
Cheers,
--
Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE
President, Technology migration, training, maintenance, support
LibLime Featuring Koha Open-Source ILS
jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Received on Wed Sep 12 2007 - 13:57:34 EDT