|Joshua Ferraro||Sep 15, 2009 2:15 pm|
|Kyle Hall||Sep 15, 2009 2:35 pm|
|Chris Cormack||Sep 15, 2009 2:52 pm|
|Chris Nighswonger||Sep 15, 2009 3:08 pm|
|Joann Ransom||Sep 15, 2009 3:14 pm|
|Piotr Wejman||Sep 15, 2009 3:26 pm|
|Brendan Gallagher||Sep 15, 2009 9:07 pm|
|paul POULAIN||Sep 16, 2009 1:15 am|
|Liz Rea||Sep 16, 2009 11:01 am|
|Daniel Grobani||Sep 16, 2009 2:19 pm|
|Reed Wade||Sep 16, 2009 3:00 pm|
|Chris Nighswonger||Sep 16, 2009 3:25 pm|
|Owen Leonard||Sep 16, 2009 6:51 pm|
|paul POULAIN||Sep 17, 2009 12:44 am|
|paul POULAIN||Sep 17, 2009 1:11 am|
|Thomas Dukleth||Sep 18, 2009 9:36 am|
|Thomas Dukleth||Sep 18, 2009 9:43 am|
|Thomas Dukleth||Sep 18, 2009 10:44 am|
|MJ Ray||Sep 22, 2009 2:56 am|
|paul POULAIN||Sep 22, 2009 6:22 am|
|Joe Atzberger||Sep 22, 2009 8:05 am|
|Subject:||Re: [Koha] LibLime Enterprise Koha Q&A|
|From:||Thomas Dukleth (koha...@agogme.com)|
|Date:||Sep 18, 2009 10:44:37 am|
On Thu, September 17, 2009 01:51, Owen Leonard wrote:
I asked on the LibLime-users list:
Will any contributions from the community be refused to LibLime customers?
LibLime's goal is to include all quality contributions to Koha in LibLime Enterprise Koha, regardless of the source. Of course, contributions that do not meet our quality standards or that introduce bugs, will not be included.
And I asked:
Will Liblime work to fix bugs in community contributions which prevent them from being included?
If not, then LibLime Enterprise Koha is a fork of the official Koha. The two will continue to diverge until no community contribution to Koha will be able to be easily incorporated into LibLime's fork.
The best way to ensure that LibLime Enterprise Koha and the official Koha community codebase do not diverge is to encourage community contributors to put better controls in place for controlling the quality assurance process and to reject patches that introduce bugs.
I interpret this as meaning: If LibLime thinks a community-contributed, RM-approved patch is deemed "unstable," LibLime will reject it from LibLime Enterprise Koha.
How is this not a fork?
It is my understanding that at least at one time concern over code quality had motivated a degree of separateness from the community in LibLime code development. Accusations back and forth about code quality and contribution level do not help to encourage a spirit of cooperation.
Concern about code quality is a serious issue but it needs cooperation to address well. Isolated development processes may protect against some types of bugs but make other types of bugs more likely and ensures that design issues are not as well considered as they would be with input from a wider range of ideas.
All software has bugs and I know of severe bugs contributed to Koha by most everyone who has been contributing a significant amount of code. Some bugs are not necessarily obvious unless the code is available for inspection. Failing to expose code to the widest number of people merely ensures that fewer bugs will be caught and that they will persist longer.
Free software is certainly about more than mere open source development methodology. Free software is about ensuring user freedom in software allowing the user to control the software being used instead of merely being subject to the software. User freedom is maximised when the user has the widest ability to modify and share code. Lack of code sharing restricts user freedom.
Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783