The theory of open source is community-driven development. The reality, however, is usually different. Most open source projects actually attract very little community. As much as a project like Linux or Kubernetes attracts deep developer involvement, most open source projects toil away in obscurity, the labor of love of a single developer. For commercial open source projects that do see significant contributions, like MongoDB or Red Hat’s JBoss, virtually all of those contributions come from developers on a single company’s payroll.
Which is why Magento is so profoundly interesting.
Magento, unlike any other project I’ve seen in my 20 years with open source, sees 50% of its code coming from developers not on the Magento payroll. Even more intriguingly, just two years ago, Magento’s code was written almost exclusively by the company itself. I sat down with Max Yekaterynenko, Magento’s director of community engineering, and Ramadass Prabhakar, Magento’s vice president of technology, to understand what changed, and how this unique community works.
From Jira issues to pull requests
Before I begin, it’s important to note that my employer, Adobe, recently completed the purchase of Magento. Given my nearly 20 years of experience with open source, I was ecstatic that we’d buy an open source company. It wasn’t until I sat down with Magento’s community team, however, that I really started to understand just how different Magento’s open source model works. My interest in Magento, then, has little to do with the purchase and everything to do with how it builds community.
Not that it was always this way.
SEE: Linux distribution comparison chart (Tech Pro Research)
Two years ago, Magento operated like any other open source company: Mostly open source code (a typical Open Core model with an open source core plus proprietary bits in an enterprise build to encourage payment), and mostly closed development. Magento’s community was largely composed of system integrators and technology partners that built their businesses around Magento. When it came to influencing the code, however, partners mostly just logged Jira issues when they came across a bug, then hoped (often in vain) for Magento to get around to fixing them.
This process should sound familiar to any company, proprietary or open source. Magento’s genius was in the realization that its SI community, in particular, spent considerable time making Magento work in real-world production, and could turn that experience into better code.
And so Magento asked its community to stop filing Jira issues and instead submit pull requests.
In tandem, Magento created the Community Engineering team with the basic goal that it would listen to and review pull requests. Today a significant majority of pull requests are accepted, but the initial rate of acceptance was lower. Over time, this initiative, which started as more of a “let the community be heard” exercise, evolved to “wow, much of the innovation in Magento is being driven by our community.”
Different kinds of innovation from different places
Magento checks in with its community on a monthly video call to highlight what the company’s engineers are working on, thereby familiarizing external developers with the company’s roadmap. While Magento’s community initially set about squashing bugs, over time the nature of its engineering contributions has shifted.
Magento’s internal engineering team now focuses on long-running, big projects, as well as quality/stability. Magento engineering also builds out tooling that both community and internal teams can use to maximize productivity.
The community handles a lot of the other innovation (incremental and otherwise), with a bevy of new features originating in the community. Through this partnership of internal and external engineering, Magento’s overall code output has increased.
SEE GitHub: A cheat sheet (TechRepublic)
Somewhat astoundingly for an open source guy like me, Magento’s partners contribute to the company’s proprietary code, not just the open source code. I asked why any partner would contribute to a proprietary product that they (or their customers) would still have to pay for. The response was that doing so makes maintenance easier. It also helps them to drive business because they can set themselves apart if their code is in the commercial offering. Similar to Red Hat positioning its contributions to Linux or Kubernetes, Magento’s active partner contributors also position themselves to be able to better support their customers if they have contributory influence with engineering.
Magento tries to follow the same process for internal and external contributions. They don’t really care where the code comes from. Focus is on improving code quality from wherever it starts, and approval doesn’t depend on the employee badge someone may or may not wear.
This approach hasn’t been without friction, internal and otherwise. But over time internal and external engineers have become increasingly comfortable with the approach, Yekaterynenko and Prabhakar tell me. It’s unlike anything I’ve ever seen in my years in open source, and could be a model for other companies to embrace, whether open source or proprietary.