Sustainability in the React Native Community

[kelset]

Introduction

This is the successor of react-native-community/discussions-and-proposals#58. It was probably not the right place nor the right time, but lately I've been hearing more conversations around issues connected to this so I feel it's time to re-open the conversation for @react-native-community/maintainers to give their opinions.

This is a small extract from my personal experience being in RN & OSS for a year and a half, so please if you see something that doesn't sound correct/fair please comment below!

The core of it

Over the past few months we have seen a steady increase of maintainers and repositories in the React Native Community org (table), one of the main reasons being the Lean Core extractions, which has put some important components in the hands of the community. This required to bring the org itself to a more consistent state, that spawned repos like this one—and efforts like the one described in #40.

This also bubbled up how some repositories are actually not in a healthy state, for many different reasons. In talking with other maintainers some or all of these themes keep recurring:

• usually a person is the only one working on the repo (both code, issue triaging, etc)
• doesn't have free time to spare anymore
• there is a change in priorities
• doesn't have the drive to work on the repo anymore, because they stopped using it in prod

While these are all valid reasons to stop being actively involved in any open source project, there's usually some "negative concerns" that are part of the reason some people stop working on a project, without providing real closure or a "happy ending." We have currently have nothing in place to prevent this from happening again and again.

This is not a unique problem of the RNComm org, it's a systematic issue in the entire Open Source ecosystem. And these reasons are usually connected to the fact that this work is being done on top of a full time job, and usually involves little to zero compensation.

All of these interconnected issues are known to lead to overworking, mental health issues, and ultimately burnouts, which is something that we—as a community and an organisation and ultimately a group of people who care for each other—should try to avoid.

The big question

How can we ensure that the task of being a core contributor and a maintainer for a repository in this org is not a stressful and negative experience, while keeping said repository in a healthy state (code is up-to-date, issues are being handled, PRs are being merged, etc), given also their relevance for the broader community of React Native developers?

Discussion points & potential solutions

As you may imagine, this is a highly complex, multi-dimensional problem. I'll try to describe a few different aspects and/or different plans here:

1) Reduce the workload per person

This could be done by adding more maintainers in each repo. As mentioned above, a healthy repository would have, in an ideal world—just to mention a few points:

• code that is up-to-date with the latest RN releases
• issues that are being replied to and/or triaged
• PRs that are getting reviewed and merged
• changelogs and releases being pushed out, managed, and communicated well

This could also happen by integrating bots and CI/CD, which is something that we are already actively trying to work on (for instance, see #30.)

2) Introduce some org-level money influx

This means, most likely, to introduce an OpenCollective or something similar, that is managed at the level of the organisation, in which each repo would be a "subdivision" of the overall org. (I don't know the precise terms)

This would give companies using the repositories an easy way to "give back" via money, sponsorships, or donations; Consequently this enables maintainers to dedicate time more sustainably and consistently, or at least to get some acknowledgement and compensation for their work.

The main concern I have is that in other instances the collected funds couldn't be used to directly pay for any development work (see Roads and Bridges, pag 111). This issue kept coming up in discussions on this subject that I've had about this approach, which does reinforce my concerns.

Something along these lines is currently happening in react-native-camera, but I don't have any further details on the matter, (cc @sibelius would you like to give us some insights on how this is working out for you?)

3) Introduce some "personal" level money influx

We could assist maintainers to go down the road of direct sponsorships via services like Patreon, or, more recently, GitHub Sponsor.

This, also, would lead to a more sustainable way for some maintainers to being involved in OSS without dedicating all their free time, or at least without getting something in return for their time.

This approach doesn't suffer from the problem of having to divide donated funds amongst recipients fairly. But, at the same time, it may make it more difficult for some companies to donate due to the bureaucracy involved. It will also likely suffer from "organic" imbalance problems as developers would receive donations based on their visibility and reach.

4) Introduce more corporates / stakeholders

The core idea behind this fourth approach is for companies relying on React Native & React Native Community libraries to get more involved in sustaining them. There are two different approaches I could imagine working,

4a) a direct approach

This is best exemplified by some companies like Callstack or GoDaddy "adopting" some repositories. In doing so they allow the maintainers that are part of their workforce to be able to work on projects during their working hours. (At least that's my understanding of how it works. I may be wrong)

Another way would be for companies to directly put bounties on issues via services like IssueHunt or by publishing grants, similar to what Google did for web frameworks.

4b) an indirect approach

This category consists of companies that have special benefit programs or schemes that allow their employees to work on Open Source in a sustainable way with some amount of either time or compensation in return. For example, Formidable has a program called Sauce which pays employees for their time spent on Open Source outside of working hours. Futurice is running a similar program and has been for a while called Spice.

spinoff thread about good reasons why a company would want to become a stakeholder: #52

---

This is all I could think of on this subject. I probably forgot some things worth mentioning. Please contribute to this conversation, share your experience! I'd love to hear different opinions and more ideas on the matter!

[mikehardy]

In my experience 4a is the most aligned way - those are the repos that see the most love I think?, with an assist of every single other thing (templates with bots etc to force multiply every maintainer w/all collective knowledge and best practice - in progress, money etc).

Thinking towards how to reduce workload by increasing collaborators: I think sometimes it might just be maintainers not trained in asking for help or having the repo ready to accept it. Nearly every good starter issue should be met with a friendly “please propose a PR” response and the repo should have easy to run local tests so the person could actually do it and the PR would likely pass CI, then change should be easily releasable. This path is how to convert something that feels like a complaint (“your repo doesn’t do X”) to a possible fresh and motivated collaborator. Some repos are excellent at this

[xzilja]

On top of what @mikehardy said, I still believe that work we are doing in template repository should help (I'll jump back on it after my holiday). Idea is to make each repository in the org as consistent as possible, thus reducing barrier of entry for maintainers of other community repos.

Hopefully this will allow for some extra helping hands across the org. 4a, is a great approach and we should 100% discuss how to approach more companies and ask them for help.

And of course, automation wherever possible.

For me personally, hardest thing at the moment is to find enough free time to actually work on all of these and coordinate changes with all maintainers (as it will take their time as well).

[brentvatne]

Another alternative I see is to reduce the scope of what community volunteers maintain. Now that the APIs from the Expo SDK can be used in any React Native project, if there is an appetite for it we can collapse the redundant modules into the Expo SDK.

Benefits

• There are people at Expo & Software Mansion who are paid to work on the SDK
• Brings greater consistency to modules
• Can use Snack to share reproducible examples
• Everything is written in TypeScript
• CI with E2E integration testing already set up (https://github.com/expo/expo/blob/master/apps/test-suite)
• Less duplication of effort
• Focus on code quality and stability

Downsides

• Currently, installing packages from the SDK require react-native-unimodules. We'd like to push as much of this as possible into core, in particular having an agreed upon dependency injection system that allows modules to depend on others
• It's difficult to get everyone to agree on conventions and it's likely that some people may not like the conventions used in the SDK, eg: functions that return promises all have the Async suffix, like methodNameAsync
• Harder to contribute to because the SDK lives in a monorepo (https://github.com/expo/expo/tree/master/packages) and the unimodules API rather than the React Native plugin API directly. Also, there are a couple of factors that need to be considered for inclusion in the client: scoping and versioning (can go more into detail on these if needed)
• Expo (and potentially another partner on the SDK in the future) has the last say on changes
• Focus on code quality and stability means slower feature release cadence

---

I'd be wary to suggest that larger and less complete (in the sense of there still being lots of work to do) modules like camera (originally forked from expo-camera) and video should move out from the community to the Expo SDK because remaining as community packages gives them more flexibility to iterate and experiment with new features and so on. Other APIs like file system, image picker, media library (basically like the camera roll API but more complete) that are more narrow in scope could be easier to do.

[jamonholmgren]

Having Expo maintain more modules, which could potentially pay for the cost of maintaining the modules via commercial services and products, does seem like a reasonable path forward to me. It would be interesting to explore this possibility more.

[kelset]

Thanks everyone for commenting!

It seems that the approach 4 is the most "interested one" and I think that the Expo road would highly benefit the ecosystem too but probably there will be a transition phase involved.

Related to getting more companies involved, I opened a dedicated spin off issue: after I gave the talk at ChainReact quite a few people asked me for a "playbook" or set of guidelines/selling points on how to convince their managers & colleagues on that -> #52

[kelset]

Hey folks, I'm going to close this issue. I should have probably closed it off once I stopped being an owner of the org and while some conversation around this happened I feel that given the "0 executive power" of these conversations it's better to just close them off - so not to give the misleading signal that something is currently being done on my side (or by anyone tbh) around it.

If and when this topic will get picked up again it's much healthier for whoever will actually handle it to just open a new issue. I'm not against the new issue picking up this same conversation, even copy/pasting stuff from here - but I want to close the ones opened up by me off.