Paying Open Source Contributors with Puneet Lath 1r1es

Transcript\r\n\nCHARLES: Hello, everybody, and welcome to the Frontside podcast. My name is Charles Lowell. With me today also from the Frontside is Taras. Hello, Taras.\r\n\nTARAS: Hey, Charles.\r\n\nCHARLES: And we\'re going to be talking with Puneet Lath, the director of R&D at Expensify today about a lot of interesting topics. Hey, Puneet.\r\n\nPUNEET: Hey, thanks for having me.\r\n\nCHARLES: One of the reasons that we wanted to have you here on the podcast was to talk about the unique way that you\'re using open source with your products. Maybe you could tell us a bit about the strategy and how you guys came to start implementing it.\r\n\nPUNEET: Yeah, absolutely. So we\'ve always been big fans of open source. We\'ve had some parts of our technology stack that have been open-sourced in the past for example our database layer called Bedrock is something that we open-sourced quite a while back. But what we\'re doing now is a little bit different, a little bit more unique I think basically not just open-sourcing software tools that we use but actually open-sourcing the front end of our product itself. So we\'re basically rebuilding our products, the front end at least, on React Native to be fully cross-platform, and we\'re doing that in an open-source manner. so all the code is public, anyone can see it and contribute to it. We\'re fully committed to open source.\r\n\nCHARLES: That\'s crazy. There are so many implications there. It\'s definitely the conventional wisdom that you maybe open-source some libraries that you use. Of course, you let everyone use your front end, and you keep your back end close source. But what\'s the advantage of having an open-source front end? There is only one Expensify. What\'s the advantage for me as a developer of being able to actually modify this code? Like, I can\'t deploy it on my own systems.\r\n\nPUNEET: Sure. The benefit that we see is we get the advantage of the open-source community. We get people who can see our code. If they use our software and they care about our software, they have a chance to be a part of building that software. So we see ourselves as more than just a company but a community of people. And there\'s so much engineering talent out there in the world and so many good ideas and so many different perspectives. So we just see it as an opportunity to try to tap into some of that.\r\n\nTARAS: It\'s mind-blowing because there are so many times that you use something and you really can\'t do anything with the software if you find there\'s something wrong with it. And so much of our stacks are now converging in similar technologies the idea that you\'re using an app and you\'re like -- and something like Expensify too because it\'s part of your core business. I could imagine a consulting company like Frontside using Expensify for our internal workflow, and we have a few people on the team who can do React, [Chuckles] I mean every single one. So you encounter something you\'re like, “Look, I think this could be different.” And the idea that we have a SaaS that we use and we can just drop into their code and like, “Hey, you know what? I don\'t like this. [Chuckles] Can we change this? This doesn\'t really work for how we\'re using it.”\r\n\nCHARLES: How many people would actually change it so that when you merge a pull request the number of pull requests actually decrements by one? [Laughter] So is it mostly that kind of thing where you get people who just see ways that they can improve the product that they themselves are using? And they’re like, “Hey, I want to contribute to it.”\r\n\nPUNEET: That\'s the dream, certainly. We think it can create a totally different relationship with customers where up until this point, if you want us to fix a bug, or if you want us to implement a feature, you had to convince us to do it. Now you can go fix it yourself, and we\'ll happily merge it. Or if there\'s a feature that you think we should build and we\'re not totally convinced, you can build it. Send us a PR, we\'ll look at it, experience it, and it just creates a more collaborative way for us to build this software. We hope that it empowers our s and gives them more of an opportunity to see the things that they want. In theory, if we don\'t merge it, they can run that local version of Expensify that has their changes if that\'s what they want to do. That\'s certainly an option that\'s available to them as well. But our hope is more that it just allows people to be a part of building our products and not just in their ideas but in actually seeing those ideas implemented.\r\n\nCHARLES: How far along are you on this experiment? Have you started to see some significant traction or contributions to your codebase from the outside community?\r\n\nPUNEET: We’re pretty early on in the experiment. We’re a few months into it so most of the contributions from people to the codebase that aren\'t employees at Expensify are contributors that we\'re paying to implement changes. So one of the big benefits is that we can squash bugs at a faster rate. When a bug comes up, that gets filed in the repo and then we can put it on a platform like Upwork and basically say, “Hey, we\'ll pay $500 or $1,000 or whatever it is depending on the bug to anyone who wants to come and fix it. And it just makes the speed of bug fixing so much faster, the same thing with implementing features or polish. Historically, we always had to prioritize, do you build new big features, or do you polish the existing ones? Now we don\'t really have to make that trade-off. We can focus on building new features, and we can have external people pick up and polish items if they want to earn extra cash, whether they\'re s or people out there in the world that do this kind of freelancing work.\r\n\nTARAS: It\'s really interesting. I like how you guys are trying a few different things at the same time because this idea that you can engage people in contributing to open source while having a system for getting paid for doing that it\'s kind of the best of both worlds in some ways because many times some people would like to break in and have some credibility on GitHub where they could show that I\'ve done this work, and they really don\'t have a lot of choices. And especially if you don\'t have a lot of bandwidth to just sit and write code, if you don\'t have that luxury to just sit down and not earn any money, then this could be a way for people to break through that barrier and get paid while also building up their GitHub portfolio. So I think it\'s a really positive thing, and I really hope that it gets traction. I hope more people start to use it.\r\n\nPUNEET: Yeah, that\'s something that we\'re already seeing where we\'re having people who have contributed who are coming back over and over again, and they\'re getting better. They\'re building skills through doing things in our codebase, maybe they\'re early on in their software engineering career, maybe they just graduated from school or they\'re maybe making a career transition. They can get some experience in a way that doesn\'t require them to get hired for a full-time job but like you said, still get paid for it and then not have to do it for free.\r\n\nCHARLES: I think it\'s amazing. From a purely practical sense, it\'s just one way to completely and totally circumvent the whole barrier to contribution of hiring somebody, getting them on either a contract or paying benefits and doing all this stuff. So you just do these micro chunks of work without having to go through all of that.\r\n\nPUNEET: Yeah, and it kind of feeds each other. So we\'re hiring. We\'re happy to hire great engineers who want to work here but working at Expensify comes with everything with Expensify. You have to be bought into the vision. You have to care about the business. You have to care about the product roap. You have to care about our values. You have to want to work full-time in a job that takes a lot from you. And that\'s great. We want those people. That\'s what we want to do, and that\'s why we work there. But at the same time, there\'s tons of expertise out there. There are people who don\'t want to do that who just want to be freelance, have more freedom, pick up chunks of work here and there. And we love the ability to lean on their experience and their specific skills. There are a lot of people with very specific skills that we can tap into even if they don\'t work at Expensify because we\'ve done this.\r\n\nTARAS: I can see this being also a way to pre-qualify people in a way because you\'re always -- if you want to hire, if you want to grow your team, it always helps to find people who already know something about you. You\'re not starting completely cold. They\'re attracted to you for whatever reason and so having them be familiar with your codebase, having seen them in action -- because you could tell so much about someone with their pull request hygiene, their commit hygiene, their attention to detail. There are all these little things that you can read from how people describe their work in a pull request that I think it would be really telling about the stage that they are in in their career or the way that they think about technology and that doesn\'t necessarily mean -- because there\'s so many different kinds of engineers but being able to read between the lines and what the person is saying I could see that being really helpful if you ever consider hiring somebody from the community.\r\n\nPUNEET: Absolutely. One of the things that we see when we do hire engineers and they don\'t succeed at Expensify, it\'s rarely a skills issue or a technical ability issue; it\'s almost always a communication and collaboration issue. How do they communicate? How do they collaborate? And one of the nice things about this is we\'re getting to see that. They get to see how we communicate and collaborate, and we get to see how they do. And so yeah, absolutely, it gives you a better sense for both sides of would this make sense in the future for them to work here? And I think that\'s a really cool aspect of it.\r\n\nCHARLES: One of the things that I\'m curious to know about is about the existing Expensify engineers and if there\'s a mental mode-switch that happens when the product is open source. Because I know I certainly feel the pull to make my best absolute product when I know that it\'s going to be open source and that it\'s not going to be in front of an audience of 10 people or 1,000 people. It could be potentially in front of an audience of 10 million. And so I really like -- Even though I try to always be the best version of my development self that I can be when I\'m writing code no matter the context, I have to say the incentive is different when it\'s open source. And I think that\'s why we see, in my experience, we see basically a higher quality of code just absolutely when you\'re developing an open-source codebase. And I\'m wondering did you see that in your internal staff in the way that people treat the open-source? Not only is it going to have a bigger audience but you just have to have, because everybody\'s not in your Slack, you have to have better documentation so that people can discover things for themselves. Your pull requests have to be more descriptive because there\'s not as much shared context, things like that.\r\n\nPUNEET: Yeah. It\'s exactly what you said. These people don\'t work here. They\'re not in Slack, they don\'t necessarily know everything. And so yeah, our REEs have gotten better as a result of this, how we set up our tools and make it easy to get set up so that you can develop on our product has gotten better as a result of external people who don\'t have access to our internal Stack Overflow on these things. They need to be able to set up quickly for this small job that they\'re doing in order to be able to send a pull request. Our communication and PRs all of that has gotten better as a result of this and ultimately, that\'s making us all better engineers as well just being forced to have this higher level of thought in our communication.\r\n\nTARAS: What kind of tools do you have around the project to help developers who are not part of the team, like someone who is contributing open source to make sure that the work that they\'re doing is fruitful? Because I can imagine it being really discouraging to put a bunch of work in and then you create a pull request and then you find out that oh, you know what? We actually can\'t really merge this.\r\n\nPUNEET: So we experienced some of that in the beginning. We hired people to do work and they\'d send a pull request, and it was totally different than what we were expecting, whether it was in style or in approach or that sort of thing. And so we\'ve done some experimentation. We experimented with hiring two people for one job and then paying them both but maybe merging the code that was better. That created some kind of weird incentive, so we\'ve gone away from that. What we do now, is we try to – basically, what we\'re doing is more of our internal processes are becoming public as a result of this. So internally, we have a process where you have to explain, you have to propose “Here\'s how I\'m going to approach this problem.” You get on that before you actually go and write the code. We\'re having our contributors do the same thing, and we\'re having them break down “Okay, what\'s going to be your approach to this problem? Let\'s have a discussion about that and agree on that first before you actually go and make the changes and submit the pull request.” So we expect that the we\'re going to have for you on the pull request is going to be minimal and more tactical rather than “No, this is all wrong.”\r\n\nCHARLES: And along that same line, how do you keep people productive just in of making sure that they have the pieces of the stack that they need to do their job? When I think about the first day on the job, you sit down, they\'re like okay, this is how you set up your front end. And now we\'ve got a little vagrant box that has the back end or a Docker container whatever. That\'s not really an option especially when you have the closed source back end and you have the core business logic that you may not want to give out. How do you resolve that tension?\r\n\nPUNEET: So it\'s been super interesting because they\'re not setting up a dev environment. They don\'t have a local server, so they\'re basically coding against our production servers. So they\'re running a local version of the front end, but they\'re developing against the production servers, which works because Expensify s are free to create. So you can create as many s as you want with as many email addresses as you want. You can play around, so it works fine to be using our production servers. So really they just need to have locally, the set up to run cross-platform front end. So they need to either have an Android or an iPhone, or they need to have local simulators set up so that they can run those. Anyone that has web is easy, but they just need to be able to run those things. So there are some small limitations there. And for that reason, we expect that they\'ve done some either mobile work or React Native work before, so they already have those things set up. They already have the ability to run local simulators and those types of things. But other than that, you just got to fork the repo and pull it down and you\'re good to go.\r\n\nTARAS: What kind of automated testing do you guys use? I’m really curious about how you have it set up in of providing on things that are working or might not be working.\r\n\nPUNEET: So right now it\'s kind of the Wild West. I would say the automated testing is pretty minimal. We are not massive proponents of doing tons of automated testing. We found that doing manual testing, regression testing is more valuable. So we have some specific requirements of the people that are contributing that they test in all platforms and post screenshots of what they\'ve seen. We have a QA company that we use that does manual testing for us across devices and those sorts of things. But our automated testing is actually pretty minimal.\r\n\nTARAS: That\'s interesting. It\'s a little bit different than how I think about organizing that kind of work, but it\'s really cool to see that you guys are putting it into practice, so it\'s fascinating to see it in motion.\r\n\nPUNEET: Absolutely. And I think our automated testing will get more robust. And what\'s cool is we can also have contributors create those automated tests as well. That\'s part of the work that we can have them do also. But I think we certainly believe that there\'s always going to be a large manual testing component especially when it comes to the myriad of devices that we\'re thinking about people running on; we definitely think mobile-first. And so we always think manual testing is going to be a big part of it.\r\n\nTARAS: One thing that comes to mind one of the reasons why I was really interested in this topic right off the bat was that it really feels like in today\'s world, the way we consume software feels almost in some ways inadequate because, from a company perspective, you have to invest into software to be able to get value from it. But you also have to invest into it to find out if the software is not going to work for you, and that\'s the part that I find really interesting about what you guys are doing is that in some ways, there seems to be the possibility of being able to pick a piece of software but know that you don\'t have to make a switch in case it doesn\'t work for you exactly as you might imagine on day one. So I wonder if you have any kind of experiences like this or if you have any thoughts about how this might evolve beyond this first experiment.\r\n\nPUNEET: That\'s super interesting. I never really thought about it from that perspective. I suppose that\'s true. You could get a full experience of using Expensify without necessarily needing to commit to it. That\'s built into the product as well. We have free trials; anyone can create an for free and play around. So I\'m not sure that I see a huge benefit from that perspective specifically. I think I could see people building interesting versions of Expensify on top of what we have and creating their own stuff from it; I think that\'s interesting. And then what\'s cool is we can pick and choose what they\'ve created. We actually want to fold into the main application, that\'s the direction I see it more from.\r\n\nTARAS: That\'s also what I\'m thinking as well. Because feature-wise, that you can determine. But as your needs evolve, so if you find you want to integrate with this other piece of software or you find that you\'ve got a few contractors and you\'d like to be able to give them a specific way of reporting time as opposed to open-ended, that applies to everybody and then if you make it available to -- I would imagine from a perspective of someone who is making software for a variety of people, you always have this conflict between making something that is customizable which means you\'re adding additional options that you have to manage or making something that is generic in which case it might be too generic for some groups of people. So finding a balance between those two things I would imagine would be really difficult. So this might not fit for everyone because not everyone is a consulting company where every single person is familiar with React but increasingly, these skills are becoming a basis; they’re becoming part of software literacy. I can imagine many kids today who are going to be 10 years from now they\'re going to be 15 or 20 with 10 years of experience doing React. [Chuckles] So in that world, I could see them being able to pick apart the app and be like, “You know what? I work at this company, but the way we use this app doesn\'t really work for what we want. What do you guys think about this build of that particular app?”\r\n\nPUNEET: I think I can totally see that happening. I hope that happens. I think that\'d be incredible. You\'re right, from a product perspective, we\'re always thinking about, okay, what\'s the most simple version of this? What\'s the widest version of this? We\'re not trying to build for very specific use cases. We\'re trying to build for the masses. And so it\'s all about simplicity, always, in of how we\'re thinking about the product. And yeah, I think people will build more specific features for more specific use cases or more specific versions. We don\'t have an explicitly open API but as a result of having an open front end, we have an open API. And so people can do whatever they want in of creating whatever they want that interacts with our server and database infrastructure.\r\n\nCHARLES: So what we\'ve been talking about and what you\'ve been describing, it\'s a pretty radical departure, as I said at the beginning, from the conventional way of doing things. And when I\'m listening to it now, it feels like oh, well this is just a no-brainer. That\'s not how most apps are and so obviously people see that there is risk to this. So from the perspective of someone who\'s over on the other side of this decision and this move, how do you perceive that risk? When you were evaluating this decision, what were you seeing as the trade-offs and the risks of doing this?\r\n\nPUNEET: Totally. And I think the risk that most people would consider is what happens if someone steals our stuff? And I can totally understand that. For us, I mean, first of all, it\'s just the front end. So everything under the hood is still private. Maybe at some point in the future if we\'re thinking really crazy, maybe it\'s all open.\r\n\nCHARLES: [Laughs]\r\n\nPUNEET: That\'s not in the plans right now. So there\'s still a lot that you would have to be able to build on your own if you really wanted to try to steal everything that we have. The other thing is we\'re established; we\'ve been around for 10 years. We spent 10 years perfecting this market. We have over 10 million s. There\'s a lot that has to be learned beyond just the front-end code in order to be able to replicate what we do. It\'s basically impossible to replicate. And so there\'s a lot of confidence there that yeah, sure, maybe there\'s a risk and maybe there\'s something hiding around the corner that we don\'t see. But we have a hard time picturing what that might be. The benefits seem to far outweigh the risks.\r\n\nTARAS: What are you excited about now? Because it\'s obvious that you guys are doing some really interesting stuff. You have your database open-source project; you have your front-end open source. What do you see that\'s on your horizon that you think is going to be really exciting from a technology perspective?\r\n\nPUNEET: So I think it\'s going to be cool to see this community of developers start to grow. We certainly believe in React Native that\'s why we adopted it. We\'re using not just React Native for mobile, but we’re also using React Native for web. So our goal for the longest time has been to not have to write three different sets of front-end code being able to write code once and have it run cross-platform that\'s certainly the dream. I think historically, it\'s been very difficult to do that and have it be good quality and feel good quality and feel Native. But we believe now that with React Native and where it\'s at that it’s possible to have a Native feeling experience while only having to write code once. So I\'m excited about that future, and I think so far so good.\r\n\nCHARLES: How does that work? And I know that\'s a very general question. So specifically, the things that are in my mind, definitely when I tried out the React Native web, it was bedeviled by performance problems ironically, the Native platform on the web. But also it\'s just the underlying components are just different, the way that the layout containment and the way events are handled. And this question comes out of left. Does it make it easier to have a design system? Do you guys have a design system, and does that help? And how does that play in making that compatibility dream real?\r\n\nPUNEET: We do have a design system, but the reality is even when you\'re developing for web, you\'re developing for all screen sizes. So in of layout and those types of things, we\'ve been thinking mobile-first even when doing web development anyways, so we\'re always thinking small screens. And in of actual writing the code perspective, writing React Native code is super similar to writing React code. The components have different names, but instead of a div you have view, but ultimately, the code is so similar. So we haven\'t found that it\'s really that hard to make the transition to using it. It\'s just believing that you can, and once you believe that you can, you realize that it\'s actually not as hard as you might think.\r\n\nCHARLES: Okay. That is exciting. If that is actually working out, that\'s a pretty awesome development. Do you find that you\'re able to do things like making sure that you\'re able to meet the same accessibility requirements on both platforms with the same set of code?\r\n\nPUNEET: So that\'s one area where we need more research done is the accessibility aspect. So we\'ve started hiring some external contributors to focus on accessibility for us and figure that part out. My answer to your question is I\'m not sure yet. I think that should be pretty solvable. When I say that we\'re using React Native for web, that doesn\'t mean there aren\'t areas or ways in which we write web-specific code but the vast majority of the code is written in a cross-platform way and sometimes you have to fill it in with Native elements. But all of the business logic and most of the main structure is written in a cross-platform way.\r\n\nCHARLES: So, how do you handle things? Do you have things like routing? Do you just use React Router on both platforms in the sense that one platform does not have the concept of a URL bar?\r\n\nPUNEET: Yeah, that\'s a great question. Right now we use React Router on both platforms. We\'re actually in the process of transitioning to React Navigation because it just handles Native Navigation much better. And it actually works quite well for web as well. So React Navigation works with React Native for web, and it works quite well for web. And you do have to think about navigation in a cross-platform way. So you have to think about Native stacks and how do those relate to URL bars and a back button? And so you have to think about them, and you have to come up with ways where things that exist on Native what are those the equivalent of? So a right-click on web, what is that the equivalent of on Native? Is that the equivalent of a long press? Okay, so we\'re going to code with that in mind and right-click and our long press are the same or a back button and a back swipe are the same or those types of things are how we have to think as a result of doing it in a cross-platform way. But the libraries like React Navigation it just fine as long as you know what you want to do.\r\n\nCHARLES: I guess if you\'re thinking in of those abstract operations, it\'s the same way that you can on an event handler you\'re thinking of is the Meta key down? Not is the option key or the ALT key because it\'s different on Unix, Mac, and Windows but that abstract operation is the same.\r\n\nPUNEET: Exactly.\r\n\nCHARLES: Okay. Man, I\'m excited to go give it a try.\r\n\nTARAS: What kind of features have you had your open source contributors implement? What\'s the biggest thing that someone has contributed?\r\n\nPUNEET: The biggest thing probably is -- So the main functionality is the chat application. So it allows people to chat with each other and facilitate payments within this chat structure. And so one of the things that we in this chat app is using Markdown and so we have this engine that basically converts between HTML and Markdown and plain text because depending on what device you\'re on, it\'s getting sent to the server in HTML or plain text. And how do we convert Markdown into HTML and vice versa? And so the biggest contribution that we had is something super specific which we have no expertise of which is around basically that HTML conversion and how browsers navigate the HTML tree and style it, and it\'s actually far beyond me. But those kinds of really specific deep things where you need this deep, deep knowledge of HTML and CSS that most web developers don\'t have, we have been able to use contributors to come in, drop-in. They understand that well. They can write this engine for us that does that conversion stuff like that.\r\n\nTARAS: That\'s a really great example of something that we\'ve observed as well. We’ve actually recently changed how we structure engagements with our clients because we observed this ourselves as well that there are certain problems that solutions to those problems exist in specific groups and most likely you just don\'t have that. A perfect example of this is that we collaborated with another consulting company or actually two consulting companies to create a Bluetooth simulator. And we could have taken a crack at it; we probably could have figured it out. But they have years of experience doing Bluetooth. It made so much more sense for us to provide access to our client to that experience as opposed to trying to do that ourselves. And so facilitating the creation of that was actually really impactful because now they\'re using this tool, and they did not have this experience internally. We did not have all that experience internally, but we were still able to create the technology that we wanted to. What you\'re describing is a perfect example of what we\'ve seen ourselves as well that there is certain expertise that you can get if you frame the relationship in a specific way.\r\n\nCHARLES: How is it that you match this? When you say, “Oh, we have this specific need,” how do you go about finding it? Do you just issue a bounty and they come to you, or how do you write it up and talk about it?\r\n\nPUNEET: There are two ways that we do it. So one is issuing a bounty and seeing if someone comes to us and proposes something that makes sense to us. That seems to work more with smaller things and less specific things. The other is we go seek people out. So for example, I told you guys we are making this transition from React Router to React Navigation. So we\'ve written that all ourselves. One of our engineers has been working on that project, but no one on our team really has a ton of experience with React Navigation. So we\'re thinking okay, now that we\'ve basically written this, let\'s go have someone who has a bunch of experience or expertise with React Navigation review it and reverse the roles where they\'re reviewing our code versus us reviewing contributor code. And so we went and looked in the React Navigation repo, and we\'re seeing okay, who are some of the big contributors? Maybe we can reach out to them and pay them for their time if they do freelance work and have them review this and give us . So we seek people out, and we let people come to us. We\'re trying both approaches, and they seem to have different times in which they work.\r\n\nTARAS: And you can do that because you\'re open. Because it\'s hard to engage when you\'re like, “Well, let\'s sign a contract first,” and then “Are you available then?” Blah, blah, blah. Instead of just like, “Hey, there\'s a link here, and we have this problem. Can you help us with this?” [Laughter]\r\n\nPUNEET: Exactly. It\'s so much easier to just be like, “Here\'s the link to the branch, check it out. If you have some , we\'d love to pay you for it.” It\'s so much easier to have that conversation because of people\'s just natural curiosity they want to go look at it.\r\n\nTARAS: Especially if someone\'s using your tool. You\'re going to be like, oh, let me see how they actually put that in practice.\r\n\nPUNEET: Yeah, absolutely.\r\n\nTARAS: Again, going back to the idea that-- I think it\'s a really healthy thing because we have so many conversations around changing how people get compensated in open source and how we compensate people for open source. But at the same time, in some ways, there can be inherent barriers that exist for no good reason other than the fact that they just simply exist. We see this with especially deg tools like when integrating with other vendors like we have a project to create Azure simulation, and I would not want to build Azure simulation without having Azure folks at the table. It makes no point to do that. It\'s a sophisticated piece of technology and being able to do that in the open is really helpful. If you don\'t think that that\'s possible, you would never even attempt it.\r\n\nPUNEET: Totally. Yeah. I think it takes a certain level of confidence that hey, we can engage in public and nothing bad is going to happen. It\'s actually going to be better for all of us. It\'s a win-win; we get something out of it, and it helps our business and our product grow but so do the people that we\'re interacting with.\r\n\nTARAS: What triggered this? Where did this come from? Why did you guys think we got to do this? This is something that we should organize our backlog, and we got to do all this work. We got to figure out the legal stuff. What was it that gave you the idea that this is something that you should do?\r\n\nPUNEET: So we for a long time for years and years and years, we\'ve been talking about how we can get to cross-platform. We\'ve always had been frustrated by the need to do all this duplicate effort in of writing front-end code. Way back in the day, we wrote our own cross-platform but back when it wasn\'t just iPhone and Android but back when Blackberry was still a big thing, Windows phone, it seemed like it was going to become a big thing. So we had this cross-platform layer that we called Yet Another Platform Layer (YAPL) which was to write cross-platform across those four mobile platforms. So this is something since the beginning of our business that we\'ve wanted to do, that wasn\'t very successful. And so we felt like maybe around mid-2020 we really felt like okay, React Native is at a place where this is truly possible where this goal that we\'ve had forever to truly write cross-platform is possible. We were also at a point in our product roap where we were building this new way of -- we were basically redeg our entire front end and how it\'s going to work. And so we were rewriting our front end from scratch, so it seemed like the perfect time to okay, let\'s make this transition to React Native since we\'re rewriting it anyway. And as we were playing that out, we were like okay, we\'re going to be using React Native, which is an open-source library. We\'re going to be using all these other open-source libraries. And we were just playing out well, what would happen if our codebase was just open source? What could we get from that? Would that work? Is that crazy? And we were going through the thought experiment. And as we talked about it more and more, we couldn\'t really figure out a downside. We just kept coming up with new upsides that could come from that. And so we were like, “I think we have to do it. Let\'s do it,” and so we went with it.\r\n\nTARAS: Yeah, that\'s really cool.\r\n\nCHARLES: Yeah. That was a great story. It opens up a whole world of possibilities. Are you aware of any other peers that are doing something similar?\r\n\nPUNEET: I\'m not aware of anyone that\'s doing anything like this. There are tons of people who have open source software and libraries and tools; all the big tech companies seem to. But I haven\'t found anyone else. When we were looking into okay, what license should we use? I was trying to find whether anyone else was doing anything like this, and I couldn\'t really find it. So I think it\'s pretty unique.\r\n\nCHARLES: Yeah. Well, it\'s certainly the first one that we\'ve come across. So one of the things that I wanted to ask you from the beginning of the call was since you\'ve done this, do you have a favorite story of something, a surprising outcome that you did not anticipate but yet was definitely positive?\r\n\nPUNEET: I don\'t know that there\'s been a specific, surprising outcome. I think the coolest thing so far in my mind is just the range of places that the people that are contributing to the codebase are from. We really have people from all over the world that are contributing to the codebase, people from Pakistan and Albania and Europe and America and Latin America. It\'s suddenly like we just have such a global base of people. And it really makes you realize that there are people that can do this work everywhere and really all over the planet and so that part has been just incredible to get to interact with these people and have them contribute. And I think the product\'s going to be better for it, just having more diverse perspectives. So that\'s the part that\'s been most exciting and most interesting to me so far.\r\n\nCHARLES: I would definitely rate that as an unexpected, positive outcome.\r\n\nTARAS: Having gone through this experience and being in it now, is there an app that you wish was open source like this?\r\n\nPUNEET: I guess I don\'t really expect it. It\'s such a mindset change that\'s never really occurred to me before. Like if Gmail was open source, what would I do? But yeah, I don\'t know. That\'s a good question.\r\n\nTARAS: The thing that I find really interesting in what you were saying earlier about the shift of by being open is it actually is making you think about being more open. It\'s making your team think about writing your pull requests in a different way. It\'s more of a proposal. This is something that we\'ve observed as well that there is a certain kind of a growing of an idea that happens. When you start to introduce transparency or this kind of openness into your organization, you start to see these kinds of effects. And I just wanted to share one of the things that we\'re observing now is that -- This is completely unrelated, but it\'s been on my mind, and it’s similar to this is that so Spotify recently open-sourced their Backstage tool, which is their developer portal framework. It’s something that they\'ve been using internally for a long time. And as we know, Spotify has a really good reputation for being a very progressive engineering culture. They go way back. And so they\'ve been using this technology for four years and now they\'ve open-sourced it. And now companies are starting to realize -- there\'s a lot of companies that are realizing you know what? We need to change how developers find different components in our ecosystem. We have all these libraries, we have all these packages but nobody can find anything. There are all kinds of services. We need something. So they start looking for a developer portal, and they find Backstage.\r\n\nBut what I find really fascinating is that there\'s a clash that happens where there is this open-source community that is sharing technology and then there\'s also these more traditional companies that are coming to use technology, but they\'re encountering the openness for the first time. And I find that the observing of this mental shift that happens in people when they start to observe things, like you have pull request processes that Backstage uses, and it\'s a really powerful tool to create alignment for distributed groups. And then when you start to observe this, you start to think, well this RFC process might be useful for us. And this idea starts to blossom on other people\'s minds, and that\'s what I\'ve been noticing. And it\'s really interesting to hear you share a similar perspective with what\'s happening inside of Expensify as a result of opening up your codebase.\r\n\nPUNEET: Yeah, totally. I 100% agree with you. I think that\'s a really cool outcome that I don\'t know that we thought a ton about going into it, but it\'s definitely the case. And I think transparency just brings up the quality of everything.\r\n\nTARAS: Yeah, that\'s a really great way of putting it. When you shine light, you will find things, right? [Laughter]\r\n\nPUNEET: Exactly.\r\n\nTARAS: So the benefit of opacity is that you get to not see the code in the corner. [Laughter] That’s really awesome. I applaud you guys for really trying to do something really different. And I\'ve kept my eye on Expensify for a long time, and it just makes me want to use your product more because it\'s the fact that you are trying something different, and it could have a really positive impact, and it just makes me want to you guys. So I really appreciate you taking this step.\r\n\nPUNEET: Yeah, I appreciate that. Hopefully, we\'ll make you proud and definitely check out the codebase. Let us know what you think.\r\n\nCHARLES: Yeah. Anybody else who\'s considering a similar move, go for it. It definitely puts you a step up in our book, especially being a company of engineers.\r\n\nAll right. Well, thank you so much, Puneet, for coming by and talking with us. I guess if there are any blog posts where you\'re talking about this in-depth or any other resources, we can drop them in the show notes, and we will see everybody later.\r\n\n\r\n\nPlease us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at @frontside.io. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer.\r\n\nThis show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.\r\n 5x1c24