Magento 2 in 2017 - How's Things?

This is a quick, personal post inspired by Karen's recent post, "What Magento Should spend some of that 250M on". Karen's post inspired me to break my entirely-too-long hiatus from blog posting to provide my personal viewpoint on Magento 2 and Magento Inc as we go into 2017. I don't have the time I'd like to dive into every aspect of M2 and Magento Inc or to blog as much as I'd like, but I want to put a few points out there for discussion and debate in the community. 

First, a disclaimer. I am not an extension author. I've written Magento 1 extensions and I've written Magento 2 extensions. But my livelihood does not come from extensions. My company, Creatuity, is a Magento Enterprise Solution Partner. Our bread and butter comes from building and supporting sites, not from extensions. Twice, we have experimented with a foray into Magento extensions for fun and profit thinking it would be a good way to diversify and twice I've decided that I have no idea how companies survive on extensions alone. So, I don't have first-hand experience with some of the pain that Karen's article expresses, because while we're porting some of our internal-use extensions from M1 to M2, we're not an extension company supporting both M1 and M2. 

Next up, there's a few items I agree with Karen on whole-heartedly. Specifically, in 2017, Magento Inc has to make a substantial investment of time, money and energy into:

1) Bug fixes. Teams and processes dedicated just to solving bugs and releasing updates as quickly as possible. There were some very large shifts in Q4 of 2016 and those that have been tracking Magento 2's roadmap have noticed that the focus shifted rather intensely in 2.1 from planned features to bug fixes, and that's appreciated. The grumblings I'm hearing are that further changes to speed up bug fixes are in the works, but I know first-hand from running a large agency that modifying development workflows and processes for a large team of developers takes a lot longer than any of us would like. I think there's an underlying problem here, though, that no one's really talking about that I will touch on later.

2) Engaging the community more in direct, measurable ways. Make more of the roadmap truly public, and engage the community (be they individual community developers or official Magento partners) with the roadmap. Work with the community and appreciate the community. Like Karen, I absolutely love what Ben and Sherrie have done to appreciate the community. I don't know a single Magento community member who can truthfully say that they've interacted with Ben or Sherrie and left the interaction feeling anything less than appreciated. Ben and Sherrie, however, are two people among an organization of over 500 people. There's only so much they can do. 

The other 498 - I know many amazing people that work for Magento Inc from the very top of the organization down to the 'rank & file' that are amazed by the Magento community and that really get that Magento's success is, and always will be, on the strength of its community. However, there are still pockets within Magento Inc. that have never worked with a community like ours before. They don't "get it", not because they don't care about the community, but because their role at Magento Inc hasn't allowed them to see first-hand the impact the community has on Magento's success. They're not achieving the success or the productivity that they could be achieving because they don't realize how the community could help them, or that the community is here to help. 

Now, a few things I disagree with, or would at least like to provide a counterpoint to Karen's article on. 

"In the last 12-18 months I’ve seen several serious size agencies get ‘burned’ by Magento."

We've had some bumps in the road in our relationship with Magento - keeping two large, fast growing companies aligned isn't easy. However, we definitely haven't been burned. We made a point to get out ahead of Magento 2 very, very early, and that experience really allowed us to grow and deepen our relationship with Magento in 2016. Maybe some other agencies have been burned, but it's not something I've experienced or witnesses.

"I’ve also heard agencies tell me similar stories, at best many have just flatlined in 2016 after years of high growth."

Creatuity has a track-record of high growth, but 2016 was phenomenal. Record-breakingly so. We completed twice as much work in 2016 over 2015. The majority of the work we did in 2016 was on Magento 2. Just like I think it's a stretch to say that an agency experienced a decline in 2016 due to Magento 2, I don't want to attribute all of our growth in 2016 to Magento 2. We worked very, very hard. We depended our partnership with Magento Inc and closed what I suspect may be more Magento 2 deals in 2016 than all but the largest partners. So, Magento 2 isn't a magic bullet that led us to substantial growth - but being on the forefront and fully trained up on Magento 2 before 2016 began definitely helped us substantially.

" Some say project times are shorter, I’ve never seen a project of any complexity that has come in faster than M1."

I'm one of those people that's been saying that; I noted it on many of my Magento 2 presentations in 2016. At Creatuity, we've used the same time tracking system since 2009. As any of our team members I'm sure would be quick to tell you - I'm almost Orwellian when it comes to time tracking. Billable time, internal time, it all gets logged down to the minute and to the project or training area. So I can say with confidence, we have had complex tasks take substantially less time in Magento 2 than Magento 1. This is after our team was trained on Magento 2, and after we built up a robust toolset around it. However, looking at our training and toolmaking time; in 2015 we spent about 5% of our time on that. In 2016, that increased to only 7%. I stand behind my previous statements that once a team is up to speed on Magento 2 and has the right tools and knows how to use them, projects are more efficient under Magneto 2 than Magento 1. Now - if you run up against a bug, yes, that will delay things (and I'll discuss that further, below).  

"And for those of you developers ‘evangalising’ about how great it is – maybe it is great when its your hobby and you aren’t seriously working on it or your merchant is willing to spend a ton of money effectively training you."

For better or worse, Magento has never been a hobby for me. And merchants most certainly won't spend a ton of money effectively training me, or our team. We've fought for every bit of Magento 2 knowledge and every line of code in our Magento 2 toolchain. And we've struck a balance between investing in internal training time and working with merchants that are excited about Magento 2 to ensure those investments pay off. 

Was it easy picking up Magento 2? No. Neither was picked up Magento 1, though. However, I hit a tipping point midway through 2016, where going back and working on Magento 1 projects 'hurt' a little. I realized that I had been immersed in Magento 2 long enough that the tools and the processes made much more sense to me, and I can truly say that developing for Magento 2 is great. I love it, and I will celebrate the day our final Magento 1 client has migrated to Magento 2 so that we no longer have to work with Magento 1. Also, as embarrassing as this is to admit - I was really, really bad at writing modules in Magento 1. For some reason, the approach didn't make sense to me and I always managed to muck something up. In Magento 2, I'm cranking out modules left and right - faster, fewer errors and overall more cohesive. 

This post is already substantially longer than I intended. So, I'm going to stop here and just focus on two areas that I think aren't being discussed enough:

First - yes, there are agencies (and in turn, merchants) having bad experiences with Magento 2. Sadly, halfway through 2016 we already had to take on our first 'rescue' project from another agency that failed in a Magento 2 implementation. From the failed implementations I've been brought in on thus far, those failures seem to stem from a few things - they tend to be agencies with no Magento 2 experience or training that decided to try to learn Magento 2 'live' on a client project. They tend to be agencies that underbid projects in order to win them. They tend to be agencies that don't have a formal relationship with Magento, or have a distant relationship at best. And you know what? I saw the exact same thing with Magento 1 projects in 2009/2010. The hardest case to watch was one Magento 2 project where the agency and the client did everything right, and then bumped up against a bug in Magento 2. In that case, luckily, the bug was well documented in a GitHub issue and resolved. So, while it delayed the launch of the project, it didn't cause the agency or the merchant to incur any additional costs. 

Second - bugs. I cringe when I see people quoting stats on the number of open issues on GitHub. As a community, we implored Magento to open things up and bring their code and their issue tracking onto GitHub. And when they did that, some people then started using it against Magento. There are competitors using the number of open issues on GitHub as a sales tactic against Magento. That really frustrates me, and I think one of the biggest problems right now are GitHub issues in general.

Don't get me wrong - I never want to see Magento step back from GitHub and GitHub Issues. I think doing so would be a very, very poor decision that would lead to a contraction in the Magento developer community, and in turn, a contraction in Magento's marketshare. 

However, there have been over 8,000 issues opened on the Magento 2 repository. 1,548 opened, 5,286 closed and apparently over a thousand merged or deleted. In the past month, over the holiday season, the Magento 2 repo averaged over 11 newly created issues per day.

Have you scanned through those issues? I just browsed through the first couple of pages, and I found:

1) Issues related to Magento 1, not Magento 2. (i.e., #8030)

2) A substantial number of issues opened with little to no details and then no reply from the original author when the Magento team asks for details. (i.e., the entire Needs Update tag, which covers about 10% of all open issues right now, or #8006)

3) Major new feature requests that are only tangentially related to the Magento 2 software itself. (i.e., #8040

4) Issues with literally no content at all (i.e., #8031

5) Issues caused by poorly written (and in many cases encrypted) third party extensions (i.e., #7950).

Don't get me wrong - Magento 2 isn't perfect. No piece of software is. But the Magento 2 GitHub repository has a major signal-to-noise ratio problem. At 11 issues created per day, if it takes an average of 45 minutes per issue to classify the issue, confirm if it's a problem or not and then close/resolve/update/process the issue, then managing the intake of new issues in the Magento 2 GitHub repository would be a full time job for a single developer. 

What's the solution to this? I'm not 100% certain. I checked three large open source projects that came to mind on GitHub (the Linux kernel, Laravel and WordPress) to see how they manage this issue - they don't. They've completely disabled the ability to open new issues. They don't use GitHub for tracking issues at all. 

I know that Magento has experimented with community volunteers to triage GitHub, but the challenge then becomes ensuring they aren't encouraged to close issues too aggressively. These GitHub issues need the appropriate attention, because there are long-running issues that are lost in the noise. 

So - we all agree (and while I don't speak from them, their actions say to me that Magento Inc agrees as well) that Magento needs to make a substantial investment in fixing bugs and closing GitHub issues in 2017. However, how do we propose they do that? How do you manage the level of noise on GitHub and zero in to the issues that absolutely need to be fixed versus those that are user error or are obscure edge cases only impacting a few users? 

I mean those questions very literally - community, how do we propose they fix this? Do you know of GitHub repositories with thousands of issues, opening at the rate of 11+ per day, being triaged and managed well? If so, speak up, and let's continue to build on the success of Magento 2 in 2017. 

This post is already entirely too long - if you read all the way to this point, you have my thanks - come up to me at Magento Imagine in April and say "I am Magento" and I'll buy you a drink to make up for the time you've invested in reading this. 

Let's keep building great things, let's stay passionate and let's keep pushing Magento (the platform, the community and the private company) forward in 2017!