How Magento Community Makes the Whole Platform Better

“The magic and power of Magento come from all of you”.

It’s hard to count how many words were said about the Magento community during Imagine 2019. Mobecls team talked to Igor Miniailo, Lead Magento Architect, and got some insights about Magento Community Engineering Team, its creation and work results. Find out how Magento community makes Magento better.

— When the core team began to collaborate with the community, receive pull requests and just communicate, were there any WOW-moments? What did the community teach you?

— Magento has always been an open source system. However, to be a real open source system, people should have an opportunity to modify and change it. That was our main problem. We didn’t take pull requests and talked to the community as often as we would like to. Some pull requests could not be processed for years. Therefore, people stopped contributing because they didn’t receive any feedback from Magento.

2 years ago we decided to fix it. Four core developers formed a team, whose initial task was to scour the queue of pull requests and Github issues. We started processing them and began to involve people in this process.

When people saw that Magento began to accept their fixes and changes quicker —  the number of pull requests started to increase exponentially. Six months later, when we significantly reduced the queue of pull requests, we decided to start developing features.

Multi-Source Inventory (hereinafter MSI) was the first big project when we tried to make a feature, not just fix bugs. The entire project, from the beginning to the current state of General Availability, was developed by the community engineers. More than a hundred people have contributed to the development of the feature.

We often encountered the following problem during features development — there is a gap between core engineers and business. Core engineers don’t always understand how merchants will use this functionality. This leads to the fact that when a new function is released, we have to make changes or even backward incompatible changes to the code. It’s a real headache for merchants. When they update Magento, they can find bugs or broken functionality that worked in the previous version. It affects not only merchants but also developers who have to do a great number of customizations.

This problem helped us to realize why it’s so necessary to work with the community.

All the community engineers, we were working with, had the experience of integrating Inventory and ERP systems. They were bringing real-life business cases and asking: “I want to see how this case will be solved with the help of your system”. That’s why, during the MSI development and its designing, we were modeling many cases, including edge ones, which we could not even think about.

We had open discussions and presentations where people were bringing their cases and asking: “Will it work for me?”. We were analyzing all of these cases. When we couldn’t give the answer, we were trying to find a solution for their case that didn’t require lots of customizations.

When the community is working on a product, it becomes much closer to the real market. This is what we work on. We are trying to reduce the gap between business and engineers.

— In other words, the community has become a resource that provides feedback from the market, not just write codes.

— That’s right. The concept of community engineering has proved to be the most effective in terms of receiving feedback on specific functionality. Despite the fact that we also communicate with merchants and our partners.

— What are the difficulties of managing such a project like MSI? Complex feature, numerous developers, all of them are distributed.

— If we are talking about project management, then we use so-called Pure Agile. We have a lot of distributed developers from different parts of the world. We have contributors from Australia, Europe, South and North America.

We don’t know how much time a person will spend on a task. To be honest, even a developer don’t know how much time can be devoted to the project. It’s volunteer work. People should do it for fun. Developers come to us just because they are bored. Good coders are always striving to find and solve complex tasks. They want to use new technologies that they lack in their companies. Someone works with the old versions of Magento, someone with the ancients.

As a result, we get a bunch of people from different places who work in their free time or even at nights. That’s why it’s hard to estimate the level of their involvement. It makes the process of project management extremely challenging.

Due to the complexity of managing such a team, we never give exact dates for our releases. When you don’t have a constant number of human resources, you can’t set a specific time frame. As we can’t set our deadlines, we can’t rely on the deadlines that Magento puts on its patch releases. But we can rely on the backlog that was made.

One more problem is the seasonality of works. In one period of time, we have a lot of coders, on holidays, for example, — very little. A surge of activity is observed in spring and autumn, during seasonal events, such as Contribution Days.  Don’t forget that people themselves are also different. Someone joins us for six months, someone — during events.

Editor’s note: This April Mobecls team attended Magento Meetup and Contribution Day in Kyiv powered by Atwix. Check our Travel Blog to find out why it’s so cool to attend such events.  

It’s very difficult for us to make precise predictions. Sometimes we build burndown charts and probability models, try to analyze and predict how many engineers we will have. These are more heuristic estimates than real ones.

We had to develop our own approach. As soon as we have a ready feature – we release it independently of Magento. This is the biggest revolutionary change in the Magento ecosystem.

To a large extent, the system will break up into more isolated applications, and each of them should be released this way.

We’ll have our own release cycles to avoid the Big Bang releases. They come out 4 times a year and contain tons of changes that become a terrible headache for merchants. When everything will be releasing in separate cycles, it’ll be easier for merchants to upgrade Magento. We also won’t accumulate unfinished features that gather dust in our Github branches.

Community forced us to do it, but thanks to them we started releasing features on our own.

— Is there any selection of developers? For example, I want to work on MSI. What do I need to do? Just come and say: “Hi, I want to work on MSI”?

— There is no selection from our side. As a rule, people have a certain interest. We just show them a shop-window with several products such as PWA, GraphQL or MSI. We give everyone the opportunity to test and use these technologies.

All of them are new and interesting in their own way. As a rule, we cover a different range of skill sets. For example, if front-end developers come to us, they won’t be interested in MSI as it’s an eCommerce business project. Probably, they will prefer PWA. We have many projects that cover different sets of skills and features. You will find what you’d like to test and sort out.

— Are there any chances for developers to get into the core team?

— We had such a case. David Manners has been working for the Community Engineering team for over a year. By the way, now we have a vacancy. We are looking for an engineer from the community. Location doesn’t matter. We want to expand our team and we need a person who will attend such events like Contribution Days in different parts of the world.

Editor’s note: Magento Association has opened membership signups at magentoassociation.org/signup .Don’t miss the chance to join!

However, there are some nuances. We can’t hire developers who work for our partners. As soon as we begin to hunt people, our partners will cease to participate in the events. All the win-win cooperation that was created may collapse. That’s why we can’t hunt our partners’ employees.

— Looking at the changes that are happening in the community, it’s hard to call Magento the Forbidden City.

— Magento has become more open and accessible to coders. I would say more friendly.

Our documentation has become much better. Terrible documentation was one of the Magento problems. We managed to solve it only starting from Magento 2.2. Now we have a really cool team of technical writers who write very good things. We were very pleased to see positive tweets to release notes 2.3.1.

There is a phrase “Code is the best documentation”. It’s not very good, but we used to follow this principle. Yes, it’s great when the code is written well and you can learn a lot from it. However, it’s not enough for Magento because there’s still a lot of legacy code.

We decided that there should be a lot of comments in the code. There are such pieces of legacy code, where it isn’t very clear what exactly should be done. It takes a lot of time to fix bugs in legacy code. First of all, you need to understand how it works at all. Honest and frank comments serve as a kind of small confessions. Developers confess that they used a workaround.

These comments allow the next engineer who works with this code to spend much less time. We offer a complex solution to problems. Community engineering, Magento documentation, everything has become public.

— Has the creation of Community Engineering Team paid off?

— Let’s turn to statistics. In the middle of the last year, the number of code that was written by the community overtook the number of code written by the core team. Community creates 60% of the code.

Someday Magento Community Edition will be developed only by community developers and the core team will be responsible for Enterprise or Cloud Edition. It would absolutely change the entire Magento business model.