As most of you are aware on Wednesday we found out that the Trademark application had been rejected. Which is a massive relief for all involved in the Koha project. To quote myself:
“While it hasn’t slowed down the progress of Koha, it has been a dark shadow hanging over us for nearly four years,” he said.
“I would like to thank everyone involved in helping us, the many people who donated money, Buddle Findlay for representing the trust, my employer Catalyst, and AJ Pietras and Co who provided legal support, as well as the many thousands of people who sent well-wishes.”
Here is a list of the publicity around this decision.
Please let me know if you spot any more
Some big news in the Koha world today, as well as the fantastic news that Biblibre and Bywater are partnering to offer services in the US comes the news that PTFS have acquired Liblime.
Over the last year PTFS has grown into a participating and valued member of the Koha community. Its developers are active on irc, the mailing lists, bugs.koha.org and the koha wiki. Patches are regularly sent from PTFS for bugfixes and new features. The fact that PTFS is an active member of the community leads me to treat the news of its acquisition of Liblime with great optimism.
I am hopeful that this will mean that previously unreleased code will be released and that the community can work together advancing Koha for the benefit of all. This quote from the press release
PTFS has supported ILS solutions for 15 years and is committed to resolving community differences and advancing Koha open source library technology
leads me to believe that PTFS understand that the way forward is to be part of the community, with all the benefits that brings.
Congratulations to PTFS and I look forward to it’s continued and increasing participation in the growth of Koha.
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 ðŸ™‚
Here are some things I spotted over the weekend
Due to the fact that for some bizarre reason, the Release Maintainer no longer has access to put a release up on download.koha.org.
Henri Damien Laurent has put a fixed 3.0.4 release at http://koha-fr.org/content/diffusion-koha-version-304 for people to download.
Please use this one instead of the one at download.koha.org.
This isn’t the authoritative list, Galen the release manager has a better idea than me, but this is what I think is going to be in the 3.2.0 release.
This was a question I was asked a few times, as the marketing coming out of Liblime was confusing people as to what is, and what is not in Koha.
So here’s what I know of
- Offline Circulation
- Callnumber splitting enhancements
- Staff search results page enhancements
- Email checkout slips
- Hold request targeting
- Overdue report enhancements
- Default settings for patron notifications
- Support for syndetics content
- Holds on multiple items
- Tag multiple items in the cart
- Support for different OPAC interfaces, by url, so different libraries/branches can have different looks
- OPAC display for UNIMARC using XSLT
- Can now disable Amazon reviews, without disabling Amazon book covers
- Many enhancements to patron messaging
- Huge piles of acquisition enhancements, too many to list here
- OPAC suggestions (checks the biblio doesn’t already exist)
- OPAC suggestions allow hold to be placed if item is ordered
- Searching allow stemming for other languages
- Bulk changes to items
- Moving items between MARC records
- Lots of holds improvements
- Allow borrowers to manage their privacy settings
- System preferences big improvements
- Labels rewrite
- RFID support code
- Patron group editing
This is just what I know of, and doesn’t include any partial features, so there is likely a lot more.
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.