Why writing this, and why now? In January 2018 I started my journey as a maintainer of the React Native (RN) open source repo — it is the longest role I’ve ever kept going in my professional career, in a way — and I think now, at the 4 years mark, it is a very good time for me to pause, and force myself to think about how things have changed since then.
How did I become a maintainer? After a big burnout with react-navigation that led me to learn how to correctly interact with Open Source Software (OSS), I was starting to interact with OSS again by being a good citizen in the RN repository. Seeing me constantly in the issue section, trying to help out, led some Facebook (FB) engineers to decide to ask me to join the OSS repo with write access, so that I could be more proactive in helping its maintenance… and here we are.
Even so, I was never an employee for Facebook/Meta — so I was never fully part of RN’s core decision-making, nor its roadmap planning. So please keep it in mind: these are all personal takes.
I’m not a massive fan of super long reads, so to make this section more digestible I’m going to split it into topics and give some quick then/now overviews.
If you are interested in having me expand on something, do let me know (comments, tweets, DMs, emails… pick your poison).
Where everything started: 4 years ago, that’s where you’d find me — commenting on stuff, trying to help out in any way I could, figuring out how to address certain bugs or questions, or close duplicates etc. Now, I very rarely go and comment on issues — for one thing that has not changed in all these years (and most OSS projects are likely in the same boat IMO) is the very poor quality of most of the issues that get opened. Poor quality + constant flow of new ones is very off putting, and even some more structured attempts at tackling them have come and gone, unable to create a new normality that would ensure that only valid issues would be active. Bots nor templates didn’t ever help much in that sense.
The main area where I’ve been involved in these years — my first ever release was a patch for 0.57 (0.57.3 to be precise), we are now at 0.67.2 and 0.68 is undergoing its Release Candidate (RC) phase. Back then, it was all community-led, literally just a few scripts, and very, very little written knowledge. Mostly you’d learn by pairing up, and even in terms of communications to the users, only the very basics were in place. Now, on top of the changelog, we have release notes, a wiki with all the steps in detail, defined release roles and there’s a dedicated group of testers that help ensure that things go smoothly. And let’s not forget the upgrade-helper! I’m overall happy with the “growth” of this aspect of the project — but things can and should still improve more.
If I could take myself back 4 years, and ask old-me “how do you think React Native will be in the future?” his answer and the current state of this technology would be far apart. While there have been some good improvements (such as auto-linking or Hermes) I kind-of find it underwhelming how little react-native has changed. I guess that it’s mostly caused by the new architecture taking a long time to roll out, and my naivete in how long four years are when talking about the evolution of software (in particular when there's a global pandemic going around). Even reactjs itself hasn’t changed much, no? The last big change was hooks, at least in my mind. In a year, probably, both RN and React will be very different thanks to the new architecture and React 18. But, at the time of writing, this has not happened yet.
This is probably the hardest topic for me to draw a comparison on. If I look back at 2018, at the number of different folks involved from all around the community (and companies), and the vibrancy I could feel being around such a good variety of engineers… and look at it now, it’s night and day. I see way less members of the community actively involved, way less folks in the “core contributors” discord participating. I can’t help but feel a general sense of dread that this project has been “bleeding out” contributors. If I had to list the main folks that were active then, and see how many are still around, it’d be very very telling. Nothing against anyone: people in tech move fast in their careers, and in four years even life changes enough that your priorities shift (global pandemic, anyone?). What scares me is that there has not been a comparable set of folks hopping in. I think that one easy way for me to “show” why this might be the case (IMHO), is to show you the “Community” page of the React Native docs and the Flutter one (or glance over at Rust). The difference in, to put simply, “care” for this part of the OSS project is astonishing. Unsurprisingly, if you don’t water a plant, it dies.
Becoming an OSS maintainer for react-native made me want to learn more about the space, and how things worked in other tech silos. What I quickly picked up is that pretty much all maintainers feel equally miserable — and that they rarely have chances to talk to each other, aside from big confs like GitHub Universe or similar. These occasions are super good in learning new ways to deal with common issues, and share stories. That led me to try and set up a small local meetup in London for OSS maintainers (called “Provided As Is”), and I feel we were doing something good — then Covid hit, and the meetup came to a halt for obvious reasons. Covid, I fear, made many OSS communities smaller because folks that were active in them might have been too stressed/overwhelmed to have time to dedicate to it.
I wanted to spare a quick section for GitHub as a platform because, from an OSS perspective, it has improved a LOT over these last few years and I feel it deserved a shoutout. Way more controls over repos, the templates, GitHub Actions, Discussions, Sponsors… They did a lot of good things for OSS maintainers. There is still work to do I’m sure, but starting an OSS today is way more manageable and empowering, I feel.
Slightly before January 2018 is when I started going to therapy. This has been, without a doubt, one of the most impactful things I’ve ever done in my life — and they helped me navigate being an OSS maintainer. Being involved in this project hasn’t always been fun. I’ve burned out once and, on at least a couple occasions, I was really really close to “sunset React Native” from my personal/oss life. Learning to take care of myself, and listening to where the feeling of pain was coming from, were instrumental in balancing doing Open Source on top of my day job. One of the most successful approaches I’ve been using is “focus on what you can control”: in doing so, even if certain aspects of the project were not going in the direction I wanted, I have been able to stick around and still help how I could. Quick example: I can’t single-handedly change how this community is managed, but I can help the releases get better. Another approach is the ability to create and respect boundaries — this is another one that is easy to explain: if you check my Github profile you’ll see how every Sat & Sun are completely white. (if you are interested in this topic, I’ve made a page with resources about this that I hope you’ll find useful - please, do take care of your mental health )
This is probably the area in which most readers might be assuming “wrongly” the most. Did OSS help with my career progression? Honestly, not much. It mostly put me in situations in which I had to try and justify and explain to my management chain why and how it was important that I was doing it — and usually the outcome would be that I’d have only my personal free time to dedicate to it. Since I’ve joined Microsoft things have changed, but not by much right away — I still had to undergo an internal team change (after a year in the company) to get in a role under a chain of command that values it enough to give me almost free rein. I feel very fortunate to be where I am today, but think about it: would you commit 4 years of your time for something that still puts you in a very, very specific box which is kind of hard to get out of? All my focus on react-native gave me some very specific insights into this tech — and being in its OSS sphere allowed me to chat with a lot of very smart people and learn by being around them. But if I used all this time for personal gain, do content on socials and learn enough web dev to look skilled, I’d be probably just sitting on some huge payroll for some fincorp. Not a single job opportunity fell into my lap from any of the companies I was interacting with day in, day out (even with MSFT, I was the one who initiated the conversation). I’m not saying it in a rant/grunty way — I’m happy where I am right now — but mostly to rip a bit to shred this idea that doing OSS will transform you into some “insta-hire” for all the companies you dream of. I mean, if it happened to you, great, but for most folks, please don’t go into OSS with that as your ultimate goal — I’m saying it for both your and the OSS project’s health.
In preparing this blogpost, I asked on twitter for questions about these past 4 years — I decided to include them in their entirety here. Hopefully these will cover all the angles I left out in the section above :)
“do you have some kind of stats for issues? how much of them are really helpful? what is a ratio of questions to real bug issues? etc…”
Not really any stats, sorry. I mean, I guess you could try to do some inference by playing with labels and open/closed issues on the repo itself. Anecdotally, I would probably say that on average out of 5 issues I’d read any day, 3 would be an insta-close for me, 1 would need a lot of hand-holding and only 1 would be actually useful. (see also the dedicated section above)
“i think some people we worked with already know, but i was always curious about the way the different partners worked together (or not..), the way RN Community crumbled, and what it’s like now working for one of those partners — to me it kind of just feels like RN OSS “lost steam” within FB (from 2016 vs. 2021) and other partners came in to pick up that slack, but sometimes FB would only cooperate if it made sense for the internal version of RN”
A very loaded question ahah — let me start from the bottom up. I have the opposite feeling about Facebook(/Meta) engagement with RN and its OSS: for one, they are now the main drivers for the releases, and they have been way more active in the issue section. It’s true that their goal is always to focus on their internal needs, but they have been more active listeners. About the “Partners”, I’ll be very straightforward: I think that, in execution, the “Partners” idea was the one of the worst things that has ever happened to the React Native ecosystem. And the only decision that was ever taken by that “organ” was to yeet out repositories from the RN Community github org, and everyone (Microsoft included) is still paying the short-sightedness of that decision. (I’ll reply about the working for MS further down)
“Any/all thoughts on encouraging meaningful contribution from users. Sytems/processes that help (automation) plus anything on the human/soft side as well (delegating repo access quickly, or not, anything you can think of).”
This is a hard one, TBH. If you are someone who wants to do a meaningful contribution, I have mostly 3 suggestions:
- Don’t get scared by the size of the repo. It’s that big because there’s a lot of different things going on but you won’t have to interact with all of them
- Contribute something that is meaningful TO YOU: if you are not getting any advantages from it, it’s not worth it. It could be that it’s going to take a while to get it in, so make sure that you’re able to use your fork for your project in the meantime
- Try to reach out to some of the engineers (maybe in the GH comments?) that can help you/guide you/mentor you in helping them get the PR in a shape that they can more easily get merged. (see further down for more)
In terms of processes/automations, aside from making the test suite way more comprehensive and reliable (which is in itself a meaningful contribution) I can’t really think of much.
“how do you think about the release cycle? e.g. some good or bad between "regular release" and "feature meaningful release".”
We are entering a phase of a 2-months release cycle. I think it’s going to help Facebook get to where they want RN OSS to get, but I’m very concerned that the community will not be able to keep up the speed. It’s a hard problem and I’ve spent months trying to find alternatives, fallbacks… but the more I try to find a solution, the less I am convinced that there’s any good one: there are some inherent constraints given by the fact that React Native is used so differently within Meta vs outside.
I don’t think it’s really a competition. One uses Javascript, the other one Dart. It’s really that simple, from my perspective. It'd be much more meaningful to think how Electron and React Native compare. That said, I am inspired (and very jealous) of how well Google is pushing behind the project, and the type of fundings that is provided for non-code things. So if, by any chance, any core Flutter engineer is reading this and wants to DM me how they managed to convince their higher-ups to give them so much funding, I’d be very very interested in learning.
Honestly, no. There are going to be very few roles in which that extra C++ knowledge will be actually needed. So, if you find yourself learning it for doing something React Native, make sure to pause one second and make sure that’s really the way to go to solve that problem.
“I'm thinking of how do your role, goals, responsibility and sustainability as an OSS maintainer have changed since you joined Microsoft”
Joining Microsoft has mostly shifted the weight I carry in meetings about RN OSS with other companies. There’s an extra layer of responsibility, sure, but it’s good to feel like I’m finally getting really heard (before, it was kind of hit-or-miss). In terms of responsibilities and sustainability, what I’ve found in Microsoft are folks who trust me and understand the needs of the company when it comes to React Native. And that allowed me to negotiate time in my working hours to dedicate to React Native itself; but it wasn’t automatic: there were literal negotiations. From my end, this has meant that whenever I’m involved in any conversation about React Native with other stakeholders like Facebook I have to keep in mind what our internal projects are, what are the needs of the things we maintain (ex. React Native for desktop), and be a bridge between internal engineers and external contributors.
“What would it take to get PRs from the community that fix things or add awesome features merged quicker ?”
Sadly, because of the way the React Native OSS repo is set up, it all boils down to Facebook engineers having time during their working hours to do it (what in big-corp is usually referred to as “funding”, I’ve used that term a few times around this post). Any PR, to be merged, needs to have someone from the FB engineering side to review it and pull it into their monorepo. At this point in time, there’s no way around it. Funny story actually: back in the early days certain external contributors could trigger a command to import to the internal monorepo via a GH comment on the PR — it was, correctly, switched off.
Despite everything, I think that React Native’s best times are still ahead. They are not here but, most likely, a couple years out: once the new architecture is fully rolled out, and there has been enough time for the ecosystem to catch up. At that point I believe that React Native will become the most used way of doing cross-platform development: it’s just too convenient. That is, of course, unless certain players in the ecosystem will fuck things up royally — and, sadly, I can’t exclude that option.
Personally, I will still be involved going forward: I’ve managed over the years to get in a position where it’s literally part of my work responsibilities to do this maintenance and being involved in React Native’s future’s conversations. Microsoft sees value in me being able to do that, and I feel both gratitude and the responsibility of doing my best. I’ve been trying to reduce the bus factor that I present by trying to open up doors for other folks to hop in, and that’s still one of my goals.
To some of you, this retro might sound bittersweet if not even negative about the state of React Native today.
One of my goals with this post is to not hide any actual problems that I feel are in the ecosystem; I hope that this will inspire conversations within and between companies that are heavily invested in the technology. And some of the things I’ve pointed out can also be seen as opportunities for individual folks to hop in and take the reins: there’s a lot of untapped potential, it just needs a little push.
Overall, from here, I’ll just keep focusing on the things that I can control, and learn and improve and morph.
Either way, the next four years are going to be interesting. See you then?
Massive thanks to Phil Pluckthun, Tasveer Singh and Kadi Kraman for their feedback and helping this blogpost become reality. Thanks also to everyone who submitted their questions, I hope the answers live up to expectations.
Thanks for your hard work. Your story and experiences are invaluable. Thanks for sharing them @kelset