Even the developers admit that K 3.1 is flailing
Download latest [development] version of K 3.1 here
Kunena and J! 3.4
Kunena documentation
Even the developers admit that K 3.1 is flailing
The latest news about Kunena 3.1 is not encouraging
We unfortunately do not have much new information to share. We have various team members still working on pieces of the software and those parts are progressing (templating, design, etc.). However we have limited experienced architecture developers that can take the current algorithmic code and have a wide experience and knowledge in how to fix and implement some blocking problems to get Kunena 3.1 ready. I foresee a stalled situation until we get our time (which relates to cost) of developing Kunena. "coder4life", When will K 3.1 be released?, 24-Nov-2014
I do not think that anyone requires a crystal ball to “foresee” the stagnation of the Kunena project. For those of you who have followed my blog over the past few months, I think it's as clear as daylight that announcements like the one you see above are little more than a veiled admission that the developers lack confidence in their own ability to shift the project into gear and get it on track again. What is required, in addressing this issue, is less excuses, less political spin and more action.
The list of problems with K 3.0 continues to grow (for example, the eBay widget code in K 3.0 does not work with the current eBay API). In my earlier article, I stated that I did not know if a future maintenance release for K 3.0 was being undertaken. For the last three weeks there has been discussion amongst the developers to address some defects that have been reported and incorporate these things into K 3.0.7. As to what those issues are, I'm left wondering what issues are being undertaken and when (or if) they will be realised.
Apparently the fixes for these problems have been done but, unless you're a whizz-kid with GitHub, you will have to wait patiently until they have been assembled into a future maintenance release of Kunena. As to when a future maintenance release will become publicly available this is anyone's guess—I know no more about this than anyone else. A big problem for all of us who rely on a volunteer-based development team to deliver these fixes is that people's patience is wearing thin and the goods are not being delivered.
A continuing disappointment about Kunena is the inability of the developers to engage in open, brutally honest, discussion with the community about the problems that they are having. Suggestions like having “limited experienced architecture developers that can take the current algorithmic code and have a wide experience and knowledge in how to fix and implement some blocking problems” don't really say anything more than the project is sinking because of a lack of competence. Excuses like those offer no comfort to the thousands of devoted followers of Kunena who have invested their countless hours in building their websites and using Kunena for their forum discussions. Introspective statements like having “limited experience” do not inspire confidence. If these sentiments are a general call for help then they are misplaced if they're buried within the depths of a discussion forum. Instead, what is needed is a general call for help from the community. Perhaps a better way to make that call would be for someone to write a centre-piece article on the “developer's blog” page at the Kunena website.
By any ordinary reckoning, the Kunena project has been out of control and failing to achieve targets for nearly a year. Like most people, my interest in Kunena is about how to maintain a web-based discussion forum in Joomla because of our faith that Joomla is a reliable mechanism for developing websites and because Kunena has consistently been the best discussion forum component available. It's not simply a matter of Kunena being the “best component” because it's free; in my opinion, Kunena is better than all other discussion forum components for Joomla that are currently available whether they are free or whether you have to purchase them. Given the public relations vacuum that currently exists at the Kunena website, it's become almost impossible to see how to regenerate enthusiasm within the Jooma community that there is a bright, progressive future for Kunena.
I have enjoyed being part of the team that produced Kunena; for me it was more than a mere hobby. I learned much from the original foundation members—Matias Griese, Oliver Ratzesberger and Ron Severdia—about the strengths and pit-falls of open-source development. Equally, we appreciated the contributions that all of us made to the Kunena project as a whole. But, over the past 6 years, the team has changed: Oliver and Ron left to pursue their own interests and Matias has been unable to devote more than a fraction of the time that is necessary to keep the project active and engaged.
My purpose in writing this article is not to unfairly or unduly emphasise that the Kunena project is in a state of torpor. My purpose is to articulate the antipathy that ordinary people everywhere are now feeling about what is happening, why it is happening, and whether there is any change in sight. For obvious reasons I am not going to publicly reveal my sources for making comments like that but, by the same token, the developers have done nothing to allay the growing doubts and suspicions that people have expressed, publicly or in private. My purpose in writing this article is to stimulate the Kunena developers into action.
The community has been waiting for over 4 months for an update from the Kunena development team concerning the current state-of-play. We are still waiting but, I regret to say, the wait seems to be a forlorn hope.
It is important to me, personally, that there may be some hope that Kunena will have a future. It's important because, like thousands of people around the world, my business relies on Kunena. The trouble is that people cannot wait forever and they will eventually move on and seek other alternatives. In the meantime I will persevere for the time being and keep faith with those of you who use this site and who want personal, professional help with Kunena, with Joomla or with web-craft generally.
Download latest [development] version of K 3.1 here
Rather that trying to piece together the current situation with the development of K 3.1, I am giving people the opportunity to see, for themselves, what it's all about.
It is important to understand that (a) I have not personally tested this package and (b) if you install it, you accept the risk that it is unsupported at this time.
Kunena and J! 3.4
The number one problem for Kunena in the future is that J! 3.4 will not ship with Mootools. This may, or may not, pose a problem for people who are already using Kunena on their J! 3.x websites and subsequently upgrade to J! 3.4 but it will definitely cause problems for new users of Kunena attempting to install the component on J! 3.4 for the first time. The reason is that the K 3.0 installation procedure relies on Joomla's Mootools; if there is no Joomla Mootools then the K 3.0 installation will fail. It's as simple as that.
The developers have mentioned that, in field trials of J! 3.4 (beta) the Kunena installation procedure needs to be changed. I am uncertain, however, whether this change will be included in K 3.0.7 or not. I am also uncertain whether K 3.0.7 will incorporate three different installation procedures—one for J! 2.5, another for J! 3.0-3.3 and a third one for J! 3.4+. Perhaps K 3.0.7 will be released in two different downloadable forms? I simply have no more information that what I have read at GitHub.
One thing is certain: if people start using J! 3.4 then they will not be able to install Kunena or upgrade from an older version of Kunena until this problem is fixed.
Kunena documentation
Documenting Kunena originally began through the generous contributions from all members of the community. Based on the popular mediaWiki software, the documentation website has grown into a major repository of knowledge on hundreds of topics about Kunena going all the way back to the inception of the project. Although some people suggest that mediaWiki mark-up language is clumsy and difficult to use—it's no more difficult to learn than any other mark-up languge—the Kunena Wiki is about the most comprehensive help manual available for people who use Kunena.
The challenge for people to keep the documentation up-to-date, relevant and “alive” is not that there's a scarcity of those who possess the technical understanding about mediaWiki mark-up language. The challenge is more about getting information from the developers in a timely manner; the challenge is getting the developers to share their technical insights about Kunena with the non-technical end users who need the bare essentials to get on with the job. The challenge is more about how to transmit that knowledge than about the transmission medium per se. And, as we all know, software technicians generally do not make good technical writers.
There is no one, specific person responsible for managing the documentation website. It has always been a team effort. Most of the recent discussions I have had with the team have revolved around whether it's necessary to maintain a documentation website or technical digressions about alternative formats that documentation may take in future. Although no specific decision has yet been made, it is likely that the existing documentation Wiki will disappear and that only a very little of what once existed will be “preserved”. It is now questionable that end-user documentation about Kunena will exist within a single repository; people could be forgiven for having to continually ask for information via the forum. Adding to the complications that the community has been kept unaware of what's actually happening with the project and its future and, amid growing disappointment felt by members of the community that the project has gone into cardiac arrest, the possibility that K 3.1 will be released without adequate documentation to prepare and assist users with the significant differences between it and its predecessors, this last encumbrance may be too much for the community to accept.
