Third party dependencies

Jeroen Leenarts: Welcome to special 102. This is an encore presentation of a episode I did with Stefan. It's about third party dependencies. While I'm on vacation, I'm doing some anchor episodes of my podcast. So because these are the episodes that I like best from the past almost 200 episodes that I did. So after minification, I will be right back again. So just one or two more weeks, and I will be back with fresh content again. Yeah, so third party dependencies. Before I dive in, I wanted to do a call to action, because this year, fortunately, in person events, and conferences, especially are a thing again, a few of the people in this Twitter space, had the fortunate luck that we could go to an in person conference called swift heroes. But there's a whole bunch of other conferences happening in the in the coming months. And all of these conferences are looking for speakers. So if you want to do a talk at a conference, this is your opportunity, submit a CFP. And especially because I've been in touch with a number of conference organizers, they're really looking for like the the non stereotypical conference speaker. So especially if you are non white, especially if you're not white, not tattooed. submit, submit to your CFPs. Because they have very huge issue with getting enough diversity on these conference stages. So if you know somebody who you think is like a great speaker, but it's like maybe a bit hesitant to do that, support this person, get them to submit a talk. And also there's plenty of people online on Twitter, who would love to help people out and support people in doing their first conference talk? Or maybe getting back to conference speaking again, after two years? Of course, if there's reasons, like immunity related COVID related things, that people are a little bit hesitant to total respect for that. But yeah, just get the word out and get people to do what, what we would love to see. And that's more diversity on these conference stages. So have a look for that one. So third party dependencies. Yeah, it's a bit of a broad topic. But we really wants to dive into a little bit on what they are, what risks you can run into with third party dependencies, how you can find them some thoughts on licensing with third party dependencies and how you can assess a third party dependency whether or not you should or want to adopt it, and how to deal with dependencies in the long run. So let's do we really want to like, go over the entire lifecycle of dealing with third party dependencies. Just to get things started, what are some of your experience with third party dependencies? Stefan Blos: So I mentioned in my I shared space already, it was a tweet. In there, I mentioned that this topic is not only for iOS people. So it's basically something that every developer should care about. And I think it really depends on the ecosystem. So in my previous shop, I was doing a lot of web development, actually. And there, it has been very common to always say, hey, there's a package for that, just just put that package in and not do it yourself, which can be a solution that has been like, thing that has been very frequently. And it's something that you should definitely care about, and be careful about. So we will talk about that. More, of course, I think in the in my current role or in the current company, so we're we're both working for stream. And in creating things like a package or like an SDK, it becomes even more important if you think about third party dependencies, because they, you are a third party dependency that other people will include in their product. So it makes sense to think about, about ways to do that and things to be careful about. But the problem still remains that if you need to include third party code, then you have to think about, hey, every one of your customers will also include that kind of code or this kind of dependency in their products. So I think it's a very, very interesting and important topic to think about, because you can leverage third party dependencies very well. But you should always be careful about what to include, and we will talk a lot about that. Yeah, that has been my my personal experience so far was it? What about you? Jeroen Leenarts: Well, to add upon what you said, and then we'll talk about share my experience with third party dependencies with with the Stream SDK, we take active measures to hide In the fact that we use some third party dependencies, for instance, by preventing the Stream SDK from polluting your namespace. So yes, there are third party dependencies used by the upstream SDK. But those are not publicly exposed outside of the framework, so that you don't run into any weird surprises beyond the public API that that the SDK provides. So it's interesting, if you want to have a look at that. It's all open source, you can have a look at it how we do that. But it is it is a conscious thing that we do with string. So yeah, me and third party dependencies. Yeah, my previous role, I was like, software developer on on the big insurance app in the Netherlands, there was like a codebase, when I left there of 200,000, of original code by the teams, and about 200,000 lines of third party culture was incorporated into the product. So all in all, it was like 400,000 lines of code that were compiled. For each release. When it got started there, it was, like three years before that the codebase was about 150,000 lines of code that was originally authored by the teams, and had like 500,000 lines of third party code. So you can imagine there were like a product of more than half a million lines of code. So it took a while to compile that. And it had a lot of complexity, due to the fact that there was a whole bunch of third party code in the product. And basically, my time there, large chunk of our time, we were working on actively thinking about third party dependencies and adopting better third party dependencies, sometimes sometimes getting rid of third party dependencies by recreating the functionality ourselves, we even went so far that some third party dependencies because they were not maintained anymore, we adopted that third party dependency in some way, basically, by incorporating that source code in our repository and doing the maintenance there. And then just making sure that we do the attribution to adhere to the licensing terms of the original third party dependency, so that we took like inspiration from a third party dependency. And of course, we did check that that third party dependency had a license on it that allowed us to do that. We'll go into that a little bit more later. So yeah, but you could say that, working on a code base of this size with that many third party dependencies, it was a fun experience. And yeah, it's not like big tech size app that I was dealing with. But it was a reasonably sized app. And even then, we were already running into, like, certain constraints with compilation time, and what Xcode could handle as an IDE in a way that it was still performance for you as a developer day to day. So that's pretty much my experience with third party dependencies. recently. And before that, I've been like an app developer in different capacities. And I have dealt with third party dependencies in different ways. Along those years, for instance, AF networking was a thing back in the day. So I've dealt with that dependency a lot as well, because it was just mighty convenient to not have to write a whole bunch of code yourself. Right. Stefan Blos: A quick question I have, like, yeah, you mentioned that you had like 500k lines of third party code. Was all of the code available, or was that was that closed source. Jeroen Leenarts: Some parts of it were like fender frameworks that were closed source. So we had like a compiled binary, but we didn't have access to the source code. So we could do some statistics on that source code. But most of it was basically open source, third party code. And especially, we had to transition at that project that we were using Firebase. And Firebase was like constantly transferring, like their, their project from like, closed source to open source. So every time we did like a Firebase dependency update, you had like, one or two more frameworks that were like, incorporate completely with source and it was yet again, another bunch of code that you needed to compile every time that you would compile the project, or a while, at least until the cash were like contaminated. So that was like a fun experience. That's every time we did a dependency update. We just basically knew that Firebase would hand us like a couple seconds more compilation duration, every time that we did the updates. Stefan Blos: That's an interesting definition of fun. But Jeroen Leenarts: yeah, it does. It did like, well get the fire going to really dive in on this topic and make sure that we did some things on their project to reduce the impact of third party dependencies and compiling that code. And one of the things that we did So that project was actually adopts a framework based architecture so that we have micro frameworks and all that bunch. But it basically meant that we incorporate the twist as a sort of in between layer. So it allowed us to generate a project file so that we didn't have Xcode project file conflicts anymore. So you define your project in Swift code, which is much more easy to read than a whole bunch of XML, or PDF file that is in in an Xcode project configuration. And it allowed us to do like, pre compiling of third party dependencies. So we could like compile large chunks of our code, like, once every time you pull the new third party dependencies, like updates, so you had to do like once a day maybe. And then the rest of the time, you were just compiling only your own stuff. And that really improved the developer experience on their project significantly, because we were dealing with compilation time, think release times, like 10 minutes. And we were able to reduce that just by adopting tools to like five minutes. And then if you take the caching and all that stuff into count, we basically could do like, a clean compile of our own source code in like, depending on the hardware, like, one minutes, or 290 seconds. So let's, let's do that huge ergonomics improvements for every developer that was working on the code base. Yeah, but that's, that's pretty much enough about me, let's just talk about third party dependencies in general. First of all, I wanted to do a big shout out to Jason Sarita. He recently published an article on his website, Jason sarita.com, titled, The Hidden Costs of dependencies. And I must say that his his article played a large part in the inspiration for this Twitter space. So Jason, thank you. And if you have read this article, then you will see that we have took some inspiration from his article. And but it's good to look up his article. And once we publish this as a as a podcast episode, I will be sure to link his article in the show notes as well. But Jason suneeta.com, you can find it there if you want to see that like right after the Twitter space. So first of all, I think it's good to define what third party dependencies are. And I like defining third party dependencies in a way that you have like three levels of dependencies. Because first of all, you have your own original code, that's not a dependency, that's the stuff that you own, that you have full control over that stuff that you write, then there's first party dependencies. Well, to me, I'm an iOS developer. So first party, to me is anything that is in the iOS SDK, because if I want to write code for the iOS platform, this these API's, these things are available within the iOS SDK. And they have like a certain lifespan, they're usually properly deprecated. So it's, it's, it's something you can plan for. And something you can just deal with and rely on really, that it's there and that it has some level of quality to some level of quality, even Apple creates bugs here and there. So that you need to deal with but at least, you can rely on that code to be there for at least a number of years, when you adopt to those API's in your applications. And then there's what I call second party dependencies. And that's basically third party dependencies that you really cannot do without. And usually those are dependencies that you have to adopt because you are increasingly integrating with like a service provider. So in for instance, you could of course, connect to Firebase, for example, by writing your own stuff. But is that reasonable? Is that feasible? Now you're probably just gonna rely on the Firebase SDK is to connect to that platform. Same goes, if you want to integrate for instance, with with stream products, you're way better off with incorporating our SDK. So that's what I would like to call like, a second party dependency, because you use a certain servers or something online, that you just have to incorporate these dependencies to, to work with these services. And that's why I call them second party. So they're like in between third party and, and first party. And what I define as third party dependencies is basically anything you integrate in your codebase because it saves you time, it's convenient. It does a lot of things that has a complexity that would be unreasonable for you to to do within the context of the codebase or project that you're working on. In some case, this could be for instance, a networking library for some people. Sometimes you expressly don't choose to adopt a networking library, but you can imagine that's basically anything that you can find in In cocoa pods or Swift package manager, or online, if it looks, it looks okay, if it tastes okay, if it works for you, and integrate in your codebase. That's typical third party dependency. And probably with some effort, of course, you can always take those out or replace it with something else or basically your old feature on your own. And I think that's like a good distinction to have when dealing with dependencies. Any thoughts on that? Stefan? Stefan Blos: It's interesting, because like I do when when you noted the differences between first second and third party code, I was thinking about that. And I was thinking like, Okay, first party is clear. That's the stuff we write and third party is also clear. But like I said, I was thinking whether that's weird counting mechanism, that some that I mean, we as developers, sometimes count weirdly, starting from zero and everything. So I thought about like, what a second party really, and I think it's a really hard distinction to make. And I just want to I want to, I want to, I want to clarify that. Everything we will talk about from now on, like every risks, or every thought you should have about third party code. That definitely also applies to the second party dependencies you have, because yeah, this is also has the same properties, like it's someone else's code, Jeroen Leenarts: you could really say that the second part of dependencies, it's really a clear subset of third party dependencies. It's just third party dependencies that have that carries some more weights, or that you are more dependent on because you integrate with a service or a service provider. Stefan Blos: Yeah, I think I think it's an interesting distinction to make and make sense. But yeah, just just wanted to definitely focus on that it's really the same, the same quality requirements apply for those as well. Jeroen Leenarts: Yeah. And also, if you work at a big enterprise, or some company that has like mandatory marketing or analytics dependencies that you have to incorporate in your code base. That's like, that's, that's something I would also call a second party pension, because you as a team, use a team member, you cannot, on your own as a team decide that you do not want to use this dependency, you have to incorporate with it for some reason. Yep. So but that's it, I Stefan Blos: think it makes sense to have those, which is just important to like, definitely think about those at the beginning, because this is probably this, these dependencies, you probably won't be able to replace. So that's, that's that makes sense to think about them like that. But yeah, that's all I wanted to add to your explanation. Jeroen Leenarts: So but what are some ways that you can, can find third party dependencies? And Stefan Blos: so I'm a big, big fan of the Swift package index. I think like the team there has done a tremendous job. I think it's safe to say Florida who also does stuff weekly, right? They, they really created this nice, this nice place of, hey, you need a third party dependency and use Swift packages for that. Just go there and search for them. This is a really, really great starting place, I think. And we are stream are actually sponsoring them, right? Jeroen Leenarts: Yeah, have recently we started doing that, because that we'll get to that a little bit later. But sustainable open source is an important thing to, to work on as a company and as an individual if you have the means and the capacity to do so especially if you use certain dependencies in your codebase. Because somebody is spending the time and the effort to actually create code can be a hobby can be somebody that's doing it to make a livelihood. So and I think, yeah, of course we always like free as in as in free beer. But yeah, it's costing somebody something, right. Stefan Blos: Absolutely. Like other other things to find third party dependencies, of course, like searching for them. I don't want Google are also GitHub offers a lot of functionality. So this also works. And you also notice something down that I actually didn't know about, which is cocoa pods index, something like that exists. Jeroen Leenarts: Yeah, if you if you go to cocoa pods.org or wasn't come, I don't know. But if you go to the cocoa hats homepage, there's like a big search box that you can just search for things. So they also have some sort of indexing going on of any dependencies that they have in the cocoa pot repository, so that you can like install with with the pop command. And the reason I mentioned it here because a while back though the Swift package index wasn't as like, well filled with all kinds of frameworks just yet. And a lot of the dependencies that you were relying on, we're still using Objective C. So what I did a while, was like trying finding dependencies was just a matter of going to CocoaPods. Do some searching there, if you find something, go to the project and see if the project supports like integration with cocoa pods with Package Manager. What's the other one? There's also another dependency management, Carthage. And yeah, and then use the integration mechanism that works for the codebase. And the project that I was working on then and there. So I, for a while I actually use the CocoaPods index as my searching mechanism, but not use CocoaPods itself as the integration mechanism. But still, they still keep updating the index. So but I do like the, the indexing of the Swift package index better, even though that there are more entries in the crockpots index, still at this point of time. So if you have your favorite dependencies, getting it into the fifth package index is just a pull request away. And I know that they constrain really like it if if people submit their own packages, but also their favorite packages to the Swift package index if it's still missing. So yeah, but CocoaPods has an index to answer your question. Yes. Stefan Blos: That's cool. That's cool. Jeroen Leenarts: And awesome. Yeah. So yeah, and also, sometimes I just look for it online, GitHub, Google search. Yeah, just having a look at some some articles, somebody who has an experience with some third party code, you know, people write about stuff that that we, that we enjoy using as well. And with, with Google, and GitHub, it is a bit more hit or miss because you also find a lot of hits that are not related to the technology stack that you're working with. But still, if you switch back to index, or CocoaPods index doesn't provide you any answers. That's all it's always good to have like an extra check on GitHub and Google search or your other search engine of choice, because I've had good experience with Duck Duck, recently as well. So yeah, and then there is one thing that you really have to be aware of when adopting third party dependencies is, of course, the licensing of the dependency that you want to incorporate. Because, at least for the iOS App Store, anything that is marked with the GPL license or a GPL type license, it's a bit difficult. If you just have like a, an Apache or an MIT type license, that's basically a license, no, no guarantees, just do whatever what you want with this source code. And the only thing you need to do is mentioned that you actually use this dependency within your source code. That's, that works much easier and way better for the iOS App Store, because of the federal aspects of a GPL. License. There are some issues there with publishing a GPL license bit of code on the on the iOS App Store. You can find more details about that. But yeah, if you if you are unsure about a certain license that you that you're looking at, or you want to learn a little bit more about the open source license, just have a look at open source.org/licenses. There's like a good rundown there of the main types of open source license. And of course, there's a whole bunch of details and intricacies that you have to be aware of. But I am not a lawyer. So if it really comes down to it, it's always better to like, get a professional involved if it's really important, or very unclear. Stefan Blos: So yeah, just quickly like it, this is a topic that is probably not not the most sexy one. As developers, we don't really want to read licensing terms and everything. But I think it's something that, like, it leads to a quick research on that. Because if if, if if you have, if you may be running into problems with that, and have some some difficulties with licensing that can really come back and bite you in the app. Because, Jeroen Leenarts: yeah, the amount of headache that you can have, if you actually get a licensing lawsuit on you or your company is it's it's huge. And most often it's quite easy to avoid. But of course, again, both of us, we're not lawyers, just just be careful there and get professional advice if it's needed. So, one thing that we didn't talk about yet is what risks you actually run when you are dealing with third party code because yeah, it's it's, of course, good to work with third party code because it avoids you from having to do a whole bunch of work to get the same functionality in your code. But there are also some drawbacks there with third party dependencies. And I think, first of all, when adopting third party dependencies, one of the biggest things that you get to deal with is, of course, the management of these third party dependencies. So you get right from the start without even having looked at the source code of this third party dependency, you're already like introducing some complexity in your project and in your code base, because most often you are using the Swift package manager, or maybe you're still using CocoaPods or Carthage, you're using some tool to get these dependencies in your project. And you have defined some sort of manifest file to actually define which dependencies at which versions you want to get into your project. So you get some free complexity right from the start, even though you are saving yourself, hopefully, a whole bunch of time down the line with using a third party dependency. So I think there are some other aspects of third party dependencies that are to be considered complexity. But one of the biggest drawbacks that I've seen with third party dependencies, especially if they are somewhat larger third party dependencies is of course, it's more code. So it's more compile time. So quite often, if you incorporate a third party dependency, you may you may be sometimes you just need like 10%, or maybe 20% of the actual functionality in this library. But you still aren't compiling the entire library to incorporate this functionality within your code base. A really cool example over the years that you've been seeing a lot was people incorporating open SSL for some certificate handling into their iOS applications. And they were just introducing like, a couple 100,000 lines of code, just to be able to do some convenience certificate inspections. Yes, you are having some convenience by being able to do certificate validations, and certificate pinning more easily. But if you look a little bit more closely, you you probably don't need all this code. And it's a solved problem with first party first party code anyways. And of course, there's no better dependencies out there that make it easy to do certificate pinning, without introducing the OpenSSL as a dependency on your codebase, which is painting the you know where to deal with when compiling. But so yeah, third party dependencies, markup more compile time, but also, third party dependencies quite often have their own dependencies again. So you already mentioned that you did some web development, before iOS development. And I know with the web development ecosystem, especially when dealing with job scripts, as you already mentioned, sometimes you have these projects, that's hardly any original code of the project itself. But there's just piles and piles and piles of third party dependencies being pulled in before the project is even able to start up to begin with. So that's also something you're dealing with, is not only do you have a dependency, but you also get to deal with the dependency graph sometimes. So SAP dependencies and all kinds of stuff that gets pulled in because you are defining your dependence on one single library somewhere. So and do you think there's even more aspects of complexity that you would be introducing when using third party dependencies? Stefan, Stefan Blos: I think you mentioned, you mentioned quite a bit of it, right? I mean, the thing is, like the complexity is to follow thing for open source project, at least you can still have like, a look at the at the code that you're introducing there. So that's like, there's at least a way to see how complex the code that you're incorporating is four source frameworks, you don't even have that. So just have to rely on the creators there. So that's, I think, something that also ties a little bit into another aspect, which is security. So if you have open source projects, and again, security wise, at least you can have a look at the code and you can be sure that there's no shenanigans shenanigans going on there. So I think that's, that's an important thing to keep in mind. Because for closed source, again, you rely on the person, company, or whoever creates this package or this dependency, to not do anything dubious with the code you're incorporating in your app. And again, if it's the people, or if the if the package stuff that it's part of your app, so it's part of your responsibility to make sure that this is not happening. So I think it's, I think it's a good thing to keep that in mind. Always when incorporating code that security wise, you have to make sure that Nothing, nothing wrong is going on in the code you're incorporating inside of your apps. Jeroen Leenarts: Now, it's an effect that I've also seen with, with many companies, especially above a certain size that then at some point, because of reasons, I always call them reasons, you get into the situation that it is required that any third party code that is not from a accepted vendor. So that's pretty much any open source and any, any library out there, you have to do a 100% code review of the third party code, and you have to do that 100% code review, anytime that you update the dependency. So you also need a mechanism there to make sure that you that you only have the approved bunch of codes for a specific version in your repository. So then you get for instance, the situation with with CocoaPods, you can do like to do the pod install and have all the source code in your directory there. And then you just commit this whole bunch of project with code of the third parties as well. And with Swift package manager, you can, of course, pin on the on the good hashes. But then you have to make sure that you verify those good hashes as well and prevent colleagues from updating these hashes without the proper approvals and review, which is all bunch of headache in itself again. And of course, first party dependencies are special because you don't have any influence on those. So you don't need to look at those at all. So that's interesting. But that's one of the reasons that I see with big companies with big corporates that they they have a tendency to move away from third party dependencies, because for the teams itself, the effects of using a third party dependency is often more headaches, and then the problems that a third party dependency might solve for them. So you get this bit of not invented here, syndrome going on there, that can be ingrained within the person itself. And that's also something to touch upon. Because when dealing with third party dependencies, it's like it's like a balance you have to run. Because sometimes incorporating third party dependencies is good. Sometimes it's not so good. So you have like, I always like to call them the two syndrome problem. Because the if you rely on only third party dependencies, and you have no clue how they work, then you will run into the issue that you might become like a third party dependency developer, so you don't know what's going on within the third party dependencies. But hey, it works. So let's move on. And hopefully the best, right, because you have no clue what you're dealing with, you have no idea what's actually happening. If you run into issues, for example, Stefan Blos: they are interesting problem, right, because like, once everything were over, when everything works, it's cool, you can be happy about it. But once you reach a point where you get issues, so get arrows, then it becomes really hard because you need to really understand everything to solve these problems. And this can become a problem depending on the dependency you have. Jeroen Leenarts: And sometimes dependencies can can have issues with each other because they try to adopt or modify behaviors in like system classes by like doing extensions and productive activity with swizzling. That, that they actually start like interacting with each other in a way that's not very helpful. But yeah, that's, that's also one of these issues that you can run into if you rely on third party dependencies a lot. And also, if you just are out of luck, and just happen to incorporate two dependencies that have this issue with each other. Because there was a time within swift that, I don't know, everybody was creating, like string extensions. And you could just pretty much guarantee that if you would go beyond like five swift packages that you would rely on that you would, at some in some way have like a weird interaction because of these string extensions. And unfortunately, now those are more like hidden quite often. So within like, the dependencies themselves, but it's been an issue over the years, the opposite spectrum of the sort of, it's a spectrum with this third party dependencies. And if you like a third party dependent developer, then there's also an opposite to this spectrum. And that's when you are dealing with the not invented here syndrome, because you probably have seen these people any source code that is not written by themselves, and maybe their team members. That's like and they don't even look at it and it's bad. That other speak other people's code is in no way in any way. It's possible that it's even any good and that's what I call the not invented here syndrome. Because I've seen quite often in projects that like a bit of source code was adopted, the new team got on a project and the first thing within a few days What the whole team is saying that whatever these previous developers were doing, they were crazy. They were stupid. They were doing things that how would they even come up with these solutions? Because they are no solutions? Well, that's the typical modern transportation from going on there. And the same holds true for third party dependencies. Because, yes, sometimes it's good to have third party dependencies, because it's, it saves you more headache than it might give you. But sometimes you run into people that say, like, any third party dependency is bad. And they just like, it's almost like if they see a third party dependency, they want to get out their pitchforks and torches to like, chase them out of the codebase. Stefan Blos: Because also, like, there's a learning curve involved here. Yeah, that actually like ties into our next point as well, on how to choose to adopt a dependency or like which dependencies you might have, or maybe maybe helpful for you and which ones are not. And I think like this, this learning curve is basically I had the experience, and that's again, from my previous shop, and it's from web development, but it's exactly the same for friars as well. So, like more junior people, and we had this situation more often in a project that like, some junior developers, they got tasked with with a thing to do like the JIRA issue, or whatever. And they thought about, Hey, how can I do that? And then they said, Oh, nice, there's a, there's a package for that, I could use that, right. And then they just did that. They didn't know how it worked. They just incorporate the dependency, and they were happy that it worked. And everything was fine. Whereas the more senior developers, they were, they were basically questioning that. And they were thinking about, hey, does it make sense? Is it feasible to implement this on our own? Or is it really a good thing to incorporate this dependency? Because this may be a solved problem? This may be very hard to replicate on our own. So is it worth to implement this on our own? Or is it actually feasible to use this third party? And I think that's a thought process that should basically be there every time you think about implementing or using a dependency? Because that's, it's always this, this balance of do it on your own or use the third party code there. Jeroen Leenarts: Yeah. And when looking to third party implementation, so like projects on GitHub, really, you you have time you develop like this, this sense of if, if a third party dependency is any good, because it's like fat, your opinion on a dependency is fed by what you're seeing on GitHub? how responsive are issues dealt with? Are there any, like, issues that like, remain open for like months on lands? What are people saying about this stuff in articles online? Because if there's a couple of people who write about a specific third party library, and they're positive about that, good news? And also, yeah, it's just it's just like this this assessment that you do before even looking at the source code, just how does this project look on GitHub? Do you have to read me in order to have like, the last term, so you have a contribution, contributing guideline, you know, just the basics to check off all the boxes, to see whether or not it's like a true open source project or not? Or if it's just some bit of code that somebody just put out? Because it was convenient to them, and they just wanted to share it? Because there's a difference there. You know, it's all about sharing. But then the follow through that you do after you do the initial share that that's what counts there. And especially what's a very good question to ask yourself, looking at a third party dependency is what you pay for this feature set if it wasn't available for free. So if somebody said, Hey, I have a nice library here, it has these nice features a check some boxes, would you would you as a person or a project or a company be willing to hand over cash, actual hard currency for this feature set because it saves you time? And it's worth it to you? And if you if you can answer that question with Yes, then most likely, you have dependencies in there that that's worth worth your time and effort to incorporate and deal with in your source code. But it also leads to another question. If you would be willing to pay for a third party dependency, why aren't you sponsoring this project? And, and I think that's, that's also a very good one, too, to think about. Because quite often, we use all kinds of third party code, awesome code sometimes. And we just use it, we just like, feed our own careers on it, and we're able to, like have success due to the work of others. I say it's a good thing to pay it forward a little bit that if you as an individual or a company have a lot of success because of certain third party dependency or third party code that you're using. Just Just throw some money to these projects, and especially if it's like a month over month recurring, a contribution that you're doing as part of a sponsorship. So an ongoing get up sponsor, even if it's just $5 a month, for just somebody working on a bit of culture that's like, that means the world to them. Because imagine, if you have like 20 or 30 people, each of them handing you over like a few dollars each month, then all of a sudden, them working on this initially hobby thing of them, it's actually becomes feasible for them to spend a little bit more time and a little bit more effort on it. So that's the support and the maintenance of the third party dependencies that you are so dependent upon, actually continues into the future, and people are able to have the same benefits as you. And maybe you can come to the same conclusion that, hey, this person here or this group of people here, doing this work on this dependency, that's just worth it to have around, right. Stefan Blos: It's also a thing, like, I can definitely support everything you just said, and it's a it's a general thing about open source work, that the people that are doing that are oftentimes doing it in their free time or in their spare time. And it's quite fascinating sometimes to realize that some of the packages are maintained by single people. And sometimes hundreds or 1000s of companies are using that. So it's, it's sometimes a shame that third party or open source developers are not really supported in the way they deserve it. And again, there's a there's this anecdote from from the web world, maintainer of some NPM packages. He was like, asking for a few months about people, hey, I need to I need some support, like I need to pay bills. I'm working on that. And there were literally like, hundreds and 1000s of companies using that these packages. And after, after Nan decided to actually supported he took those packages down. And it resulted in a big chaos, because like every every company who was relying on that, that dependency, and these packages were actually like, very surprised and shocked that he actually did that. But like, it's a reasonable approach, because supporting open source contributors is really a thing that is not done enough and should really, really be be done in a Jeroen Leenarts: better way. Or more often than it just starts with with you, the individual just like picking out your wallet and just throwing some money somewhere, or just telling your, your project manager that. Yeah, this dependency, it represents this amount of work that we did not have to do. So it's reasonable to at least throw some money their way as a company, because they saved you so much time and effort. And, yeah, in that way, then we can make sure that that all this open source that we can build upon, it stays available. And then we also get to the last and final topic of this tradespace. And that's how to deal with dependencies in the long run. Because, of course, new dependency, it's amazing. It looks great to get up and it works well. And then you incorporate it and things are good. You release your product. And then things happen, right? So often what happens with third party dependencies, especially open source, once the maintenance, they move on they they start doing other things, or they have another project or their interest is just not there anymore for this third party dependency to to keep up to maintenance with it. And then how can you deal with it? I think there's three things that you can do, the, the harshest thing that you can do is to just say goodbye, just take out this dependency of your code base and in some way replace the features in this dependency, either with your own code or another third party dependency. Another option would be to privately adopt the third party dependencies. So that basically means technically putting it in your repository and doing the bug fixes and changes that you need to make sure that dependency is feasible for you in the long run. Of course, you have to adhere to any licensing terms that are on there. And the final option is to openly adopt a dependency and that's also something that you can do right from the start If you've run into any issues, instead of like posting an issue and complaining that there's no responsiveness on the on the issue or on GitHub. You can also like create an issue and publish your fixes as a pull request to this situation. And quite often you will see after some back and forth and some review any maintenance they will gladly incorporate your changes into their codebase and if the maintainer is not available anymore You can always well get ownership of the repository or forked repository and openly continue the support and development of our dependency. Stefan Blos: I really want to strengthen the last code you mentioned, like doing pull requests, and trying to add or help the project maintainers. To solve problems is, again, something that's really underappreciated, because like, it's, it's, it's beneficial on many levels, like, you can support the maintainers. You can even support other people who are using this, this package, because they might run into the same issues that you have. And third, it actually really helps you to better understand the structure of the of the code you're incorporating. So you learn how the project is set up, you learn how it's structured, and what the words are, architecture is and everything. And you really better understand everything. So I think it's a really beneficial thing to do, you should definitely consider doing this. Jeroen Leenarts: And if you're a project maintainer, have a little bit of source code, or you actually have some pull requests that are incorporated in in an open third party dependency. Quite often, there's like a great conference talk in there as well, because people are interested in what things you do with open source code. And especially if it's an, if it's a if it's like an open source package that is used by a certain amount of people, just sharing your experiences there, and why you used it and what it did for you. That's just already a talk topic in itself that you can easily submit as a call for paper on any conference. And it really builds having some pull requests adopted into a GitHub repository, it also really builds your online portfolio, and helps you like, to your next project, or your next job, from a better position as an experienced more experienced software developer. Stefan Blos: But you never know how many people might might find this useful, right? You may find like two two users, or to customers who are really, really happy about the code you published. So that can even be like a motivational factor as well. Jeroen Leenarts: All right. I think that's what he wants to share about third party dependencies, right? Stefan Blos: I think so. Yeah. Are there any questions from from the audience here? Because then you, you still have a few more moments, if you want to ask some questions here. Aside from that, I think you did a did a good circle back on, on the call to action about submitting talks to conferences. That's a very valid point. A lot of a lot of come. Conferences, conferences are actually offering things for first time speakers and everything. So definitely check that off. We have a question from Andre. Who is connecting? I think and if you want to mute yourself, Andre, you can ask your question. Unknown: Guys, first of all, thank you very much. For a great topic. It was quite this interesting. And the question is following. If we consider a large project that lasts for years, we've got, you know, actually many of not big and too widespread dependencies, such as Firebase, for example, or RX Swift or snap kids, etc, etc. We've got many of small dependencies, like, for example, custom date picker, or something like that. And I faced actually a situation where some developers will were aware of this small dependencies, and some of that some of them tried to do it natively, to coat the same elements natively, and how to provide good awareness of all of all small dependencies throughout the project for all developers, for example, in geo geographically spread team. Jeroen Leenarts: That's a good one. Can you can you answer that one? Stefan, what are your thoughts? Stefan Blos: I think, I think so you basically mean the developers that are on the team of the app developing that has the dependencies. Okay, so I think I think, what's always a good thing is to have a list of dependencies you have. So for example, if you have an internal of a key or something, it definitely makes sense to document which dependencies you incorporate. Also the reasoning behind those because In the system something point you can go back to, for example, you mentioned like a custom date picker or something. Maybe, maybe maybe if the project is longer running, you can come back to this after each maybe data to see for example, and reevaluate if the dependency is still necessary, maybe, maybe there's some first party code or some code from Apple who might replace the dependency. So that's the thing to, to keep in mind there. But I think it's it's always good to have some documentation of which dependencies you have, and be very transparent about, why did you incorporate that? How to use it, when to use it? And when to evaluate if it's still necessary to, to actually have this dependency in the project. Your own any other thoughts on that? Jeroen Leenarts: Yeah, what I tend to do is have our Markdown documents in the repository that just lists out dependencies that we're using. So at least the main dependencies, not the sub dependencies, but then also, with either references or the actual description why this one was incorporated. And, for example, with with networking plus you had like NSURL session, and there was like another networking NSURL connection before that. And with NSURL connection, you really wanted to do your networking with a third party dependency, and that became less so an NSURL session. So if you get these kinds of changes within the first party dependencies so within the iOS SDK, then that's a very clear point in time that you have to reevaluate your choices with your dependencies. And then assess whether or not you want to keep on using this dependency or migrate away from them. So it's, it's, it's something you have to plan for really, and having some notes and some documentation on why you adopted the dependency in the first place, is really helpful in this case, and it is a document that you probably you read it and then you might not even look at these lines for like a year, maybe longer. But having it's there available when you are reevaluating your dependencies, then yeah, it's very helpful to have some documentation on why you adopt something in the first place. Stefan Blos: Does that answer your question? Unknown: Yes. Sounds really good. Thank you. Stefan Blos: Thanks for asking. All right. If there's no other questions, I think we've covered everything we wanted to write. Jeroen Leenarts: Yeah, yeah. And I'm about to run out and go fetch my kids from school. So great timing, actually. Perfect. All right, um, no, raise hands. So talk to you again, on the next readyspace. If you run into any questions, afterwards, feel free to send us a DM or a message on Twitter. And we always love to get some feedback. And yeah, thanks for your time, and thanks for listening. Stefan Blos: Thanks for listening everybody. Bye bye.