+1 fror the "one Koha to rule them all" approach. Such country-specific yet country-wide needs would become occasions to consider koha functionality in a broader context, for the principle behind them is very unlikely to be unique and restricted to a single country. Good ideas and organization developments tend to resurface globally.
It is bad enough that there are an open koha and a separate open-ish one, that program behaviour may be altered by the combination of OS distribution and libraries used, version-specific features and regressions. Country-specific forks quickly become dated, and would in fact deter new libraries/organizations from considering koha. Consider the analog of Microsoft making globally available English/Spanish/Chinese versions of MS-Office 2013, supplying French, German and Russian markets though with country-specific versions of MS-Office 2002/XP. Not a good move, surely. If koha aspires to be used globally, it should try and be country/language/culture agnostic. One example I may quote is character sets supported in Z39.50 target definitions. Once the need to support more than one character set is acknowledged, the "global" approach would be to make koha able to easily accommodate any language/set, not just to manually amend code in order to add a single language/set, each time an addition is requested. In general, whatever may be defined in the database - and changed by the implementor in a trial-and-error procedure - would best be kept off the code. More server resources may be thus required, this approach however leads to a more adaptable, more agile product. Hope to meet you in Salonica on May 31st :-) Manos Petridis
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
