I've found that to be relevant for a few issues (including one of my own) with Facebook Open Source projects—that or they just go unheeded by staff, but confirmed by a stream of others.
I am a distant outsider to that company, I haven't used the platform in years and remain quite critical of it and many business practices especially regarding recent exposures (though I am a fan of their engineering they've released or open-sourced for the web)— yet I can understand somewhat how staff associated with such projects are not necessarily actively and regularly allocated to addressing those issues. At times they're passion projects that still need to gain traction that entreats the company to something worthwhile to the company [re: endpoint-shareholders]—mindshare, general confidence, whatever. Big corps often do what big corps do...
>At times they're passion projects that still need to gain traction that entreats the company to something worthwhile to the company
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.
Why should Facebook pay for that? If there are issues that are extremely costly to a bunch of outside teams maybe they should be the ones hiring people to fix their problems.
Because the overall health of the open source ecosystem around React and React Native depends upon the cost of development being somewhat predictable.
Most of the bugs in this category are inefficient for most teams to tackle because they get below the surface of the APIs and tooling. Not only is there (by design) no contract for how these things should work, but the appeal of React and React Native is that the developers and teams using them can be selectively ignorant about these things.
In life one must choose which things to devote energy into becoming expert in. These kinds of bugs tend to be show stoppers for teams impacted by them. It's a coincidence that Facebook itself has not been impacted, but someone needs to adopt a higher level view to realize these are very important issues which the maintainer should be addressing as top priority.
Facebook is a many billion dollar company and can surely afford to put a few more top engineers on the team to do this stuff. These things create major credibility issues for React Native supporters in their own orgs.
If Facebook decides to upgrade to a newer Babel library (for instance) and it creates a major issue with an open source library that is used by 30% of React Native projects, this warrants direct attention by Facebook.
If a RN update causes thousands of teams using RN to get failed builds, there should be someone at Facebook trying hard to reproduce the problem even if there is no obvious theoretical reason why it should have occurred and it is not impacting Facebook's builds.
React Native is a great project, but this stuff causes a tremendous amount of thrash and wasted time for the teams impacted. It could be much more efficiently dealt with by Facebook directly (and should be).
It looks like Microsoft is pursuing React Native as an alternative to Google's Flutter.
It may be strategic for them to take that role and hire folks to work on React Native, either a MS fork, or as part of a conjoined effort with Facebook.
FWIW I think you guys should put out a major call for help to other companies and add more non-FB people to the core committers.
React Native is fantastic, but the ecosystem is thrashed around horribly by these kinds of bugs and the non response from Facebook for things that impact most of the non-Facebook open source ecosystem around React Native.
Been actively wondering if there would be enough interest/momentum for a community LTS fork.
Love RN, and the daunting vastness of the surface area not lost on me, but would be totally ok with me if development stalled for 6 months of purely bug-fix releases. Maybe I'd sound differently if I cared about integration with native apps.
Can't understand how any internal team at Facebook tolerates the sloppy coding practices of the RN team. Is everything just technical debt to be ignored and left behind so the team can work on the latest shiniest feature?
I am a distant outsider to that company, I haven't used the platform in years and remain quite critical of it and many business practices especially regarding recent exposures (though I am a fan of their engineering they've released or open-sourced for the web)— yet I can understand somewhat how staff associated with such projects are not necessarily actively and regularly allocated to addressing those issues. At times they're passion projects that still need to gain traction that entreats the company to something worthwhile to the company [re: endpoint-shareholders]—mindshare, general confidence, whatever. Big corps often do what big corps do...