Maybe by using LibLime's own naming I have fallen into a marketing trap. LEK is however Koha based even if referring to LEK as Koha may lead to semantic confusion. OPALS is Koha based at least from an earlier period and LEK is more recently Koha based which should make integration of LEK into Koha fairly easy at the present time.
Except that Liblime has indicated that they will only be releasing the files in a standard tarball style, and will make no effort to help integrate the work with standard Koha. At the very best, this makes integration extremely hard.
All I am suggesting is not to push LibLime out of the Koha community any faster than they are taking themselves out. LibLime obviously wants the association with the Koha name and that at least should be used as an inducement for them to participate in the community.
I would agree. Liblime has been a great contributor in the past, and perhaps they will come back in time. However, it's also possible that Liblime needs only the name recognition that Koha brings.
I would like to see what might be done to encourage LEK to actually become part of Koha by not insisting too strongly that it is entirely alien code. Gentle encouragement may not have been working well with LibLime recently, however, there is some evidence that taking a stern attitude about some things has only exacerbated problems with the company which does effectively control the community website.
The problem is that it *is* alien code. And the longer the time between releasing the code to LEK, the harder it becomes to integrate. We are working on Koha, and they are working on LEK. So it's not the situation where they release code that is just more features on top of standard Koha. By the time they release it, Koha will have changed quite a lot. Features are being added continuously to Koha. Once this happens, integrating the two becomes extremely difficult. This problem is exacerbated by Liblimes outright statement that they will not make a Git repository for LEK available, which would have gone a long way to helping this situation.
I have always thought that the English demonstration should have been hosted on the community website without any subtle advertising. Failing to correct the issue in the past has become a small problem for the image of Koha as free software which is not dependent upon any particular company. It would have been much easier to address that issue when Katipo was controlling the community website but I never made comment. Fixing the issue had always meant maintaining a current demonstration system and at least LibLime had been doing that work when no one else offered.
There was no reason they could not have left up their standard Koha demos, and added their LEK demos in addition, but they chose not to. No request was ever made. Liblime, at least in recent times, has prefered to do everything internally, rather than get community help. The way they went ahead with forming a Koha non-profit foundation is another example. No intention of doing so was declared, we only found out after the fact. I can't really judge them for these actions, but it is what it is.
Yes I think that we should make the issue clear but I do not think we should press the issue in a manner which is only likely to provoke a negative reaction. Until the community is less dependent upon what LibLime controls, the community should keep better in mind the personal attitude of those in control. At the present time, I think that our prospect of influence is greater by asking for cooperation where it is more likely to be obtained.
At this point, I get the feeling that the only way we the community will ever have full control of Koha again is to 'fork' Koha by renaming it, while registering all trademarks and domain names in advance. What's Maori for 'Another Gift'? I'm sure the collective resources of the Koha support companies could easily handle this. If another Koha demo is needed, I will volunteer to host it, along with anything else ( websites, git, etc. ). Kyle