React-native-community & React-community: let's talk about them

[kelset]

Introduction

With this discussion, I want to tackle a long lasting conversation that, like a wave, comes and goes in the chats of the React Native Contributors channels.

Historically, as umbrella organisations for react-native projects, there have been for a long time two entities:

• React Native Community
• React Community

And the conversations happened lately seemed to suggest that now there is no more the need for these two to be split.

(one of the main inspirations for me to write this was @brentvatne's talk at ChainConf 2017)

The Core of It

Since I started using React Native, I become more aware of how much developers rely on third party packages to quickly insert new functionalities in their projects (given most of them come from a Web background where this is the approach*).

While a portion of those are hosted in repositories owned by the single person, a few of the 'most used' were instead in React Community or React Native Community. The fact that these two orgs coexisted was always a bit confusing to me, and also created the doubt of a scattered community and a bit of a 'bias' towards one or the other (ex. "oh well if it's hosted on XXX it's better").

Over the past 6-8 months, the React Native Community organisation has become a de-facto "officially endorsed by FB" hosting components from The Slimmening (ex. WebView) and with this very repo and the releases one I become more aware of how much the community is a shaping force in the evolution of React Native.

But this is still history-in-the-making, and I strongly feel that we need to take this chance to resolve this duality, and by doing so establish some structure to it so that everyone can benefit from a trustful place to get involved.

I believe that, similarly to projects like Flutter or Ionic (IIRC), the whole React Native community would benefit from an org that, by enforcing a set of standards for all the packages/repos hosted in it and providing a common place for all the maintainers to help each other, provides quality code for everyone and set the example for everyone in the community.

In conclusion, here's what I'd like to see happen:

1. We write a manifesto to enforce in the React Native Community - we could use the Ocaml community one as starting point (this could happen via a proposal PR in this repo) **
2. We move the repos from React Community into React Native Community
3. When a repo joins the RNCommunity, the maintainer will join the React Native Contributors Discord and we will help them to make sure that the repo is in line with the others/the manifesto
4. Once the migration is done we publish a blogpost in the React Native website to increase awareness

Discussion points

1. Is everyone ok with this happening?
2. What do you think of the manifesto proposal? What should be in it?
3. What happens if a maintainer wants to stop? Or a repo stops following the manifesto?
4. Who owns the npm permissions to publish each pack?
   (this is also related to trying to avoid situations like the bitcoin miner last month using an OSS repo as vector of attack)
5. Is there any way we could make this compatible with sponsorships/making it profitable in some ways to create sustainable ways for people to work on their OSS repos? (related issue)

---

* on the other hand, mobile devs expect more of a 'all in one' solution

** this whole process would also automatically effect the Slimmening repos, for which there has been talks of creating some guidelines but nothing has been done yet - so yeah we can merge the efforts

[kelset]

given the nature of the discussion, I'm tagging here all the people in the two orgs to make sure that they are aware of it:

@anp @brentvatne @felipecsl @ide @jimmylee @kmagiera @osdnk @skevy @tsapeta @axe-fb
@bestander @binoy14 @dabit3 @DanielMSchmidt @dustinsavery @empyrical @empyrical @GantMan @grabbou @hramos @ivanzotov @jamonholmgren @JHabdas @knowbody @Kureev @magicismight @mattapperson @mmazzarolo @Monte9 @n1ru4l @oblador @satya164 @sibelius @Titozzz @turnrye @zoontek

(sorry in advance if you are not involved anymore 😅 - you can always unsubscribe from the right panel)

[jamonholmgren]

This all looks quite good to me and it seems to make sense to combine efforts.

I do have one question and a comment:

1. What happens when a package is supposed to be both React and React Native? I believe React navigation was supposed to be both, although few use it on web
2. “...the maintainer will join the React Native Contributors Discord and we will help him to...” replace “him” with “them” here.

[mmazzarolo]

Thanks for starting the discussion and providing a nice recap.

What do you think of the manifesto proposal? What should be in it?

That's, great. I think the Ocaml manifesto is a great starting point.

What happens if a maintainer wants to stop?

Just my 2 cents.
Unfortunately I don't think there's a safe solution for this issue but I have a feeling that it might be prevented by keeping the library as simple as possible: it should just provide good primitives that could be extended by other external libraries.
Constantly adding new features is the best way to ask for open issues and more complexities in the long run.
The maintainer should feel ok in (politely) closing PRs that adds new features if he thinks they're not really useful.

The smaller/simpler the library is, the easier you'll find contributors/maintainers (IMO).

[Titozzz]

Quick intro just in case, I'm the main contributor to the react-native-webview repository, so I already encountered most of these issues 😄

Is everyone ok with this happening?

I think it would be really bad not to step up and do this. Enforcing clear rules will help new contributors on every project to have clear rules and will show that we really care about their inputs / contributions.

What do you think of the manifesto proposal? What should be in it?

I've just read the OCaml manifesto and I really like the contents / ideas inside it. Most of what inside would be completely applicable for us.

What happens if a maintainer wants to stop? Or a repo stops following the manifesto?

I think it is okay that some people won't want to follow the manifesto to the letter. However if a repository does not want to follow the rules, I think it should not stay in the community as it need to be easy for anyone to trust and contribute to the community repositories. (However if anyone does not want to follow the rules and have good reasons we might want to update the rules, let's not close our minds to anything different)

Who owns the npm permissions to publish each pack?
(this is also related to trying to avoid situations like the bitcoin miner last month using an OSS repo as vector of attack)

I'm no expert on that, but for now for the webview I've created a npm user react-native-community-bot that does all the publishing for me

Is there any way we could make this compatible with sponsorships/making it profitable in some ways to create sustainable ways for people to work on their OSS repos? (related issue)

This is something that could help have a healthier community but I guess we need to be careful on the how/why/when !

[anp]

I'm no longer working at Expo and so I don't have any time carved out for RN stuff anymore, but I'd like to quickly express support for the general direction here. We created react-community initially to have a dedicated place for the CRNA collab, a project that's now no longer being developed. We had a very permissive policy for adding repos there -- react-native-maps for example didn't have any up front coordination before the transfer between various admins and that was totally OK. It seems to me that in the absence of CRNA the react-community org doesn't have any governance model nor any businesses with active stake in its maintenance. Seems like a no-brainer to firm this up and clarify governance and responsibilities.

[jamonholmgren]

To support what @Titozzz said (as another react-native-webview maintainer), I think it's a very good idea to set up continuous integration and continuous deployment using semantic-release as we've done. That way, maintainers only have to squash & merge with a simple commit message prefix to release new versions.

I've created a guide for my own company here: https://github.com/infinitered/open-source/blob/master/Continuous-Deployment-Setup-NPM.md

This should help you started on CircleCI, which I do recommend.

[n1ru4l]

@jamonholmgren We did also setup semantic-release for react-native-camera and I can definitely recommend it!

Also there are many great react-native libraries that are not updated any more and I would love to see instructions on how to migrate those to react-native-community/react-community!

[grabbou]

This issue makes me really excited!

Historically, I think it was super confusing for the developers what community was the "official one". Over time, I developed the conclusion that React was the "official" one (as lead by Expo in collaboration with React Native team members) whereas React Native Community was the one run by the community.

I am really happy that it became much more than just a place for projects, with RFC and Releases repositories being meta-projects for the community.

I think the plan presented in the first issue is good - we need a manifesto and some simple governance guidelines. I think this is really important first step. This organisation is going to be the central place for the community, which is going to take the momentum now.

Answering your questions:

Is everyone ok with this happening?

Yup

What do you think of the manifesto proposal? What should be in it?

I like the ocaml-community manifesto, nothing additional comes to my mind.

What happens if a maintainer wants to stop? Or a repo stops following the manifesto?

In my understanding, when project is transferred to this organisation and becomes developed under React Native Community, its ownership is also shared with the members of this organisation. When a lead maintainer (aka product owner) wants to stop, he should follow the process (that we develop) of transferring this over to someone else within the RN Community. It is similar to what you would usually do when one of your employees leaves and there's work left that has to be taken.

If the repository stops following the manifesto, we should first check why it happens. I would be sceptical about removing projects from the community. Transferring ownership and the project would be similar to what happened recently with event-stream.

We could replace the lead maintainer or/and put someone else from the RN Community to look after the project and to make sure it's back on the right track.

Who owns the npm permissions to publish each pack?

As I said in the previous post, transferring project here also shares the ownership with the RN Community. Having a single npm account (aka bot) that does publishing from CircleCI just like React Native does it's releases would be a good idea.

Is there any way we could make this compatible with sponsorships/making it profitable in some ways to create sustainable ways for people to work on their OSS repos? (related issue)

Look at Hapi.js community - some of the projects that are part of their Github organisation have a sponsor (there's a banner) and what they also do, which is great, is that each release is sponsored by a different company. Could be useful to get some funds into making change-logs and releases.

[matt-oakes]

I think this would be a massive boon to the community and could help solve some of the issues where libraries are abandoned by authors and are left without a maintainer.

Is there currently any information about how to ask for a project to be transferred into react-native-community (or whichever organisation ends up being used)?

I have recently taken over maintainership of the previously abandoned react-native-location and I would be interested in putting it under the community organisation.

[DanielMSchmidt]

I agree with all being said, sounds like a wonderful idea. The only little detail I would like to add is that I think it would make a lot of sense to clarify what a project needs to fulfill and what a maintainer needs to so that it can enter this organization. (For example, I think react-native-sensors might be a good fit technically as it lays a foundation, but the ProBot that auto-adds contributors to get push access might be not fitted for this organization. Thank you @kelset for picking up the discussion 👍

[kelset]

Hey everyone, thanks for the positive feedback so far ❤️
I think that before doing any further step we should wait around 5 days to give the everyone I tagged a fair chance to speak their mind :)

In the meantime, to keep the ball rolling:

What happens when a package is supposed to be both React and React Native? I believe React navigation was supposed to be both, although few use it on web

I think it's an edge case - like, navigation is its own org - but tbh I don't see any issues with components that also work on Web, but ofc we should at least expect proper RN support first.

---

Unfortunately I don't think there's a safe solution for this issue but I have a feeling that it might be prevented by keeping the library as simple as possible: it should just provide good primitives that could be extended by other external libraries.

Matteo, as Mike wrote a bit after, there are actually ways, and also there is also the option of archiving a repo if we can't migrate it to the latest 'lead maintainer'.

---

I think it's a very good idea to set up continuous integration and continuous deployment using semantic-release as we've done. That way, maintainers only have to squash & merge with a simple commit message prefix to release new versions.

Absolutely! We should have the same setup for all the repos (or at least an how to) for how to handle releases, how to handle issues, changelogs...

---

Is there currently any information about how to ask for a project to be transferred into react-native-community (or whichever organisation ends up being used)?

The only little detail I would like to add is that I think it would make a lot of sense to clarify what a project needs to fulfill and what a maintainer needs to so that it can enter this organization.

This is precisely what we'd like to produce along the manifesto I think, so yeah atm there are no fixed rules but until we write them down feel free to suggest anything around them :)

[zoontek]

Sorry for the late answer, I'm the creator and maintainer of react-native-languages, and a collaborator on react-native-permissions (which is quite abandoned right now, because I lack time)

I think merging the two organisations under react-native-community is the right move. We need a list of strong and maintained packages (possibly a simple website, with search).
The manifesto is also a great idea.

Some points:

• RN APIs continue to change way too much. Keeping track of needed modifications on our libs is painful, and often the last version of the lib only work with the last X versions of RN. I have big hopes in Fabric, maybe we will finally have a stable way to create quality bindings.
• I support @mmazzarolo: libs should be as simple as possible. Just keeping a thin layer of abstraction over the systems should be our ultimate goal. The JS ecosystem will do the rest.

Also, I would like to put react-native-permissions under the organisation (if @yonahforst agrees), and work on a v2 based on PermissionAndroid API for the android part (I guess it will not stay in the core)

[cpojer]

This all sounds really good, do it, make it happen, let us know what you need help with :)

[kesha-antonov]

Great idea! Recently I couldn’t find good repo for audio. Found one. But owners don’t maintain it and not answer.

[brentvatne]

perhaps we should close this issue since react-community is basically empty now? just two archived repos

[kelset]

Yeah I guess we can progress this conversation on the PR with the draft of the manifesto (still in my TODO list 😅)

[ghost]

SGTM. I've moved on to Hugo and Vue. 👋 @brentvatne