This blog post is part of a series of blog posts, which aims to shed some light and share from our experience working with React Native at Wix.

Since the moment we embarked on our journey with React Native, back in early 2016, we were immediately fascinated by the concept of Open Source Software (OSS). React Native (an open source software in itself) brought a novel take on mobile development and opened our eyes to the benefits of open source; where developers from all over the world collaborate for the benefit of the entire community.

Our main mission at Wix is to empower small and medium sized businesses by giving them the tools to succeed in today’s competitive market. We felt open source complements our mission perfectly. By taking an active part in the open source community, we let smaller companies or individual developers gain free access to quality software helping them compete against the bigger players in the market.

As a young team that had just adopted React Native and was eager to contribute back to the community, we knew we wanted to contribute right from the start. Though, taking certain constraints into consideration, we had somewhat of a hard time deciding what we should open source, and how. After countless brainstorming sessions around this, one of our managers had come up with a brilliant idea — If open source is so beneficial, why don’t we open source everything that can be decoupled from our business logic? And that’s how we came to adopt an “open source by default” mentality.

The benefits of “open source by default”

As we began to use open source libraries extensively in our app, we noticed that our overall design has greatly improved. Developing with an “open source by default” mentality allowed us to visualize more clearly the boundaries between the components in our app. Thus, making Separation of Concerns, one of the principles of modern software engineering, an inherent part of our architecture.

Using OSS libraries to enforce boundaries and delineate responsibilities between components might seem like an overkill at first. After all, such boundaries can be achieved with less strict and time consuming measures. Folder structure and refactoring tools like extract method and extract class are great examples of this. By extracting pieces of code to dedicated files we can reuse them throughout our codebase, while keeping the origin code focused on a single concern.

So why use OSS libraries to enforce separation of concerns?

Handling concerns in dedicated libraries generally results in more flexible API’s and better abstractions. Since an OSS library can’t depend on the actual application, concerns from the application can’t leak to the library, ensuring the library is focused on addressing a single responsibility.

By orienting our team towards a modular approach to building mobile applications, we managed to write more extensible code early on which supported our scale in the years to come.

Another advantage of open sourcing parts of our codebase is that by doing so, we commit to a higher standard of code. Adequate tests coverage, well written documentation and readable code, are paramount to the success of an open source project. Maintaining a project without the former, in most cases, becomes increasingly difficult and regressions are bound to happen. If a project is buggy and of inferior quality, users will shy away from it and it is less likely to be adopted by the community.

Challenges

Not everything is rosy in the land of open source, and as we open sourced more code we eventually started encountering difficulties caused by our strategy.

Libraries are stand alone projects that require their own CI/CD and release process. When a bug fix or a feature involved a few transitive dependencies, we sometimes had to wait for multiple CI runs to complete before we could ship a fixed version. We realised that the structure we created, aimed at facilitating faster development and growth, sometimes got in the way of things and over complicated simple tasks.

As libraries are small scoped projects, their requirements don’t change much over time and as a result they are less frequently worked on. This means they are always prone to use outdated best practices and dependencies.

The Wix app has grown a lot over the years and upgrading the React Native version it uses is a carefully coordinated process involving developers from multiple teams. Having to upgrade a set of relatively outdated libraries, in addition to our app, turned the upgrade task into a tedious and time consuming ordeal.

But perhaps the biggest challenge we faced had nothing to do with code. Open source is all about being part of a community. Sharing meaningful projects with others to benefit from, giving and receiving and collaborating with developers from all over the world; These are just some of the things that made open source so appealing to us. Unfortunately they also require a huge time investment.

Open source projects require a lot of maintenance; Issue triaging, reproducing bug reports and implementing feature requests, are all time consuming tasks which are difficult to prioritise over our daily tasks on the Wix app.

Focusing on sustainable open source projects

It’s quite apparent by now that time management was our biggest challenge. More often than not, allocating time for open source did not align with the needs of our main product — the Wix app. If a bug report, a feature request or even a pull request, were not related to the Wix app, then they were usually overlooked and never addressed. Eventually we realized that some of our libraries were only open source by technicality. Sure, they were available freely to use and modify, but since we weren’t dedicating enough time for them they slowly became obsolete in the eyes of the community.

To improve the quality of our open source libraries we had to rethink our strategy. We realized that it’s not enough to open source code, it’s also essential to ensure these projects are actively maintained and supported in the long run.

As we sat down and assessed our most successful OSS projects we noticed they all had two things in common:

• Owned by an entire team. Teams tend to be more stable compared to individual developers. A team has a well defined long term vision and clear goals in mind. Developers on the other hand are more dynamic. Over time their interests are more likely to change, they might take on a new challenge in a different team or even move on to a different company.
  The bottom line is that projects owned by individuals are at a higher risk of abandonment as their maintainers continue to the next destination in their careers.
  Teams on the other hand are more stable since they are an inherent part of the organization’s structure. If ownership of an OSS project is part of a team’s mission and their success is directly coupled with it, then the project is guaranteed to have long term support.
• Infrastructure oriented. A man is only as good as his tools, and a product is only as good as its infrastructure. As a product grows and scales so does its infrastructure. An infrastructure project always needs to facilitate new requirements thus ensuring it’s actively supported and maintained.

To conclude, by open sourcing infrastructure projects that are maintained by a development team, we ensure they always remain in focus and are well maintained for both us at Wix and the community. Being able to accommodate for the community’s needs is what differentiates sustainable open source projects from projects that are simply developed in the open.

Sunsetting Open Source projects

The switch to sustainable OSS meant some difficult decisions were ahead of us. A few of our projects were pretty much abandoned, some were not even used by Wix anymore. As these projects were still in use by the community, we couldn’t simply shut them down and had to come up with more conscientious solutions.

Early on in our adventure with React Native, we open sourced quite a lot of components like autogrow-textinput, keyboard-aware-scrollview and keyboard-input to name a few. We’re still using these libraries in our app, but as standalone libraries they’ve stopped getting the attention they deserve. Since we put a lot of love and effort into these libraries, seeing the issues and PR’s pile up was very displeasing.

To bring these libraries back under the spotlight, we decided to consolidate them with our UI components library. What might seem like a technical change, actually makes a big difference and is also aligned with our new approach to OSS — focus on bigger infrastructure projects, avoid small scale libraries.

Although sometimes, we simply had to accept the fact that we are unlikely to ever have the capacity to support a project. Such was the case with our camera library. Ever since it was created, the library was never owned by a team and was maintained by a few developers. Eventually it was abandoned and we started looking for maintainers. The wonderful people at Tesla have contacted us and suggested that we collaborate on the library, as they are using it a lot in their apps.
We could tell right away that this collaboration was going to be very fruitful, and indeed it didn’t take long until we transferred ownership of react-native-camera-kit over to Tesla. We’re glad it found a new home, thanks Tesla!

Open source loves innovation. New solutions with fresh approaches are constantly being worked on and libraries rise and fall in popularity. When our animations library, react-native-interactable, was first introduced back in early 2017 it quickly took off. But it’s brush with success was very brief as it was superseded by the ever so popular react-native-reanimated. Eventually we conceded that Interactable’s development had run its course and migrated to Reanimated.

Our flagship open source projects

react-native-ui-lib

All the components used in the Wix app are available through our UI Library. It’s actively developed by one of the biggest teams working on the Wix app consisting of 6 developers and 4 designers. From keyboard handing views to carousels, we got you covered! Managed to peak your interest? Read more about UI Lib and the components it offers here.

react-native-navigation

Our greenfield navigation solution for react native applications. React-native-naviagtion provides fully native navigation constructs giving your apps that native look and feel users expect. By offloading all navigation concerns from the JavaScript thread to the native thread, it ensures the JS thread is available as much as possible for your application.

Detox

Gray box end-to-end testing for react-native applications. UI testing mobile apps is no easy task, especially with react native where any UI interaction is handled in both JS and Native. Detox takes care of synchronization so you can focus on writing solid tests that pass consistently without having to worry about flakiness.
Over time Detox has evolved to become a suite of tools centered around performance and stability. It includes both:

• detox-instruments — which lets developers profile their apps and analyze performance problems.
• detox-recorder — a tool to record Detox end-to-end tests while using your application instead of writing them in the IDE. Simply hit the record button on the device and perform the desired sequence of actions. Detox-recorder will then process these actions and output the corresponding detox test. This opens up the possibility for less technical team members to write tests as well.

react-native-calendars

A feature rich and highly customizable calendar library. The library supports both horizontal and vertical calendar lists, infinite scroll and various date markings. To complete the package, It also provides a performant agenda component allowing you to show a detailed view of each day.

react-native-crash-course

All developers who join the mobile team at Wix take this crash course as part of their training. The library is a self-learning course designed to help new developers learn the ropes and familiarize themselves with our tech stack.
The course starts with a basic introduction to git, JavaScript and React Native, followed by a deep dive into how we write mobile apps at Wix; from navigation
with react-native-navigation to state management with Remx and testing with Jest and Detox.

Conclusions

Our journey with React Native and Open Source has been a great educational experience for us. We are grateful for the opportunity to contribute back to the community that has evolved around React Native.

Extracting code to open source libraries can ensure better decoupling and separation of concerns. Over time this modularity will become part of the team’s DNA which will help facilitate future scale.

Open sourcing a project can elevate it on all fronts, whether it’s code quality or documentation, but it does require a drastic increase in maintenance time. If not enough developers are dedicated to an OSS project, then the requirements of the community probably won’t be met making the project less viable to others outside of the organization.

As I wrap up this post, I’d like to thank all of our amazing contributors and partners from the community. Collaborating with you has been an incredible experience. Thank you for believing in us and for motivating us to keep going!

This blog post is part of a series where we, Wix engineers, outline our experience with React Native, share best practices and what’s next for us.

Part 1 — Intro

Part 2 — The Architecture I

Part 3 — The Architecture II (Deep Dive)

Part 4 — Open Source

Part 5 — Performance [coming soon]

Part 6 — Tools [coming soon]

Part 7 — Testing [coming soon]

Part 8 — Challenges and future plans [coming soon]

If you’d like to get updates, follow me on Twitter.

To hear more about mobile at Wix Engineering listen to our podcast episode where Lev Vidrak and Omri Bruchim deep dive into Reach Native and talk about adopting and using it to build the Wix Mobile App.

For more engineering updates and insights:

• Follow us on: Twitter | Facebook | LinkedIn
• Read our blog
• Visit us on GitHub
• Subscribe to our monthly newsletter
• Subscribe to our YouTube channel
• Follow our Medium publication