Key Person Dependency in OSS Projects or: Do We Need to Talk About Ryan McCue?
Iain Poulson

Hi, I’m Ryan McCue, the guy in this post. I figured I should probably give time to respond, seeing as it’s about me. :)

To preface, I’d like to mention that I don’t think who am I or what I do affects the argument itself: there’s a danger in using any library or framework based around a single developer. Vue fits that criteria, whereas React has a company with a vested stake in its strength. That said, this maintainer-based argument is a secondary one at best, and I think there are stronger reasons to pick React.

React vs Vue

On the whole, I agree with the central premise of the post: projects with a bus factor of 1 are generally not suitable for production use, especially at the scale of WordPress. With that said, I think there is a significant difference between the libraries I maintain that are in core, and the choice of a new JS framework for WordPress.

Both of the libraries mentioned in the post (Requests and SimplePie, although I’m no longer the maintainer for the latter; more on that below) are separated from WordPress through somewhat-clean abstractions. At their heart, they are functions: you call wp_http_request and get a response array; you call fetch_feed and get a response object. They’re also reasonably simple (notwithstanding the complexity of the 8 different mutually-incompatible RSS specifications).

Both of these libraries are convenience libraries: Requests simplifies the work of using cURL/PHP sockets, and SimplePie simplifies accessing data in RSS/Atom XML documents. These are things you can use directly, but it’s way easier to use the convenience of abstractions instead. Because of this, they can be swapped out for different libraries. They actually have been changed in the past (Requests is the ~4th HTTP request implementation in core, SimplePie is the 2nd feed parsing implementation). For the most part, no one needs to know or care about the underlying libraries we use.

On the other hand, React and Vue are functional libraries, and architectural frameworks. To use them, you need to embrace their paradigms, and structure your project in a certain way. Swapping one out for the other is tough: I’ve converted a Vue project to React, and it took a lot of work, due to the paradigm shift. (Alternative implementations of the same paradigm are much easier; Preact is a good alternative to React that follows the same paradigm, and can be a wholesale replacement with the compatibility layer.)

The view library that we pick is going to massively influence the future of WordPress to the degree that nothing else will. The philosophy and management of the project matters immensely for that reason. Smaller libraries that we use don’t have anywhere near that effect. (Compare jQuery vs Twemoji, e.g.) At the end of the day, neither Requests nor SimplePie mattters that much.

I don’t think it’s a major concern that Vue is run by a single person. However, there’s no strong vested interest in Vue from the lead; at any point, Evan You could decide to stop working on Vue, which could leave a void in the project. Conversely, Facebook can’t just drop support for React, because their production software runs on it. (Vue does have third parties with vested interests, in particular, Alibaba, Baidu, Tencent, which is why it’s not a major concern.)

However, I do think it’s more of many signals that contribute towards the overall picture. I also think React’s patent license and commercial control contribute towards this (negatively for React) as well. The question isn’t about any particular point, but rather about the overall picture, and my belief is that combined, the case is stronger for React.

Leaving aside any potential bias Ryan might have towards using React over Vue, and taking a look further at his argument against using Vue

I absolutely have a bias towards using React, as do many of the core contributors, because it’s what I know best. React is clearly the most used choice with the core contributors, which is why there’s an overall bias in the discussion.

Regardless of what we pick, people who want to contribute to core need to learn it. The library that the majority of core developers are most familiar with is React. That’s a strong signal towards choosing React, because if we pick something else, they will need to learn and switch to it, which is a source of friction for core contributing.

The libraries included with core primarily affect core development, because they’re the only libraries we can use. The wider community can use anything that’s available. (One of many reasons I don’t think the admin would work as a single-page app is because it wouldn’t allow this choice.)

With that said, the choice has large flow-on effects to the community, which is why we’re encouraging more discussion. There wouldn’t be a discussion at all if we’d already picked a library, we would have just done it.

Both React and Vue have benefits and problems. I personally think that the benefits of picking React are stronger, and that generally they outweigh the problems. I am glad that we’re having a lively discussion on the topic though, because it means people do actually care. At the end of the day though, we need to make a decision, and people are inevitably going to be unhappy.

Me, Specifically

I’d like to also clarify a few points about myself from the post. (These are not in the same order as the original post.)

If you’re only interested in React vs Vue, you can stop reading here.

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.

I am indeed the lead developer of Requests, and one of the focus leads of the REST API, but I’m not the lead developer of SimplePie anymore. I passed maintainership of SimplePie on a fair while ago when it was clear that I couldn’t give time to it.

In reality, I should have passed it on much earlier, but finding people willing to maintain a project who also share the same philosophy on how that should be done is tough. Crucially for projects used by WordPress, this includes working with outdated technology (PHP 5.2) and being reasonably locked into the existing API to avoid breaking backwards compatibility. Thankfully, the new maintainer (Malcolm Blaney) has been doing a great job there.

In contrast, [Requests] has only 37 contributors (the more active are also WP contributors), yet it was merged into core with significantly less discussion.
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.

The idea with merging Requests into core was for this exact reason. For a long time, WordPress had its own homegrown HTTP library, WP_Http. Along with Dion Hulse, I was one of the two people maintaining WP_Http. This library wasn’t usable outside of WordPress at all.

The idea with incorporating Requests was to improve the state of maintenance on the project. This separates WordPress from the HTTP library implementation, allowing other projects to use it and contribute back. It also has a high level of test coverage, helping to improve the code quality overall.

A different way to think about this is that we took the core of WP_Http, and split it into a more widely usable library. I worked on WP_Http and Requests, and the two shared ideas and workarounds (although not code directly, as Requests is under a more liberal license).

That said, Requests does only have two maintainers, myself and Dion (by way of the HTTP component of WordPress). This isn’t a desirable state to be in, and I’d love for more people to help out here. (If you’d like to, let me know!) I’d also be more than happy to move Requests to the WordPress GitHub organisation.

This is on me. I need to be more active about giving commit access, and documenting philosophies and goals rather than storing that in my head.

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:

Indeed, this was hugely problematic, and I’m sorry for how this issue was handled. I didn’t fully appreciate the impact or severity of the issue, and I didn’t move fast enough on fixing it. Apologies to everyone this affected.

It is worth mentioning, however, that this issue is with the integration layer with WordPress, not the underlying library. The issue here is that the HTTP component of WordPress has very few people who work on it (primarily myself and Dion); the maintenance of Requests itself is less important.

The key reason that there’s so little time put into this is because it’s boring, low-level work which has a relatively small impact. It’s not the sort of shiny fun stuff that people generally enjoy working on. It’s pretty stable generally speaking as well. There are a lot of other components of WordPress that suffer from this same problem (the Media library is one famous example), and there’s no real systematic solution to it. You can’t force people to contribute to things in open source.

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.

It’s worth clarifying exactly what I do at Human Made: since October 2016, I’ve been the Director of Engineering, which means I oversee a lot of different things. This includes internal tooling, improving the life of our developers, and wider efforts in the community. Fundamentally though, my job is to act as a force multiplier for everyone else, and improve their experience.

My time is essentially all self-directed; that is, I choose what I work on, and allocate the time myself. There’s no “Human Made” choosing what I work on in that regard. In theory, if I wanted to dedicate two weeks solely to working on Requests, I could totally do that. Generally speaking, my time is split into two halves. I spend two days a week (typically Monday and Tuesday) working on WordPress core and the REST API, and the other three days working on HM work and related projects.

The time I spend on the REST API is my own decision, and when I’m working on it, I work independently of HM. It just so happens that this aligns with what we do as an agency. Primarily, I work on the REST API because I believe it has the greatest benefit to the community, and to the users.

He is also the lead on a large number of projects being pumped out at Human Made.

As part of my role, I’ve been pushing us as a company to better maintain and support our open source projects. This includes writing posts about our projects so people know they exist, and working on documentation around them. This is partially a marketing effort (since we’re promoting our projects), and partially a community effort (since we’re contributing these projects back to the community).

While I write these posts, I’m not necessarily the maintainer of them. There are four projects noted here:

  • Tachyon: I wrote the linked blog post for this, with input from Joe Hoyle, our CTO. All active work on Tachyon is done by our servers team, primarily Joe.
  • Mercator: I initially wrote Mercator as part of work on Happytables, roughly two years ago. While it is mostly stable, there is some active work here by Rob O’Rourke, who took over the actual maintenance and development a while ago.
  • Cavalcade: I wrote and maintain Cavalcade. This is mostly stable software, and there haven’t really been major changes since I wrote it two years ago.
  • Chassis: I wrote Chassis alongside Bronson Quick (who later joined HM by way of acquisition), and continue maintaining and actively developing it with Bronson. Practically speaking, this is the only project of these four I spend time on, as it directly improves the developer experience across the company.

With the exception of Chassis (which I do actively work on), I don’t spend time on the other projects. These projects are subject to our company-wide open source support policy, and in particular, we treat them as complete: we aren’t actively adding features or refactoring anything. In addition, they belong to Human Made (both in terms of IP, and the GitHub organisation), so if something happens to me, someone else can easily pick up the maintenance role.

I do put significant time into Chassis. This is primarily in my capacity as a force multiplier: improving development tools frees up time for other engineers and makes them more productive. I cannot count how much time has been lost to terrible development environment setups across the company. (Chassis is also not a Human Made project, so it’s not subject to the HM support policy, which means helping others uses up some time too.)

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.

This is absolutely true, and I’m a serial starter of projects without giving enough time to maintaining those projects.

Often, the way this happens is I get frustrated with a problem, and I can see the solution, so I write it. Usually these projects work, but they’re far from the most usable things in the world. They’re way more valuable released to the world than sitting on my computer or only used internally at HM though.

A classic example of this is the WordPress Importer v2 project. I started this because I have a lot of experience with XML parsing from my SimplePie days, and I could see that the existing Importer was inefficient and causing problems. I fixed that by switching to a streaming parser, wrote a minimal CLI interface, and then unfortunately had no more time to work on it. The current solutions (particularly WXR splitting) aren’t great, but they’re good enough, so there’s just not a need for it.

One of the reasons the REST API was such a great project was because I had a fantastic co-lead in Rachel Baker. Rachel is probably more important to the project than I was, because she was the one doing the real work of maintaining an open source project. There is no doubt in my mind that the REST API would never have shipped without her.

Unfortunately, people like Rachel are rare, and not every project has someone who’s great at this. I would love to have more people help out on my projects, but the reality is that they just don’t exist. It sucks, but the reality is that unless other people step up to join these projects, nothing will happen.

(And for what it’s worth, I have a pretty balanced schedule. I’m fortunate in being able to assign my own time, which means I don’t need to work late into the night, nor all weekend. My GitHub contribution graph is mostly grey on the weekends, although I’d like it to be completely grey.)

I’m aware that this post is entirely too long, but I figured I’d bore you all with too much detail rather than not enough.

Thanks to Iain for bringing this topic up. The vast majority of his points are right, but sometimes they’re just unavoidable, unfortunately. As much as I’d love to be everywhere at once, it’s not possible.

I’m open to answering any questions or comments at any point, and I have an open AMA repo where you can ask me literally anything. I’m also always available on the WordPress and Post Status Slack teams if you want to message me.