|
The problem with Magento, like so many other OSS eCommerce platforms, is that of extensibility (or lack thereof), and the ensuing technical debt. We've been making eCommerce solutions (not just sites - CRM, warehouse management, analytics, lots and lots of marketing tools) for nearly a decade now. We started out with OsC, played with Magento, and saw, 8 years ago, that the strategy of these platforms was, well, broken. How? Well. Let's consider the typical scenario. Joe sells kites. Joe wants a website that helps him sell kites. Magento looks like it does what he wants, as it's got a cart and all that stuff. Joe finds a contractor who looks good, and has decent references from his current clients. They start work. Part way through the build, Joe realises that he wants to sell custom-printed kites, and to do this, he needs to take a deposit, and then charge the customer the balance. "Uh-oh", thinks the developer, "I'm on fixed costs, and there's no plugin for that. The architecture is a nightmare... screw it, I'll just chuck it in the core and worry about it later". Joe is happy, as his site does what he needs it to, and the developer is happy because he got paid. Six months later, Joe reads about a security update, and wants to apply it. His developer sucks his teeth, and applies it, manually re-patching in his previous hack, because making a plugin is hard, m'kay (never mind that in many scenarios, you can't make a plugin to make whatever you need to happen, happen). Joe wants another addition, and another hack is born. This cycle continues for a while, until the developer fears looking at Joe's code-base, and Joe is pissed off that everything takes a long time, and that upgrades can't be done/take forever, because the developer is having to re-implement, and re-implement, and re-implement, rather than move forwards. The other side of this is that a magento install will run a magento site - not ten, not two on different databases, and no mix-and-match of either, meaning that you end up with a whole bunch of code-bases, many of which differ, even if you're a shop exclusively running magento for your N clients. It's not clear who Magento is built for. It's not for developers, as it's painful to work with... it's not for the end user, as the front-end experience is so-so at best, and again, hard to customise without screwing up upgradability... and it's definitely not for the merchant, as it's featureless, barren, slow, and ultimately expensive to run. So what we did was build an eCommerce platform where everything is extensible and overridable. Core method doesn't quite do what you want? Not a problem, write a client-specific one, just keep your interfaces consistent, and you won't break maintainability. You can upgrade the core with impunity. You can hang as many sites as you can grind out off a single install. We deploy continuously. As a result, we've been able to focus on building features marketeers and merchandisers want, by being able to build something once, respond quickly to market and client demands, and roll it out widely with minimal effort - rather than being stuck on the terminal treadmill of broken upgrade paths. |
There is a learning curve, made steep by the esoteric MVC approach and initial lack of documentation. However, there is now a wealth of material available for learning and reference. Magento is opinionated as a framework and in its domain modeling. You mention your homegrown application; how easy is it for developers to spin up on your application, and how well would it satisfy & improve things as a drop-in app replacement for the hundreds of thousands of Magento instances out there?
"...it's not for the end user, as the front-end experience is so-so at best, and again, hard to customise without screwing up upgradability..."
Frontend experience - I'd say mostly okay, but I'll not fight you on "so-so at best". However for customizations, upgradability and obedience to DRY are the underpinning of the theming architecture. Again, lack of documentation was an issue at first (I remember duplicating the default themes for customization purposes when I first started out), but there is ample documentation now. I am most disappointed with the power given to templates, and I think this is the only legitimate gripe.
"The other side of this is that a magento install will run a magento site - not ten, not two on different databases, and no mix-and-match of either, meaning that you end up with a whole bunch of code-bases, many of which differ, even if you're a shop exclusively running magento for your N clients."
If this is an issue, you're doing it wrong. I would like to know more about how Magento cannot be a library for you to manage in VCS for your clients. There are SaaS offerings based on Magento, but at the point of building a SaaS you are beyond the edge of the intent/target of the problems which Magento is built to solve.
"...it's definitely not for the merchant, as it's featureless, barren..."
/me looks at all the routes in the admin and at the Connect marketplace...
"[it's] slow, and ultimately expensive to run"
Would like to know your numbers for this. Scalability is a concern, as Magento vertical and horizontal scaling are both costly.