The latest discussion happening amongst WordPress core contributors and developers is about which new JavaScript framework to adopt in WordPress core. I’m not going to wade into that debate here, but rather pick up on something in this WP Tavern article about the debate, as an argument against using Vue.js:
“I’m uncomfortable relying on a project run by a single person that could disappear,” React proponent and WP REST API co-lead Ryan McCue said.
Vue.js is a one man show, run by Evan You and funded using Patreon. I was stunned by the hypocrisy of this comment from Ryan McCue. I fundamentally agree with Ryan’s position here, but it’s the exact same argument that could have been levelled at the inclusion of the Requests for PHP library, included in WordPress 4.6, of which Ryan himself is the lead developer.
The Problem
For those who don’t know who Ryan is, he is one of the many (awesome) people who contribute heavily to WordPress in their own time, as well as whilst working for Human Made. He works extremely hard for WordPress, giving a lot back, and talking at WordCamps and other conferences. But, he has a lot on his plate! He is the lead developer of the Requests library, the co-lead developer of the REST API project (now merged into core), and the lead developer of SimplePie also used in core. He is also the lead on a large number of projects being pumped out at Human Made. He is the exact same key person dependency he is arguing against for using Vue.js.
Leaving aside any potential bias Ryan might have towards using React over Vue, and taking a look further at his argument against using Vue, it doesn’t hold up in a WordPress context, especially when considering the Requests library. Evan is working full time on Vue, his only project (and getting paid to do so), along with over a hundred contributors to the project. On the other hand, Ryan has arguably too many projects on the go at the one time, splitting his development time during his work day and no doubt during a lot of his evenings and weekends. In contrast, Request has only 37 contributors (the more active are also WP contributors), yet it was merged into core with significantly less discussion.
Heavy reliance on one person with so many active projects isn’t sustainable and is a potential flaw of WordPress itself. Just to be clear, this isn’t a personal attack on Ryan, but simply highlighting the issues caused by key person dependency. For example, when WP 4.6 was released, its implementation of the Requests library created breaking changes for a number of plugins, including WP Migrate DB Pro. It took Ryan over a month to respond to the trac ticket and illness meant he fell behind tagging new releases of the library which affected users managing sites with Composer:
Sorry, been sick! Will get to it as soon as possible.
— Ryan McCue ☂️ (@rmccue) August 30, 2016
Of course, life is never simple, we all get sick, and shit happens. But with WordPress and larger projects, there are other people to cover such eventualities. However, libraries that are managed mainly by one person are much more susceptible to the bus factor. If that one person leaves the project, then all that knowledge walks out the door, along with the ability to quickly patch bugs and build new features. The project needs to look elsewhere for a maintainer, and the upstream project (WordPress) is left in limbo whilst this happens.
Having so many projects on the go opens a maintainer up to having burnout, which raises the bus factor risk even higher. It also means the maintainer’s limited time is shared amongst all the projects, and as a result, they are spread thin and projects can begin to suffer. For example, issues start to languish and development slows. Although the thread in which this was highlighted is not the best way to feedback such issues, it shows the impact that key person dependency can have within OSS projects.
Ways to Solve the Problem
Undoubtedly the best way to mitigate the risk is to encourage other contributors and eventually have multiple lead maintainers of the project. This, is of course, harder for smaller projects. Not all projects can have WordPress levels of contribution, but important projects need marketing, outreach, and encouragement to garner high levels of contributions.
One way to help ensure the longevity of a third-party library, relied upon by a project such as WordPress is to fold it into a larger organisation like WordPress itself. If WordPress took on the Requests library, it would open it up to a wider audience of contributors and would take some responsibility for its survival out of the hands of the one maintainer, Ryan. There’s no doubt that the REST API project is stronger because it was a WordPress feature project, with multiple developers.
Similarly, WP-CLI, which recently was brought under the WordPress banner, increased the chances of a longer life by reducing the bus factor around its main developer, Daniel Bachhuber, by appointing a new co-maintainer. Of course, this was only made possible due to the funding Daniel secured earlier in the year, as the role is a paid position, but it shows what corporate sponsorship can do to help OSS projects. Human Made has a lot invested in the REST API, but perhaps some of that could be redirected to add support to the other projects that Ryan works on which are critical to WordPress.
Ultimately, there are no hard and fast rules when it comes to judging which OSS projects are safe to use when considering longevity and future support. However, there needs to be a significant push to decrease the bus factor on projects such as Requests for PHP, that other projects rely on.
The React vs Vue.js debate for WordPress has highlighted the need, I believe, for wider discussion when it comes to introducing any and all libraries into WordPress, regardless of their importance and size. How else can we reduce bus factor in project dependencies? Let me know in the comments below.
