Choosing and Implementing Open Source Libraries
When building an MVP, you want to steal as much code as possible. You’re not worried about code licensing, you want to validate the market as quickly as possible with open source. So you want to use third party libraries to do the heavy lifting in your app. This is the heart of most great new companies, leveraging an emerging technology to serve a new market. Uber didn’t build a GPS mapping system in its first version. Google didn’t build an NLP system in its first version. Netflix didn’t build a facial recognition library for identifying actors in its prototype. You shouldn’t either. This article gives a few tips in identifying and using existing libraries for your MVP.
There are many forms of solutions you can choose, from white labeled options, to services like calendly, to open source python libraries. Here, we’re focusing primarily on code libraries that would be imported into your app directly to serve a particular function. Things like a pose detection library, facial recognition, [natural language processing](https://www.nltk.org/, fuzzy matching https://pypi.org/project/fuzzywuzzy/), or email sending from code. The first thing to see is if the library will serve the features you need at a high enough accuracy. Is your use case a standard thing that the library does? Or is it at the bleeding edge of the tech in the library? Does it have enough customization? Then you want to determine popularity and current activity. How many stars does the project have on github compared to its competitors? When was the last commit? How many active authors are there in the codebase? Determine if it’s compatible with your tech stack, or if you can build a new stack to interact with the library. Will you communicate with it through a database, files, streams, if it’s in a different language. Do you have developers that can work with the library, or do you need to find new specialists who have expertise in it?
When implementing the library, it often makes sense to find a developer who’s worked with that library before. They have their own intricacies, gotchas, and ways of doing things that might be counter to the standard style the language it’s written in. Find the developer on upwork or similar, as it’s generally worth it for code quality and expediency to find an expert to pay a bit more. If the perfect library is in a different language than your main code base, think carefully about the design constaints of piping information to and from. There are many ways to do this, but try to maintain your other language codebase as singly focused as possible. Do the tasks of the library, and leave the rest to the main app. Whether it’s in another language or not, it’s usually good practice to keep tasks of the library relegated to its own files in your app. Keep tasks related to the library away from more mundane business logic of the app. This way, if you need to swap out the library, extend, or build your own in the future, it’s easy to manage and work with.
You may need to extend and edit the library. For this, you may want to become a contributor directly to their github. Request a feature, and then take ownership of the building, go through their code review process, and get it pulled in. This will make it available to anyone using the library in the future. Alternatively, you can create a patch to the library that is private and for your use only. By creating a patch, instead of forking and editing directly, you can patch any new versions of the library that come out. In this way, you get access to new features of the main library while still extending the functionality you need. When your app succeeds and blows up in popularity, you may find that the library you originally chose does not have a commercial license or you’re paying too much for it. Now, you’ll have to re-evaluate and possibly build your own more specialized and powerful tool to do those tasks. This is a great problem to have, and you are intimately familiar with the advanced features of the library you used. You can hire a team to build out a new one and focus energy on the features most relevant to the business.
Be product first. Avoid the trap of getting enamored with a library. It’s ok to use 5% of its features, that’s most likely what you’ll be doing. Don’t dig into all the amazing features the library offers and then come up with products or complex features for your users that shows it off. Maintain focus on the value you’re adding to users, and pick and choose libraries and code snippets that enable that. Most of the imported code will lie dormant, and that’s good.
There is lots to consider when choosing and building an app on top of third party libraries. It’s almost always best practice to start this way: stand on the shoulders of giants. If you need help choosing or navigating the open source landscape, reach out.
Original article posted at https://mvpengineer.com/choosing-and-implementing-open-source-libraries/
