We look into the fascinating world of customisation versus open source software. In this electrifying conversation, we tackle the critical questions: What are the risks and challenges involved? Can you truly have the best of both worlds? Discover the secrets behind striking the perfect balance between customisation and open source. Unveil the hidden costs, complexities, and potential pitfalls.

Anthony Perl: Philip, I wanted to get into a little bit around this idea of customization, versus picking up on a lot of open source software in particular, there's a bit of a, you know, some of it is, is customization and utilising it. Some of it is not, but you. They're building, you know, they can find the situation where you're building upon building upon building and it can all crumble down very easily if you're not aware of where all these individual pieces are going, because, there is this idea that people come in and they go, let's buy this piece of technology because it does most of, or if not all of what we want, but then there's also this other idea.

Do we just build it? Do we build it ourselves? Is the risk less by building it ourselves?

Philip Zada: I get asked that question all the time. It's a good one. Um, it all comes down to context. That's the thing. It's not one answer is going to fit all scenarios. You know, open source is great for what it is. Anyone who says you're not going to be customising open source or implementing it in different ways is being silly.

Because it has the same issue. The challenges with open source versus proprietary technology, it comes down to the requirement and the, Appetite of the organisation to do that heavy lifting, like, for example, if there's an open source library that is very, very, very popular, you know, it's huge, it does, you know, 90 percent of it will work for you and you can easily find the developers to do the work, great.

But if there's a proprietary technology that you can just turnkey, you know, switch it on, but then you've got to still hire 2 or 3 developers to sit there customising it the whole time. Is it worth it? And based on the customizations that you've done, can the actual proprietary software be upgraded in the future with its next version, or what's the licensing fee and etc.

There's a whole plethora of questions that need to be answered there. But to answer your question, it's not one size fits all. It all comes down to the context and the unique business position.

Anthony Perl: Because it used to be, didn't it, that You had this , and as you're saying, it's not a simple decision, but you had this, okay, we can buy this bit of software or we can build it.

But now that building it bit with, particularly with the volume of, of APIs and those sorts of ideas that are out there, open source type platforms, it enables you to customise to a degree that has. risks as well, doesn't it? It's not as simple as just going, okay, well, this is the best of both worlds.

Philip Zada: Yeah. And there's even actually even a third layer in there. So that's all the, the, uh, platform as a service technologies that are being offered at the moment where you can actually. Effectively outsource small components and functionality in your overall system. So things like, you know, in Azure and Amazon and Google, where you can get this little piece that does this, or this little piece that does that, and it's just a service that they offer, they charge you, usage fee.

And that's where striking that balance about getting those pieces to kind of all sit on the scales evenly. It is the big challenge there. Um, and you're right. It's not gonna be that, you know, this is, okay, cool, we're doing this way and this is the path that we're going. For the challenge that we're trying to solve.

What's gonna be the best way to do it? Which tech, which approach is gonna be the path of least resistance and what's going to give us the better integration and compatibility between the different layers?

Anthony Perl: Yes. And it has become an increasingly difficult decision, isn't it? And it's crazy.

And I think even when you look at, if you know, you sort of dumb it down a little bit and you say, you look at a platform like Xero, which has lots of things that you can add on to it. It's a question of there can be multiple choices sometimes within the one area. And then suddenly you've got all these subscriptions that are adding on top of one another.

And the cost of doing all of these things suddenly shoots up enormously. And each time they're going, Oh, well, it's just another, it's just another, it's just another, but suddenly it's.

Philip Zada: It definitely adds up. I think it was recently, interestingly enough they came out with reports that it's actually now cheaper to go back to on premise hardware than it is to run in, in, in the cloud in some instances, because the pricing has just evolved.

And the exact problem you mentioned, you know, yeah, you start off with this little free, you know, we're getting this service, but then you've added this service and this security layer and this layer and this and this and this. And the next thing you know, you're paying. Yeah. Tens of thousands of dollars a month for something that you could just buy a server for and chuck it in a server in some way that will be cheaper to run.

Anthony Perl: Yes, and you're right, isn't it? Because, and we've sort of touched on this in previous podcasts, but the whole idea of being swept up in the. Buzzwords and the things that you, Oh, you've got to have this, and you've got to have that. And so suddenly you're, you're adding on this and adding on that, and it can spin out of control very quickly.

And, and to the extent where you may not even realise what initial bits of software are actually capable of doing before you even bothered to add the extra bits.

Philip Zada: Yeah, exactly. One of the things that I find really helpful when it comes to designing these systems, uh, this might seem a bit unorthodox, but what I try and do is if I'm looking at a solution from a Project perspective.

So as in, we need to do, we need to build a system for this customer that does x, y, and z, and these are the problems they're trying to solve. Can I run that whole system in a development environment on my computer? If I can't, as in, I need to go to the cloud for this, I need to go to the cloud for that, I need to go to this for this, I need to do this, then I really look at it and say, well, that's not really, Listly coupled is it because then if that cloud service changes, I'm stuffed.

How can I, you know, I'll come up with a solution where it's like, okay, we need to send emails just for argument's sake out of the system. Cool. We might use SendGrid or Twilio to send the message, but locally, I could use a local client instead, or, you know, things like this, where it gives you those alternatives and that's what you need to and that's where it comes down to that, that micro componentry and being able to appreciate what each one does and.

How hard is it to replace that piece of effort effectively?

Anthony Perl: Yeah, because, in this kind of environment where we're becoming more and more used to adding things on top of things, um, you know, it's, that's, you know, they should, people demonstrate sort of a, a piece of software and then what you suddenly realise is, yes, that's not the basic version.

And I think where this has become so common, hasn't it? That, that things Upsold immediately. I had a case recently where a piece of software that I've been using and I wanted to grab the API to interact with another piece of technology. Yes, we've got that, but that means you've got to go up a plan.

Really? Just to grab that API. I've got to go up to another plan that was going to cost me, I think it was going to cost me over a thousand dollars a year to go up in that plan. And I'm just like, no, there's got to be another way of doing it. And it's interesting. There is another way.

And it involves a third party that, that is a free tool that I can use. And I can then take from that free tool and just zip it across into the, into my ongoing platform. And it's crazy, right? Because that's, what's happening as well out there is that people are finding these patches to, if you look hard enough.

To stop you from having to spend the money on some of these things.

Philip Zada: Oh, it's crazy, especially when it comes down to API consumption, where they say, Hey, now if you want to use our API, yep, you got to go up to the next plan, but then you got to pay per every hundred requests. And it's like, really? You're charging for something that's, uh, anyway, uh, obviously everyone, every business has to make their money, but like, you know, there's, that can be the real traps there.

And that's where it comes down to really understanding your need, because if you're, obviously from a. Business perspective is understanding the costs involved. You know, there's been projects where they had no idea about the subscription costs, about the usage fees, and then the system got hit hard.

The next thing you know, they've got a bill for, you know, hundreds of thousands of dollars. Where the hell did this come from? Excuse the language, but you know what I mean? And it's, and it becomes, um, really Important to understand that, especially when you're doing your cost easing analysis on your project, especially for the 2 3 year run time.

Anthony Perl: Yeah, and I think that's the other thing too is, is that often these subscriptions, , that are becoming a real cost for business can be based on the amount of users. And you've got to also strategically look at, well, are we going to need more and more people? And therefore the subscriptions are going to cost us more and more along the way as well.

So you've got to factor all of those things into the equation and whether you can share, I mean, I've, I've, I find that a really interesting one when, when they often restrict the amount of users. But yet, so what that causes organisations to do is to share users. So they just share the, uh, the, you know, which, which of course has security implications as well, but ultimately your hand is being forced because I think a lot of these, businesses that develop the technology are not, uh, necessarily as friendly as you would like them to be towards the end user.

And, and that's something you've got to factor into the equation.

Philip Zada: Yeah, definitely.

They're trying to, I think they're trying, the last thing attempt is the OTP. So, you know, when you get the SMS code on your mobile, that's how they're trying to stop it from happening. But, you know, they say it's more secure, but it's actually limiting the, the, the account sharing.

Um, but yeah, it's, it's definitely one, one interesting challenge the good thing is, most of these organisations, and again, as we were talking about before, right? So, you were talking about how things can change. Yeah, when you start the project, they could say, yeah, we'll give you 500 users at X amount a month, but then they could change to, okay, now it's down to 100 and they have to pay extra.

Yeah, some good, some good, you know, proprietary vendors will actually tell you, you know what, we'll keep, keep you on the grandfather clause. You can stay on your old pricing. But then some of them will just force you over. And then it comes back down to that previous mindset. If we wanted to get rid of these guys tomorrow, how hard is it going to be?

Do we, do we pull the trigger on that?

Anthony Perl: And I think the perspective, I think you gave this to me before we started recording this particular podcast is this whole idea of looking at the technology and the way you would look at a house that you're building a house and you've got to make sure that, you know, things are going to work together.

You can't just, you can't just magically, as we would know in a house, knock down a wall, because if that wall is holding up the roof, then you're in big trouble. And I think we don't. Yeah. Think about all of this in that same way and what the implications are as much as perhaps we should , and, , it isn't visualised as well as it can be mixed with this expectation that you should be able to do everything you want just because it's technology.

Philip Zada: Yeah, so with regards to technology, the key thing is you have to think of it or how I put, you know, an analogy in my mind that you're building a house and a lot of the systems and a lot of the technology behind that is you effectively your foundations of your house, you know, your pillow that's holding up that roof or, You know how can you build it in a way where you've got that foundational piece there?

Now, it's not saying you can't put an extension on a house. You can do an extension, you can do a renovation, that's fine. But it's doing it in a way where you know what's, what needs, what's effective, what's interconnected. So if you do pull out that foundation, what's, what rooms are coming down?

Anthony Perl: Yes. And I think it's an appreciation much like a house as to where you need a specialist to be able to help you do that versus it can, you know, someone has half an eye on it, uh, effectively like watching a YouTube video and you can do it.

I often say to people, well, you know, you wouldn't knock out a window out of your house. And just expect that you can replace it yourself. You might be able to watch a YouTube video on how to do it, but is it going to meet all the codes and standards? And is it going to be done , in the right fashion so that it lasts long term?

Surely you're better off with a specialist doing that, but it's somehow with technology, people believe that just because it's technology, it should be simple.

Philip Zada: Yeah, it really, really is and, you know, adding on to your analogy, it's like, okay, now that you've put the window in, oh, wait, the window doesn't open.

What do you do then? You still don't bring that specialist in. Or in some cases, if we're talking technology, people will replace a piece of technology without understanding where and how it's connected to things, which could then have also detrimental effects where it could stop the business Performing its task because they've gone, you know, decommissioned something without understanding what it's really done in the business.

Anthony Perl: It kind of leads me to come back full circle in understanding this whole idea of customization, complete customization, building it from the ground up, because the value of that is, is you do understand the architecture a little bit better. You do have that kind of platform that's been built for your Case scenario.

Does that mean that that's come comes back into flavour is for many organisations could be a better option. Or is that still a really expensive, not really worthwhile choice?

Philip Zada: It's not necessarily as expensive as people think. For example, if we were using what we were speaking about in the previous, um, cast about the Salesforce, you know, and that person who brought in that Salesforce into their organisation, they ended up bringing in a whole, um, team just to write the customization code.

What's the difference from having your own development team just building your software for you? You know, you don't need much, you know, a really powerful development team could be anywhere from three to five people, . In comparison, and the benefit of going down custom solution, this is where I try to actually weigh the option is with the custom stuff, the reason why it's custom is because it's niche for your business.

You're building technology to work to how your businesses worked and always work. Plus you're flexible enough that you can change it as you want. Whereas if you go down the whole, , proprietary technology path solely, then you're basically, constrained to the way they want you to do your business and the way they allow you to do it, if that makes sense.

Anthony Perl: Yes, and I think, again, that's one of the hard parts, isn't it, as well, that it's also, you're also constrained by the way of thinking of the people that are currently there and the people you're currently servicing, and what's your ability to adapt to changes as changes naturally happen because people come and go at all aspects of your business.

Correct.

Philip Zada: Yes. Um, and that's, that's one of the, one of the key attractors I like about custom solutions is that you have that ability to pivot with the times and if it's built correctly, then once you have the underlying foundation of your custom system, you can chop and change with ease. There are some, projects we've worked on where we spent three to six months building the initial platform.

We got it out there and then adding and taking away features from the initial platform. Is not even a few weeks process in each way. So it actually becomes faster to go to market. And it gives you that kind of upstream curve because then your output is growing with the least amount of effort.

Anthony Perl: I love that thought process because I've often heard people talking about businesses and people needing to pivot, but that idea of technology needing to be able to pivot for you and. Going into something, thinking about that opportunity is, um, I think it's, it's really interesting because we don't necessarily haven't traditionally, at least not in my circles, have traditionally thought about the technology pivoting with you or pivoting for you.

Philip Zada: And most people think that, when we talk pivoting technology, it's like, okay, well, we got to buy a new piece of tech. No, it shouldn't have to be. It should be, can you actually take what you have and customise it to how you need it to, to work, essentially. Whether it's either custom code, an extra extension, like you were mentioning this year earlier, it could be a number of different ways.

It could be a simple way of a business process change, but at the same time, it's, it's just trying to, Have the freedom to do that without worrying. Oh, God, this is going to be, you know, multi million dollar project. We're going to have to do X, Y and Z. You know, how can we do this with the least amount of resilience possible?