Recently I had a really long battle upgrading the react-native version for a mobile applications.

Typically, updating packages involves reading a bit of annoyingly vague documentation, sifting through issues and Stack Overflow answers. It's sometimes annoying, sometimes feels good in a way, akin to popping bubble wrap.

However, this year, this upgrade became a long drawn out battle and we are still in "waiting mode" as there are packages that no longer support the latest react-native versions and there are replacement packages that might be feature-complete soonish.

Therefore we are stuck in the middle. But how did this happen, what's the reason?

The Open Source Experiment Might Be Reaching Its Conclusion

Sorry for the "click-baitish" title for this section. I made a list of the biggest frustrations, and then I am trying to justify my title selection.

The Abandonware

If you had been using ts-mockito to mock with type safety in TypeScript, you might have realized that there are no more releases. The maintainer inexplicably disappeared.

While I'm thankful for all the efforts on the original project, and especially to :Lxxx and :jxxx in fixing up the fork with some great collaboration last year, our team have decided to move away from ts-mockito entirely. The pain caused with the Typescript update last year was far too much of a burden to want to repeat, especially in an enterprise scenario.

In fact, as a result of all that, we ended up introducing new processes (both automated and manual) to ensure we don't get bitten by consuming poorly maintained packages in future.

So even though people are forking the original project and merging pull requests, there's a friction where people no longer interested in the original package anymore.

Critical Vulnerabilities Never Gets Fixed

Another side of abandonware is a dependency of a dependency of a dependency that introduces a critical vulnerability.

Let's have a look at react-native-code-push:

https://github.com/microsoft/react-native-code-push/issues/2542

So we have a critical vulnerability because...

the chain of dependencies that leads to vm2 being present in the app is react-native-code-push -> code-push -> superagent-proxy -> proxy-agent -> pac-proxy-agent -> pac-resolver -> degenerator -> vm2

That's pretty bad, so naturally you descend down the chain, only to find that the vm2 package had some "unfixable" problems and now it is also deprecated:

The library contains critical security issues and should not be used for production! The maintenance of the project has been discontinued. Consider migrating your code to isolated-vm.

Source: https://github.com/patriksimek/vm2#readme

The Volunteer Job

When yarn shipped its bold v2, they kinda decided on their own, that everyone should follow they way; regardless if you had the same problem or not. I have tried myself switching a project to yarn-berry and failed. I realized that for our simple cases the performance improvements that yarn-berry could bring would not justify weeks of hunting compatible replacement packages, or shipping our own code to replace ones that won't be converted.

Naturally, I was not the only person who used yarn and was just hoping for v1 to be maintained: https://github.com/yarnpkg/yarn/issues/8583#issuecomment-784017423

You have to understand we're a team of volunteers. It's too bad if you have legacy code and you're not willing to upgrade, but there's no reason why we should maintain a codebase we've already fully rewritten more than a year ago because of its numerous issues. Your problems are likely fixed already, why should we duplicate our (volunteer) work just for your project? I'd very much prefer to spend this time with my family.

(I have left in the last sentence for a reason from this quote, I'll come back to it soon).

Reading this, I have decided I'm going to systematically replace all yarn based repositories at the company with npm. It works, it is fast, it warns me about security issues. For the collaborator who wrote this: I totally understand and it is a good decision not to wear themselves thin. However, this decision made yarn into a niche package.

The Tech Enthusiastic Maintainer

A spin on the Volunteer Job is the person who is doing an open source project for technical curiosity, or bit of internet fame. This requires a very-very special personality (and probably family configuration), and as such, cannot be maintainable on the long term.

The danger here is shiny, exciting features arrive one after the other, while boring, but very necessary features are, well, maybe later. Or never.

I have mentioned react-native upgrade at the top of the article. While I was trying to replace the deprecated react-native-camera module, I tried using the preferred successor react-native-vision-camera module. But there's a problem: we depend on QR code reading capabilities and v2 of vision-camera does not work on latest react-native while v3 might have the QR code reading... maybe later:

The most interesting part for me is pushing boundaries of what's possible in React Native. I find joy in developing cutting edge technology such as a Tensorflow plugin that runs in JS but is still as fast as native - this is fun to work on. [...] V3 is also about stability and we will get there, but first I focus on new features. Then comes stability, code cleanup and more, and finally after everything is done, I will add a small QR code scanner plugin as a first-class citizen to VisionCamera.

How frustrating! We are locked in an intermediary version because of this.

But also, how can I demand anything from a volunteer? That's just plain silly! He's got every right to do whatever he wants with his own experimental repository.

Running Out of Energy

I just quote the former maintainer of a great state management handler:

There is a dark side to doing open source, at least for me. Even though it is a recipe for learning I have also been spending most of my time lost in thought. Thinking about ideas, issues and craving recognition for the stuff that I share. It is not a healthy way to live your life. [...] The cost/benefit was okay for a long time as the only people who were affected by it was my partner and myself, but now with 2 kids I have to stop...

If you talk with a psychologist, psychiatrist, neurologist, etc. they will all tell you the same: you need regular and ample rest to do your work well, to be productive. Your brain can't really distinguish between coding for work and coding for hobby.

Only psychopath CEOs push their employees to work extreme long hours, who don't really care about real productivity, only about the illusion of it.

This extreme unproductive productivity and "grindset" normalized self-exploitation, but it comes a cost and a debt that some people already started to pay back.

Quality Must be Paid For

I hope now that I at least implanted the though in your brain that the open source ecosystem faces the very same problems as all volunteer work based systems: things that do not provide a stable incoming for maintaining or improving your life are not going to be consistently maintained.

That's basic human psychology. We must not get angry at a person who did a project in college that become wildly used and now they have other priorities. That's not how life works! Family and mental health must come before work as if you don't have those first two, you won't be able to get the job done as well. We also can't depend on magic, goldilocks, one of a kind people, because that's just foolish. What if tomorrow the main contributor of react-native-vision-camera gets distracted and run over by an oversized SUV? We just wait another year to upgrade our project?

We don't sign a contract with any of the contributors of an open source supply chain that they will fix critical security vulnerabilities, or adapt their codebase for breaking changes of another package.

If we want one, e need to find a consistent and dependable way of rewarding the people who enable so many projects to focus solely on business requirements and not on basics. It made us incredibly productive, it made tiny coding workshops being able to deliver professional value, but it also created new classes of vulnerabilities.