This is a question I have been asked too many times ever since I announced I would be refactoring the component to not use Nooku anymore. Well, it all boils down to stability and compatibility of the framework. And it's finally time to write down everything I have in my mind and promised to put on a blog post many times during the last three weeks.

Edit – May 2012 – answering to the blatant lies. I wrote this blog post back in October, just 2 months after I stopped using Nooku Framework. In this blog post I made two allegations:

• Nooku Framework is a "forever alpha" software which means that the promise of using it for mass-distributed extensions is a false one
• Nooku Server is a fork of Joomla! 1.5, not a distribution, despite the assurances to the opposite which were given at that time

At the time I wrote it, Nooku zealots came to get me, accusing me of spreading FUD. Well, well... A few months later the following happened:

• Nooku Framework was announced to never stop being "refactored". Translation: it is forever alpha, as I said.
• Nooku Server was officially called a fork, as I said.

Still, Johan somehow insists that I vilified him and won't talk to me. Ladies and gentlemen, we have the first case in mankind's recorded history were saying things the way they are constitutes vilification.

Another two things, answering to some stupidities I read in the comments. No, I don't bit the hand that feeds me. Simply put, I only had exactly one component based on Nooku Framework: Akeeba Subscriptions 1.x. I only ever sold 8 licenses of 49 Euros each for it, which I had to refund (in fact, the refund cost me 85 Euros a pop, so I lost money in the process). Why? Because Nooku Framework was causing so many problems on my clients' sites that I had to pull the plug, rewrite it and now I am offering it for free. I wonder how the heck this is the hand that feeds me when I actually had to spend time, lose money and suffer bad reputation for problems not caused by my code.

The other thing I've been accused of is that I have "ripped off" Nooku Framework's code. The truth is quite different. I have never copied large chunks of NF's code into my projects. Whenever I've copied code, I've given proper attribution in the source code comments and you can check the SVN and Git hostory of my projects if you do not believe me. Not to mention that NF's code is GPL, just like mine. I don't consider making use of the GPL liberties a rip-off. I don't even consider getting ideas off another project a rip-off. If you insist with this logic, please explain to me why -using the same logic- NF should not count as a rip-off of Ruby on Rails (it's got many ideas from it) or why KInflector is an unmodified copy of Akelos PHP's Inflector class with the only change being the copyright headers. Next time you bring in a strawman argument be ready for it to backfire, morons. Some of us can actually *gasp* use Google. Who would have known?

In any case, here's the original blog article in its entiretey, unedited. Because when I say something I stick to it, I don't try to edit history to suit my agenda du jour. Now do as you guys preach and "stick to the code". This is the last time I'm wasting time on your pathetic lies. kthxbye

For starters, Nooku Framework is in a constant state of change. It's not that it's still in Alpha. That, I would understand. But the roadmap of the framework –if you're lucky enough to spot it– explicitly states: "[...] the roadmap is constantly evolving, and should be regarded as a snapshot of our current understanding of the future of the framework.". In other words, the only constant thing in this framework is change. It is not just possible, it is guaranteed, that each release will work completely differently than the previous one.

I've experienced that long enough (December 2010 - October 2011) to realise that it doesn't make business sense for me to use this framework. Why? Because I have to waste a lot of time refactoring my component, following the changes in the framework. It's the same kind of refactoring that is required to get a Joomla! 1.5 component to run on Joomla! 1.6 or later. The refactoring gets so deep, that it introduces regressions and destabilises the software. I'm in the business of providing mass-distributed extensions; I am pretty darn sure that my users and customers don't care if the code follows the latest and greatest in software engineering methodologies more than they care if it's stable.

And to those fanboys who said that "I'm doing it wrong", please tell me –in all honesty– if there is a univerally accepted "right" way to do it. I'll give a stupid example. In the pre-alpha stage, I was using Joomla!'s JFactory to fetch things like Joomla! configuration parameters. No, it was the "wrong" way. OK, I changed it to use KFactory and the Joomla! library decorator. That was the right way until sometime around 0.7.a3 when this became the "wrong" way and the right way was to use... JFactory! So, the "right" way is constantly changing in an Orwellian 1984 way. You guys may forget what was the "right" and "wrong" way of yesteryear and how this has changed time over time since but, unfortunately, I am not blessed with the memory of a goldfish...

The constant state of change in the Nooku Framework also raises compatibility issues with other Nooku-based extensions. The most notorious example is probably the complete lack of compatibility of Akeeba Subscriptions 1.x with NinjaBoard. We both used the Nooku Framework for our software, albeit different versions. I was using 0.7.a3, Stian was using 0.7.a2. The differences were so big that installing one would break the other. The same thing goes for any other Nooku-based component. It's nigh impossible to find three components using the same version of the Nooku Framework at the same time. This renders the use of the Nooku Framework a huge liability for those who are in the business of mass-distributed extensions, i.e. the majority of Joomla! developers.

I could speak about the other incompatibilites this framework has. It requires the MySQLi driver, which is incompatible with older hosts, arguably a problem of the host not the software. It is also incompatible with older versions of the IonCube Loaders (again a hosting issue), pre-5.0.41 MySQL releases (ditto) and the Suhosin patch (hm, it's half of a hosting issue and half of a software issue). Moreover, it isn't compatible with older versions of Kunena (that was mostly Kunena's fault). Anyway, these incompatibilities are not absolutely Nooku Framework's fault so I won't consider them issues unique to NF.

Anyway, the aforementioned compatibility issues forced me to violate the "dogfooding" rule I religiously follow. I've always believed that there is no point in releasing software that I'm not willing to use myself. That's why I run the latest dev releases of my other software (Akeeba Backup, Admin Tools and Akeeba Release System) on AkeebaBackup.com, which is my business and only source of income. As the saying goes, "I eat my own dogfood" in order to prove to you that I do trust my software with, essentially, my business' very existence. But not with Akeeba Subscriptions. Since I use Ninjaboard for the support forum, I couldn't use the latest release of Akeeba Subscriptions 1.0.x. I had to create a Frankenstein version, which is basically Akeeba Subscriptions 1.0.b2 on which I backported select bugfixes and features from later versions. But if I can't run my own software on my own site, how can I ask you to trust me and run it on your sites? That was a major conflict I had to resolve.

The Nooku Framework also feels over-architectured to boot. It forces you to fit your component's needs into a RESTful API. OK, this is a good idea if you're intending to create a web service, but sometimes it is just an overkill. Stupid example number two: form validation.

I wanted to have the subscription form validated both using JavaScript (live validation) and on the server side. Obviously, I didn't want to duplicate the server-side logic in JavaScript, so the logical thing to do is to place the validation code in the model. Now, how do we access that from JavaScript? Using AJAX! Therefore, we need to add a task to the controller. Oh, wait, you can't do that in Nooku as it would not be a RESTful controller anymore. Right. Let's bite the bullet create a new view, adding otherwise unnecessary controller code to force a different model to it.

Now, here's another thing. Validation is supposed to be a Read operation, therefore it has to use GET. This is fine and dandy, until you realise that real-world servers chose to severely limit the maximum length of a URL, i.e. they limit how much data you can pass in a GET request. Therefore, you need to use POST. And Nooku sees that and calls the Edit task. Fine, fine, just change the method name to handle POST requests. Oh, wait, it doesn't work! Nooku supposes that edit requests (actually, anything except a GET request) need to have a token. But the token may change anytime while you're doing your AJAX requests.

One way is to call a GET request, get the token, replace it in your form, POST the form to the validation view and read the result. The problem is that you have to rapidly do a GET followed by a POST. There's a catch: most real world servers don't allow that, they consider it a DDoS attack and block your IP. Bummer! So, we have to find a way to circumvent the token check.

And here kicks in the ever changing API. The code which checks the token was once part of the controller, then went into the dispatcher, got moved around a few places in there, then became a controller behaviour. On each version I published, I had to track down where the heck the bloody check is being done and override it. Argh!

Could it have been solved more simply? Oh, yeah. Standard Joomla! Framework: create a task in the controller. Done. A 5 minute job. Nooku Framework? Hours and hours of reading the code, tracing the execution and trying to figure out what is going on. BTW, using XDebug with Valgrind can save you some hair pulling. I realised it a few hours too late.

And, finally, it's a matter of trust. Johan Janssens was the lead developer behind Joomla! 1.5's API. I trusted him that he could create a very powerful Joomla! technology. After all, he places Nooku Framework as "a new brain for Joomla!". That's fine, until the moment he started wearing his Joomla! baseball cap and polo shirt, going to Joomla! events and having keynotes which... bash Joomla! ?! Suddenly, he urges us to "claim back" Joomla! because it's not community driven. OK, hold on. Last time I checked, the Nooku community was using the "benevolent dictator" leadership model. Johan has the first and final say about what goes in or changes in the framework. Everyone else can hope for a week's notice at the very best. It's nowhere near community-driven development. So, basically, it's the pot calling the kettle black here. This started shaking my trust.

Then, we have Nooku Server, allegedly a Joomla! 1.5 distribution. I will insist on "allegedly". Nooku Server is essentially a fork of the Joomla! CMS. Yes, a fork! According to Wikipedia, a fork "happens when developers take a legal copy of source code from one software package and start independent development on it, creating a distinct piece of software". This is exactly what Nooku Server is all about. The only thing in common with Joomla! 1.5 is the database schema and, for now, some part of the core routing logic – which Johan has said will be refactored (replaced). Everything else, all core components, have been rewritten using the Nooku Framework and restyled using CSS3 and a completely different layout. Nooku Server 0.7.a4 is as much a Joomla! 1.5 distribution as Joomla! 1.7 is a Mambo 4.5 distribution, i.e. not even by a far cry of your imagination. Having someone who creates his own CMS go to Joomla! events and bash Joomla! undermines all the trust that was left. It's clear that the forked CMS will have a life of its own at some point. I just can't trust him with supporting Joomla! any more I would trust a WordPress or Drupal developer. I respect him for what he's doing, but he seems to be diverging from Joomla! very fast.

And that's how it all comes down to stability and compatibility. We have a framework which is in constant flux and forces developers who use it to perpetually refactor their code, leading to unstable software. It makes it nigh impossible to be compatible with other software written using a different version of the same framework. It is not even certain that it will remain a Joomla! technology or if it will force you to migrate to a different CMS. It just doesn't make any business sense for me to use it any more. I am a Joomla! developer who strives to produce mass-distributed, stable software. The Nooku Framework doesn't allow me to do that, therefore I am not using it any more.

That said, I would urge all developers to try to use it, mostly as a cool educational toy. I can speak for myself. Using the Nooku Framework helped me dissolve some doubts I had regarding the correct implementation of MVC, helped me with the use of software patterns, showed me the benefits of convention-over-configuration and helped me crystallise my opinions on different possible architectures for Joomla! components. It's a very cool toy, but unless a miracle happens and it becomes stable and backwards compatible it will remain just that: a cool toy. Or a cool tool for one-off custom components which won't be mass-distributed and on which you'll never, ever lay eyes on. That is, if it continues to run on Joomla!, a bet I'm unwilling to take.