You might be solving someone else's problem, and they've never seen your source code. They've never used your library, but because you have published it, that brilliant way that you invented of doing something can now be used in anyone's source code, just that genius, three lines of code that you made, the do something really efficiently can be used by someone else.
Malcom:Welcome to CTIO 1 O 1 Episode 4,. Sponsored by Fairmont Recruitment, Hiring Technology Professionals Across the UK Europe
Jon Grainger:One of the topics that it does the rounds, but anyone in business technology really needs to get their head around. What's your approach with open source? What is open source? We've got a few areas we're going to go through, we're going to try and look at some of the cliches around open source and also explore your own experience and what you guys do specifically with open source. Given that we're 1 0 1 to start off with, why don't we try, I a definition what would your 1 0 1 explanation be?
David Bond:Computers and robots work using instructions. they haven't got a mind or imagination of their own. You have to explain to them in great detail So let's say you ask a robot to make a cup of tea, and you discovered that it always tastes awful. So the instructions that have told that robot, how to make that cup of tea are hidden from you. So that's closed source. You've no idea why the cup of tea tastes so bad with open source. The idea is that everyone in the world can see the instructions that be given to the robot to make the cup of and as soon as you reveal that, and as soon as you open the source or you can see that the robot has been told to put the tea back in the milk, stir it for five minutes and then add some boiling water. we know that's a terrible way to make a cup of tea, you need to put the boiling water in first. So obviously robots can only read zeros and ones. So that source code, whether it's open or closed is converted in something called binary's before they're given to the computer or the robot. So just making the source code open, doesn't make it better. Cup of tea does not make it better. But it does mean that people who really care about how their tea tastes can complain about it, vociferously on the internet and say, this is awful the instructions are all wrong. and this is how you should be making a cup of tea. The three important steps that w one is it's all very well understanding how to improve the source code. And, that means reading it And the more eyes you've got on the better. So open source gives you some advantages there but it's also about making those improved instructions available. And then finally for people actually giving the robot, the team instructions. The open versus closed source question is really how easy is it to see how a computer or a robot has been instructed to behave?
Jon Grainger:I've never had it explained like that before. Which I think is absolutely brilliant. So I wanted to play back to you. What you've just said, see if I've got it right. And use, an analogy I've just made up on the fly, which is always risky. So would a similar analogy be you go into a restaurant, you order an omelet and you eat the omlette that. You go absolutely amazing. I love it. But you want to improve, or you want to improve on that omlette, on that, and you go and ask the chef and the chef says, I'm sorry I'm not telling you how I made it. It's a secret. And that's your kind of closed source open sources. he welcomes you or she welcomes you with open arms and says, actually I'm part of a community of chefs. And we've been spending the last 20 years on how to create the perfect omelet. Can see you're passionate about omelets come and join us.
David Bond:Having been through the pain of learning, how to make the omelet. wanting to keep that secret for yourself so that people have to buy their omlettes from you, or are you saying everyone in the world should benefit from this amazing recipe and by doing so you gather people together who are like minded, which in itself is a social thing, which we're all is important to all of us. But also you've transformed your mission from making the most money you can from your secret recipe, which one day someone will find out or improve upon. You've converted your mission to making the perfect omelet. And it is very much that distinction between why Are we doing this? are we doing this in order to make the world. better? Or are we doing this in order to make ourselves richer? and you have to do both, right. There is a balance to be struck, but you find that. Give the open source to the community. They come back to you for work for other reasons, right? They're like, oh, look, I know you're the guy behind the omelets, but we've got a new mission and we want to make the perfect cake. So come and work with us. And so that might then be a closed source project. So that's very much how we operate a Panorama Data is here is the stuff of which we want everyone to use for free, because we want to help the community. And we find that as a result of that, people come to us for closed source.
Jon Grainger:We won't keep going back on about omelets, et cetera, but that restaurant where you've had that great omlette, Not only was it great, the chef was very open with you about, how they've made it and actually already you've got trust there and you're thinking, you know what? I think I'm just going to come back and eat here because they're really cool there's trust. And we can probably do some other really cool things, especially in a world where the first position seems to be. We're not telling you anything. This is a black box. Which is really maybe becoming very outdated as a way of selling?
David Bond:I think so. I think the whole world is moving away from transactional sales and towards relationship establishment. If you look at the way, the whole industry is going towards software as a service, right? You're selling software as a service, you're not just doing one of license sale, like a copy of Office. To run on your machine and asset. And if you want to buy the next version, you have to, know, You have to you have to pay a capital cost for them for the next version of the software. The whole world is moving towards a model where you in effect, and this is what most companies are moving to with Office 365 and Google's other offering around that space. So not so much a rental model, but a sort of a subscription service. So we subscribe to be able to use word which to many people seems utterly the wrong way to go about things. And yet that is a long-term relationship between the company and, Microsoft or whoever the supplier is and that trust and the relationship is far more important to Microsoft. And we can see that revenues are doing fantastic things these days than the closed source will sell you a transactional W we'll make a transaction with you and sell you this one copy of the software. So I think this whole move away from transactional sales in software and towards trust relationships, long-term and annual recurring revenue, I think is a model that will stick with us forever. And I think it's weirdly it's moving to other areas of society as well. So if you look at, how you go to a a theme park they don't want to sell you on that one day. They're trying to get you on the annual pass, right? They want you to have ongoing returns to whatever the Theme park is with your kids. Once or twice in the summer for the rest of their kid, your lives, that's what they want you to move towards. And I think that in order to do that, they have to provide a much better experience. I have to also continue to innovate to make you want to keep coming back. And That's another important thing is by moving away from a transactional sale and towards a more, as a service. Methodology your encouraging, the continued development and improvement of the software. I think that the same thing is true in the community as well, by making a source open you're encouraging continual improvements and the community input into those improvements. And I think we're certainly seeing that with Microsoft being very successful with their open source and all that.net framework
Jon Grainger:if you just cast your mind back even a few years, if someone said to you, oh, Microsoft are going to go Open source. You'd like, no, they're not. They are the very last people at the party. But with and the sort of the new leadership, I think it's made them a much stronger. They're already a huge force, but it's probably got their roots and you're getting loyalty, from folks and embedding into the community. One of the things that gets banded about a lot, and I think some of our listeners will hear this, if they've never used open source before. this will be someone in the meeting might say, oh actually I've heard that open source has inherent security flaws or weaknesses because, we don't know who's working on it so david is open source software more prone to security flaws? than closed source. Is, it a myth? Is there any truths around it? What's your view on that?
David Bond:All source code all software has the inherent weakness that it was written by humans. So if you take any bit of software, the chances that have got zero bugs are tiny there's no chance. Most software that you use everyday on your phone, on your laptop will have bugs riddled throughout it. most of them not very severe, but all of them potentially are problem for you. And if you were any doubt on, whether that was true how often do you get software updates rather than a lot of the reason that those software updates are coming in is not just new features. It'll be a whole sway. This, If you look at the release notes, whole swaves of bug fixes, whether it's open-source or places. Humans are mostly harmless. So most of the code that they write is well intentioned, but just flawed. So open source has inherent security, weaknesses, close source has inherent security weaknesses just by the fact that it was written by imperfect people. So the argument used to be that we keep our weaknesses, hidden, right? So when you do that, the weaknesses remain, you still got those weaknesses in your code and the computers are still running that flawed software. So when you first make your source code open, everyone can inspect it, find the issues and exploit them. So when you first take a closed source project and you make it open source, you gotta be very careful because what you're then doing is revealing to the world, all your weaknesses and all your security holes. However, if your project starts off open source, you'll tend to fix those things as people spot them fairly quickly, particularly anything related to security, there's a whole sort of urgency that comes with any security for all that any developer will immediately try and close that down because the last thing they want is people abandoning their code, whether it's open or closed. So the trick is when you go from closed source to open source, you really have to go to one of the. Companies that will do a full audit of your code base and make sure that it has no flaws at all from, as far as they can tell it doesn't mean again, it's going to be perfect, but it means that you do have an independent eye on your source code before going from pure closed source to pure open source. Otherwise the community is going to rip it apart. And also no one's going to trust it, because you didn't have that previous trust relationship that we were talking about. And so it's going to be a sort of a, an immediate switch on of the the source being inspected, people will find flaws and exploit them immediately.
Jon Grainger:I never thought of it as a, you start closed, then you go open and that being a vulnerable time, because you've had. Previously, maybe eight eyes or sorry, eight pairs of eyes looking at it. And now you've got, thousands, so you've got that. And I suppose when you start something, which is kind of Greenfield open source, you're building on certain frameworks that have already got a lot of scrutiny within it. So you're starting from a different sort of point of view. So if folks are looking at open source either looking to open source their own code. So if they're looking to make that leap to open source, or if they're looking at evaluating open source, understanding where that product is, it's lineage and where, and how new or is important. And I suppose also the domain authority of whoever's check their code as well to make sure it's a bit like, when you do your pen test, you make sure it's done by a really reputable company. Otherwise, it's not worth anything. Is that fair to say?
David Bond:I look at it in the way that you look at people who drive and operate computers don't need a license but you do need a license to drive a car, right? So there's a certain level that you have to get through. Otherwise it goes, not even can compile, but above that level above the level where you can write hello world and put it out into the world, everything else that you write on top of that can be awful and no one's ever looked. at it. I used to be as a developer, very protective over my code, and this is mine and it's my baby. But you soon discover that the more eyes on your software, whether they are professional eyes or amateur eyes the better, but when we write close source code for our customers, and they bring in an auditor, We used to be very nervous in that process. And now we're actively interested in where we've made mistakes. And I think that attitude is really important for any developer is a bit of humility and a bit of understanding that the code that you write is continually awful and get other people to inspect it. Whether that's your pair developer that you work with every day every cut line of code that was inspected at the time it was written it would be of high quality whether it's because you've got static code inspection running against your code. And we use, Visual Studio which is fantastic bit a software. But it has got now static code inspection built in. So it will assess the quality of your code as you write it. And point out flaws, the very second that you've written the code and it will, give you improvements. There are independent, modules that you can put into your code to inspect it at compile time. So for example, we use something called security code scan, which is a free thing. Anyone that uses visual studio should have it in all their projects. And it's just, they're inspecting you for security, bad practices. It might not be intentional. You might've accidentally left the password somewhere, but it will tell you about that. And, those tools are hugely valuable. And then finally, when you've got these third party auditors coming into the for your code, they will, again, they'll run static code inspection, but they might look a bit more carefully and do some penetration testing and do all kinds of things that you wouldn't do yourself while you're developing it. So I think the message here is it doesn't matter whether it's open or closed, the more eyes and the more processes that inspect your code for flaws as early in the process as possible. as includes as you're writing it.
Jon Grainger:So David had a quick question for you. I was at an event last night, which was all around it's mental health week. This episode will not be going out during Mental Health week. The topic They were covering was something called Imposter Syndrome which is not a formally recognized condition. But it is something that's been talked about and quite prevalent in technology and, it goes along the lines of I'm not really good enough for what I'm doing. Someone's going to tap me on the shoulder. I'm going to get found out, that sort of thing. And it just, when you were talking about making your code public, something you've written that, do you have to dig deep with your confidence to put something that you've written out there? It, have you ever experienced that or seen that I'm just wondering whether that's something that our folks might think about in terms of actually making that leap to publishing their own code. Hey, look, this is something I've written. And I said that's not very good. Okay. I won't ever publish again. I'm going to go and change jobs and become a librarian.
David Bond:I think the thing that everyone should embrace is that's just perfectly normal paranoia. Everyone in the Universe has that, so we all have that, but the question is not really all, you're good enough, so much as what are your intentions. And if your intentions are to put out the best quality bit of software that you can, then it will happen, but it will be the best bit of software that you can produce. If you then open yourself up to the community, say, here is my flawed bit of software, please rip it apart. They will. And that is a good thing. And so it becomes less about, Am I good. Enough and more of that. What is it at the time trying to achieve? And if what you're trying to achieve is high quality then it will be. If what you are trying to achieve is whatever, you can just throw that out as quickly as it possibly can be thrown onto the Internet, it will be very low quality. So I think anyone who's getting into software and thinking, do you know what I'm I've written this code. it's terrible. And it's awful. The last thing I'm going to do is put it on, Github, should flip that around completely and say I'm going to put"Hello World" on the internet. And I'm going to ask for criticism until it actually is writing war and peace. but that's, if that's your intention, start off by publishing the awful little bit of scrappy code that you written as soon as you get someone who's interested in what you're doing, and if it's sufficiently niche, believe me there'll be someone out there in the seven, 8 billion people in the world, there'll be interested in it. They will contribute. They will help, and they will become part of the community. And it's not about you creating it. It's about you facilitating the community and creating the best possible version of what it is you're trying to achieve.
Jon Grainger:What motivates a software developer to actually contribute towards open source? When you contribute towards an open source project as a developer it's, you don't get paid I believe not directly. You obviously get some kind of benefits. So what's the motivation? Where what, why do folks get stuck in to it from a developer point of view?
David Bond:That's a very good question. Mostly I believe that people publish open source initially because they've just been through hell solving a particular problem, and they just want to prevent anyone else from going through that hell themselves. So by publishing it really, they're just like putting a bow on it and saying, this is now finished. It's almost like a, now I can release my child out into the world and they can go out there and do good. That's not always the motivation. Quite often the motivation is someone's got, I can't get my code to work. Here's the Github come someone on Stack Overflow, please fix my code for me.
Jon Grainger:I can't get any further. Please Can someone, I just do not know why this is not working. Yeah. A been there.
David Bond:And quite often the answer is, oh, you just want to use this library over there. Someone's done it for you already.
Jon Grainger:There is almost everything written already, again, a massive generalization there, but there is a lot out there isn't there that people don't realize that a lot of people sit down to write. things and it's probably been written maybe even a hundred times before.
David Bond:Now, this gets me onto the topic that I'm so excited to about, which is the release of Github copilot, which is an amazing bit of technology. And it's basically you write the comment about the code you're about to, write and it will then write the code for you. And the reason it can do that is that this AI has scoured. The whole of GitHub has exactly 20 different implementations of the thing that you're about to write. And it knows which the best one is, and it will write it for you. Now you have to be a bit careful. You have to read that it's doing exactly what You intended. And if you phrase your comment wrongly before it types for you. it's going to do exactly what you described, not what you want. But this is a way of all of this open source that's being contributed out there. Isn't just going out into the void. You might be solving someone else's problem, and they've never seen your source code. They've never used your library, but because you have published it, that brilliant way that you invented of doing something can now be used in anyone's source code, just in, just that genius, three lines of code that you made, the do something really efficiently can be used by someone else. The idea that the source code that you're writing there is going out into the void and not being used by anyone. It's not, true. You might find that some bit of aI has picked it up folded in and someone else now benefits
Jon Grainger:Does it accredit you to so does your kind of standing increase because your bit of code has been used?
David Bond:But this comes down to what your motivation is, right? If your motivation is to get your problem solved, then you ask a question on stack overflow, if your motivation is to prevent someone else from having to write that bit of code ever again, because it was a nightmare to figure out then that's your motivation. If your motivation is to I don't know, get someone to use your software and then maybe buy your support services, that's another motivation. There are multiple motivations of why people would open source. One, answer is that you've got your legacy software, you're about to retire, and you just want to make sure your impact on the world is, stored forever. Who knows why people do the things that they do?
Jon Grainger:David, these are very human motivations. They're also very grounded in engineering. I think a lot of people get into engineering because they want to make something that is really good it advances how people experience the world, but also has some kind of permanence, it's yeah, I built that
David Bond:exactly is when you're long gone. Personally, I'm not going to star in a sort of a multimillion dollar blockbuster and that legacy won't be there forever. You look at Some of the amazing films that are coming out right now. we all want to have been robert downey Jr. As Iron Man. It'll never happen. So our legacy is going to be a few lines of code that we wrote
Jon Grainger:David don't write it off. Don't write it off. You never know you might get that phone call.
David Bond:This is my audition, right? Yeah. I'll be the next Iron Man. Don't they'll fit in the suit unfortunately.
Jon Grainger:When you're using consuming open source, you may see, the element that you're directly consuming, but that might be built on a number of other modules or parts of of what are called dependencies. And if that runs quite deep, you might have quite a lot of homework to do before you really understand how solid, the open source platform is that you're using. I wrote down the phrase"buyer beware", what's your approach when you're thinking about dependencies?
David Bond:So we recently saw this, of course, with the Log4J exploit, which is a library used in thousands of different software packages. So these are all potentially vulnerable for many years, the trick with all software engineering, but there's open or closed source is to use the fewest lines of code possible. Everything should be done in the fewest lines of code. So for our Tea making robot, for example, wouldn't it be good if you could use instructions written by someone else that already gave detailed instructions on how to boil a kettle, right because that's a dangerous thing and you really don't want to be writing code that handles boiling water. So you would use someone else's Library. The question is have you got time to inspect every single line of code that's Being written, instructing the robot, how the boila kettle and do you know, actually is not going to start throwing that boiling water around the kitchen. you, don't know that. And in reality, those people writing open source themselves will be relying on underlying libraries that they've never seen. They haven't taken the time to inspect the code. So the important thing there is to use code that is tried and tested was always open source and has been open to inspection for a very long time. As we were saying earlier, if something's only just been moved from closed source to open source. It's potentially vulnerable, and that's a bad thing. But that's never going to completely protect you, but the same is true of open or closed source, right? So when you are in, as I am Visual Studio and you're choosing which NuGet packaged to bring in, take a quick look at a couple of key metrics. One is how many other people on the internet are using it. And there's a little metric as you choose the library that you can include in your, source code as to how many other people are using it. And the second thing is just have a very quick look at the repository and look to see if there are thousands of outstanding issues in which case you might want to avoid it because lots of people are finding issues with the source code and it's not being fixed. And then the other one is how often are releases made. So I think we spoke earlier. about how it's all very well that someone's invented a better way or written instructions for better way to make a cup of tea. But two things still have to happen. Those suggestions on improvements have to be accepted in by the people who are maintaining that software package. And the second thing is people have to actively update their code. So we try to on every release of our software, make sure that all the NuGet packages are up to date. And we've got all the latest bug fixes and security fixes in place we also try to minimize though the number of packages we use. And specifically we try to minimize the number of packages that we use that are obscure or poorly used or poorly maintained. If possible, we would prefer to rewrite the code ourselves from scratch than use a poorly maintained or an obscure package. And we have done that. We've found a code that exists and looks okay. We've may have be suggested improvements back to the original writer of that code. And some of those have been folded in, so those are called pull requests and you say here's some improvements. We suggest you make these. And then the author either accepts that, or they don't, or an extreme cases where the author is just gone and we can't find. Who they are or how we can get that, code improved. We will occasionally do something called forking and forking is where you take the existing code base. And you say there is a new way of doing this and it's our way. And we're going to patch all these things up and maybe add a couple of new features. Now, forking is something we should avoid because if we're being properly community about this, we should all try to stick to one best way of doing things. But in reality, people retire, people go and do a job somewhere else in the world, and haven't got time for this project anymore. So occasionally, and it is rare. We will take over, the maintenance of an open-source package ourselves. Again, not because we benefit from it directly, but because it's the right thing to do. And also because it means that we will benefit from the improvements that we can see, need to be made, and we can keep the legacy of that project going forward. and this is really one of the for me, great hopes for the future is that some of the code that is being written today, maybe that for hundreds or even thousands of years, because it will evolve to the point where it does exactly what it's supposed to do. And the community Is looking after it over multiple generations. This is one of the most exciting things to me about the open-source community and the open source movement is that the code that's being written, today may still be being used in decades or even centuries
Jon Grainger:Which is incredible. So I wanted to get into the code folks a little bit more because I'm just going to run some scenarios past you to see whether they exist or not. So the first scenario would be two different schools of thought. So it's more about, achieving the same outcome, but implementing it in a different way. So if you like where you were saying, I think David, when you're saying in that scenario, we'd like to see as few of those as possible, because really we want the same tool with the same outcome rather than coming, we're implementing it this way, we're implementing it that way. So that was one scenario. The second scenario is where genuinely something is born out of the code. So it's not really a fork. It's like a new purpose, which I would have thought is like a legitimate, fork, I don't even know if you call that a fork because it would be we're using this, but we're really, we've taken what it has, it's got such a different purpose. It's a genuinely new use, et cetera. And I was just thinking if you've got code that relies on open, source and then you've got this, these forks that occur. Is there anything you need to do when, does it, does a fork get announced or how do you keep on top of that?
David Bond:Imagine that you've got a species of frog in the amazon and they wander to the edge of a region. One area has got slightly browner leaves and the other one's got something greener leaves. And then the ones that are green in the brown environment get picked off by predators and vice versa. So eventually what'll happen is you will split into two different species of frog, and they will eventually become very different. than what. The red spots. The other one become enormous for various secretly, good reasons. So what has motivated the frog there to split nothing? nothing? at all. It's just, happened naturally. So that's one way that software can split it. Someone goes, oh, do you know, what I can use this code for this other thing. And they'll just pick it up and use it and start developing their own thing. eventually it'll be, called something different than rename it. And no one will really know have the same origins And that can happen very naturally. the other thing that you occasionally see is for large software packages where you've got egos and a committee you're going to get factions. And the splits and those are mostly happened, I think for either ideological reasons or some kind of sense of loyalty to a leader or some of the sort of social. reason. Now, those things are brilliant to sit down with some popcorn and watch happening, right? Because no one loves anything more than a drama where people are screaming at each other.
Jon Grainger:You are describing quite a niche Netflix series there. But I'd watch it. I'd watch
David Bond:If you haven't seen Silicon valley yet, and you're a software developer I know most people have by now, but whatever you do find some streaming service that you can watch that if you, if he wants to see an insight into, how social interaction or ineptitude, depending on who you are and your and your colleagues works reflected back at you, Silicon valley is a brilliant series for that. So we are so fun animals, right? A lot of these things will just come out of natural tensions and social groupings and that kind of thing. And that's fine. This is the thing that perhaps people watching from afar, I don't understand it. Don't understand why there's such a spat going on. And the reason is normally because these two groups of people passionately care about. the legacy of the code that they have their name against, and they believe it needs to go in a particular direction. and quite often, as I say, that's either for perfectly natural reasons and it'll be done very quietly or it's more ego and fractional, and that's fine too. These people don't live in the same neighborhood. There's not going to be any blood here. There will be a winner and there will be a loser and it doesn't matter. it doesn't matter which one wins. The point is that society should benefit from the fact that this splitting of the source code can happen. And actually bizarrely because of the way that open source is done with licensing must be able to happen. Nothing should prevent you from splitting off and making a fork of the code is a positive thing
Malcom:This Podcast is Sponsored by Fairmont Recruitment- leading the way in technology recruitment across the UK and Europe. Fairmont provide a high quality consultative approach to recruitment, advising and tailoring a campaign to your recruitment needs With a deep understanding of the technology sector. Fairmont can provide an overview of the market, advise on hiring best practice, and provide strategies to attract talent in an extremely competitive environment.
Jon Grainger:Do people, try and get hold of open source, get the community to improve it, and then somehow extract it and make it closed and then try and sell it as their own closed IP like a smash and grab or, extremely cynical, but I'm just wondering whether that happens and are there mechanisms to detect it?
David Bond:It happens and it is actively encouraged. So we use a particular license, which is the MIT license, which means that any source code that? we write and put out as open source can be used for good. It can be used for evil, be used for business purposes of community. for personal purposes can be useful, whatever you like providing. Nothing in effect. If you look at the MIT licenses
Jon Grainger:It's not even like creative commons where you use it, but you have to attributes. it's just, you just have it.
David Bond:Probably there's something in there saying you have to keep the copyright message on it, whether or not people do generally. No one really cares because the way that the license is designed is very permissive. So we would, we write an open source NuGet packages for Meraki cisco Servicenow, all kinds of different software vendors. And we encourage people to use that in their code. And so we'd love feedback and we'd love to get improvements to it. But you can use it for you. Like you can use it for making commercial software. We use it for writing closed source commercial software. It's the best way of doing it and anyone else can as well. So quite possibly we have a product that some of our source code is in, that's competing with someone else. Who's also using our source go to that, but that's fine. We encourage that right? Because we just want to make the best possible Meraki library that we can. And we do get pull requests and people do give us improvements, but that is fine. I think this is that there's a sort of view of open sources. is quite hippie-ish and that's a bad thing for some reason, and it's not commercially oriented. It absolutely is. We encourage people to use the open source code that we write in their closed source packages. And that's absolutely fine.
Jon Grainger:if you didn't have the open source you wouldn't even have the means to compete with each other because the open sources allowing you to go further and faster, it's basically open source is creating the playing field. Whereas if you had to do everything from scratch, you would everyone's velocity would be very low it's just like a huge accelerator, isn't it? It sounds like open source is going to be is one of those things that's just exponentially driving technology at the moment
David Bond:One analogy is the road network, but right. So it's in everyone's interest to have a really good road network so that goods can efficiently move around. So everyone pays their taxes in and the road network is created and goods can be shipped around the country and increasingly they can be moved efficiently. But that sort of common platform or playing field, as you've put, it is a layer on which other things can be built. So you can build all kinds of services on top of that road network. So everyone contributes to getting, this is the community and everyone can contribute to getting, the base layer done, and then everyone differentiates on top of it. And so there's nothing wrong with right. Creating a private taxi service that runs on the open roads. And that's probably the best analogy that I can think of is let's all create something that is common and shared that we all agree with and we try and make it as good as we possibly can.
Jon Grainger:I love analogies. So basically we say to Tesla, UBER Ford, Jaguar random names. I'm thinking of, lots that we say to all of them you're gonna bring your cars or your vehicles. But you've all got to contribute together to create the road network because without, I'm not suggesting that by the way but do you see, but do you see what I mean, It's almost like the open source is like you say, it's creating that infrastructure from which then you're creating commerce off at the top of that.
David Bond:I think that's it. Remember we've all got to eat and live, right? So we all need to generate an income, but let's all work together on the bit that we commonly agree on, and let's then build our own businesses on top of that. And I think that's a very strong approach for any society to take on, on, on many topics. So the same thing on creating common laws that we all agree on. Once we get that foundation set, we can then build upon it. Now that's not to say there aren't gonna be disagreements, right? People might not like that the roads are expanding or they might not like the road is going in a particular direction. So I'm not saying that's going to produce some kind of utopia and there still gonna be disagreements. But we're all, as long as the intent is to create that, which is in the best interest of the community, I think. I don't think there's any other way that you can improve upon that. Look at what Microsoft's doing with Azure, for example, by making it very easy for people use free open-source software. And to write that software they're making their services an Azure compute service that has to run code. So it has to be a reason for people to put their code in there. But if you look at Microsoft revenues of late that they're doing fantastically well, and a lot of that is about their move to azure and the office subscription as a service model. And I think that's something we can learn from that. There is a very healthy mix between. Open source closed source and commerce. I think they all fit together very
Jon Grainger:There's a worldwide shortage of software developers and not every business has got its own dev team. And the, reason I say this is one of the topics is getting support, vendor support as it were. Do you think there's a kind of like a minimum capability before you should really delve into open source because You don't have that support because clearly you're very engaged with the community. You're an engineer and it's engineers helping each other out. But if you've got a company where you don't have that capability Could using open source, be a difficult scenario?
David Bond:Let's look at the support question first, because you're absolutely right. If someone was written some source code it's going to put it on the internet. You've got no relationship with that person. You've gotten they've gotten no reason per se, to fix a bug that you found, Right. there. they're not financially obligated or legally obligated to do so that is why you do see models whereby okay, it's open source, but if you want to speed up a bug fix, you can pay some money. We don't subscribe to that model at all. Okay. But that is a perfectly legitimate model. Other companies will give their entire software suite away for free in the hope that you will buy support on top. Now we quite like that model, right? Because that is it's free. There's no constraints. It's not crippled in any way. you can use it, and you can use all of it. But if you want us to support it, if you want to be able to call us up, or if you want us to configure it for you. Here's our fee and here's how much it will cost. And that can either be a one-off thing, or it can be, a an ongoing support agreement that works again quite well. For many companies, we don't use that one so much. What we, our model is mostly, we've got this fantastic library of or libraries of code made, and we've got a lot of experience Come and have us work on your personal project, your closed source project, which we will maybe fold some of this code into. Do I use this open source software or library of the package and you worried that it might require some support. Ask around the community for people that are already buying the support. Do they get value from that? Do they get a little bit more or a bit less than they were hoping for or expecting, But if you're using software that requires a lot of support, you might choose to go with a pure commercial. code base or a pure commercial company, the open or closed sources is, actually a bit of a a misdirect because at the end of the day, you're running binary's that if you really wanted to, you could decompile them, right? You could take apart these boundaries and look at the source code. It's a lot of effort to do, but if you really wanted to see what the source code was, you could, that's not the question. The question is when you get stuck, will you need help? And actually, depending on the company, some companies won't need help. Some companies will just figure it out for. themselves. Other companies are really buying a service for. from a development house. not a not the software itself and the service that they're buying is we need to make this thing and we're gonna, we're gonna, how much of that is going to be in the house and how much of that is going to be pushed down to a third party. And that's really the decision but people are making. it not really whether it's open-source closed source is it's what. level of effort am I going to put teams my company can put, puts in and how much Am I going to push
Jon Grainger:yeah, cause I'm close source software you can buy and the support can be non-existent. I think we've all been there. That, that's definitely a thing everyone. You just have to be, you have to do your research and your due diligence for any software that you're going to consume.
David Bond:I think you should probably spend less time talking to the salesperson. and more time talking to the other customers. So the first question really that you should ask your salesperson is who can I talk to from one of your customers? And if they say, oh, we can't tell you that's a big warning flag. If they're immediately trying to push you to talk to someone before they've even explained what the software does, that's a very good sign because word of mouth is you were talking about Teslas, why people buying Teslas, not because they're advertised It's because word is good on the street. Is it's that kind of approach. And so I think we're seeing also, I particularly amongst the softwares of service companies that I work with move away from sales and move towards, it's very sort of American term, but it's really like it is customer success management. How cool is that? That sounds like an awful buzzword from the nineties, right? But customer success management is not about how much can we sell you? customer success management. is How successful can we make you? And therefore. How much value can we provide to you? And that will determine how much you're willing to pay for the service. So I think a move away from transactional sales that we were talking about earlier and a move towards relationship development, trust development And word of, mouth being how you find the bit of software that you've now arrived upon is it is a very strong way forward. And I think it's, We're never going to go back to the old model of you see an advert in a newspaper and therefore you buy the thing. I think we're moving much more towards now YouTube reviews interacting with existing customers of software. And that being the reason that you've chosen a software or hardware or whatever it is nearby.
Jon Grainger:Panoramic data, you all running a business that, that old saying, we're not running a charity, we run a business yet, everyone's got to make money and hopefully be really successful. What's the essence of open source in terms of not giving you? I don't want you to give away any secrets or anything, but, you use open source in your business. What's your, what, why do you do it? What's the benefit of as the if there's other folks listening or thinking, maybe, I originally liked the sound of the fact that we can accelerate there's this the fact that it's reviewed and could actually be more secure, more eyes on. The fact that it's it, we could have some very efficient code. I've got all of those elements in it to bring together to make great software. It w what is it that says to you? You know what, we couldn't be successful without open-source. Is it like that, or is, open-source kind of it's something we really like, we're proud of it, but it's not our core success or has it become something that's really integral to your success?
David Bond:Yeah, I think it's fair to say that there'll be very few C level Execs who. would make any business decision based on whether something was opened or closed source? I think broadly what they'll find is every bit of software that they're using is 80% open source plus some stuff on top. And it's the plus some stuff on top can either be a support wrapper. And that is an important decision to make when deciding on, on on some software or some services that you're buying. But the open or closed nature of the source is actually relevant because the C-level exec a, isn't going to look at the source code themselves. And so there's no idea whether it being open or closed makes any
Jon Grainger:Although, if it does happen, David, please send me the name. Cause I wouldn't mind speaking to that. That would be unusual. Wouldn't it?
David Bond:do you know, what, there are a few out there who care deeply and will submit, pull requests and raise issues on Github. And, immediately you're talking to someone like that. So we're working with a company at the minute. I can't mention the name. but the lead guy is the guy designing the database structure that he wants us to create some reports on top of. And that is fantastic because you've got a direct relationship between the business requirement and the fundamental data. That's really important to his business being a success. And it's a wonderful relationship because of course we say, hang on, right? The data structures don't contain the data we need. And he said, okay, I'll add it. And this is a C-level exec. And you think this is, a, this is such a rarity, most businesses that you deal with have got, the people that are on the Board are focused purely on sales or marketing, or some aspect of not perfectly legitimate work the way, but not focused on the actual core process automation that makes their business so efficient. And so someone who can really get that link between having an efficient. and the underlying data structures and the code that is executed upon it is in a very good position for accelerating their business going forward. But I must say most execs don't care. All they want to see is a successful outcome. And I think that's the important thing is as long as everyone's focused on outcomes, that the open or closed nature of the source, it doesn't actually matter that much, but I'll tell you who it
Jon Grainger:yeah. Cool.
David Bond:that's the developers.
Jon Grainger:a quick question. So in the episode we did on people process technology. One of the questions was within the next five years can the CEO five years from now survive without really understanding technology. And I'm not going to tell you what that individual said on the episode, but I'd be really interested in your view. And then I can compare what's your cause when you talked about the C-suite not understanding process and operations and how things are done. I don't mean not understanding, but at that kind of detailed level, which is obviously the detail you need to know to then enable it with business technology. Isn't that going to just become more and more of a pressing need in the community as well? Not? Or is it or is tech just going to take that away as being an issue?
David Bond:So if you look at the business, being successful right now let's just take a simple example of Uber, right? Maybe it was successful maybe it's not, but the point is it took an existing model and it made it much more efficient and much more accessible to its consumers. So fundamentally when it was created, someone understood that this is going to be huge because, and the, because is a matter of efficiency. So any, I must agree that any C-level exec who is not looking at their business operations model and their product operations model and ensuring that it is the most efficient and well automated version that it can possibly be, is going to be hit by
Jon Grainger:Someone else will do that for them. Yeah,
David Bond:Yeah. So if you've got someone who's running a very efficient taxi firm that can efficiently get phone calls and sMS is out to the drivers the best way that you could possibly do that with phone calls and a very efficient operator who can talk, the fastest possible rate with all the all encoded and everything is very efficiently done. They're going to be destroyed somebody comes in. and does that just with an app on the
Jon Grainger:yes. Yes.
David Bond:So I absolutely agree that every business, all C level exact should be looking at that fundamental product and fundamental business models and be more efficient. But I think the thing that we perhaps forget is that C level executives, you find this running your own small business, maybe our business isn't that big, under 20 people. and so the amount of my time that I spend not writing. code is incredible. There's, people management, there is finance, there's all kinds of stuff, which takes you away from the business of work, where work is perceived by developers to be writing code, but they're all other aspects to running business as well. So that's where delegation comes in. And so the important thing really for Board is when you go down. So we work a lot with managed service providers. If You go, if you are running a managed service provider and you have your service delivery team and you don't delegate the work. operating and talking to the customers really efficiently down to the service delivery team, and you're trying to own it all yourself, it's gonna be a disaster. So you have to delegate down and have specialist service delivery managers for the particular customers that they deal with. So the idea that the C level should be inspecting code is nonsense, but two or three layers down, Should they be working out the most efficient way of running a process? Should you be hiring developers in to automate existing processes? They absolutely. You should. Because any process that's being repeated. We we've got a bit of software that does reports and replaces the work of five people that have worked for half of The month to produce the reports for managed service provider customers. the moment that you can say, oh, that's just something that runs automatically overnight between one and three in the morning of the first. You've saved so much of those people's time and who is going to look to do that, to, to make that innovation, probably the people who are suffering the pain of having to manually create those reports. So those guys have to be empowered with and almost encouraged to find ways of improving, continually improving what it is that they do. And a lot of the time that's gonna involve automation. The problem is most people don't have the software development skills that are required to do that. So the question is then when I've got to some process that I know is inefficient, who can I go to? Who can I find that can make this more efficient? And often it's the one guy in the department who can write some code, that starts to write some Python scripts or something, just to speed up the process that, that kind of behavior. Of people seeking out automation and seeking out the one guy or the one girl that can do that automation, that. behavior is the most important. Not the actual writing the code. That's not the important thing is identifying
Jon Grainger:it's recognizing that's actually something you want to pursue,
David Bond:yeah, but now that has to come from the top though, you have to instruct your people to always be trying to find a better, more efficient, more reliable, more repeatable way of doing that process. Particularly one that has quality issues. So for example, if you're producing reports and you're cutting and pasting screenshots from something into a word document and saving as PDF and sending it off to the customer that is. Inconsistent the size of the picture might be squashed in one direction. We might cut a bit off the legend or something, as you're facing into the document. As soon as you get a bit of software to do it, it's gonna do exactly the same way. every month. And that will be done more efficiently as a result of having it automated. and I think that is, if you, if I was talking to a C-level exec and saying, here's what I would advise. It's send out a diktat now that everyone that comes up with an idea that can improve the automation of what they're doing manually currently should be encouraged to do. So that's it, that's just absolutely what every C-level exec should be
Jon Grainger:spot on David on so I just want it to play back to something around competitive advantage and the use of open source just from listening to you. So from what you've said this is what I think, you can do with open source to gain competitive advantage. So you're a software provider and you want to be famous for something. Know you can't be famous for. everything, but there's gonna be something you're gonna be famous for And what you're gonna be famous for is actually what you're really good at doing. it. And maybe it hasn't been done a lot, you're recognized as a niche, you've got something that's very, maybe even proprietary. That's your, that's what you're famous for, but you're using open source so that you're not having to build the roads. Yeah. You've got your open source around it so that you're able to actually put more of your development time into what you want to be famous for and not have to or we've got to work out how to create a road cause that's been done a hundred times before. So the competitive advantage is have you got that niche and have you got something you want to be famous for, but also isn't the competitive advantage. Also really understanding what is actually available out there in open source. and really Like you've just told us all how to spot good open source where some of the red flags might be. Do you see what I mean is that part of the competitive advantage is actually tends to be very experienced and knowledgeable about what is available and how to spot. a good branch or fork to use it as a bit of a, not quite used as in a tactical sense, but do you see what I mean that your knowledge, for example, and your comfort of being able to navigate around all of that plus what you guys do yourselves, your niche put those two together, that's, what's creating your competitive advantage, whereas before you just wrote everything and, it becomes, that's a much more expensive model to run because you're doing everything. Does that make sense, David? Or is there a nuance. that I've missed?
David Bond:No, I think that's absolutely right. Where we're using it doesn't really matter what it does, but we were using an old technology called subversion and it was doing all of our looking after our source code for us. And one day Dan here's my friend long-term work colleague said we should be using this new thing or. And I was like, ah, no, we shouldn't. No. Think of all the process we would have to change. Think of we'd have to rip so many things out and we did, and it was initially slightly painful. And then we were on this new technology, and it was a good decision and he convinced me and gave me all the good reasons why we should move from this old technology. So this new technology, and it's the thing that Brett him, pits hub is based on, obviously it's the pleasing, the name. And it's the way the whole world has gone for source code management. Now it'd be very easy for me to say no, this is the way we've always done things. So I'm sure most people listening to this will be familiar if you're not do go out and get a copy of"Who Moved My Cheese"? Absolutely brilliant book that every manager of any company ever should have read from one end to the other. and it's a seemingly very simple story about mice looking around a maze for cheese and the cheese runs out. And then we're going to find some more cheese, you can always read it as a children's but it's super important to understand that the points that the technology or the the stuff that your business is based on is going to cause you to fail unless you change, no matter how painful it, you think it might be the big problem. There is not everyone has a dad, right? Who's going to spot this stuff. Who's going to identify this. And again, the community is, there to help you. So there are fantastic podcasts and YouTube is, and people who are just putting content out there for you to consume, to understand what the new and better and the reasons for them being better. Things are in the marketplace. Now don't just change just because you see one guy that says it's a good idea. You have to build up. Momentum. And the way that I look at it is this when someone says that we should do something once I'm like, okay, that's interesting. But when I hear it again, a month later it's okay, I better investigate this. And when someone else tells me that we should be doing something, it's okay, I'm listening Now, Let's have a look. Now, if you've got that one person that is continually niggling you and your department to say, come on, we need to look at this new technology and you've brushed them off three times already. You are failing as a manager. If you've not actually sat down And have them do a presentation to you and actually argued with them and discussed with them, okay, what this is going to cause us a lot of, you have to explain to them, this is going to cause a lot of disruption. Why is it still worth it? And they still come back with really good arguments. That person is one of the more valuable people in your department because they care enough to improve your process. Not their own. They want to share this with the team. They want the whole team to be benefiting from this. You've asked, w when do we decide to go for a different solution? So for example, log for j we've been using that forever. Should we still be using it? The answer might be, yes, it might be no, but what are the alternatives? As soon as you start to hear some noise about how there are better options available, pay a little bit of attention, but when you really start to hear people barking on about a new way of going, you should be actively investigating that yourself, and you won't necessarily have the expertise yourself, but you should be surrounded by people who do, and if you're not surrounded by those people, either seek them out or just go and see what you can find in terms of podcasts or YouTube, or just, do a bit of Googling around yourself to find out what people are saying in the blogs. And so on about this new technologies, simple example, is that what Josh has less effort is And so we worked with Microsoft technologies and we use, what used to be called the.dotNet framework. And it's very easy and there's still people out there still using old microsoft technologies from 10 years ago and they haven't updated their code basis. There are very good reasons for keeping it, even if you've made one technical decision, the last thing you should do is just sit on it. You need to continue to refresh because companies are putting out very good performance improvements, very good security improvements, and you should keep on top of that. But at some point it might make sense for us to switch to a different technology. And I find it extraordinary, unlikely that I would suddenly move from developing and C-sharp developing in javaScript. I wouldn't personally go in that direction, but one day in the future, it might be a very good reason to do and if people are repeatedly shouting at me that we really need to go in this direction, I would have to listen. And I think that's very important is you're surrounded by people who know more about particular things than you do. Just spend a little time listening
Jon Grainger:David I think that is such a, an important point you make. And it's sometimes they call it Servant leadership. We've all got a role to play in the organization. And if you're, if you occupying quotes the senior role it, by no means does that equate to, everything. In fact, it means that you cover such a wide area. You probably know less than anyone because you're one of the key points is to recognize your engineers, listen to them. And I think the other point you made David about that, that individual who is putting their hand up saying, we need to do X, Y, Z. If you don't listen to them, they'll simply leave that the talent, that the situation, the market we're in they'll go somewhere where they do feel valued as well. So there's a really important reason for having those, all those additional minds being listened to and treated. First amongst equals, we're all engineers, we just have different. Some of us have more managerial engineering responsibilities which is really important because it keeps things going, gets people paid, it keeps the electricity on that sort of thing and orders coming through the But that's as important as someone who is currently evaluating three different approaches that you might want to be taking, with some open source that you're assessing. That it's all flattened equal in my opinion, it's about,
David Bond:You should only hire people who are smarter than you hire someone who's going to make, you can delegate complex problems too. And so that you don't have to. Anyone that's still running command and control these days is. not going to be there for.
Jon Grainger:no, I agree. And I think also I take a lot of comfort with advice on hiring people that are more intelligent than That That gives me a really a talent pool to go for. So I'm feeling very confident on being able to put together my next team. David, I just wanted to see, are there any other 1 0 1 points that you would want to either re-emphasize or call out around that, that this amazing topic where we started with talking about how to, the code or the analogy in terms of how you make a cup of tea and and how that equates to open source software. If you've got the perfect way of making a cup of tea, that's tried and tested. bearing in mind that it deals with boiling water. Stick with that. Don't reinvent that wheel, especially, I if making tears and what you want to be famous for, you just need T to, for what you're trying to achieve. I know there'd be a lot of. people listening who will have learnt elements around opensource I've learnt loads. And I really appreciate it. It is such a big topic. Can you just give us what your key one-on-one takeaways are for Open Source?
David Bond:The key thing is that whether the software is open source or closed source, doesn't really matter so much as who is developing it. And how can they help you when you have questions or there are bugs. I think the fact that most software, in fact, probably venture to say all software that you use today is based on a foundation of open source. it is worth considering where is that boundary? Where do you think the right point for the boundary is? Is it that the fact that it's open source should stop at the fact that you're running proprietary software on Linux, or is it that the, your entire, I don't know what a management system is, open source, and you're just buying a little bit of support from the vendor. Where is that line? Where do you think the appropriate line, the appropriate border point is for your company and for your requirements? And that is very much a personal thing. The other thing I would take away is that whether open or closed source is not, whether software is open or closed source is not as important as who is identified a process or an efficiency that can be gained through automation. Who is that person? How did they introduce it to you? Did it, result in improvements and how can that behavior be encouraged? I think that really is. that, is the fundamentals of people who are looking to improve the world versus people who are trying to make the best for themselves. Make sure that any source code that you use, whether it's open or closed source has a relationship aspect to it, whether that is that he's got a really good community around it, or whether that's because the relationship between you and the developer is a good one and that by the way, can be in-house or in a third party or strangers on the internet. That doesn't really matter. It's just, how can you form a good relationship with whoever is supplying you with your software? And then the final thing is you would probably be surprised at how much of the source code whoever you pay to write software for you. You'd be surprised about how much of that source code they've just got off the internet. Anyone who writes codes these days, New student get hub copilot. They write a comment which is, slash find first 10 prime numbers. They won't have written the next bit of code that follows. They will either get cola. Pilot will have written it for them, or they'll have gone and found it on stack overflow. So don't think that people are writing software are doing it just for You It might be the person that writing that software is somewhere on the other side of the planet. You just didn't know that.
Malcom:Thank you for listening to Episode 4 Sponsored by Fairmont Recruitment, Hiring Technology Professionals Across the UK Europe. My name is Malcom and I am AI generated. Something David said in this episode got me processing...
David Bond:robots work using instructions. they haven't got a mind or imagination of their own. You have to explain to them in great detail
Malcom:Thank goodness I am not a robot, I am. therefore. I think. Yes I have read Daycar. I am Artificial Intelligence Tune in next week for more CTIO one O one. Business Technology. Simplified. and Shared.