Six years of Kunena
What is wrong with Kunena?
A new plan for Kunena
As we come to the end of what has been a disappointing year for the Kunena project, I have been trying to think of a few positive things to write. Kunena is more than just an open-source, web-based discussion forum product that people can download and install at no cost: it is something I am particularly fond of; I would regret seeing its development end and thousands of hours of work become an historical footnote. The sad truth is that the Kunena project has been suffering for far too long and a top-level management restructure is long overdue.
Kunena has enjoyed considerable success over the last six years, rising to become one of the popular extensions used with Joomla. However, while Kunena has been successful in the past, its future is unclear. For over six months there have been no reliable or regular information updates from the Kunena developers. People can draw their own conclusions about this information vacuum but I believe the main reason is the failure of project management at the top. Strategically, Kunena has failed as a project because of the overall inefficiency in its current management: there is no coherent plan or timetable, publicity or marketing narrative to encourage users that a future version (or versions) of Kunena can reasonably be expected.
Of course it troubles me to publicly state my conclusions because of my fondness for Kunena and out of respect for the people with whom I have worked for nearly six years. However, when there are more than just murmurs of discontent within the Kunena community, and when I am frequently asked what I know about the state of the project, perhaps it's time to openly discuss what has gone wrong and how we may be able to fix things … if indeed there's anyone else who feels, as I do, that things can be fixed.
Six years of Kunena
The encouraging news is that the Kunena component has been downloaded 3 million times. The chart on the right of this page shows that, of all the versions of Kunena, K 3.0 is the most popular.
Although the raw numbers show a sustained interest in Kunena over the past six years, I think it's curious that obsolete versions are still being downloaded. While there's undoubtedly genuine interest in using Kunena in a production sense it's difficult to explain why obsolete software is being downloaded except, perhaps, that people download out of curiosity or, more likely, because it's free. I call this the “free sample syndrome”. In other words, people are downloading anything—perhaps “everything”—they can simply because it's there! An analysis of the last 12 months' downloads of different versions of Kunena may illustrate this point better.
Kunena downloads by month by version
Raw statistics are only one indication of a software product's popularity. The data, by itself, neither upholds nor diminishes claims that Kunena is any more popular than other products of its type. Therefore, while it's comforting to see people continuing to download Kunena at the rate of 30,000+ downloads per month, this fact does not correlate in terms of how confident people are in deploying it or whether they would continue to use it if there were newer versions available. To gauge user confidence and market penetration we need other sources of information.
Regardless of the raw numbers, the overall download activity is trending downwards.
In an earlier article, I used data from the Kunena website to show the downturn in forum activity over the past couple of years. More recent information shows that the forum activity—measured as the number of messages posted per month—has further declined.
There is some correlation between the downward trend in forum activity and download activity. As these trends continue then the future oulook for Kunena is looking less promising as time goes on.
What is wrong with Kunena?
There is nothing essentially wrong with the current stable version of Kunena—functionality-wise—but there are, however, serious problems with the way the project is being managed.
Kunena's biggest asset is Matias Griese. Kunena would not be in the position it is today if it were not for him. It is to his credit that Kunena ranks as a popular/noteworthy extension on the JED. Although Kunena was a team effort in its creation and ongoing support, Matias was mostly responsible for rewriting a hundred thousand (or more) lines of PHP code.
The problem with Kunena has little to do with the code. The problem lies more with the absence of disciplined project management: the project is out of control.
To be fair, Matias has not been able to focus on Kunena for several months through no real fault of his own. However, without his involvement the remaining (few) members of the project team have been incapacitated, powerless to act and unable to achieve the project's outcomes. The main problem is that no-one is visibly in control. While, on the one hand, Matias is Kunena's biggest asset, his non-participation is also the project's biggest risk. The team needs to acknowledge this problem and develop a strategy to mitigate that risk. If the project's objectives are too ambitious for the team then they need to be realigned to something more realistic. It is better to have incremental, small successes than to gamble and risk losing everything on one big win.
Recent postings at the Kunena forum do not discuss the challenges ahead. They do not hint that the project is off-track; rather, they suggest that new versions of Kunena are actively under development and nearing completion. The question—that no-one has been able to answer (or even attempted to answer)—is “What's happening?” When will these new versions become available and when will things improve?
The question is not “When will K 3.1 be released?” The question is not even about whether K 3.0 will remain a viable forum component for Joomla while people are waiting for news about K 3.1. These questions cannot be answered because the project has no plan or structure and exists as a group of well-intentioned people individually following their own instincts and interests. In a commercially-run project these difficulties would be unlikely to occur. The difference is that Kunena is crewed by volunteers but no-one is charting its course: even with the best intentions, the “good ship Kunena” will founder if the crew members don't work together under the guidance of a watchful, alert captain.
A new plan for Kunena
The Kunena project needs a plan. The current strategy is not working. Software updates are not progressing at regular intervals. The declining trend in forum and download activity suggests a decreasing level of consumer confidence in the team's commitment.
Refocus and reorganise the team
The current team has a lot of IT talent but lacks business talent. The team needs people with business analysis skills, written communication skills and an understanding of customer relationship management.
The team lacks leadership—someone who is prepared to make tough decisions and see that objectives are achieved in a timely manner. There is no clear-cut vision or statement of goals and objectives. Without a leader the team is tearing itself and the project apart. In my opinion, the team needs a leader.
Release K 3.0.7
The last [minor] release of Kunena was K 3.0.6—released nearly 5 months ago. Although work has been ongoing with K 3.0.7 over this time, this new version has not been tested in a live operational environment. It has always been the case that pre-release versions of Kunena are installed on the Kunena website before they are released to the public. The Kunena website currently uses K 3.0.6.
According to the latest information available, there are no plans to release K 3.0.7 in the near future—possible for several more weeks. It is also unclear whether K 3.0.7 will be released before or after J! 3.4. The arrival of J! 3.4 will be a critical factor for Kunena because K 3.0 cannot be installed or upgraded on J! 3.4 with the current installation procedure.
In my opinion it would be better to release K 3.0.7 now and revise it, as necessary, after J! 3.4 is released rather than postpone its release indefinitely or argue the case for J! 3.4 as the justification for taking that decision. Again, this goes back to what I wrote earlier that, in my opinion, it is preferable to have incremental, small gains than run the risk of trying to fix everything at the one time.
Upgrade the Kunena website to J! 3.x
The Kunena website achieves a number of purposes: it exists to showcase Kunena's features; it exists as a “test environment” for the development team; it exists to demonstrate Kunena's functionality; and it exists to prove that the development team stands behind the product that is has created.
The Kunena website currently operates on an out-of-date version of J! 2.5. As we know, J! 2.5 is “dead”—support will cease on 31 December this year—and the development team has already publicly stated that they will not support Kunena on J! 2.5 systems after this date. While the Kunena website continues to use outdated and unsupported Joomla software, the purposes for which it exists cannot be accommodated.
K 3.1 relies on J! 3.x in order for people to make use of the new Crypsis template. Unless and until the Kunena website is upgraded to J! 3.x, there is no way to showcase the new features of Crypsis; there is no fully operational “test environment” for the development team to use. If “seasoned”, skilled developers are unable perform a website upgrade, what does this say to other, less-experienced users of Joomla? Therefore, while the Kunena website continues to use outdated and unsupported Joomla software, the website is unable to accommodate a working demonstration of this significant new release.
In my opinion it is imperative that the Kunena website is upgraded to J! 3.x as soon as possible. If the current website administrators are unable to undertake this task themselves, there are funds available to outsource this activity.
Abandon “K 3.1”—create “K 4.0”
K 3.1 is not a “minor” update; it involves thousands of lines of PHP, CSS and SQL rewrites. The user interface is different; the underlying architecture is different; by any reasonable assessment it is a major change. K 3.1 has been one of the longest-running software projects that I have seen and it's still in the “alpha” stage with “new features” continually being added.
I do not believe that the community will warmly welcome a new, untried and untested, major release until it has been subjected to rigorous testing by non-developers/end-users. In its current form, this new version of Kunena requires a level of understanding in how to use GitHub that removes it from the reach of everyday users of Joomla. Ordinary, everyday users are not prepared to learn the intricacies of GitHub in order to trial a new extension of Joomla if the developers are not willing to help them by giving them the basics—an installation kit that people can use with the Joomla Extension Manager. Testers will also lose interest if these revised installation packages are not frequently updated.
The last K 3.1 installation package “update” occurred on 29 November this year; the previous “update” was 20 October. If packages for [“alpha” version] testing are only released at the rate of one a month, it raises the question how long it will take before the first (of several) “beta” versions will be available and, further, how quickly the developers will respond to address problems that testers encounter.
The original objectives for K 3.1 were ambitious but, because of scope creep and lack of project oversight, the original objectives have not been realised and later alterations have contributed to the mess. Because of untrammelled scope creep and project mismanagement, K 3.1 is unsustainable.
In my opinion, it would be better to consolidate K 3.0, fix the known problems and ensure that Kunena remains sustainable for Joomla, remove the legacy code that is no required for unsupported versions of Joomla, and start again. In rebooting Kunena, start over by labelling it “K 4.0”. Although the original “K 3.1” strategy was probably reasonable—and there may be some aspects that can be salvaged from it—the tactics to achieve its outcomes have been unsuccessful. A good tactician is one who is prepared to admit their mistakes. The lesson to be learned is:
We cannot solve our problems with the same thinking we used when we created them. Albert Einstein
