While my travels give me broad exposure to much of the novel & interesting projects out there, I’m aware that many more things are being created than I am aware of. I’m therefore making a request of you all: show me your creations. Tell me about your future-forward projects which blend Magento and other tech, apply Magento in novel ways, or… whatever feels novel & inspiring. Bonus points for open source projects, though it’s not a requirement.

On one of my first trips of 2016 I spoke at the London Magento Meetup. While I was there I was invited to see a demo of Bluefoot CMS. Despite having a 39.5º fever, I knew I was looking at one of the best CMS extensions for Magento that I’ve ever seen: new content concepts, page building capability, excellent UX… there’s a lot on offer with it.

Recognizing the increasing importance of content in commerce, I’m thrilled to announce that – at the recommendation of our Head of Product Paul Boisvert and with the direction of my Strategy & Growth colleague Peter Sheldon – Magento has acquired the technology behind Bluefoot CMS and will be integrating it into our platform in 2017.

We know that our users will have several questions such as which features will be implemented for Enterprise Edition and Community Edition. A preliminary guide with some answers can be found at the announcement post on our official blog. You can post comments and questions to me here, which I will answer as best I can. Also, we are mapping out a number of improvements for content management in 2017. I am representing the ecosystem’s interests during this process, and will share this part of the roadmap as soon as we have more details.

I’m excited for Magento in 2017. As always we have a lot going on and are looking forward to moving the world of commerce ever forward with the help and support of our community.

I’m Ben Marks, Magento’s chief Evangelist, and I have some very good news about education for developers who are interested in Magento 2: the tl;dr is that we are offering several Magento U courses for free during December and January. Read on for background & details, or sign up here!

In 2008 I started my Magento development career as employee #1 at Blue Acorn (thanks Kevin!). Back then there were no formal training tools from Magento, and there was scant information available online outside of IRC and the blogs from Inchoo and Alan Storm. In fact, in those early days Google would even autocorrect “magento” to “magneto”!

This all changed forever In 2011 when Varien (the company that would become Magento Inc.) charted the Magento U department and created the first official Magento curriculum, Fundamentals of Magento Development. I was given an offer to teach the initial course alongside my friend and mentor Vinai Kopp. After more than 1500 hours of in-person training as well as hundreds of events attended I’ve personally seen our training have a life-changing impact for hundreds of developers. I’m anecdotally aware of similar effects for the thousands of developers around the world who watched the on-demand version of this training. These experiences have given me a deep appreciation for the power and effectiveness of our developer education. Put succinctly, our enablement of developers is us doing our absolute best for our ecosystem.

Because of my experiences I believe in and advocate for broad & affordable education as a way to empower more developers to do well in the world of Magento. Whereas the success of Magento is closely tied to the abilities of our developers, we are shaking things up in Magento U. For the second time in its history, Magento U is offering online training for free – you need only register to take advantage of it. Right now, you can get the following four courses for free during December and January:

I encourage every developer to avail him or herself of this opportunity.

For those of you who take advantage of our free training, I’m asking you to let me know what you think of the curricula, the materials, as well as any success or issues you have following along. Your feedback will help us to refactor existing courses, to build new courses, and to improve our overall product.

In 2017 you can look forward to more education innovation in the form of new courses, new delivery mechanisms, as well as Magento 2-focused certifications. As always, your ideas & feedback are a crucial part of our success, so please feel free to share with us early & often.

“There are a handful of people in the world who truly understand UI Components well, and putting them in a room together for a full week made for a fascinating event.”

Magento 2, like all feature-rich platforms, has some complexities. UI Components, introduced in 2.0, is a feature with perhaps one of the biggest needs for solid documentation.

The power of being able to quickly add a button set, drop-down list, or a new form onto a page, and then to be able to customize that element as deeply as needed, is easily understood.

But the nuances of the code structure, the configuration workflow, and the many parts and pieces of a UI Component instance require a closer look to really understand. Data sources, .php modifiers, generated JSON content, a lot of xml, nested nodes that allow for an extreme level of customization, Javascript, .xhtml templates… there is a lot going on. And when things don’t work, what about debugging??

The community asked for better documentation around UI Components, and we heard you. We would like to thank some very specific wording in one particularly painful GitHub Issue; a few key phrases resulted in the first ever Magento Doc Sprint. Thank You and Дякую!

Hello Kyiv

About two thirds of our development and testing teams are in the beautiful city of Kyiv (along with many other essential staff). The office there is spread out on two floors of a big, modern building (with an amazing coffee shop on the ground floor). I’ve been to Kyiv four times over the past 9 years for software dev work, and I can say that the energy level and creativity buzz in the Magento offices is incredible and unmatched. I could barely wait to get started!

The engineers who developed UI Components, with guidance from our resident yogi Vitaliy Korotun, are there. The Frontend team is one of the many dedicated scrum teams in the Kyiv offices, and they were the ones I needed to talk to.

DevDocs realized that we need get the deep technical knowledge that is in their heads out and into the documentation, and a Doc Sprint is a terrifically effective method for doing this.

But Magento had never done one before, most developers in the world haven’t (*yet*!), so there had to be some warm-up conversations, some explanations, and well… convincing.

Brief History of Doc Sprints

Doc Sprints have been around for a while; small, company-specific ones started in the late 2000s. In 2011 gnome hosted a popular event in exotic Brno, Czech Republic, and Mozilla sponsored a Javascript-centric Doc Sprint in Berlin. Australia-based Atlassian made an art form of them in the early 2010s, with across-the-globe, simultaneous, live-feed Doc Sprints fueled by chocolate.

The word “sprint” was, from the beginning, applied in the exact spirit of the word: it’s a race, it’s intensive, and it’s short. When Doc Sprints started, though, Agile and our current understanding of sprints was just being formalized. Now in 2016, typical scrum sprints involve code, testing, and documenting… and the two-week sprints used at Magento are the work-horse method for consistently adding new functionality to the product… but it takes many many two-week sprints to get a good amount of docs created.

A Doc sprint, focused 100% on documentation, is much faster… and since the docs are written by the developer who actually created the functionality, the technical depth and insight goes directly out of the developer’s brain and straight into the documentation.

And they’re fun… similar to Hackathons, a Doc Sprint (also called a Doc-a-thon) eschews any overly formal processes, and emphasizes the act of identifying required documentation and then very quickly producing it. Doc Sprints can be an intense, laughter-filled, brain-draining, and multi-cultural collaborative act of creation, resulting in a quality of docs that most easily come straight from the core developers who created the code.

How it works

Before we get into the logistics, let’s cover some important new glossary terms:

Extreme Editing: [verb, from the practice of extreme programming] the process of 3-6 people "demo'ing" on the big screen the previous session's documentation topics, and everyone together editing and tweaking the words and code samples. This was my favorite part of the Doc Sprint; the bursts of impassioned, intense conversations in Russian and Ukrainian... and then the final, "OK, this is how it works..." in English, for my benefit. ;-)

Developer-Who-Writes: [noun] The instantiation of a coder who really knows his or her stuff, and wants to take pride and ownership in sharing their deep knowledge. Not that rare of a creature, after all.

Our Doc Sprint Days

A team of developers, an architect, a product owner, and two tech writers walked into a room… and hashed out a rough outline for a new UI Components Guide. Our work started with carefully analyzing the many, many community questions and complaints; what were our users asking for? Sasha, the technical writer for Frontend work, created a wiki page with a rather large table of community issues, with a column for distilling the exact pain points of each GitHub Issue, StackExchange post, Tweet, and email. What are the most contentious areas? What was most painful? We then discussed the traditional aspects of good documentation: Use cases, Examples, How Tos, Conceptual topics, navigation, etc.

By Monday afternoon, August 15th, we had a solid outline for the new guide. We invited additional team members to join for a final review of the proposed outline. Then on Monday evening we asked Vinai Kopp and Ryan Fowler to take a look and send comments, especially about the prioritization of the topics. (Thank you two!). Both internally and externally there was agreement that conceptural topics were badly needed: what are these things, why should I bother to learn them, advantages, caveats for when maybe you actually don’t want to use them, etc.

Ambitious outline… and these are just the conceptual topics!

Every day for the rest of the week had this basic structure:

1) morning demos of new articles, 2) extreme editing of the articles by whole team, 3) push to internal GitHub, 4) refine outline if needed, 5) pick next article to write, 6) go to a quiet area and write or stay in big room with pastries and write, 7) afternoon demo, 8) more extreme editing until we are all about to cry from brain and language exhaustion, 9) push to GitHub. Repeat for four days.

What a fun (and terrifying) challenge to convince a team of developers to take on a Doc Sprint (and write in a foreign language!), plus explain the spirit and concept and urgency, while keeping it fun with pastries, fruits, coffee and collaborative brainstorming. But it went really well.

It’s a true privilege to ask the basic prodding questions of say, How does one do troubleshooting or diagnostics around UI Components… and watch the developers think… and then they start brainstorming with themselves, out loud, then other developers jump in and start adding information or correcting or questioning or challenging, and next thing you know I can’t type fast enough.

Photos of Participants and our Workspaces

So many people helped in so many different ways. There has been tremendous support, all the way from early acceptance of the proposal, then throughout the actual week-long Sprint, and even now as the project continues at a reduced scale. In particular, the developers who sat in the room day after day, and took very seriously the challenge to explain UI Components, are forever my heroes.

I think that my biggest take-away from this Doc sprint (in addition to a start on some solid documentation) is that cross-team collaboration on almost anything is incredibly valuable. A product is simply better when it’s designed and built and tested and doc’ed by people who can learn other perspectives and create solutions together.

There were many “bonus” side-effects of this Doc Sprint, beyond getting the documents written:

Stronger consensus within core team about the feature and its implementation (Best Practices, etc.)

Enhanced sense of ownership, pride, and customer-focus in all participants

The participating technical writers now feel much better trained about UI Components

Product owners had a chance to assess community feedback in detail and consider some “opportunities”

And, I was really happy to learn that our core developers are excited to share with the community and to help with the understanding and adoption of Magento 2. This week-long event is hopefully yet another channel by which our core team can develop not only a better understanding of what our users want and need, but also a sense of ownership and joy in their code. Oh, and… a much deeper appreciation of the difficulty of using words to describe code implementation. 😉

Results, and What’s Next?

And the verdict is…. great, but we want more. We ended up with 6 topics, for five days work, about 5 hours each day, from 2.5 people (don’t ask). We focused on the Conceptual topics first, but next up are How Tos and also Debugging topics.

1. Publish what we have, and ask for feedback:

But for the next day or so, we are doing some final edits on the work from Kyiv. However, we want to hurry and get them out there, as raw as they are, so that our community can benefit from any new information AND can provide feedback and even contributions. We are including templates in the GitHub repo; please, if you know a lot about a particular topic, grab a template and send us a PR with your content. Remember, DevDocs will add your name beneath each topic you contribute and we publish!

We will also publish the full outline as a simple .md file; we welcome feedback on the proposed topics and the organization.

Visit devdocs.magento.com to view the new UI Components Guide in its infancy, and all of the other DevDocs documentation.

NOTE: The original UI Components docs will reman for a while, but it will eventually be subsumed by the new Guide; saving, of course, all valuable content first.

2. Write More:

So we still have a lot to do. The project continues on a reduced schedule of 1-2 hours each day, with demos and extreme editing for each new topics on the Very Long outline. We have the interest and the commitment from the small team of core developers to “keep going forward”: Тiльки вперед!

3. Publish Again, and ask for more feedback

We plan to iteratively publish each week’s work in GitHub, and continue to add value and knowledge to our documentation about UI Components.

In Summary:

Let us know your thoughts: you know where we are on GitHub and on Twitter at @MagentoDevDocs, and please use Comments below as well.

And most importantly, Thank you and Дякую to our Magento core developers, the writers who participated, and to our community developers. Please keep the feedback coming: the good, the bad, and the ugly. An especially big thanks to Vinai and Ryan, who planted the seed for the first Magento Doc Sprint, and for their valuable review of our proposal early in the Doc Sprint.

In light of recent passionate discussions, and in anticipation of MageStackDay #5, I have been thinking a lot about Magento StackExchange (MSE) culture. I’d like to present my thoughts as a sort of historical waypoint as well as an introduction to (or clarification of) the culture & activities which underpin this wonderful resource.

tl;dr: For me the most important bits are at the end (“What should I do?”)

How is something like StackExchange created and sustained?

The answer begins with open source and its ethos of open sharing of experience, knowledge, and effort. (My counterpart at Akamai, Davey Shafik, has a great presentation involving this topic, particularly on what I call the compound interest of open source’s collective effort: https://youtu.be/VS0kG3O9Ro0?t=269. The entire presentation is worth watching, but at the very least, watch the five minutes following the linked starting point.) Specifically for StackExchange, it all began with people in open source (and in general) doing what they do when they need help: asking questions. In the early days of the Internet, netizens asked questions in bulletin-board-style forums. Once the WWW came along, forum software was developed, and people asked questions in forums. Eventually, a couple of fairly sharp developers realized that general forum technology fit the domain of Q&A very well, and they created StackExchange, with the goal of providing a tool and a ruleset for content creation centered on authoritative questions and answers. (The genius of the StackExchange approach is that it allows for two dimensions of answering, by allowing for an answer to be marked as a solution by the inquirer, and also by allowing the community of users to vote on other answers which may indicate a better or more applicable solution.) From this grew the StackExchange network, the crown jewel of which is StackOverflow (SO).

How did Magento SE come to be?

The first Magento-related question on SO appeared September 2008, and from then on the body of questions and answers grew organically, reaching over 37,000 questions to date. Adoption of SO as the Q&A forum for Magento increased as more users abandoned v1 of the Magento forums, which had become overrun with spam. True to form, as more users moved to SO, more and better content appeared, creating a positive feedback loop via search engines. I myself jumped from being a moderator on our forums to being a contributing member of the SO community in July 2011, and over the next 1.5 years I spent a lot of time answering questions there. During this time, I began to notice an increase in “user” questions, that is, questions about how to use the Magento application. These questions were closed right away, which is appropriate given SO’s scope. However, I felt that these were valuable questions to ask & answer, and I further believed that there was value in having them exist alongside technical questions. A new forum home was indicated.

Therefore, in December of 2013 I proposed a Magento-dedicated SE site which would allow focused Magento technical and user questions. Initially I was warned by SE staff that they might close the proposal, ironically for the most of the reasons that I was proposing it. From the initial proposal (2012/12/27 01:22:44Z), the site went through the necessary steps to achieve public beta in just over one month, launching in late January 2013, and immediately becoming one of the highest-traffic sites in the SE network. SE decided to let it play out.

How did Magento SE evolve over time?

Over the next 1.5 years the content on Magento SE grew and grew. Many dedicated users engaged with the constant deluge of questions from users new and old, simultaneously providing and curating content, following a typical but quick trajectory for SE sites. Despite our efforts however, the site remained in public beta. We began to look at the core metrics for beta sites: questions per day, percent answered, number of users, question/answer ratio, and daily traffic. We were constantly deficient in two of these: percent answered and question/answer ratio. A concerted effort was needed to improve the site’s stats, and by extension improve the content itself. This is what inspired Anna Völkl and Sander Mangel to create #MageStackDay, an event dedicated to “cleaning up” content with the hope of graduating MSE from its beta state. The first MageStackDay was quite successful, so a followup event was planned & executed a few months later. These efforts helped the MSE site to graduate to a full-fledged SE network site, opening it up for elected moderators, custom design, and other features.

Why do we still need MageStackDay?

The purpose of MageStackDay remains as it always has: to benefit MSE and the broader Magento community through focused collaboration. That said, the collective effort is only beneficial when the actions are obey and honor the chief tenet of Stack Exchange when it comes to content, which is to help it be better rather than to obliterate it altogether. While MageStackDay uses SE metrics to both inform and track progress, it’s essential to realize that these metrics are an indication of site quality only. It is easy to obsess over metrics rather than over material.

What should I do?

So, when engaging in today’s MageStackDay activities, or when participating on MSE in general, consider the following guidelines by to which I hold myself:

Prefer existing content over creating new content. Suggest edits, propose duplicates, and avoid adding answers which offer no new information.

Upvote good content liberally, but do so with integrity.

Down vote conservatively & comment when you do. Downvotes should be reserved for egregiously wrong answers.

Comment with kindness and consideration of quality. Comments are the spice of life.

Be helpful & courteous to new users. MSE culture is high-context & different from most forums; people need an introduction!

When it comes to content and conduct on MSE, think of the main tenet of the Hippocratic Oath: primum non nocere, or, do no harm. Perhaps we shall call it the Stackocritic Oath.

A curious thing happened during this morning’s dose of coffee & social media (the latter being an important component of my job at Magento, I promise). I read a brief piece on stoicism and then almost immediately was linked to an exchange from Eric S. Raymond to Linus Torvalds in which Mr. Raymond states the following:

…[T]he bill always comes due — the scale of the problems always increases to a point where your native talent alone doesn’t cut it any more.

The combination of these two posts has kind of rocked me to the core, and I want to discuss this openly.

Over the past few months thousands of people have seen me onstage stating, “If you are a skilled Magento 1 developer, much of your knowledge will port forward to Magento 2,” by which I mean that many of the distinct PHP framework and commerce application aspects of M1 are present in M2. Some aspects of M2 are essentially indistinguishable from their M1 implementation (e.g. the ORM), and some differ only in implementation pattern (e.g. route configuration and controller actions). While the existence of numerous code migration tools bears this out, what I was really trying to say was, “Change and modernization are part & parcel of M2, but never fear – you know what you need to know in order to make the transition!”

And yet, despite these calm assurances and my confidence in the Magento 2 code which we’ve crafted, I find myself seized by the same symptoms of unfamiliarity as I did when I expanded the Magento 1 download for the first time 7.5 years ago. The dread of self-doubt, the fear of failure, and the appearance of other’s inherent ability to master the material are once more swirling around me each time I open my editor. In other words, in Magento 1 I feel confident and capable, but in Magento 2 I am a babe in the woods. I have to wonder, is this impostor syndrome, or am I truly playing the part of expert when I have no right to? Am I struggling with something new, or am I an impostor?

I’m no stranger to Impostor Syndrome (IS); I’ve been experiencing it since I started teaching the Magento 1 Fundamentals of Development class 5 years ago. IS is a cognitive process in which one fears appearing to be a fraud by doubting or dismissing one’s abilities and accomplishments. This kind of irrational disconnect is typical of anxiety conditions and fits well with my history of anxiety disorder. The fear I experienced while teaching diminished over time once I accepted how much I knew and didn’t know, and it all but disappeared once I realized that it is okay to not know everything. In fact, for teachers, it’s essential to openly state as much! During this period I began speaking about Magento at PHP conferences, and while IS reared its head again, it wasn’t quite as strong as before, perhaps because my past experience inoculated me against it to a degree. However, in these nascent days of Magento 2, I am experiencing unrelenting symptoms of IS all over again. I want to share this experience honestly & openly with the community, because I think I see others struggling with IS as well – whether they know it or not.

For me, my fear stems from being pulled forward into modern PHP development. Consider all of the “new-to-me” technologies, workflows and tooling which are part of Magento 2 (or which at least complement its use):

This is not to say that these things are new (far from it). Rather, they are new to me and – I suspect – to many developers who have kept their focus inside the aging box of whichever framework idiom pays the bills.

Unpacking this reality is important, as it creates a logical path for resolving my fear. To that end, I’ll be posting at least bi-weekly about the technologies and workflows in Magento 2 which are new to me. This is mainly an effort to help myself and hopefully many others quickly become uninhibited and effective developers in Magento 2.

You all can help me by recommending topics which you’ve struggled with, or would like to see answered canonically. Comment here, @benmarks me on Twitter, or send an email to ben@magento.com.

I have one of the best jobs on the planet. I get to go all over the place talking about Magento and listening to others talk about Magento, commerce, programming, and life in general. With only a couple of weeks at my actual home in Charleston, SC from mid-August through mid-December, the end of 2015 is proving to be my busiest speaking season yet (20+ presentations across 4 continents) and I couldn’t be more excited to get out there & talk about Magento 2!

Starting in August I spoke at Meet Magento Vietnam in Hanoi. It was one of the most impressive first-time events I’ve ever attended. The venue, the crowd (five hundred strong), and the speakers (including a government minister) all contributed to a fabulous freshman effort. After a brief stay at home I spoke at New Zealand PHP Conference’s sophomore show. While more lightly attended than last year, the content was good, and it’s great to make it to the end of the Internet. I took advantage of my trip to speak at both the PHP Wellington User Group and the Auckland Magento User Group (thanks to Lero9 for hosting and Fooman for organizing).

After one day at home I headed back out for another freshman effort: Northwest PHP Conference. It was obvious that a conference veteran (Jeremy Lindblom) had organized the event, because it was professional through and through. From there I went to Hong Kong to attend one of the Rackspace::SOLVE series of events. Man, they know how to put a conference on! This was one of the most interesting speaker events I’ve done: an open discussion about commerce with my counterpart from SAP/hybris as well as a mobile application developer. Matthew Hand from Rackspace moderated, and to be honest everyone’s lucky we finished in the allotted time – we could’ve gone on forever.

With only one day at home I headed out with my wife to Meet Magento New York, where I had the honor to introduce our former president and original-bleeder-of-orange, Bob Schwartz. I got to spend a lot of time talking about Magento 2, especially with Josh & Jenna Warren, the awesome duo behind Creatuity, a pioneering Magento agency which just released THE Pintrest buyable pins integration for Magento. From there it was on to the second year of Meet Magento Romania, which was held at a five-star hotel on a hill overlooking the tech hotspot of Cluj-Napoca. This year’s event was a step up from the first MMRO last year, and that’s remarkable given how awesome that first year was. Over four hundred attendees joined the main event, with hundreds more coming in for the tech-focused Party404 at a hot nightclub in Cluj. It was great to have two of my colleagues (Bas Nawijn, our Head of Sales in EMEA and Marc Wiesler, our go-to Solutions person in the region) there to present as well. Getting shuttled around in the official event Audis wasn’t too bad, either!

And now I sit here in a lounge at the Paris airport, waiting to go to Athens for the first Meet Magento Greece. I have never been to a country which is dealing with such critical issues, and I expect to be quite humbled by the stories I will hear there. There is no doubt though that Magento impacts millions of lives all over the globe. I have to believe that this effect is quite profound for agencies, merchants, and commerce employees in Greece. If you are in Greece or proximal, why not register to support the event and the Magento community there?

Late last year the Engineering team gave the Magento community an early New Year’s gift when they announced that we could accept pull requests on the Magento 2 repository. It’s been amazing to collaborate so closely and frequently with everyone. The Magento 2 product is fundamentally better because of these contributions, and we look forward to continued collaboration.

There has been so much interaction on GitHub that we feel it’s time provide some guidance on what issues should be filed there as opposed to being discussed on the community forums (which can be found HERE):

Specific Magento 2 bugs should be filed as issues on the Magento 2 repository, preferably with an accompanying pull request

Issues with installation, unknown errors, etc. should be started as threads in the forum, and then filed as bugs when enough details are known (and if appropriate)

Feature-based pull requests should be discussed with us beforehand (so we don’t duplicate work)

Also, in order to establish the proper rights for contributed code, we need to have every contributor sign a contributor license agreement (CLA). We’ve integrated this check into the pull request process using, and will make that available soon.

Magento 2 offers many improvements to how we as developers will build, customize, and deploy eCommerce sites. It features a modernized architecture including improved modularity, improved testability, and enhanced scalability. One of the most significant improvements regarding Magento 2 is the way in which it is being developed, via direct collaboration and contribution with the Magento community on GitHub. While we’ve always relied on the community’s input when working on our application, this new era of collaboration has allowed us to:

be more transparent in our development approach and design decisions

incorporate more community knowledge and opinion in our codebase

accept & acknowledge more community-contributed code more quickly than ever before

We know from the feedback that collaboration via GitHub has been well-received, and we’re looking to expand on this. We are looking for a few developers who can commit around three hours per week to help us triage the comments, suggestions, and issues being reported. The participants will be made members of the Magento 2 repository on GitHub and will be educated by the core team on how to process community contributions.

If you are interested in this and can commit to help us make Magento 2 even better, please send me an email at ben.marks@magento.com.

What is the Magento 2 “Developer Release Candidate”?

The Magento 2 Dev Release Candidate (RC) is one of the development milestones which we announced almost a year ago at Imagine 2014 along with the Magento 2 Developer Beta and Merchant Beta. Dev RC represents the following:

A completed platform architecture in which there will likely be no major architectural shifts between now and the general release in Q4 of 2015

Incorporation of feedback from the awesome Developer Beta participants around the world (including feedback from two separate in-person developer forums with participants from four continents)

On-time completion of the Developer Beta period

As an interested developer, what should I do now?

If you are already involved in the discussions on GitHub, Twitter, email, etc. please continue to play with each release and provide your feedback, features, and fixes! If you aren’t, well… time’s a-wasting! The production versions of Magento 2 will be released this year. There is no better time than right now to install Magento 2, explore the improved architecture, and even contribute to the codebase. That’s right; just because the Dev RC is here doesn’t mean that we no longer need developer feedback. In fact, we expect to receive more feedback, because now is the time to start porting Magento 1.x extensions and custom code. Doing this will put you ahead of the curve for when Magento 2 becomes generally available (GA), and it may even result in you helping to improve the Magento 2 core.

What is Magento doing between now and Merchant Beta?

The developer community doesn’t get to have all the fun! Now we (Magento) get focus on porting our own code into the Magento 2 idiom, much as we did for the Magento_Customer module for Developer Beta. In addition to this, we will continue to incorporate community feedback and contributions, and we’ll be spending a substantial amount of time on performance enhancements – something which will proceed up to and after GA. Prior to GA expect to see new, exciting changes to checkout and admin UX.