Tag Archives: fork

Taking a break

I am currently feeling really disheartened and disappointed in the reaction of many libraries to the situation with Koha and the proprietary Liblime fork.

So I am stepping back, I am not going to comment on it, and try to not even think about it for the next month or so. I feel I have said my piece, and feel like I have not been listened to, which is fine, but it signals that there is little point continuing.

So I wish you all a merry whatever you celebrate, and a happy new year. I’ll get to bugfixing and coding :)

Reflections on the fork, a week later

When I was thinking back on this I found myself wondering, why was I so angry, disappointed and sad  about this, after all forks come and go in the FLOSS world. Often they wither and die or are merged back into the main development line. Sometimes there is enough momentum behind them they continue on, like the BSDs have done.

Forks can happen for a philosophical reason, like Gnote and Tomboy. Forks can happen due to the main trunk stalling, or being unwilling to move development in a direction that people want. Forks can happen due purely to personality conflicts.

So why did the Liblime fork cause so much of a stir, and it is a fork there can be no argument about that, separate development line = fork .. the only argument is whether it will be a long lasting or short lasting fork. So no it wasn’t the fact it was a fork, I had been resigned to that for a while, ever since it became obvious months ago there was significant amounts of work not being committed upstream. No it was the ‘spin’ around the fork that was the most concerning.

All sorts of reasons have been given as to why Liblime ‘had’ to fork.

  • They don’t have the time or resources to send patches upstream. Or another version, recent resignations of staff have meant they don’t have the resources.
  • The community’s code is so bad they have to maintain their own version.
  • They aren’t withholding code, or even if they are its only for a month or 2 (which still makes it a fork for a month or 2)
  • And lately, there is customer data bound in with their code so they can’t make it publicly available.

I’m not going to rebut each of these excuses, people have already done so, and suffice to say reality doesn’t support these. But it is distressing that what appears to me to be the real reason for maintaining their own repository and version has not been said.
Given that the technical reasons for not releasing patches upstream are demonstrably false, the only reason left is to deprive other Koha users and developers of code, to gain some kind of competitive advantage in the market place. This is a valid business strategy, not one I would take, or that I think will succeed, but valid none the less. So I don’t really take huge issue over this. It is just the fact that you should not try to make excuses and in the process cast aspersions about a huge range of people so that you don’t have to admit the real reason you are doing something. It is the fact that in the attempt to justify the fork, Liblime and their supporters have maligned a huge group of people who do not deserve that.

The Koha community retains its Documentation Manager

It has been a week of big news in the koha world. Some bad, like Liblime’s fork of Koha finally becoming public knowledge and some good like Nicole staying on as Documentation Manager.

What makes this news even better, is the fact that two of the Koha support vendors teamed up to insure Nicole could stay in the community

In an environment when some people are actively trying to paint the community as a bad thing, it’s great to see that the people who understand Free Software are prepared to walk the walk, not just talk the talk