I spent two years trying to innovate on Magento, because it was the platform before I got there and rebasing seemed like overkill, and it almost broke me as an

I spent two years trying to innovate on Magento, because it was the platform before I got there and rebasing seemed like overkill, and it almost broke me as an engineer. My experience (and I'm not even going to complain about the XML!): The code base is horrifying; we would often trace bugs through the stack, realize they were in magento core files, then face really difficult decisions about furthering our fork. The code is deeply integrated from UI to DB. If you change it, upgrades won't apply cleanly. But you need to change it (or the data structures/applications therein) to implement any non-core features. Speaking of upgrades, they are mostly done by opaque and undocumented upgrade scripts, and tend to break plugins or addons... Which are generally poorly written and untested, even highly rated ones in their web store, but their quality isn't even the biggest problem. The absence of a sane extensibility model means they virtually can't coexist consistently, and when they do they break on (or need rigorous requesting due to) upgrades... The EAV table layout wouldn't be totally horrible if it weren't so badly implementated. They put everything, even system data, in EAV tables; not only did this make it hard to extend, but it put a huge load on the (outdated) ORM. Performance was an exercise in caching like no system I've seen before, entirely due to this design choice. The downside of that is that server restarts under load could cause a full system panic as new web hosts put an unbearable load on the DB, which could throw off other web hosts when their ORMs blew up by timing out all their pooled DB threads, which started a cascade through the rest of the system. It was possible to deploy a single cache shared by all your Magento servers, but even stock Magento would pepper that cache with dozens of serialized queries to serve a single page, making the network overhead barely worth it. Plus, this meant you couldn't clear the cache under load or you'd be down for an hour, and clearing the cache was a daily necessity because their tagging system to rebuild the cache incrementally was horribly broken. (Only barely worked using Redis, which was both recommended by Magento and provided by a 3rd party unmaintained driver and officially unsupported.) We ended up reimplementing all our e-commerce properties on a custom node platform by assembling high-quality atomic tools for the important bits. The technical debt of the transition was paid off in 3-6 months on our feature schedule and has paid dividends since, and we easily handle double the load on ~10% the infrastructure spend.