The bulk of our team here at Nanobox has been working together for nearly a decade. In what now seems like a former life, we were knee-deep in Magento implementations and advocating Magento as the open-source solution for ecommerce. We were early adopters of Magento and bought in to the promise of it being a feature-rich, easy to use, easy to manage ecommerce platform, which it was... at first. But as it evolved, things went south, ultimately forcing us to abandon Magento in 2013-ish.
I was curious just how things have changed in the years since we stopped using Magento. After digging in a little bit, overall, I think Magento is in a better place and is moving in the right direction.
A Little History
Back in late 2008, Zumiez, America's top action-sports retailer, contracted us to bring their underperforming website out of its pre-2000 mire onto a modern, flexible, scalable platform. We convinced them Magento was a good fit. Yes, I know — many of you probably laugh when thinking of Magento being "modern, flexible, and scalable", but we were confident it could be done, and we did it. In June of 2009, the new zumiez.com, built with Magento, was released. At the time, it was the largest Magento implementation in the world, spanning across a cluster of 20+ bare metal machines.
We continued to forge on in the Magento implementation world and even started TinyBrick (best seen in the Wayback Machine), a Magento module side-business, which we sold in 2013. But as the years went on, both changes behind the scenes of Magento and in the project itself left a sour taste in our mouth.
The eBay Buyout
Magento was originally developed by Varien Inc., led by Roy Rubin and Yoav Kutner. In March 2010, eBay invested in the project allowing it to become a standalone company and later, in June 2011, acquired Magento with plans to integrate it into its X.commerce ecosystem.
Anybody who was deeply involved with Magento at the time can tell you, things went stale fast. Feedback from developers was largely ignored; major problems weren't being fixed; the "openness" of the open-source platform was only skin-deep, which was acknowledge by Yoav when he left eBay in 2012:
eBay and the folks at X.commerce don’t really understand the meaning of open...
The X.commerce initiative has since been dissolved and Magento has changed hands a few more times, which we'll talk more about later.
Our Reasons for Abandoning Magento
While the managerial and cultural changes in the Magento community contributed somewhat to us looking elsewhere, they weren't the primary cause. As a development shop doing client implementations, we struggled with both development and business aspects of Magento.
Catering to Developers and Non-Developers
From the outset, Magento was meant to be easy for both developers and non-developers (business owners), but striking this balance is tough. In order to make Magento easy to install and use for non-devs, sacrifices had to be made on the architectural side (web-based install/update vs command line install/update, layout overrides in the admin panel, admin panel configs that should've been in the source code, etc.). But to keep the project flexible and dev-friendly, sacrifices had to be made on the user-facing side as well (code-based CMS zones, semi-manual module installs, etc.). Unfortunately Magento landed somewhere in the middle and didn't really make things easy for anyone.
After the eBay buyout, there seemed to be a shift as all new releases catered more to non-devs, leaving us and other developers frustrated.
A common complaint about Magento was how resource-intensive it was. For us, this meant that Magento often priced itself out of smaller implementations because the client(s) couldn't afford the overhead of running it.
Enterprise Licensing & Community Edition Neglect
In April 2009, Magento introduced the Enterprise Edition (EE) offering more functionality, better performance, and technical support... for a price. In 2012, the annual license for Magento EE was $10,000USD+ per server. Yes, that's right, per server. So unless you planned on running your shop on a single, monolithic server, the cost of the EE license went up really fast. This pricing structure encouraged antiquated, single-server infrastructures at a time when multi-node, micro-service architectures were really gaining traction.
To justify the cost of the EE license, Magento had to increase the "gap" between its enterprise license and the Community Edition (CE). While from a business perspective, I completely understand why they did this, from a development perspective, it was a headache. The gap between the two editions included functionality we felt should've come standard — things like full-page caching, advanced tax rules, simpler customer management, etc. — ultimately making Magento CE and its users feel neglected.
Albeit this did open up a market for module developers to come in and bridge the gap between CE and EE; a market in which TinyBrick thrived.
Lack of Dependency Management
This was really more of an issue with PHP than it was with Magento, but the lack of dependency management was frustrating. Manually downloading and including libraries/packages; keeping them up to date; manually resolving conflicts... Yeah, no fun.
Lack of Multiple Environment Support
A staple of the modern development workflow is running an application in different environments such as staging and/or production. With Magento, everything was considered production. To setup the dev-staging-production workflow, we had to devise ways to update or replace the
local.xml as it was deployed. While this was fairly simple to do, it's something we felt was a common enough practice that it should've been accounted for.
It's been a few years since we last touched Magento and a lot has happened. In 2014, X.commerce fell victim to the breakup of eBay following Carl Icahn's raid and Magento was spun out as an independent company. In November 2015, Magento was purchased by Permira, a UK-based private equity firm. This new ownership brought with it new freedom and new focus.
Magento 2 (M2) was announced by Yoav Kutner in 2010 around the time eBay initially invested in Magento, but M2 development stagnated under the X.commerce umbrella. Since the 2015 acquisition, Magento has renewed its efforts to improve Magento and M2 has become the flag bearer of those efforts.
Because we've been out of the Magento business for so long, we decided to talk with someone who has stuck through it all. Allan MacGregor, Director of Engineering at Demac Media and author of multiple Magento books, was kind enough to take a few minutes to bring us up to speed on the current state of Magento.Allan MacGregor
Developer-Minded and Truly Open
After expressing the pain-points we had with Magento, the first thing Allan told us is that Magento is now much more developer-minded than it was. The tricky dev/non-dev balance has shifted back in favor of developers, but that's not to say business owners are losing out. They've made things nicer for developers, but have also added a lot of great functionality for end-users.
To help guide new development, Magento has held special conferences/meetings with prominent Magento developers to have face-to-face conversations about the future of the project and get direct, honest feedback. The overhaul of Magento Connect, now "Magento Marketplace," was a direct result of one of these conversations (more on that later).
Under eBay, Magento source code was published on Github and all are welcome to contribute. The community is very active, submitting multiple pull requests and issues daily.
Composer has thankfully provided a robust solution for dependency management in PHP and M2 has whole-heartedly embraced it. You can install the M2 core as a composer dependency and extend it with additional packages and modules.
M2 includes "modes" – The ability to switch between development and production. No more
To improve security and ease-of-use, we added a command that switches Magento modes from developer to production and vice versa.
Production mode also has better performance because static view files are populated in the
pub/staticdirectory and because of code compilation. 
While switching between "modes" with a CLI command departs from the somewhat standard practice of defining the environment through environment variables, it is a step in the right direction.
M2 API Coverage & Headless Magento
A major focus of the M2 build as been expanding the coverage of the M2 API, which has opened up some really interesting possibilities.
At last year's Imagine Conference, a popular subject was running Magento "headless". This essentially means that the front-end of your Magento shop can be built in whatever framework you like. Magento simply acts as an API from which information can be pulled and posted. The growing coverage of the M2 API is making this easier and easier.
Allan brought up the fact that a major complaint with Magento in the past has been the mostly unregulated extension market. Shop owners would purchase Magento modules on Magento Connect only to find out the underlying code was complete crap. Some modules would even require modifications to the Magento core in order to install, essentially locking you in at the current version. If you wanted a refund for a paid extension, it was a fight. Magento Connect was a total mess.
Magento Connect has since been replaced by Magento Marketplace and new coding standards and best practices have been introduced for extension developers. Magento realized the practices of extension developers, good or bad, reflected on Magento as a whole and have taken more ownership in the process.
Restructured Enterprise License
Rather than a per-server cost, M2's EE pricing structure is tier-based, determined by your site's revenue. The cost is still significant, but it is much more affordable for sites running on a multi-node cluster than the M1 EE license was.
Also, the functionality gap between M2 EE and CE is much smaller. The technical support and additional functionality that come with the Enterprise license are enough to justify the cost, but CE no longer feels like it's losing out. The features in EE are really geared larger businesses with high SKU volumes; businesses that can afford the license.
Something Allan mentioned in our conversation and something we noticed as we began to dig into M2 was the documentation – it's a lot better than it used to be. I personally think they could tweak the structure a little bit and make the installation and configuration docs more linear and a little easier to follow, but as a whole, the docs are much deeper than they were with M1. I believe this is in large part due to fact that they're now open-source and the community is actively contributing.
M2 Migration Tools
While I don't have the exact numbers to support this, it seems to me that M2 adoption has been a little slow (feel free to correct me if I'm wrong), and understandably so. Migrating a functional, money-making storefront to essentially a new platform can be risky. To help aid in the process, Magento has provided both data migration tools and code migration tools.
The data migration tools include scripts that allow you to work on both sites simultaneously and migrate delta updates from one database to the other. As data gets updated on the live M1 database, getting the updates into the M2 database is really easy. This greatly reduces the chance for data loss once the switch is finally flipped and traffic gets routed to the M2 site.
When Allan mentioned the code migration tools, he also noted that he hasn't used them yet, because the process of "automagically" porting code from M1 to M2 is "scary." We tend to agree, but Magento is working hard to iron out the process.
Room for Improvement
Both we and Allan agree that Magento is moving in the right direction, but there is still room for improvement. Fortunately, the core team is very transparent and straight forward about the challenges and problems they're facing.
Being owned by a private equity / venture capital (VC) firm, there are politics at play that may be stifling some of the community interaction and community-driven direction. Compared to the past however, the Magento team has a clear vision of where they want to go. If they can just establish a unified vision of how they're going to get there – a vision that involves the community – they'll be in great shape.
When deploying M2, it runs through a compilation process that automatically generates code classes, minifies static assets, etc., all to improve performance in a production environment. This process can take upwards of 20 minutes for a simple code change. They are working to optimize it.
Also, the deployment and compilation docs are a little light. Something else we've been assured they're working on.
Getting Magento up and running in a local development environment can be a challenge. They've attempted to make it easier with Magento DevBox (currently in beta), which uses Docker and some installation scripts to get Magento installed and ready. But Allan told us it's not quite there yet (sounds like something Nanobox may be able to help with... wink wink).
12 Factor Compliance
In 2012, Adam Wiggins, Co-Founder of Heroku, introduced the Twelve-Factor App – a standard for designing and building web apps running on cloud infrastructures. While M2 meets most of the 12-factors, in my experience, it still needs to improve on points IX, X, and XII – Disposability, Dev/Production Parity, and Admin Processes – to be easily deployed to cloud infrastructures without the EE license.
So there you have it. Magento has seen its share of ups and downs over the years, but as of now, things are looking better. The core team is listening to the community and changes have been made and are being made to give developers more control.
I want to give a special thanks to Allan MacGregor for sitting down with us and getting us up to speed. Allan, you're awesome.
Those of you who are using Magento or who have moved away, what are your thoughts?
This topic has generated a lot of conversation about the current state of Magento. To facilitate the conversation, we've set up a webinar with Allan MacGregor and members of the Magento Team. You're welcome to join us on Wednesday, May 17, 10:00 AM – 11:00 AM MDT.
Subscribe to Nanobox
Get the latest posts delivered right to your inbox