That's not the case with React Native though.

The problem is that the surface area is vast, and the popularity is booming through the roof. If RN team looked at every issue, the (very active) development would stall completely. On the "web" React repo we can afford to do this because our surface area is much smaller, but on RN it's not practical.

So instead, the RN team tends to focus on the issues that are reported most often by the FB product teams. While this is not a great outside communication strategy, it ends up highlighting most pain points shared by folks outside the company too. Note this includes vast architectural improvements as highlighted in the post--something that goes way beyond a traditional GitHub issue report.

While admittedly this approach puts FB's needs first, it also serves as an important way to keep the team focused. It is very hard to deal with dozen new issues every day and still move the project forward so they chose this path.

I want to highlight that RN has maintainers outside of FB who help with different parts of the codebase (because again, the surface area is vast), sometimes with more expertise in those areas than people at FB. So the project isn't dependent on FB maintainers looking at issues alone. Folks outside can, and do help.

This doesn't mean issues don't end up being addressed in the end. But GH issue communication model just doesn't scale well for RN.