Open Source is everywhere - in our software, in our servers, and in the services we use every day - and its here to stay. In this episode, I give an introduction to what Open Source is, why its incorrect to think of it as free, and why there needs to be governance to protect your organisation.
Or listen at:
Published: Wed, 04 Aug 2021 15:48:22 GMT
Transcript
Hello and welcome back to The Better ROI from Software Development podcast.
In this episode, I want to talk about Open Source.
Open Source is another larger subject, I want to cover it, or parts of it, over the next few episodes.
In this episode, I'm going to talk about it as an intro, provide introduction of where Open Source is, why you might be using it and where you would find it. What I also want to touch on in this episode is the fact that it's quite often seen as being free - and I'll talk about that as I go through this episode and why it may be a bit of a myth.
There's a few other things I touch on in this episode, such as motivation and licencing - two subjects I will pick up in future episodes.
So what is Open Source?
Wikipedia describes Open Source as:
"Open source is source code that is made freely available for possible modification and redistribution. Products include permission to use the source code, design documents, or content of the product.
The open-source movement in software began as a response to the limitations of proprietary code.
Open source promotes universal access via an open-source or free license to a product's design or blueprint, and universal redistribution of that design or blueprint.
Generally, open source refers to a computer program in which the source code is available to the general public for use or modification from its original design. Code is released under the terms of a software license. Depending on the license terms, others may then download, modify, and publish their version back to the community."
So one of the first things I want to say about Open Source is it's everywhere - It's in almost every single piece of software that we use today and most hardware. Open source has become such a force within computing that it's very difficult to not use it. If we go back maybe 10 years, it was only starting to really become available and people didn't really understand what it was, whereas now, it's prevalent through everything. And I talk about some of that as we go through.
But you will currently find it in both your software your teams are building, you will find it in the laptop you're using now, you'll find it in most major systems that you buy.
Open source is so prevalent that it's everywhere and you most certainly will be using it. And as a concept, it's here to stay.
One of the things I really want to get across early in this episode is to talk about whether or not open source is free.
Often because we can just download it, people can see it as being free, and that often is not strictly true. Yes, downloading the source code may be free, but what are the licences attached to it? What are the commitments that you as an organisation need to undertake to use it? You need to look a bit deeper sometimes to understand exactly how free this free software is.
It can often come with unexpected costs, costs that are often accepted by technologists rather than the business, by the technologies using the software.
If anyone asks him: "oh, no, it's free, there aren't any licences". And then everyone assumes that it's free to use - that isn't always true as I go through some of this episode.
It's an important thing for the business to be aware of. It's important thing for the business to understand what Open Source is and the potential impact on it as a business in terms of its responsibilities and the hidden costs that it may be attracting by using it.
As I say, many times this is left to the technologists. And it's delivered by technologists without the business understanding. There is a missing piece of governance where the business is not understanding what the technologists are doing or using - so are not in a position to know they should be thinking about these things - they should be thinking about the costs and whether or not there are dependencies that are being accepted via their technologists on behalf of the business.
So let's take a look at what I consider free software packages first. So these aren't just source code, but these are readily distributed software packages that can be installed.
And again, these are often seen as free.
So let's take database's an example. These are seen as free in some cases.
So you've got a couple of well-known software packages called MySQL and PostgreSQL. These are seen as being free databases - because you can download them. Because they are open source, you can download them, install them, you don't have to pay a licence for them. There is no licence cost. And as such, they can look very, very attractive if you compare them to similar database products from Microsoft or maybe Oracle, which come at licence cost.
Thus, you see the popularity of the databases like MySQL and Postgres, which are effectively licenced free compared to licenced products such as Microsoft and Oracle.
Now, that doesn't mean that running MySQL and Postgres is free. You still need to put them on servers that will cost money - OK, you still need to put the Microsoft and Oracle onto servers and they would cost money, so maybe you're balancing out.
But you also need to support them. I find, and this is anecdotal in my own opinion, is you need more manpower to operate MySQL and Postgres than you do the Microsoft and Oracle once you get to a certain scale.
What can seem free with MySQL and Postgres licences, people forget that you still need to have people to run them to make them work efficiently and effectively, especially when you get to scale.
And that does cost money.
You need the right manpower in place to do that. You often don't get support with MySQL and Postgres, certainly not free versions - there are community forums, but that can be slow to respond.
So if you want to have a SLA for someone to respond to problems, then you'd have to go out to a support company to provide that level of support, which there are. There are companies out there that will provide you support for MySQL and PostgreSQL. But again, you're then balancing that up against the licence cost that you were paying against Microsoft and Oracle.
This is sometimes referred to as not having a neck to ring - having someone that you've bought software from, when something goes wrong. You know you've got someone on the other end of that phone to actually resolve your problems. You've got someone to actually take ownership.
If you are just downloading the software off the Internet, licence free, without having any level of support, then it's up to you to handle when things go wrong. So you have to weigh up that risk.
Now, certainly for certain applications, that free licence, maybe not even having the support may be a good choice, but you do need to consider those SLAs - the uptime that you need. And the larger you get, the more the costs will come in with that software somewhere, whether that's in maintenance, in terms of people or whether that's going to third party to provide you that support.
With all being said, using something like MySQL or Postgres can be a good choice versus something like Microsoft or Oracle, but you do have to weigh up those costs - it isn't free software. There is a cost running that software. There's a cost to maintaining that software. And that has to then be an ability to support you and your systems that you're relying on for the critical operation of your business. So, again, you need to think about this carefully.
Let's move on to source code.
It's very easy for a team to take a dependency on third party Open Source source code. Almost all software environments now support the ability to include other people's work into your software applications. It's often seen as a really good way of getting started, a good way of saving time rather than reinventing the wheel - why would we do that when we can pull in this open source library to do the job for us?
And that, to be honest, is a good way of moving forward on a productivity level. Increasing the productivity of the team by not having to repeat the same thing over and over again - by standing on the shoulders of giants.
But in open source, there is a wide spectrum of quality. Now there's some really, really good open source projects out there with exceptionally well written code, exceptionally well supported systems, exceptionally bullet proof code all the way through to complete rubbish - and to be honest, in some cases, even harmful.
So when your team takes a dependency, there has to be a level of consideration as to whether the dependency they're taking is right. You as an organisation, by taking that dependency, is relying on a third party. You're probably relying on somebody that's written that Open Source code that they're going to continue to maintain, they're going to continue to operate and they can provide you assistance if you get stuck.
A number of years ago, I released a number of my projects at Open Source. It solved a very specific niche problem. It was part of a growing ecosystem around a product called PhoneGap, which allowed them to do background services on Android mobile phones.
PhoneGap in itself was always described as being a way of filling the gap between functionality existed at the time and functionality as it was expected to be. Now, largely now I see the need for PhoneGap, and thus my open source project that worked with it, to be surplus to requirements, I don't think they need to be there anymore. The whole purpose of PhoneGap kind of has gone away because things have evolved to fill that gap. Thus the name PhoneGap. So largely speaking, I don't think my product needs to exist anymore.
As such, I have not done any further development, no further work on my Open Source work for probably getting on towards almost 10 years. But I still occasionally have people coming back to me and saying: "oh, we're using this" or "we're relying on this" or "can you help us with this?"
Now, for me, as a software consultant, I don't have the time to help everybody. I wish I did, but from a practical point of view, I don't have the ability to help everybody that comes to me.
As such, I'm letting people down and I know this. I know that I've let people down by people taking dependency on my software.
But me, as a single contributor maintaining that library, I honestly cannot justify my time to maintain that for a handful of people around the world that may still need to use it.
So if you're on the receiving end of that and you're the organisation has relied on my software to be able to do something. Then what happens then? You're stuck.
I can't help you, or are not prepared to help you. I'm not able to help you. But you've taken a dependency. This is why I think you need to be very careful about what products you take dependencies on and whether or not we expect them to be supportable and maintainable.
In the case of me, I've largely said I'm sorry, but I'm stepping back from that, I see no purpose for that, I see no need for any more.
Other people again, through life decisions, may have to step back from the project or it may take a completely different direction, one that doesn't work with what your company needs it for.
In March 2016, a story floated about how someone had broken a good chunk of the Internet by removing one of these Open Source packages. If you look for the LeftPad story, you'll find articles about where various software systems, all relying on this one actually very simple Open Source library called LeftPad, suddenly all broke. It all broke because the owner had had a falling out with a site that was hosting the LeftPad library and had removed it.
So many other software packages took a dependency on that LeftPad library that great swathes of the Internet were broken. So many people source code would no longer work because they were unable to get that library.
Again, this is talking about whether or not it's appropriate to take that level of dependency.
A growing problem around open source is also the security of the supply chain. You're again taken that depends on that reliability on a third party, one that you don't necessarily know. Almost certainly you don't know. You've never met. You have no contractual obligation. You have no legal liability with. And the danger is they become a security exploit for your software by allowing security problems into theirs, whether by accident or even by design.
There are a number of instances where people have bought projects to basically then use that existing user base as a means of exploiting for security - for security implications.
And over time, I can see the likes of supply chain attacks becoming more and more prevalent where high dependency Open Source projects are corrupted, are attacked, are exploited, allowing attackers to exploit many, many people's code that rely on it.
The other thing I want to touch on briefly in this episode was licences. I'm going to cover a bit further in another episode, but in this episode, I just wanted to make you aware that there are a number of licences that Open Source can be made available from.
Open Source is not always free, either monetary or commitment wise, different licences will put legal responsibility on you as the user of that software, and you have to understand what those responsibilities are in terms of how you're allowed to use it, where you're allowed to use it, and what you need to do if you then make any further changes to.
I'll talk about it more in an upcoming episode, but at this stage I wanted to make you aware that they are released with licences that you need to abide by.
In this episode I've introduced Open Source.
Its definitely here to stay, and it's very valuable.
It's important to computing and software development as a whole. It almost certainly will be in use in your organisations, whether it's in your software development, whether it's on your laptop or whether it's in your servers.
But the key thing you need to understand is that it's not free.
There are risks attached to it. There are management costs to it. There are governance costs to it. You cannot just assume that it's a free product and that's it.
As such, there's a growing ecosystem of tools around making sure that licences are correct, making sure that security is correct, making sure that dependencies are understood. And it's something that maybe, as an organisation, something you want to start looking at as you grow - because while Open Source is something you will definitely have to use, you'll definitely be using, you also need to make sure that you've got a governance and the control around it, that you're not taking dangerous dependencies, that you're not breaking contractual licences, making sure that you're using it in a way that it's intended safe and legal. And I think that's where the ecosystem of growing tools will help you going forward.
In next week's episode, I want to talk about the motivation behind why opensource exists and why people spend time doing it.
Thank you for taking the time to listen to this podcast, and I look forward to speaking to you again next week.