In a previous post, I covered the benefits of using Open Source Software (OSS), but as with everything else in life, there’s a trade-off you make when using software written outside of your company and your engineering team’s standards.
Before getting into the nitty-gritty, I would like to state that most experienced engineers know how to vet OSS, so I will not spend the time covering how that’s done, as it’s not conducive to this blog’s audience; non-technical business owners who want to build an app. However, what I will cover are the pitfalls and repercussions of using certain types of OSS projects at the onset of the development of your iOS app.
First, not all OSS is of the same quality. Just because one library/module, which is what we refer to a single piece of OSS, is available for your use for free, does not mean it is free of bugs. This means that every library/module that is brought into your application is essentially bringing in a potential list of other people’s bugs. Are you willing to take that risk? With certain projects, especially ones with large communities, the answer should be yes for two reasons; (1) those projects tend to be less bug-ridden, and (2) they save your engineers, and by extension, you, a lot of time/money rebuilding the wheel.
This leads into my second point, which will be more clearly delineated by a hypothetical situation in which an engineer chooses to use a library in your iOS app that was well maintained at one point in time, but due to one reason or another, it has now been abandoned by the original developer(s). We call this type of software, be it free or paid, Abandonware. Over time, such software becomes stale for a plethora of reasons (to be covered in a future blog post). What does this mean for your app? It means that at some point that library that was included in your app may stop working or may become buggy, as there’s a hypotehtical chance it may no longer be interoperable with the changes made to the iOS libraries that Apple provides with each new version of iOS, or to a third-party platform that your app leverages. There are three ways out of this situation; (1) your engineers, and by proxy, your company, becomes the new maintainers of this project, or (2) you remove this third-party code and build it yourself, from scratch, or (3) work around having to use this library. None of these situations are ideal, but unfortunately, there are times when these decisions must be made.
There are two real-life situations that I am reminded of when it comes to Abandonware in the iOS community. While I do not know the full story behind each situation, I do now how each ended.
- In 2010, Facebook released the Three20 OSS library, which at that time, provided iPhone developers with a lot of useful user interface (UI) components. In 2013, they killed off the library, as Apple began supporting some of these features, and because it was no longer conducive for Facebook to maintain this library. No alternative was made available, so the community began maintaining them in separate, disparate libraries.
In 2013, Tumblr released the TMCache OSS library. At the time, it enabled an easier way of storing temporary data onto the hardrive space allocated by Apple to your app. In 2013, they killed it off. Thankfully, alternatives existed, and one particular alternative was PINCache, which was an improved clone of TMCache, that was back then, and to this day, maintained by Pinterest.
As you can see, both stories had a happy ending, but for a brief moment in time, these scenarios caused each developer who used either of the aforementioned libraries to freak-out, as it had the potential of adding a lot of extra, unplanned work to their plates. I would like to state that this is not always the case. As you can plainly see, both projects that I mentioned, and all the parties involved in the development and maintenance of this software revolve around established companies, which is why alternatives were quickly made available. This is not always the case with libraries maintained by single indivudals or smaller companies.
The last item I’d like to cover are software licenses. Each software license comes with a different list of what you can and cannot do with each piece of software. Most OSS uses one of following licenses; Apache, GPL, MIT, Mozilla. All of these licenses allow you to package and distribute software in your commercial product. There are other benefits and limitations to each of the aforementioned licenses, but for all intents-and-purposes for this blog’s audience, you can make money without having to pay the developer(s) and/or maintainer(s) of the OSS your products makes use of. For a human-friendly list of popular OSS licenses and their permissions, conditions, and limitations, check out https://choosealicense.com/licenses/.
In summary, OSS, and by extension, OSS developers and maintaers are a boon to the technology world, as they have enabled, and continue to enable software developers to create more products at a faster pace. However, for the sake of your product and your business, your engineers must exercise discretion when deciding to incorporate some of these time/money-saving libraries into your iOS app.