mikehardy
commented
5 years ago 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
brentvatne
jamonholmgren
kelset
Introduction
This is the successor of https://github.com/react-native-community/discussions-and-proposals/issues/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:
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:
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!