Magento is referred to as “open source” software as it is being distributed under an open source license. Magento 2 continues the trend and introduced an official Github repository. But is that all there is to it?

The situation

The development of Magento 1.X has always been a bit of a black hole. Now and then a questionable roadmap, a bug tracker like the average “suggestions box” and no transparency whatsoever.

Magento planned to solve this with Magento 2. In November 2011 they went public on Github, late 2013 they started publishing weekly commits and to this day they still do this without severe interruption. In addition, there is now a “developer evangelist“, Magento 2 issues can be publicly discussed by anyone, the Magento bug tracker has been revised and one of the platform goals of Magento 2 is to “closely engage with the community”.

Because a complete timeline is not within the scope of this article, this Cloudways article contains more background information on the transition between Magento 1 and 2. What we are going to talk about, is the “open source” part of Magento 2. Or rather, the lack of.

How Github is used

Each Friday, sometimes a day or two later, the Magento 2 team pushes a massive commit to the public Github repository. These are the development releases and each commit indicates a new version (e.g. 0.1.0-alpha100, 0.1.0-alpha101). Github its issues tracker is used to communicate with developers. When relevant, those issues are cross-referenced in commit messages and the changelog.

And that’s about it.

What’s wrong

There is a strong suspicion that the public Github is nothing more than a weekly sync-spot for the internal VCS repo, where- and whatever that may be. The issue tracker is just a proxy to the internal JIRA tracker. Once you submit a issue to Magento 2, you will either get a notice that it is already being worked on or that it has been forwarded to the “team”. I.e. you will not hear back, until it has been fixed or the internal JIRA discussion has concluded something.

Part of this might have to do with the fact that Magento is part of eBay and its Enterprise Processes™. But when you are commiting yourself to an open source project, communication with developers should entail more than “letting the team know” about issues. Platform developers and users have ideas too, maybe even code to contribute.

Which brings us to the next major issue: contributing to Magento 2. In a traditional open source project, especially in this “social coding” era, working together is part of the package. A project has clear defined goals, issues, todo’s, milestones and proper attribution. Magento 2 doesn’t have any of this.

Where you might be used to fork a project, update, send a pull request and get proper attribution, in Magento 2 the last part is completely missing. They take your submission, incorporate it in the code base and on Friday they push a big commit with no reference to the original corporation whatsoever. This is not about personal ego, but rather about building something together and getting attributed for it.

How to make it better

All of this is probably linked to the internals of eBay & Magento. However, if the plan is to have Magento 2 out there as a true open source project, communication should be a magnitude more transparent. “Move Magento-oriented communication to Github” might not be realistic given the scope of Magento and its license-based enterprise edition, but at least all issue tracking which has to do with development could be moved to Github.

In an ideal situation, enterprise edition would be built on top of the base community edition. The extra components, libraries and modules can be hosted in a different protected repository which developers of license-owners can get access to. There, Magento 2 enterprise edition can be developed in the same open manner as the community edition – including transparent discussion relevant for the enterprise edition.

Without a clue of how internal Magento 2 development is currently organised, a major improvement is to just get all the relevant Magento 2 developers on Github. Make them commit their work there. Make use of branches. Merge those pull requests. Create a weekly release instead of a massive commit. Make development transparent.

Final words

Maintaining an open source project entails more than syncing an internal code-repository with a public one, once a week. It’s about collaborating together to build something great. Magento 2 might be classified as open source due to its permissive license, all other informal requirements are neglected.

“We can learn more from each other when information is open.” – The Open Source Way

It’s not like nothing is happening. Rumor has it that Ben Marks is shifting boulders to improve the situation and issues reported are noticeably getting more response from Magento staff. Relatively speaking it’s not a lot, but at least there are plans to improve the situation.

And with that in mind, hopefully these two cents are not relevant anymore in a near future.