UIBuzz - Software and game development

What's up everybody? Welcome to another episode of the UIBuzz Podcast. I'm your host, Peter Witham. You can find me and this podcast at peterwitham. com This episode we are talking all about source control and specifically about repos and ones that don't belong to you and whether you should fork them or just trust that they'll always be there.

So let's get into the details on this And little bit of a painful background story here. I'm sure maybe many of you have experienced this, certainly some of you have. Now, it's almost impossible these days unless you almost go out of your way to not use a technology that has some kind of third-party repository attached to it. A classic example for me is anything with React Native, of course. has an absolute mountain of dependencies and third party libraries. And most of the time those third party libraries they exist in repositories, right?

On GitHub or whatever service you want to use, but most of the time it's GitHub. Now there exists a problem here and the problem is this. If you rely on a third-party library And one day the author decides, you know what, I'm done.

They take it down or they don't keep it up to date and it no longer works with your tooling or platform of choice or version of platform, whatever it may be, something breaks it And you now have a problem because number one, if it doesn't exist anymore, well you're just flat out screwed.

Or maybe you can find a copy of it somewhere Number two, if it's broken, um you're either waiting for them to fix it and maybe that will never happen. or you fix it yourself. And if you do fix it yourself, I hope that you do the right thing and submit a pull request and have those fixes go back into the main repo for the benefit of everybody else.

However, the end result is you got a problem, right? Now one potential solution is that you fork that repository from the get-go.

From from day one, you decide you're gonna use it. So you make your own copy on your own GitHub account or again whatever service of choice Now you're gonna use your copy, which you can update, you know, from either changes you make. or from the master one, the original owner, those kind of things.

But at the end of the day, you are using your copy of the repository. So if the original one goes away the impact is clearly reduced if not completely removed that you've got a problem because you're working from your copy. Okay?

Hope hope that makes sense Now the question becomes do you do that with every repository that you use Or do you do that selectively? And I don't know that there's a a universal right answer.

I feel like There's an obvious answer here, which is um we've all learned to to try and protect your future as best you can. because I know this scenario has happened to me, I'm sure it's happened to a lot of y other folks, and we've all certainly those who read developer news stories, feeds, whatever have read about cases where this happens a developer decides screw it I now hate X and I'm bringing the repository down or I'm intentionally gonna break it.

Whatever it may be, right? So there's a better than average chance these days that it might affect you at some point. The obvious answer is yes, you fork them all, and then you can sleep a little easier at night and your code will hopefully be okay. That is certainly one way to go.

It adds a level of maintenance and overhead, although there are automation tools that you can use these days to protect against this sort of thing that act as, you know, kind of an intermediary proxy that says Oh you want that repo? Okay, well look you let's I'll add that to my service and you can pull it from there automatically and I'll just take care of everything for you.

And there's a bunch of tools out there that do that I'm not gonna list them off, but but there are tools that will do this for you and take away some of the pain. So that is one option and arguably the Easier of the two for you know sleeping better at night. The other option is that you selectively pick them, which I don't know that there's a good process for that because Whether what whatever your criteria is, like let's say, oh, it's a company behind this repo, or it's seeing regular updates over years And therefore, this is great, I can just trust it, or this one is a one-off by one person or hasn't seen an update in quite a while and I should make a copy of it.

I mean I don't know. You would have to define your own criteria for that and uh arguably whatever you pick Might be right, you might be lucky, or you might be wrong. But either way you're sort of gambling a little bit, maybe Um the other option is that you just don't do anything and you just use those third-party libraries and repositories directly and just always trust that it's gonna work Which is probably the worst plan, right? Now I say that because let's say that hypothetically you say to yourself at the beginning, you know what, it's fine.

This is just a test This is just a prototype, an exploratory whatever to see if this is a viable solution or whether anybody even wants whatever you're building And therefore if something happens it's not the end of the world. Okay, that's fine. Problem there is, what if it turns out that you were right? And it is successful and people want it.

And as we all know these days, prototypes become production in a heartbeat, depending on the scenario. And now now you're sort of like, oh, you know what? I I had this success and I wasn't necessarily expecting it and now I gotta deal with it. Yeah, you could go back and and realign those repos, of course. Uh, but it's all technical debt, right? And and you're building it in from the get-go. But arguably you're building technical debt if you fork it and maintain it. I don't know.

Like I say, it's gonna be an answer for each of us. I think if you're a team, you absolutely should discuss this. No question. Because like I say, this this happens more often than you might think, especially this day and age where technologies come and go overnight. We've all done the joke about the next JavaScript framework, right? So I'd love to hear your thoughts on this.

Just putting that out there in this episode. For me personally, on my personal projects, I try not to use third-party libraries if I can help it. But of course There's always gonna be one or two. And uh I I I do it on a case-by-case basis. Um if I'm doing something for a client or a day job or something like that I build in that level of foul safe to have a copy because you just don't want to be that one that finds out two o'clock in the morning the build doesn't work because this repo doesn't exist or is broken or whatever.

Okay, so that's kind of my stance on it. Love to hear what you think though. Reach out to me at peterwitham.com. There's a contact form there. This is something you have to think about. It's as simple as that. Doesn't matter what it is, you you owe it to yourself and to everybody else you work with and your products to think about this and and come up with some kind of plan or solution.

That's it folks. This has been helpful, you know what to do. Tell one of your developer friends about it You want to go the extra mile, buy me a coffee, help, help this content stay alive, go to peterwitham/bmc.com.

That's it.