The impression I get here and from other comments made by other core developers is this:

“Don’t worry your pretty heads about how core developers chose to alter the project, that’s of no concern to you”

First off, I apologise for giving that impression - I certainly had no intention of minimising yours or anyone's concerns about this. I'm strong believer in all of us being able to have a respectful dialogue about these kinds of decisions. 🙂

How learnable and accessible core code is matters.

I absolutely agree! Core is currently really hard to contribute to, it's very rare for folks to make the jump from occasional contributor to regular contributor. Gutenberg is an excellent opportunity for us to reset that.

There is should be no jump in complexity just because something is core code vs a plugin or theme.

I almost entirely agree with this, too. 🙂 I should note that there are three different APIs I'm thinking of when I say this:

- The third party framework API. This should only ever be used directly in one place - the WordPress element. The WordPress element exposes and translates selected parts of the framework, nothing in Core or plugins should ever talk directly to the third party framework. This abstraction treats all frameworks that plugins use equally, and gives us the freedom to change the third party framework in the future, if we need to.
- The WordPress element API. This is used for implementing UI components within Gutenberg - buttons, panels, form fields, and the like. More complex plugins can also implement and use these components in their UI. There's ongoing work to ensure that these components can be used in any framework.
- The Gutenblock API. This is a higher level API again, allowing plugin developers to implement blocks in a simple and accessible manner. All of Gutenberg's blocks are implemented using this API.

So, I agree that anyone contributing blocks or components to Core should be able to do it as easily as they build them for their own plugins. The glue that makes this possible will likely be trickier to contribute to, but that seems like a reasonable tradeoff to provide a great experience for the all plugin developers and most Core contributors.

If the only blocker was the license, it stands to reason that most in core were fine with the ideological fitness of React, being a FB project, which to be quite frank is a despicable entity not least for undermining the open web and profiting off the demolition of democracy and privacy.

I don't think this is entirely fair. Every corporation will have politics that we disagree with, judging their projects through that lens just means we're cutting off all possible avenues to help change those politics.

Before the license debacle, React had been annointed and would have been annointed sooner if not for objections made largely by others. If there had been little noise about the license and the Apache foundation hadn’t ruled against React, we’d have been apparently content to go along with it.

As I mentioned in my parent comment, we'd already started reaching out to Facebook before the Apache foundation thing happened, we weren't aware that they were having an internal discussion about it. As Matt mentioned in his earlier post:

Core WordPress updates go out to over a quarter of all websites, having them all inherit the patents clause isn’t something I’m comfortable with.

I think there's an important distinction to be made between the practical, legal effect of the patent grant, which patent legal experts tend to agree would've had no practical effect; and the philosophical issue of that patent grant. The GPL3 and Apache2 licenses have similar patent grants, the difference is the breadth of the revocation clause. It's clear that even if there's no practical difference, there's certainly a difference in how that difference is seen. I agree that it felt like a step too far in Facebook's favour, with nothing given in return.

Meanwhile there had been little explanation why React was a special technical fit for WordPress – it simply owned the matter by being the dominant tool in use.

I agree that there hasn't been enough discussion on why React was considered the best technical fit. It's briefly covered here, but I think it's important that, when Gutenberg finalises the framework, the decision is accompanied by a comprehensive document on why that framework was chosen.

Core developers and Matt should be the principal decision makers. It’s not something I quarrel with, I think this type of meritocracy has served WordPress very well. But it also means we trust you to make decisions that serve the whole community in alignment with the project. I have never doubted that decision making process until React came along.

I truly thank you for that trust - it's critical for WordPress to be able to grow and evolve. We try to treat appropriately, but clearly erred in this situation. Regardless of which framework Gutenberg uses, I do hope that we're able to win back that trust. 🙂