Under the Radar

37: Code Reuse


00:00:00   Welcome to Under the Radar, a show about independent iOS app development.

00:00:03   I'm Mark O'Arment.

00:00:05   And I'm David Smith.

00:00:06   Under the Radar is never longer than 30 minutes, so let's get started.

00:00:10   So after a couple of weeks of having topics that are a bit more conceptual and a little

00:00:15   bit more topical, I thought it would be fun to dive into something a little bit more technical.

00:00:19   Not too technical, don't be afraid if you're, if you listen to the show but you're not a

00:00:22   programmer, but something a bit more in the weeds.

00:00:26   And specifically, I kind of wanted to talk about code reuse.

00:00:31   And the degree to which it makes sense to take aspects of our programs and turn them

00:00:39   out and sort of cut them out and put them into libraries.

00:00:42   So you know, take a functionality and rather than having it be tailor-made for a particular

00:00:47   app, try to make it sort of somewhat more generic or reusable.

00:00:52   And specifically, this is something that I've been really, I would say, struggling with

00:00:57   recently as I've been working over this summer with my app updates.

00:01:02   Because I'm now in a position where I have a bunch of different apps that largely do,

00:01:07   they have very similar aspects to them at their core, but are very different in their

00:01:13   actual use.

00:01:14   You know, so but most of my apps now, all these health and fitness apps, all the plus

00:01:17   plus apps, use health kit in one way or another, for example.

00:01:23   And I keep finding myself going back and forth on whether or not I should take my, all my

00:01:30   sort of my health kit management and front-end code that deals with, you know, pulling data

00:01:35   in and out of health kit and authorizing things, and I should pull that out and turn it into,

00:01:39   you know, some grand unified library to deal with health kit.

00:01:43   Or if I should do what I have been doing right now, which is taking the approach of learning

00:01:49   lessons each time I kind of implement it, but ultimately having custom tailored solutions

00:01:55   for each of my apps.

00:01:57   And I feel like this is one of those things where ultimately there's probably not a right

00:02:01   answer.

00:02:02   It's sort of like a Vi and Emacs kind of a problem where there's just different ways

00:02:08   to do it.

00:02:09   Because both sides, you always have these pros and cons.

00:02:12   If you take something and make it super generic and like this is a great library that's super

00:02:18   reusable, that's great in concept and can sometimes give you some great benefits in

00:02:23   terms of, you know, if you find a bug, you can fix it for lots of different places.

00:02:27   But then you also have the downsides of now you have all these other complexity to manage

00:02:33   in terms of if you make a change in your library, it could potentially affect all your apps

00:02:37   at once and in ways that you aren't expecting.

00:02:40   Maybe one of the apps is expecting that bug to be there because it's sort of had coded

00:02:44   around it or against it.

00:02:46   And it can make things really complicated, but intellectually or academically, it seems

00:02:50   like that's a better thing to not repeat your code or similar code in multiple places.

00:02:56   Or you can be super pragmatic and say like each of these apps has the tailor-made solution

00:03:02   for it.

00:03:03   And in some ways that seems really good.

00:03:06   And so I keep going back and forth about it.

00:03:08   And ultimately, I think I tend to almost always go on the side of just tailoring a custom

00:03:15   solution to each of my applications and just giving myself permission to be okay with the

00:03:20   fact that that means that I have in my code base at large, there are bits of code that

00:03:25   are repeated and just say like that's okay.

00:03:30   That's not theoretically or academically the best, but that kind of works for me.

00:03:33   But I was curious to hear what you do, Marco, because obviously you don't have as many different

00:03:37   apps as I do, but you have built a number of apps for long enough that I imagine you

00:03:42   have a lot of things that you could kind of turn into libraries and reuse them.

00:03:47   And how do you tend to approach doing that?

00:03:50   I mean, so you're right.

00:03:52   I don't really face it as much as you do because I just don't have very many apps I'm working

00:03:57   on at any given time.

00:03:59   But I do build up common libraries, frameworks, things like that just over time.

00:04:06   I think many programmers do this, if not most.

00:04:10   I hesitate to say all because who knows what everyone else does, but I would guess this

00:04:13   is very, very common that everybody kind of builds up their own kind of personal collection

00:04:17   of utilities and things that they like to use.

00:04:21   There's always, as you said, there's always this kind of balancing act where if you try

00:04:25   to make something that is generic and reusable and stable for use in multiple apps and everything

00:04:32   and it handles all the various edge cases that any kind of different use could have,

00:04:37   it is a lot more work to make that thing.

00:04:39   To make whatever component that is, it's more work and you might never save that work.

00:04:46   You might never reap the benefits of that because you might put all this effort into

00:04:49   making something reusable and then never reuse it.

00:04:51   Or reuse it in one other place where a copy paste would have been fine or re-implementation

00:04:56   wouldn't have been that much work or whatever else.

00:04:58   So there's the whole angle there of whether you make something reusable and generic at

00:05:04   all or not or whether you just kind of stick it into your app in some kind of semi-orthogonal

00:05:09   way that is semi-generic and just kind of hope for the best and just keep going and

00:05:14   get your work done.

00:05:15   And so I find myself doing this with a small collection of things.

00:05:19   So in Overcast what I do is, I have my public collection of open source utility things called

00:05:28   FC utilities for my company Full City Utilities.

00:05:33   And we'll talk about open source a little bit later.

00:05:35   I've actually debated pulling it down and closing the source again just because maintaining

00:05:39   it is kind of a pain in an open way.

00:05:42   But we'll get to that.

00:05:43   So I have FC utilities as like this kind of separate collection of generic utilities.

00:05:49   And then in Overcast I have a private, just a folder, like a group in Xcode, just a folder

00:05:55   of files that I call FC utilities extras, which is like components that I make that

00:06:01   I think might be reusable someday.

00:06:03   It's kind of like a staging area before they go into the main library of my open source

00:06:08   and shared components.

00:06:09   Kind of like a staging area of things that, you know, I'm making this code that this might

00:06:14   be useful.

00:06:15   I might reuse this.

00:06:16   I'm going to write it in a way that it could be reused.

00:06:18   I'm going to write it in that kind of generic, reusable, edge case compatible way of a level

00:06:24   of quality that I would expect from that.

00:06:26   But I might never release it.

00:06:28   Or I might never use it anywhere else.

00:06:29   So I kind of had this kind of middle area that helps me decide or that gives me a place

00:06:33   to put things like that that are kind of, you know, in the middle or in a gray area

00:06:36   or underdeveloped in that way.

00:06:39   And I do find myself needing to reuse things between Overcast and occasional other things.

00:06:48   So occasionally it might be something else in iOS, although that's rare because I don't

00:06:51   usually do multiple iOS apps at once.

00:06:55   But I do have now, as I mentioned last episode, I am making a Mac MP3 kind of toolkit app

00:07:04   for putting chapters in podcasts and stuff.

00:07:07   And so I am dealing with a lot of the same kind of low level audio handling, MP3 handling,

00:07:13   reading and writing of chapter metadata, stuff like that.

00:07:16   I am having a lot of things now where I need code reuse.

00:07:20   And I have faced this dilemma multiple times.

00:07:22   Do I consolidate, you know, Overcast tag reading thing into this tag reading thing and make

00:07:27   it one thing?

00:07:29   Or do I share this low level audio reading code or not?

00:07:33   And then when I do want to share it, what are the mechanics of that?

00:07:38   Do I just copy the .c and .m file over?

00:07:40   Or the .h and the .m file over?

00:07:44   And copy it into the new directory?

00:07:45   And that has a lot of advantages in simplicity and in lack of any kind of external dependency.

00:07:52   But that also kind of sucks from a version control standpoint where if you then improve

00:07:57   it in one place, the other one doesn't get that improvement.

00:08:00   Or if you fix a bug, the other one doesn't get that bug.

00:08:01   And you have to either just not backport it or manually switch it over or copy it back.

00:08:07   And obviously we try to avoid those kind of hacks in programming these days because we

00:08:12   know as a practice that's generally a bad thing.

00:08:17   So then do I make a library?

00:08:20   Do I make an actual, like...

00:08:24   Do you actually use dynamic libraries in iOS?

00:08:29   I never have, no.

00:08:30   Like you can talk about things in, like, when you build stuff with Carthage or you could

00:08:34   build them manually.

00:08:35   Like, I've never gone down that road.

00:08:37   Because I always find myself thinking, the inertia I have to overcome before I was like,

00:08:42   "Okay, this is worth going through this process."

00:08:45   Where now suddenly it's this whole, like, building my app is not just as simple as hitting

00:08:49   build in Xcode.

00:08:50   Like, there's dependencies I need to manage and version control that I need to keep track

00:08:54   of.

00:08:55   And if I want to rebuild a particular version of my app, that's now a more complicated question.

00:09:01   It's not just like, check out of Git, the tagged version for that release, and say,

00:09:07   like, this is the code.

00:09:08   And I also then need to make sure that it's pulling in the right dependencies and all

00:09:11   that kind of stuff.

00:09:13   So I've never gone down that road.

00:09:14   But I know what you're talking about, where you turn it into something that's a much more,

00:09:18   you know, into a concrete version of that dependency and say, like, this is the library

00:09:25   that I'm going to add into my project.

00:09:27   Yeah.

00:09:28   I mean, I generally have a kind of allergic reaction to any kind of overhead of fighting

00:09:35   with my tools on things like module management and, you know, submodules, libraries, any kind

00:09:44   of, like, dependency managers.

00:09:46   Like, these things can so often become such massive time sinks and such pains in the rear.

00:09:52   And a lot of times, I don't feel like the benefit I'm getting by dealing with that is

00:09:58   worth all that pain.

00:09:59   You know, a lot of times, I feel like I'm just fighting the tools for, like, an hour

00:10:03   or more to just do something simple, like, okay, I want to reuse this code in a way that

00:10:07   is, like, you know, academically sound, like, that is, like, principally sound.

00:10:13   You know, so maybe it's a Git submodule or a subtree or maybe it's, you know, just requiring

00:10:20   a second checkout that's, like, in parallel with this one, like, you know, at the top

00:10:24   level directory.

00:10:25   Like, oh, just include dot dot slash utilities slash whatever and just require you to always

00:10:30   have that checked out, which is also a terrible solution.

00:10:34   And then you have, you know, whether you build it as a library or whether you just link it

00:10:38   all in as, you know, from source files into every app that uses these things.

00:10:42   And there's all these kind of, like, technical and management different decisions you can

00:10:46   make about how you incorporate code from other places, whether you just copy it in, you know,

00:10:52   just copy the files in or whether you do it, quote, properly with some kind of submodule

00:10:55   or subtree or library kind of system.

00:10:58   And, again, it's just so much overhead.

00:11:01   And I just so often when I do that, I feel like I'm just fighting the tools and moving

00:11:06   paper around.

00:11:07   I mean, it feels like administrative work.

00:11:09   It doesn't feel like I'm actually producing much.

00:11:12   And so often that work is not worth it because it brings on such an incredible level of complexity

00:11:18   and just fiddliness and fussiness and fragileness or fragility, whatever the word is, to just

00:11:24   something simple.

00:11:25   Like, okay, I want to check out everything required to build this app from the source

00:11:29   repository and then I want to build it.

00:11:31   How hard is that?

00:11:32   How many steps does that take and how many ways can that break?

00:11:36   And so often when you get into some of these systems, it just gets unwieldy.

00:11:39   Sure.

00:11:40   And even you start to think about things where you say, oh, like, I don't actually do that.

00:11:44   I mean, this is the kind of thing that I say to myself a lot.

00:11:46   Like, I'm one developer.

00:11:48   I don't have to deal with, like, a lot of the usual complexity even of if I have to

00:11:53   check this out and get a building.

00:11:56   Because when you have a larger team, keeping everybody in sync is a much more difficult

00:12:02   problem.

00:12:03   But I certainly run into this situation a lot where, say, I'm going out of town for

00:12:09   a week or for a couple weeks, or I'm going to WWDC or something like that.

00:12:13   I want to make sure that I can build my main apps when I'm on the road in case something

00:12:19   comes up.

00:12:20   You never know.

00:12:21   I've done release builds to the app store while I was on vacation because some weird

00:12:26   situation occurred.

00:12:27   Like, that's not what I try to do, but that's certainly something I want to be able to do.

00:12:31   And the worst thing that you can run into that situation is when you're doing that kind

00:12:34   of work, and then all of a sudden you're like, oh, I don't have that file that I need from

00:12:39   my main Mac because it wasn't checked into the main repository or something.

00:12:46   And even just being a one-man shop, I'll still run into that problem.

00:12:50   And so I always find it's this weird tension too.

00:12:53   I feel like in so many things in programming you have this tension between doing it the

00:12:59   right way.

00:13:01   And the supposed benefit of doing it the right way is that it's like in aggregate or over

00:13:12   the course of the whole development project, you'll end up better.

00:13:15   And you'll think yourself two years down the line when you've saved yourself all this time

00:13:20   or hassle or saved all these bugs or issues.

00:13:24   That's the promise that all this work is paid off by.

00:13:29   But it's the weird thing of that it sounds good when I was learning computer science

00:13:35   in college or something, where you get into design patterns.

00:13:39   And it's like, well, what you really should do is have this really generic system by which

00:13:44   you can have a factory that creates observers that are loosely coupled to your actual model

00:13:51   objects and then you can dynamically change that in and out if you change database backends.

00:13:57   You can invent all these systems that sound academically really cool and have these abstract

00:14:03   benefits that are tangible and sound sweet.

00:14:08   But I was so rarely--maybe there's a slight selection bias to it, but I don't think that's

00:14:15   actually the case.

00:14:16   And I think more often than not, I've never really reaped those benefits down the road.

00:14:21   I don't look back and be like, "Oh man, I'm so glad I went through all this effort to

00:14:25   put all these armatures in place to make my app work better rather than just coding and

00:14:33   just putting it together."

00:14:34   And certainly there's some amount of that.

00:14:38   It's probably kind of like if you're a chef or something like that, where if you watch

00:14:44   cooking shows and you watch chefs cut vegetables with ridiculously sharp knives, ridiculously

00:14:49   close to their fingers, it's not the way that you teach your kid to cut vegetables in the

00:14:57   kitchen.

00:14:58   For them, you're like, "Hold the carrot way on the other end and keep the knife far away."

00:15:04   And maybe that's what you would need to do.

00:15:07   And when you're starting out programming, everything's safer, everything's a bit cleaner.

00:15:13   But as you get good at it, after you've been a professional developer for a long time,

00:15:18   I feel like I kind of have more of an intuition for these types of problems, where I look

00:15:23   at it and sometimes I will make things more abstract, or I'll pull things out.

00:15:27   And sometimes I'll just copy-paste the same function twice, sometimes even in the same

00:15:33   project.

00:15:34   I'll have this basic, very similar functionality repeated a couple times, and it's like, "I

00:15:38   could take this and make it generic, but if I did that, I'm aware of all of the downsides

00:15:44   of that and all the issues that are later going to come and bite me."

00:15:49   And often those issues are more direct and practical, rather than the kind of abstract

00:15:53   benefits and things that I'm avoiding by being abstract.

00:15:59   And I feel like that intuition is the thing that's so unsatisfying to me about this, because

00:16:03   I wish I could put it into a rule.

00:16:05   I wish I could say, "When you're doing this, if you're writing code that would..."

00:16:12   I try to come up with rules like, "Would this make sense if Apple released it as an addition

00:16:18   to Foundation or an addition to UIKit?"

00:16:21   And if they would, if I could imagine Apple adding something like that, then maybe it

00:16:26   makes sense as a library.

00:16:28   I run into this with date comparisons or things like that.

00:16:31   A lot of my apps have a concept of, "What's the start of today?

00:16:36   What's the end of today?"

00:16:37   Very basic date operations that I do a lot for, in pedometers, saying, "Which range of

00:16:43   steps should I display?"

00:16:45   It's like, "Well, it's from the start of today till the end of today."

00:16:48   And I have pulled those into a bit of libraries because I would be entirely reasonable if

00:16:53   NSDate had a function on it that said "Start of date" or "End of date."

00:16:58   And so that seems like that makes sense, but anything that wouldn't make sense that isn't

00:17:04   like...

00:17:05   It's almost like you need...

00:17:06   Maybe the better rule is to say, "In order for it to make sense to have a generic solution,

00:17:10   it has to be a generic problem rather than a generic solution to a specific problem,"

00:17:17   or something like that.

00:17:18   Maybe that's kind of where I'm ending up as I'm talking this through, for turning something

00:17:23   into something that's a generic reusable thing only makes sense if it is a truly generic

00:17:28   problem that it's trying to solve.

00:17:29   Yeah, I'd say that's a very good rule, and we'll get into open sourcing and how that

00:17:33   plays in in a second.

00:17:35   But I also just want to add a little bit, just to clarify a point you made a few minutes

00:17:38   ago, which is I think we put in all this work to make things correct, the correct way to

00:17:44   do things, or the professional way to do things.

00:17:47   A lot of this work of avoiding duplication and trying to make things reusable and making

00:17:51   things modules and all the work that goes into that, it is kind of like to avoid this

00:17:57   boogeyman of future bugs or future inconvenience even, future manual labor.

00:18:04   We are all so averse to that that we're willing to put in a large amount of work now upfront

00:18:11   to prevent possible future work down the road.

00:18:15   But a lot of times the amount of work required that we're doing upfront is not worth it,

00:18:20   because we might have to put in lots of work now to avoid a potential future inconvenience

00:18:27   or bug that in reality will probably never happen.

00:18:31   And we have to always keep in mind, what is that balance?

00:18:37   Is what we're doing really demanding, or is the work we're putting in now really

00:18:44   worth it compared to the problem that we're going to avoid down the road?

00:18:48   How bad will that pain be if it comes?

00:18:51   And is that worth doing all this work now and spending all this time now?

00:18:56   Anyway, our sponsor today is CocoConf.

00:19:00   The upcoming March 20th to 23rd CocoConf will be returning to Yosemite National Park for

00:19:05   its third Yosemite event.

00:19:07   Man, I hear great things about these, I hope I can go this year.

00:19:10   This event will be held again at Yosemite Lodge at the Falls in Yosemite National Park.

00:19:15   Speakers include Ashley Nelson Hornstein, friend of the show David Smith, Andy Anotko,

00:19:22   Matt Drance, Jamie Newberry, Brent Simmons, and Daniel Steinberg.

00:19:26   That's a great lineup.

00:19:28   Sessions run in the mornings and evenings.

00:19:30   Afternoons will be spent exploring Yosemite National Park with activities including ranger-led

00:19:35   hikes, a bus tour of the valley, and a photo walk led by TED photographer James Duncan

00:19:39   Davidson, also a great person.

00:19:41   There will be music by James Dempsey in the Breakpoints, another great person.

00:19:45   And Jonathan Songadayman, man, this is a great lineup.

00:19:48   You can use the code UnderTheRadar, that's once again code UnderTheRadar to save 20%

00:19:53   on your tickets to Yosemite.

00:19:54   Head on over to CocoConf.com/Yosemite to register.

00:19:59   Man, that's a great event, great lineup.

00:20:02   Anybody who can go to this should go.

00:20:04   CocoConf.com/Yosemite, code UnderTheRadar for 20% off.

00:20:08   Thank you very much to CocoConf for sponsoring UnderTheRadar.

00:20:12   So I want to talk a little bit about the role that open source has in common functionality,

00:20:19   open sourcing your common libraries, things like that.

00:20:21   I have a little bit of experience with this, not a lot really, but a little bit with things

00:20:26   like my database layer FC model, which is kind of like an alternative to core data that

00:20:31   uses SQLite more directly.

00:20:33   I also have, as I mentioned, my open source utilities, FC utilities.

00:20:38   One thing that's changed a lot for me recently is when GitHub recently switched their pricing

00:20:44   model for private repositories.

00:20:45   And it used to be that you could do as many repositories as you want in the open for free,

00:20:51   but they had these paid plans and they were tiered based on how many private repositories

00:20:57   you needed, plus a few other things that didn't affect me.

00:21:00   So it's like you could pay X dollars a month for five private repositories, and then if

00:21:04   you wanted six, you had to jump up to another price tier.

00:21:07   So it basically had this incentive to not create very many private repositories.

00:21:11   And they recently changed that so that now it's basically like if you pay them at all,

00:21:15   you can create as many private ones as you want.

00:21:17   So what I've been doing recently is for these kind of small utility libraries and things

00:21:24   like that, I've just been creating private Git repositories and then using submodules.

00:21:30   And I mentioned earlier, submodules can be a big pain, but every alternative that people

00:21:35   have told me to use over the last few months as I've been exploring this kind of functionality,

00:21:40   I find every alternative to be either the same or worse in complexity.

00:21:44   So here's my top tips for using submodules.

00:21:47   Number one, use Git Tower.

00:21:49   It is an app, it's a GUI app for Mac and I think soon to be Windows.

00:21:54   It's called Tower or Git Tower, depending on what page you look at.

00:21:57   It's something like, I don't know, 60 bucks.

00:21:59   Just get it.

00:22:00   It is so much better than dealing with command line for submodule management.

00:22:04   Second thing that I recommend is, so use it to add your submodules.

00:22:08   For any Git repository that you have any control over whatsoever, whether it's a fork of some

00:22:15   public one or whether it's one of your own, always connect to it using the Git SSH URL.

00:22:21   Don't use the HTTPS URL.

00:22:23   If you do those things, if you use Git Tower and always use the Git SSH checkout URLs,

00:22:29   then you get this amazing balance of functionality where you have all these submodules in your

00:22:34   project.

00:22:35   You can easily check them all out at once using Tower because for some reason Git doesn't

00:22:37   do that by itself because I don't know why because Git is just obtuse and hard to use

00:22:42   by itself.

00:22:44   But then you can, so you have like version stability because it's part of your checkout

00:22:48   is what version of all these things you're using and then if you want to work on one

00:22:53   of those submodules from that checkout, from within the app that is using it, you just

00:22:58   change the file.

00:22:59   You just make the edit and you just go into Git Tower, go into that submodule and commit

00:23:02   it and you can do all that without having to like, all right, first back out to my main

00:23:06   checkout of this thing and do the edit there and then copy it back or whatever.

00:23:10   It's so much better and I've tried so many other ways to do this and believe me, the

00:23:13   other ones are mostly terrible.

00:23:15   If you're doing a lot of code reuse, especially if it's mostly your own code and especially

00:23:19   if it's a private code, Git submodules with private Git repositories managed by Git Tower

00:23:24   is fantastic.

00:23:25   >> Whoa.

00:23:26   >> Yeah, sorry.

00:23:27   >> Yeah, no, that's, it's, I've, my only experience with submodules has always just been I try

00:23:36   it for like a couple hours to try and get something to work and then I just give up

00:23:40   and like check it out, copy the files over and move on with my life.

00:23:43   >> Yeah, I mean just never touch the command line when it comes to Git submodules.

00:23:46   Like and you know, I am command line heavy with so many things.

00:23:50   Like I mentioned before, like I always use MySQL, MySQL, I always use that through the

00:23:54   command line.

00:23:55   I never use, you know, GUI apps to do MySQL stuff.

00:24:00   I will use the command line for almost everything that can be done by the command line but I've

00:24:04   slowly converted over to using Tower for any kind of Git operation and it is just, once

00:24:09   you just give in and just do it for everything, it's so much nicer.

00:24:12   It's really great and for the submodules thing, do as I said before and it's great.

00:24:17   Open sourcing, we have a few minutes left about this.

00:24:20   Have you done any open sourcing?

00:24:21   >> I've never open sourced anything, not a thing.

00:24:25   So as I mentioned, I've only open sourced a couple things.

00:24:29   I've had mixed success.

00:24:30   I would say FC model, my database layer has been the most successful open source project

00:24:35   and it doesn't even have that much external contribution or external bug reporting.

00:24:42   As far as I can tell, there's only a handful of people even using it.

00:24:46   The main challenge with open sourcing things is that there is a cost to doing it.

00:24:51   You are adding work for yourself by open sourcing things.

00:24:54   You are exposing yourself to possible liabilities of weirdness of legal stuff or functionality

00:25:00   stuff or hacking stuff.

00:25:01   That's not too much of a concern for most people but it's mainly you're just adding

00:25:05   work for yourself.

00:25:07   You also might be giving advantages to your competitors but that's also kind of not really

00:25:10   a concern for most people for the kind of things you'd be open sourcing.

00:25:14   I have found that the value you get out of open sourcing of oh, you'll have other people

00:25:18   contributing improvements and fixing bugs and maybe facing security problems, that only

00:25:23   happens if you're open sourcing something that a lot of other people will need and use.

00:25:29   For most stuff that you're going to be open sourcing, that just doesn't happen.

00:25:32   I open sourced my FC utilities utility library as I mentioned earlier and one of the reasons

00:25:37   I thought about closing it back down is just because I don't really get anything out of

00:25:41   that.

00:25:42   Almost no one else uses it but occasionally I get a pull request to change something and

00:25:45   usually it's a change that I might not even need and so this is just more work for me

00:25:49   or adding functionality that I wouldn't do or that I don't need or that is done in a

00:25:55   way that I wouldn't have done it.

00:25:57   And it's just kind of like what's the value there really and most people don't need your

00:26:02   personal utilities.

00:26:03   Most people have their own personal utilities and so it only makes sense if you're going

00:26:08   to be open sourcing something that a good number of people will use.

00:26:13   Otherwise the benefit to you as the person doing the work and taking the risk of open

00:26:18   sourcing it is really small to non-existent.

00:26:21   And so I found that generally speaking like most of the stuff I write would not benefit

00:26:28   from being open sourced.

00:26:29   And that's also why like completely open sourcing an application is not incredibly useful for

00:26:34   most people.

00:26:36   You know it's just like there's lots of nuance to like what makes a good open source or what

00:26:40   makes a useful open source project.

00:26:42   And it's not always what you think and it mainly comes down to like am I open sourcing

00:26:47   a component that a lot of people will actually need and that they will find and choose to

00:26:51   use mine.

00:26:53   And if the answer to that is no, if you have like limitations on your time and stuff it's

00:26:58   probably not worth it.

00:26:59   But when the answer to that is yes it is pretty nice.

00:27:03   And you know for the most part you do have the risk of like you're going to get pull

00:27:06   requests you're going to have to deal with them.

00:27:08   You're going to like it is going to add work but hopefully it's also going to add some

00:27:13   kind of value if you get enough people to use it.

00:27:14   But as I said that's a huge if and of the I don't know five or ten things of open source

00:27:21   of open source so far only one of them has really gotten that and only just barely.

00:27:26   So it's a mixed bag.

00:27:29   Yeah because I think the biggest reason that I've never really gone down the road of open

00:27:33   sourcing things is that tension of if it's unique enough to be useful to someone else

00:27:41   then there's a good chance it's something that I wouldn't want to open source.

00:27:47   Like it's something that's kind of unique to what I the way that I approach things or

00:27:51   is part of what makes my app special.

00:27:54   And so it's like say I'm imagining something like your smart speed system in overcast right

00:27:58   would I'm sure there would be many people who would love to use that in their applications

00:28:03   if it were open sourced.

00:28:04   But the nature of open sourcing it like completely diminishes the value of it to your own application.

00:28:11   And so that weird tension in open source is like if it's super cool and interesting and

00:28:15   other people would want to use it then you may not want to then give it to them because

00:28:21   it's special and unique and kind of something you want to hold on to a little closer like

00:28:26   it's more of a trade secret in that way.

00:28:28   And then the things that are not that special are not that unique to yourself that you then

00:28:34   would be fine to open source maybe aren't as useful like you're if you're adding you

00:28:40   know it's like hey I have this way that I do like HUD pop ups like great but there's

00:28:45   also like 10 of those already and that's a weird process circular problem that you kind

00:28:50   of run into at least any time I've ever thought about it and so usually I just say you know

00:28:54   that's that's not for me and I don't really use much open source in my apps I just tend

00:28:57   to just kind of like write it myself and it works for me.

00:29:00   Yeah it's always a balance of strike and you know just like just like any kind of you know

00:29:04   code reuse situation like there's a balance of strike here there is no one answer all

00:29:09   the time and that's incredibly useful information I'm sure for everybody.

00:29:14   The answer is it depends.

00:29:16   It depends but hopefully you can make a slightly more informed decision about exactly why it

00:29:21   depends.

00:29:22   Exactly.

00:29:23   All right we're out of time this week thank you everybody for listening and we will talk

00:29:26   to you next week.

00:29:27   Bye.

00:29:27   Bye!