On Wed, May 11, 2011 at 2:01 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
Hi All
Recently I have been having a crisis of confidence. I have, I hope, always tried to do what I think is best for the project. Often I do make mistakes, a notable one happened in 2007, which I hope I in part was rectified in 2008. But my underlying motivation with Koha has always been to do the best for the users of the software. In my role as Release Manager for 3.4 (and again for 3.6) what I felt was best for the software users was a stable and well tested release. This is something I made clear in my proposal, and which I had assumed was understood (but you know what they say about assumptions ;)). With the huge amount of work put in by over 80 people, I think we managed to achieve some measure of success with that with 3.4.0 and that the stability of the 3.2.x releases is something we can all be proud of.
Over the last couple of weeks, comments and mails both on and off list have made me think that maybe I am out of step with what the community desires. For 3.6 quality was still the major goal, but perhaps I have misjudged what others want. This has resulted in sleepless nights and quite a large amount of self doubt.
First of all, Chris++ for the hard and good work he is doing every day. For a noob like me its leadership has been really inspiring and I'm comfortable with the current workflow which I think . As a 'small' (+30 libraries/koha deploys) contributor University, we've faced several times this problem Paul brought into discussion last year about BibLibre's difficulties to make community development roadmap/process fit their own's, and its' business model. Even if we are a small non-profit contributor we 'felt the same' [1]. I think it is not easy to avoid this problem: the tension between community established roadmap and the needs of a third party's business. Companies like BibLibre have made Koha the great piece of software it is now (the same goes for LibLime and other companies), so it is not just BibLibre's problem. Community and third parties roadmaps diverge easily. As Paul said, perhaps forking is the only solution for a business model if we don't find a proper solution. I'd like to see an approach that provided a proper semi-formal way to make strategic decisions on the future of the project, so that third parties can propose the community a "big feature" or a "big change", and the core developers can plan on how the integration will be done. If it fits the business model (i.e. secrecy is not a need for it), maybe even make external core devs have access to relevant information on the inside development process: develop on the open. I'd like to elaborate a bit more on the need for a strategic decision taking mechanism, but i've been busy with other project for which i'll fly to europe tomorrow. Maybe I get some more time to spend in koha in a few weeks. Thanks for all the hard work and good will put into this discussion. To+ [1] We even stopped developing some features our librarians asked for until we could understand and fit into the dev community and the process itself. WE DON'T WANT TO FORK. Several times we had the feeling we could have spent our money/time in a more feature-providing way, but where confident that we could make our voice into the dev community. Day suspension fines is a feature we proposed to develop ourselves with some core-developer guidance but only got this answer: "liblime has developed that, wait for them to merge their branch". We are currently working with a small, harmless fork we can maintain updated.