{"id":1410,"date":"2017-08-10T20:28:19","date_gmt":"2017-08-10T15:28:19","guid":{"rendered":"https:\/\/thedevcouple.com\/?p=1410"},"modified":"2017-08-11T09:29:11","modified_gmt":"2017-08-11T04:29:11","slug":"ryan-mccues-befitting-response-key-person-dependency-oss-projects","status":"publish","type":"post","link":"https:\/\/thedevcouple.com\/ryan-mccues-befitting-response-key-person-dependency-oss-projects\/","title":{"rendered":"Ryan McCue’s Befitting Response to Key Person Dependency in OSS Projects"},"content":{"rendered":"

After the inclusion of REST API and WP CLI in the core, WordPress developers are concerned\u00a0about which new JavaScript framework will be adopted next. And for that React vs. Vue.js has been long into a heated debate. However, the argument took wild fire once again when Iain Poulson<\/a>\u00a0<\/strong>\u2014 PHP developer at Delicious Brains<\/a><\/strong> \u2014 wrote a post about\u00a0Key Person Dependency in OSS Projects<\/a>.<\/strong><\/p>\n

Ryan McCue’s Response<\/h1>\n

While several concerns raised in the article by Iain are very much real, there’s more to it than meets the eye. Honestly, Ahmad<\/a>\u00a0had told me about his concerns which were pretty much along the same lines.<\/p>\n

I think Ryan’s response is worth a read. So, we reached out to Ryan seeking permission to repost his response from Medium to WordPress \u2014 guess what he said?\u00a0\ud83d\udc9c<\/p>\n

Below is what Ryan wrote, and both I and\u00a0Ahmad<\/a>\u00a0agree with him.<\/p>\n

\n
\n

 <\/p>\n

\"\"<\/p>\n<\/div>\n

Hi, I\u2019m Ryan McCue, the guy in\u00a0<\/span>this post<\/a>. I figured I should probably give time to respond, seeing as it\u2019s about me.\u00a0\ud83d\ude42<\/span><\/p>\n

\n

To preface, I\u2019d like to mention that I don\u2019t think who am I or what I do affects the argument itself: there\u2019s 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.<\/p>\n

React vs\u00a0Vue<\/h2>\n

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.<\/p>\n

Both of the libraries mentioned in the post (Requests and SimplePie, although I\u2019m 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\u00a0wp_http_request<\/code>\u00a0and get a response array; you call\u00a0fetch_feed<\/code>\u00a0and get a response object. They\u2019re also reasonably simple (notwithstanding the complexity of the 8 different mutually-incompatible RSS specifications).<\/p>\n

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\u2019s way easier to use the convenience of abstractions instead. Because of this, they can be swapped out for different libraries. They actually\u00a0have<\/strong>\u00a0been 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.<\/p>\n

On the other hand, React and Vue are functional libraries, and\u00a0architectural<\/em>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\u2019ve 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.)<\/p>\n

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\u2019t have anywhere near that effect. (Compare jQuery vs Twemoji, e.g.) At the end of the day, neither Requests nor SimplePie mattters that much.<\/p>\n

I don\u2019t think it\u2019s a\u00a0major<\/strong>\u00a0concern that Vue is run by a single person. However, there\u2019s 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\u2019t 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\u2019s not a major concern.)<\/p>\n

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

Leaving aside any potential bias Ryan might have towards using React over Vue, and taking a look further at his argument against using Vue<\/p><\/blockquote>\n

I absolutely have a bias towards using React, as do many of the core contributors, because it\u2019s what I know best. React is clearly the most used choice with the core contributors, which is why there\u2019s an overall bias in the discussion.<\/p>\n

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\u2019s 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.<\/p>\n

The libraries included with core primarily affect core development, because they\u2019re the only libraries we can use. The wider community can use anything that\u2019s available. (One of many reasons I don\u2019t think the admin would work as a single-page app is because it wouldn\u2019t allow this choice.)<\/p>\n

With that said, the choice has large flow-on effects to the community, which is why we\u2019re encouraging more discussion. There wouldn\u2019t be a discussion at all if we\u2019d already picked a library, we would have just done it.<\/p>\n

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\u2019re 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.<\/p>\n

Me, Specifically<\/h2>\n

I\u2019d like to also clarify a few points about myself from the post. (These are not in the same order as the original post.)<\/p>\n

If you\u2019re only interested in React vs Vue, you can stop reading here.<\/p>\n

He is the lead developer of the Requests library, the co-lead developer of the\u00a0REST API<\/a>\u00a0project (now merged into core), and the lead developer of\u00a0SimplePie<\/a>also used in core.<\/p><\/blockquote>\n

I am indeed the lead developer of Requests, and one of the focus leads of the REST API, but I\u2019m not the lead developer of SimplePie anymore. I passed maintainership of SimplePie on a fair while ago when it was clear that I couldn\u2019t give time to it.<\/p>\n

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<\/a>) has been doing a great job there.<\/p>\n

In contrast, [Requests] has only 37 contributors (the more active are also WP contributors), yet it was merged into core with\u00a0significantly less discussion<\/a>.<\/p>\n

[\u2026]<\/span><\/p>\n

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.<\/span><\/p><\/blockquote>\n

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\u2019t usable outside of WordPress at all.<\/p>\n

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.<\/p>\n

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).<\/p>\n

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

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.<\/p>\n

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:<\/p><\/blockquote>\n

Indeed, this was hugely problematic, and I\u2019m sorry for how this issue was handled. I didn\u2019t fully appreciate the impact or severity of the issue, and I didn\u2019t move fast enough on fixing it. Apologies to everyone this affected.<\/p>\n

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.<\/p>\n

The key reason that there\u2019s so little time put into this is because it\u2019s boring, low-level work which has a relatively small impact. It\u2019s not the sort of shiny fun stuff that people generally enjoy working on. It\u2019s 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\u2019s no real systematic solution to it. You can\u2019t force people to contribute to things in open source.<\/p>\n

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.<\/p><\/blockquote>\n

It\u2019s worth clarifying exactly what I do at Human Made: since October 2016,\u00a0I\u2019ve 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.<\/p>\n

My time is essentially all self-directed; that is, I choose what I work on, and allocate the time myself. There\u2019s no \u201cHuman Made\u201d 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.<\/p>\n

The time I spend on the REST API is my own decision, and when I\u2019m 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\u00a0I\u00a0believe it has the greatest benefit to the community, and to the users.<\/p>\n

He is also the lead on a\u00a0large<\/a>\u00a0number<\/a>\u00a0of<\/a>\u00a0projects<\/a>\u00a0being pumped out at Human Made.<\/p><\/blockquote>\n

As part of my role, I\u2019ve 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\u2019re promoting our projects), and partially a community effort (since we\u2019re contributing these projects back to the community).<\/p>\n

While I write these posts, I\u2019m not necessarily the maintainer of them. There are four projects noted here:<\/p>\n