Recently I had a really long battle upgrading thereact-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 thatno longer support the latestreact-native versions and there are replacement packages thatmight 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 usingts-mockito to mock with type safety inTypeScript, you might have realized that there are no more releases. The maintainerinexplicably 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 fromts-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 ofabandonware is a dependency of a dependency of a dependency that introduces a critical vulnerability.

Let's have a look atreact-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 isreact-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 thevm2 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

Whenyarn shipped its boldv2, 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 toyarn-berry and failed. I realized that for our simple cases the performance improvements thatyarn-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 usedyarn and was just hoping forv1 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 ifyou have legacy code andyou're not willing to upgrade, but there's no reason whywe 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 allyarn based repositories at the company withnpm. 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 madeyarn into a niche package.

The Tech Enthusiastic Maintainer

A spin on theVolunteer 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 mentionedreact-native upgrade at the top of the article. While I was trying to replace the deprecatedreact-native-camera module, I tried using the preferred successorreact-native-vision-camera module. But there's a problem: we depend on QR code reading capabilities andv2 ofvision-camera does not work on latest react-native whilev3 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 Idemand 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 ofreact-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 aconsistent 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.