No incomings because of ionCube
Monday, 15 March 2010Open source software gives freedom: That's something you know if you have chosen for Joomla! or Magento with a conscience mind. But today we were again so frustrated with closed source, that we almost need to say that open source is part of running a business professionally - and closed source is not!
How a perfect day gets ruined ... with ionCube
Our Yireo Shop hosts many different products, some available for free, some against a reasonable price. All our software is un-encrypted, meaning that you get full access to the source code once you've purchased the product. The same applies to the shop itself: Our Yireo Shop is based on Joomla!, MageBridge and Magento, plus a lot of extensions. And almost all of these extensions are open source as well.
All except one ... Within Magento, we need to check the customers tax-details to apply the right tax-rate to him/her, and for this, we rely on a third party Magento module which is encrypted using ionCube. We really needed the software, so we deciced to accept the risk anyway. And today, we had to feel the consequence of that: Customers had problems completing their orders and after some research we found out that the ionCube-encrypted module was to be blamed.
If one thing goes bad, everything goes bad
The ionCube-encrypted module itself relied on a SOAP-service, and this SOAP-service changed its address. After some research it was very clear to us which PHP-code needed to be changed in which way to fix this problem, with only one big "but": ionCube-encrypted software can not be edited. We had to wait for a solution of the original creators to fix this problem.
As a programmer myself, I know that you need to anticipate all exceptions possible: Once the SOAP-service goes down, you need to create a workaround. But this module caused a PHP Fatal Error instead. My main question here is that if I know that this exception was not checked for, how well written is the rest of the code? There is no way of checking for programming standards, let alone fix problems if they need fixing.
But wait, it can get worse!
So today, we had no income thanks to a problem within an ionCube-encrypted module. After disabling the module all together, the problem was bypassed. True, this could have happened with open source code as well, but at least there we were able to fix the issue right away.
But it can get worse! We once bumped into a Joomla! plugin that was base64-encrypted (excuse me, "encoded") that brought down entire websites: The commercial plugin was 100-times encoded with base64, but after decoding this weird encryption-attempt, we found that the plugin itself contained no code at all. All PHP-code was instead fetched from a remote server and executed locally. Once the remote server was down, all other sites that were using the Joomla! plugin were brought down as well.
Do we still trust closed source?
After cases like these, we became very suspicous about closed source: Was the ionCube-encryption really needed to protect the intellectual property? Or was it just a way to hide the actual spaghetti-code and all its flaws? Do we still trust ionCube-encrypted extensions? Not really.