Should encrypted Magento extensions be allowed on the new Magento Connect?
A heated Twitter debate is under way over what Magento should or should not allow in the new, updated Connect, and it was started by Magento themselves.
The plans are that new Magento Connect will focus on the quality of extensions listed and will, ultimately, become a much more merchant- and developer-friendly place where everyone around Magento ecosystem will run to, not from.
The biggest question seems to be – should encrypted Magento extensions be allowed? Let’s check the story behind it, pros, cons, and in-betweens and try to come up with a solution, or figure out what Magento will decide.
So, what’s the whole fuss about?
If you’re not that familiar with Magento Connect (really? so what are you doing here exactly?), it started out as a Magento “app store”, or a place where anyone involved with Magento implementations can find extensions that will give them that extra piece of functionality needed on top of already a robust system that is Magento.
The issue with it, as it was with Android Market as opposed to App Store, was that developers were able to publish any type of extension without any scrutiny, quality or security check – and you can imagine the “diversity” we had there.
Extensions extravaganza
Working directly with merchants as a Solution Partner, you can imagine the things we came across and the stories our developers can share – dozens (in some instances hundreds) of extensions installed, completely messed up installations, websites that we had no idea how they’re still holding up.
With that said, we have used a number of high quality extensions and recommended a lot to our clients as there are plenty of great extension development companies out there who also offer top level support.
Open source, you say? We don’t think so.
Now, this is all good for “standard”, OSS extensions – but, there are some players in the Magento ecosystem who decided to go an extra mile with protecting their IP and have decided to encrypt their extensions – there are several ways to go about this, and one widely used, and such that most discussions are in fact about, is by using ionCube.
What this encryption does is protect certain files within a software (in this case a Magento extension) from being accessed and, ultimately, modified.
And that, my friends, is what open source community doesn’t like 🙂
Imagine a developer whose job and passion is solving problems. Now imagine that developer running into an ionCubed extension on a client’s site. Now imagine the frustration if that particular extension is causing an issue with the site and he can’t do anything about it.
Now imagine, on top of all that, a merchant who opted to go with Magento because it was open source and because the usual sales pitch is that you are free to modify it in any way and that you have a vast community of quality partners who can help you out.
But hey, there’s always support, right?
Yes and no. Granted, there are some companies that provide excellent support around their encrypted extensions and they can work together with solution partners and merchants. And there are those who can’t or simply don’t. And then everyone is stuck.
It started with a tweet…
The most recent debate was started by a tweet from Tanya Soroka, one of Magento’s product managers. And Magento should know by now that once you ask for opinion from a very vocal community, that’s exactly what you’re going to get.
As you can imagine, the discussion(s) quickly took a lot of twists and turns and it’s kind of difficult to keep track of everything that’s being said. So, I tried to sum it up.
Pros, cons and in-betweens
The majority of the recent controversy stems from two main “philosophies”, at least how I see them:
- Magento is open source, and should promote open source across its entire ecosystem (because it’s also a way to ensure no-one gets stuck with any particular vendor, beating the entire open source concept)
- Magento is a business and it should do what it deems necessary to ensure the majority of their stakeholders are happy, and basically let the market decide (and since the ecosystem around it has grown well beyond development companies, can’t we all just get along?)
Now, these two don’t need to be in a complete mismatch, but there are strong feelings from developers, solution partners, and many industry partners as well that encryption simply doesn’t play to anyone’s best interest (other than those encrypting the extensions, of course). The feelings around this option are in my mind stronger as they take into account the whole idea of the open source and the community, and bring it to a higher level.
Those opposing such an opposing attitude from an open source community do raise a valid point when they say that a community around Magento used to be (and should be) a little more inclusive. They say we shouldn’t force someone out of play just because they decided to protect their IP in a certain way. And they argue that ultimately the merchants will decide and move away from such providers who do not give them the proper support. This position is more business- and not community-driven.
Should this discussion really be about Unirgy?
Many people have mentioned Unirgy as a shiny example of good support and encryption that only covers a handful of files. And we’ve been in touch with them on several occasions and can confirm they are professional, responsive and willing to assist.
And I believe this is where most problems arise – everyone mostly mentions Unirgy – what about others? Are they the only ones who provide encryption AND good support? If so, we really do have a problem.
How shall Magento proceed?
First off, it’s great that they are including the community about a lot of new decisions they are making, especially around Magento 2. And this can, of course, be a double-edged sword with any business.
The product leadership should have a clear vision and strategy once they do take into account all different opinions, and I hope, actually I do believe the current team calling the shots around Magento product understands this.
Let’s face it, if they hadn’t asked this question and simply continued allowing all types of extensions, I don’t think there would have been so much fuss about this – yes, the developers and many solution partners, even merchants, would continue to be frustrated, but now this frustration can only get amplified is this policy remains unchanged.
There is already an “alternate” path many have suggested, and that would be that Magento allows encrypted extensions to be listed on Magento Connect, but ONLY after they have been
- submitted unencrypted
- scrutinized and approved by Magento
- encrypted by Magento themselves
And since this option is advocated by some Magento people themselves, this is probably the way they will proceed – I would only ask for regular checkups of the support level and quality of support such authors are providing. They should be placed under additional scrutiny since they are not playing by the open source rules and this should be very clear to everyone.
Our “verdict”
As for our two cents, we don’t prefer those in-between solutions that try to make everybody happy as they usually end up making everybody feel the opposite.
We would prefer Magento takes this up as an opportunity to strengthen its position as an eCommerce open source leader and stand as an advocate for a true open source ecosystem.
Everyone can still offer their solutions via other channels, but if Magento Connect is looking to be a creative platform for developers and something as close to a safe haven for merchants as possible, we see it happening only with OSS written all over it.
After all, Magento isn’t using any encryption for their product themselves and they’ve created a business model around it.
So, what’s your take? Feel free to share and let some steam off before the decision is made 🙂
25 comments
while, magento is an Open Source platform, Encryption is point less for extension.
Encrypted magento extension for the Open source platform doesn’t make any sense.
My problem with Unirgy and ioncube encrypted files is they don’t let me debug most of the site. I work on a site where there are about 15 Unirgy extensions installed and there are very few things that can be debugged without the connection being reset. It makes development take a lot longer than it should and it is very frustrating. As for Unirgy support, they have been pretty rude and unhelpful with us. If you’re willing to give them access to your production environment just so they will even listen to your problem, good luck
The trouble with encryption is: every single encrypted module that I have come across is poorly built, non-functioning with no proper / qualified support. It is my one secret thought – if it is encrypted, it is because they want to hide how badly it is coded. If I could see what they have done inside, I would run for the hills. As pointed out, it has been 100% true so far.
Why advocate for open source as well – quite honestly, I have fixed some modules myself and let the owner know what was wrong and what to fix. This is usually again due to poor support, and sometimes the fix itself is easy, but very needed.
I will not comment any technical related issue, encrypted extensions will bring – imho everyone has its own opinion there 🙂
There is another strong benefit, when you keep your code unencrypted, and this is the power of sharing your knowledge and being part of a huge community. I have started learning programming as many other people from reading code – the academic degree ist just for the records 🙂 . This allows us to constantly improve our knowledge and also share it with others.
If you build a good product and deliver a good support, then there is no need to encrypt your data or parts of the code. Your clients or customers might use your products in multiple projects and not license it, okay, this is a risk i will take. On the other hand side other developers will love you for having nothing encrypted.
Being a part of such a huge ecosystem and community is great and it is even greater if you can earn money with this. Earning money relies on building trust and encrypting means that you do not fully trust your customers or clients. This is my personal opinion. I know that there are good companies out there that do a good job with encrypted extensions – but it is not part of my philosophy.
Nice post Aron. In my opinion encryption should not be allowed on extension listed on magento Commerce. I have seen many extension provider inject unnecessary code on the name of licensing. I used a One page checkout extension that has some encrypted code and that was adding links back to their website in a hidden way when customer reaches to order success page or when cart is empty.
Personally hell NO for encryption. A project I worked for used an extension litextension and it was encrypted. Now I contacted them for the ownership but they basicly said no we cant help you.
So I bought it again and saw the extension needed a lot of extra fine tuning and the sourcecode was encrypted but the project owner already bought the extension for the other developer that could not complete the project. After new contact they wanted me to pay a huge amount to do some custom adjustment.
After that I started to decode there current extension I bought and looked the files up that were already on the FTP/website. I found out that the extension developer had FTP access and uploaded a even newer version of there extension to the website.
So after this my only thought was that the encryption wasnt there to protect there code but to make sure they could earn more cash.
After that moment I refuse to use encrypted extensions cause as a developer I dont mind buying an extension over and over cause the programming has already been done for me. The money to buy an extension is a laugh since some cost like 50 to 250 dollar and if I needed to make it myself it would cost me a lot of time and the costs for a customer grows daily. The costs of a extension can be charged extra to a client (I have that in my work contract.) and they are even happy that I tell them about an extension that saves time to get the website only but the more important thing it saves them sometimes huge amounts that would go in the thousands of euro’s sometimes.
besides the omnpany that sells the extensions usally provide FREE debugging themself so most of the time I dont have to do the thinking/work myself but if there is something that needs to be done quick, encryption free is the only way to go since you always have to way for the one to make the extension to have time.
In the end. Dont even start buying encrypted extensions. there is almosty always an other extension that is the same without. 🙂
Open source means no encryption anybody can enhance the feature and when you avoid that with encryption, its not an open source. We develop extensions for Magento community but we dont encrypt our extension as we want end client or developers to enhance its future themselves if they want in future…. Either way if you want to secure your extension have a license key with observer setting on it, that way you can prevent the public sharing of your extension…….
Thanks, Yogesh.
All of the companies (majority) in the Magento ecosystem who offer their extensions in a true OSS model with licensing (if needed) actually make a good case for this – it is possible to create a viable business model with open source.
If someone decides to encrypt their software, that’s their decision. I agree that merchants should also make their own ultimate decision (if they are aware of all the details – which they usually are not) on what to use, but I also believe that an official channel that Connect is supposed to be should be all about supporting OSS.
Opinions are always strong, especially in a community like the one Magento has built over the years, but I believe that the new team heading product development will come up with a well-thought out approach, even if some won’t like it.
So how many of you are using Intel/Atheros/Broadcom wifi cards with binary encrypted firmware while advocating open source here? My objections with Ioncube are from a technical PoV: debugging (xdebug), performance (hhvm). Quality of an extension can be gauged from the outside, if encryption is limited.
With experience, you’ll learn how extensions feel that hide bad coding under a layer of encryption. The support quality is a good measurement too. Phone home code can be stopped with good firewalling.
In the end, Magento Connect should be about using the right tool for the right job and encryption as a concept isn’t a factor in that. What is a factor is objective measurements for quality and use cases that make sense to a merchant. For (partially) encrypted modules this means:
– Dependency on vendor support: true
– Fully debuggable: false
– Can work with accellerated PHP (hhvm): false
Other object measurements can still be answered:
– Scaling factor: show a graph 0-1000 VU
– Replaces core code: true/false
– Compatible with:
– Support quality: x/5
– Works as advertized: x/5
etc.
This is the real problem with current Magento Connect. You see merchants posting “works as a charm”, but for all you know, that merchant is fine with 15 second pageloads. Hardly any technical reviews on Connect, so how is a merchant going to assess if this is the right tool.
Don’t forget that extensions aren’t for the open source community, they are for the merchants that pay our bread and butter and if they have objective measurements to weigh the downsides of encrypted source against the module’s (business and technical) perks, then who are we to argue?
Great comments, Melvyn – thanks.
This is exactly the type of information I would love to see about each extension (where possible) and in the ideal world you would have all of this information posted next to every Magento Connect extension.
But do you think these extension authors would like to be presented with huge “WARNING” signs across the board when merchants come into Connect (dependency on vendor support should be highlighted if they’re coming into an open-source playground)? Sort of beats the point of having Connect as a place that Magento firmly stands behind, doesn’t it?
No-one is arguing these extensions should be “banned” as they would still be widely available via other channels, but Magento should have their own set or principles and rules it stands behind. Merchants come to Magento because it is the most popular, most robust software, and usually marketed as an open-source, customize-it-all-you-want, take-advantage-of-partner-network solution.
Magento is now asking for opinion – the answers come from mostly development companies who also understand that merchants are their bread and butter. Opinions are never objective, whether they come from developers or merchants 🙂
We’ve seen more and more cases where merchants rely on expert opinion and advice from Magento Solution Partners – I’d say vast majority in those cases recommend not using encrypted extensions, perhaps only viable use cases (unless there’s an alternative) would be those if an extension is essential for the core of the business model.
But, in that case we always raise our concerns and ask them if they really want to build a business model based on an extension of a platform? In those cases perhaps Magento itself is not even the best option for them in the long run, and we have to be very honest about that.
At the end of the day, I would LOVE to see your suggestion on as many objectively verifiable information for all extensions, not just encrypted ones, be implemented in the new Connect 🙂
Good, it locks in conflicts that will lock you out of using a mix of modules as you will be unable to resolve those conflicts. I will guarantee that you will only be buying suites of modules from single developer houses before it’s all over. All the junk will be weeded out and you will be paying through the nose for what’s left. Magento will deserve what it becomes.
I wouldn’t go that far into worst-case scenarios as we have been working with these extensions so far – this is more of a general principle and “what do you stand for” type of question.
This might happen if all extensions were encrypted 🙂
Ioncube isn’t compatible with xdebug. This means that if ioncubed extensions are in use, you’re resorting to doing your magneto development without access to decent dev tools – it’s really frustrating.
Hi Tim, I believe you can in fact use xdebug with ioncube – here’s a piece of the discussion around this – https://twitter.com/Flyingmana/status/616321573604212737 but it still doesn’t allow you to take that extra step and actually do anything about it.
Ioncube is bad for performance , so you should consider if you want this
https://www.byte.nl/blog/magento-ioncube-and-performance/
for unirgy import there are other good extensions
cobby.io
Thanks, Jan, for sharing this article – I love those “old” ones that still apply 🙂
In my short experience, we have encountered extensions wich conflict with our modules rewrites, layouts, etc. Sometimes there’s a good support from authors, but sometimes it’s easy for us just simply modify extension’s classes. I’m gonna go with “no encryption”. Regards
I agree – extensions themselves can sometimes create an ecosystem of their own within a Magento installation 🙂
And when that happens, the worst thing you can encounter is several encrypted extensions and having to depend on the 3rd party support (which can be great btw, but the whole idea around open source platform is that you can tweak it, fix it, extend it on your own).
I had to deal with an encrypted extension in the past. I didn’t like it, additionally I had to ask my hosting provider to enable ionCube. This move will definetely increase the demand for decrypting tools.
Thanks for the comments, Oleksiy. Yes, that’s another thing we haven’t touched – sometimes these extensions have additional system requirements on top of default Magento ones which can be confusing for merchants and frustrating for devs.
Now, to make sure we’re on the same page – currently anyone can post their encrypted extensions to Connect, this is more of a consideration on whether this should change, especially in light of the latest announcements on what the new Connect will bring.
PLEASE no encryption. This is why we use Magento… complete control in customization.
Thanks, Charles – and yes, I believe a huge majority of the community prefers (and expects) this since we’re in an open source ecosystem. Let’s see how this rolls out…
I’d prefer no encryption – I like to be able to view & audit the code, to make sure there’s no obvious back doors, dodgy backlinks in the fronted code, etc. I know there’s a lot of plagiarism or outright copying of extensions, but encryption makes me nervous & prevents me from trying to figure out any bugs I encounter.
Thanks, Eddie, for your comment. Yes, that’s right on the money with what most people are saying, developers really don’t like that as they love figuring things out and understanding the system as a whole.
And from the merchant’s perspective you just don’t have control over the code and you’re usually stuck if you either can’t get proper support and/or extra features would cost you more than you’d like to invest.
With open source, you can at least get help elsewhere if things go south in any relationship.