My goal was to integrate a Facebook Login solution into my React Native app so people can login using their Facebook accounts. I thought this task would be easy, because there already existed a React Native library called react-native-fbsdk to do exactly that, and it was owned and maintained by the Facebook group on GitHub. I won’t go into the exact details of the integration.
What’s important is that I followed the documentation, got everything ready, but the app wouldn’t build. I googled all the errors and looked through all the relevant issues in the repository, but none of the solutions were the ones I was looking for. I found the most relevant issue on GitHub.
It felt like no one knew what was wrong and how to fix it. It made me sad that this library didn’t work out of the box. I really expected it to work like that: just drop it in, configure it and that’s all. Unfortunately, this wasn’t the case. I had two options and neither of them were good.
There was no way I was going to sit and do nothing waiting for someone else to fix it, so I went with option number two. First, I looked at the native source code of the library to see the error as close as possible. This turned out to be a great approach, because I deduced fairly quickly that the library doesn’t support the latest version of the native Facebook SDK which contained breaking changes.
My original goal looked pretty far away at this point, but I knew I had to do something about this issue. I had never worked with the SDK before, and barely done any lines of native mobile code. Despite all this, I was confident that I could make it work and do a good job of it.
I believe it’s always a good idea to think that you will make it somehow, even if you’re doing something you’ve never done before.
My goal changed into a much more ambitious one: integrating the latest SDK into the library.
I had no idea how long would it take, but I felt that it shouldn’t be more than a couple days. I planned to integrate, document and test everything, to do a proper job so everyone can understand the changes.
In the meantime, react-native was preparing to release v0.60 with some big changes, including switching to AndroidX. Janic’s idea was to create a new release of the library, which would support RN v0.60 and the latest Facebook SDK. This basically meant not supporting anything below RN v0.60 and SDK v5.
I wasn’t liking the idea of not supporting the current stable version of RN, since v0.60 only was at the release candidate stage. I told Janic that I would be creating another edition of the library, which would support RN v0.59 and lower. I knew that many people, including myself, couldn’t upgrade to RN v0.60 for a couple months because of the massive changes it contained.
We finished pretty fast with the integration, and the RN v0.60 compatible release was almost done. Janic decided to support my idea of creating a backwards compatible release as well. It was fairly easy to make it work, thanks to the knowledge I had gathered during the previous days of fixing the original issue.
A week after me discovering the issues of the library, we managed to solve all the problems and create two release candidates: v0.10 to support RN v0.59 and below, and v1.0 to support RN v0.60 and above. It was definitely challenging to make everything work in the native layer of the library. I learned a lot about debugging and understanding native code. In the end, I was happy that I had chosen to fix the issue myself.
Finally, I was able to go back to my original goal. It felt nice to know that I contributed a considerable amount of effort to the most widely used React Native Facebook Login solution.
The thought that popped into my mind after everything was done described my philosophy pretty well — give back to the world freely sometimes because you will lift people up and in return you get lifted up too. Being a software engineer, open-sourcing is a really nice tool to do so.
I know one big task that hasn’t been taken care of. The documentation of the library is not very friendly. It requires a deep understanding of mobile development tools in order to make everything work. On top of that, it’s not very polished, and a bit confusing here and there. Overall I didn’t have a great experience going through it.
I do have an idea on how to make it more understandable and straightforward to developers of all backgrounds, and I will be making improvements. At the time of writing, I’m not aware of anyone joining this effort. Maybe someone will. For now, this will be my gift to the believers of a loving documentation.
I believe that the message of this story is that it is very easy to take an open source library for granted; that it would “just work”, without major issues. Most of the time this is the case, for popular libraries. Sometimes, though, these magical libraries do break.
I think the important thing is to not be afraid to start fixing an issue in an open source library. Describe the problem, provide some fixes that show a good direction to solve it, and open a pull request. This way the issue will be more exposed, and others might join the cause to fix it together and spread goodness in the world.
At Supercharge we build high impact digital products that make life easier for millions of users. If you liked this article, check out some of Supercharge’s other articles on our blog, and follow us on LinkedIn, and Facebook. If you’re interested in open positions, follow this link.
Open Source Taken for Granted was originally published in Supercharge's Digital Product Development Guide on Medium, where people are continuing the conversation by highlighting and responding to this story.