Transcript of "Open source landscape, with Ryan Bergman"

[Intro Music]

Hello, and welcome to Making Tech Better – Made Tech’s fortnightly podcast, bringing you content from all over the world on how to improve your software delivery.

My name is Clare Sudbery, my pronouns are she and her, and I am a lead engineer at Made Tech.

On Friday the 4th of February 2022, I spoke to Ryan Bergman. He’s a long-time expert on Open  Source code and an all-round top bloke, so I loved getting the chance to talk to him about a tonne of stuff to do with Open Source.

Clare: Hello, Ryan!

Ryan: Hello, Clare. How are you doing?

Clare: I’m good, thanks. It’s great to have you here. Welcome to the podcast! Ryan: It’s great to be here.

Clare: I’m going to leap straight in, as I always do, and I’m gonna ask you: Who in this industry are you inspired by?

Ryan: I was thinking about this, and there’s just so many people. I had the privilege early in my career of having a lot of really great coaches, and working with people like Tim Ottinger and  Jeff Langr who I worked with for years. But after I became more senior or intermediate, and was trying to find my own voice in software, I think there’s two people who really inspired me in my own practice, and those two people are Chris Matts, and his stuff around Real  Options and software; and Liz Keogh, who worked a lot in BDD. I interacted with both of them at a conference early in my career, and I saw Liz and she just blew me away with some of the stuff she was doing and really inspired me. I came back from that conference so energised.

Clare: Wonderful. So you’re here to talk to me about Open Source, right? So I’m gonna start with a  really simple question: What does ‘Open Source’ actually mean?

Ryan: That is a very good question! I think a lot of developers, especially maybe some of the ones who are new to our industry, might kind of take it for granted. There is all the software in the world that they can just use. Probably for you and I, you know, I can remember the beginning of my career, there was no Open Source software, not really, not that I could include in my own work. We had to write pretty much everything by hand. So Open Source is software that is available in the world, for use.

And it’s not exactly for free, right? People think – oh, it’s free, because I don’t have to pay a  monetary cost. But that’s not really true, fully, because there’s licences associated with that work. And when you download that through something like NPM or Maven, or IB, or whatever your dependency management system is, you’re essentially agreeing to those licences, and those licences have terms and conditions, and rules for how you can use that software. And those are important things, and it’s really dependent upon how you’re going to use the software. So, the obligations you have for using that kind of software on a mobile application that gets distributed to people’s phones, is going to be different than the obligations you have if you’re running it in a datacentre and it’s serving up web pages.  People need to be aware of those differences and what kind of software they can and can’t use.

And there’s generally two major versions of Open Source software licences. One is the MIT  or Apache style, which really lets you do most anything you want with it. You might have to give some kind of attribution that you’re using it, but you can distribute it and use it, for the most part, all you want. Make sure to read your licence of course. And the other style is the

GPM or GPL type of licences which are more restrictive and mean that if you use it, and especially if you modify it and you distribute it, then you are obligated to also distribute the source code. And you might be also obligated to distribute your own source code. So because you linked or modified that kind of software, you now actually have to distribute it  as also GPL. And there’s various different versions of that – some are more restrictive than others and have different rules. So I’m sure if you are working for a company, and you have questions about like what my obligations are, you might have an Open Source Compliance  Office, you might just have a lawyer, you might have some person in a senior position that would know what you can and cannot do.

Clare: Loads of questions have come into my mind on the back of that. The first thing that occurred to me actually is really interesting, because you said at the start, you’re absolutely right, that  I remember the time when you had to buy software and it wasn’t that easy. But then this suddenly popped into my mind: I remembered Shareware. Do you remember Shareware?  That was a thing.

Ryan: Sure! Yeah, like WinZip.

Clare: Yeah, so that was kind of like an early precursor, I guess to Open Source. And the idea of  Shareware was, I think, that there was some kind of voluntary contribution that you could pay, but essentially, it was being shared for free.

Ryan: Yeah, or a lot of times there was a more advanced features that were kind of locked behind paying for it. There was even like shareware video games where, when you download it, and  you could play the first you know, number of levels, and then you pay some more and you get more of it, essentially a demo.

Clare: Yeah. The other thing that occurred to me was that Open Source – as well as being freely available to use – the other big thing for me about Open Source is, it’s generally open to contributions. So you can download the source code and you can add to it. Your addition won’t necessarily become integrated with the original. So effectively, you tend to issue a pull request, and then whoever owns that software effectively makes a decision as to whether your addition will be incorporated. And then there’s a whole community around that, isn’t there? There’s the whole Open Source community of people who are developing code together and issuing pull requests to one another’s codebases. Do you have a lot of experience of that?

Ryan: Yeah, well, I myself am a maintainer of an Open Source project that’s mildly popular. It’s kind of a funny story. So there’s this old – and I say old I mean, like 2010 – HTTP client for Java, that’s called Unirest. That was made by a company called Mashape who eventually became  Kong, and Kong makes API gateways and service mesh stuff today, and they still technically own it. And the way that happened was that this library had kind of slid down in their priorities and it hadn’t been getting maintained, but it was fairly popular. And I happened to have some software that we were writing that was using this Open Source library. I was becoming frustrated by the fact that there were bug fixes and security issues that weren’t being addressed. But it was gonna be a lot of work just to try to rip it out to move to something else. And it’s a pretty easy library to use.

So I ‘forked’ it. So that means on GitHub, basically, I made a copy of the source code, which is legitimate under the licence, which is MIT. And so I made all the fixes, and I published my own version of the library. So I called it ‘Open Unirest’. Eventually, people kept complaining  to Kong, so then they said “We want the community to maintain it. Who would be a good

shepherd for it?” And a lot of people who were using it pointed over to my project, said  “Hey, this guy is taking care of it.” And so then Marco, the CTO of Kong, reached out to me and we came to an agreement, and basically I got maintainer access into their organisation in GitHub. I merged all of the stuff that I had done for Open Unirest into Unirest, and today I  am continuing to maintain it and make enhancements. I’ve got a pretty major new version bump coming out. But I work with the community, you know, people come and they ask questions. And sometimes I get people making contributions, fixing little things, and asking for new features. And so I really enjoy that as part of just existing within that space,  interacting with a lot of people throughout the world who I would normally not interact with. There’s also the advantage of – because we continue to use Unirest at work – if I want an enhancement to it, that’s really easy. I can just do it!

Clare: Yeah! So that sounds like a very gratifying thing to be doing.

Ryan: Yeah, you got a lot of different people in the world, and I get a lot of people who I would probably assume are more junior developers and are trying to figure stuff out, and they feel like they have dumb questions – and no question’s dumb, really. And so it’s an education opportunity for me too.

Clare: Do you get many pull requests, do you get many people offering up enhancements?

Ryan: Not a lot. Every once in a while. It’s a pretty robust little library, and there’s not a lot to do with it that isn’t major. You know, people come in and say “we want to add WebSockets to it”. I wouldn’t expect someone to issue that kind of pull request because that’d be a  significant amount of work. Not without talking to me first. That’s something I would also recommend to people, that if you do want to change Open Source software, it’s usually a  good idea to first open an issue and ask about it. Don’t just do a bunch of work and then issue a pull request. You might be very disappointed in the results! Because the maintainers might not agree with you that that’s the direction that they want to take their software. And that’s something I have to deal with too. People look at it and they they’re like “well, this should do this.” – and that’s not really in the vein of what it was designed to do, or how it does things. There’s a lot of design considerations. It’s more difficult in doing Open Source than like local development that you’re doing for work, because when I publish something in  Unirest, it’s forever. You can’t, you don’t control the consumers.

Clare: Yeah! Once it’s out there, it’s out there!

Ryan: It’s out there. And if you change it, you’re going to break people. Every once in a while, you have to make a breaking change. You kind of have to, and I feel terrible every time I do it,  because it’s gonna cause somebody pain, and I don’t want to cause developers pain.

Clare: But I would imagine as well, that potentially this could be quite a responsibility, and also maybe quite a drain on time. That for instance, every time somebody issues a pull request,  particularly if it’s a significant change, you can’t just look at it necessarily and say yes or no,  you actually have to give it your time and attention in order to be able to make those decisions, and you might not have spare time. Is that problematic?

Ryan: Right. It is problematic, and it’s not necessarily been a huge problem for me, because I don’t field all that many pull requests that are of significance or complexity. Usually, the ones that  I get are honestly pretty minor, but within the industry as a whole, it’s been a big problem. A  few years ago, there was a Node.js library had something to do with streaming data. I can’t

remember exactly what it was, but a malicious actor, introduced through a combination of two different pull requests, a security vulnerability that basically I don’t think it worked, but it would attempt to find a crypto wallet on the local server and then mine Bitcoin or something. And it wasn’t super obvious through either one of those two pull requests, but it was the combination of them that got it in. And it was published and went out, and the npm community has a tendency to set their dependencies to be flighting, to just say, “go ahead and download whatever new patch version has come out” – which I think is more prevalent in that community than it is in say Java. And so all these people, suddenly as soon as that patch went out, downloaded this vulnerable library and started running it. And those commits had gotten in because the maintainers hadn’t fully thought through maybe what was going into them.

Clare: Yeah, I can totally imagine if you were a maintainer and you’ve got other stuff going on,  you’ve got a day job, you might be busy, it might be stuff going on in your life. You never know when these requests are going to arrive. You’re not necessarily always going to do due diligence.

Ryan: Right. And that’s been a problem in the industry. Some Open Source is maintained by a  corporate entity, like React is maintained by Facebook, as is GraphQL. But a lot of the stuff,  even things that have a home in an Open Source wheelhouse like Apache, we’re not paid.  Nobody pays us. This isn’t my full-time job. I have family, I have other obligations. And yeah,  especially if it’s a very highly used project, and it does get a lot of pull requests and issues and requests for changes, it can be a little overwhelming. And I’ve seen plenty of Open  Source maintainers just completely burn out and give up. You’re using something and you go to its repository on GitHub, and there’s 500 issues and nobody’s merged anything in over a  year. It’s probably because the maintainer has burned out on that project.

Clare: Yeah, I can totally imagine how that would happen.

[music]

While I’ve got your attention, let me tell you a bit about Made Tech. After 21 years in the industry,  I’m quite choosy about who I’ll work for. Made Tech are software delivery experts with high technical standards. We work almost exclusively with the public sector. We have an open-source employee handbook on GitHub, which I love. We have unlimited annual leave. But what I love most about Made Tech is the people. They’ve got such passion for making a difference, and they really care for each other. Our Twitter handle is Made Tech. That’s M A D E T E C H. We have free books available on our website at https://madetech.com/resources/books. We’re currently recruiting in  London, Bristol, South Wales, and the North of England via our Manchester office. If you go to https://madetech.com/careers, you can find more about that.

[music]

Before the break, we were talking about how most Open Source maintainers aren’t paid, and they often burn out and give up.

Clare: I wanted to go back to something you mentioned right at the start, which is the different kinds of licences that are available. And I was wondering if you have any tips, because typically, if you’re a developer and you want to do a thing, and you do a little bit of googling or just somebody recommends a particular package or library and you’re like “okay, that does the thing that I want it to do” – you just download it and install it, often without even thinking about it very much. How do you know if that actually has got some licensing requirements with it, particularly if you’re incorporating it into commercial software, that are going to have an impact on you?

Ryan: So I would first say again, if you’re working for a company that does software – and it doesn’t have to be a software company, you could be working for a bank or an insurance company or whatever – but if there’s a significant amount of software development being done in house, you most likely have a lawyer who is tasked with coming up with the policies for the  Open Source software you use. Almost all Open Source software will contain a licence file,  it’s usually called (all caps) LICENCE that sits at the root of the repository. And you can read through them, and some of them are very, very short, and some of them are much, much longer and have lots of different obligations. So I’m going to tell you to talk to your lawyer first and foremost, and not try to interpret it yourself, is probably the best advice. Keep in mind that most of the obligations, the more difficult obligations, will come into play when you distribute the software that you’re writing. And those of us who do web development with a much cushier lifestyle, using Open Source, we have a lot more leeway for what we could do without really needing to say anything, because we don’t distribute it.

That said, there are still some Open Source libraries that you can’t use, even on a server, because they come into effect if you network them really at all. And that’s the GPL thing. It’s called the Affero licence, which is generally used only by companies that have Open Source parts of their software, but they sell commercial versions. And then they might have an  Affero licence version, which lets you download it and use it but not in a commercial sense.  You can’t make money off it, you can’t use it in a production environment, unless you’re willing to also Open Source your entire stack back there, which is probably not what your product owners and your lawyers want you to do. So be careful.

There’s also software that you can buy that will analyse your bill of materials and tell you what kind of licences you have. And usually with these tools you can set up you know, this is the kind of software it is, this is what its distribution is going to be, and then they’ll give you a licence risk that – “Oh, this is a problem licence. This is not a problem licence.” – and then you can make a little bit better informed decision because, you know, doing software today,  you download, sometimes hundreds and on a large project, maybe thousands of Open  Source libraries. It can be overwhelming to have to try to go through all of those and figure it out. Especially on NPM stuff. They’ve broken that stuff down so tiny. They have an entire library for left-pad. It can be a bit much.

I have an interesting story about the licensing part. When I took over Unirest, it used a  library called org.json. So org.json was kind of the original JSON library for Java, came out before some of the other ones that are more popular today. And it was used by Unirest as its kind of native JSON library. So JSON is a data format for data. So it’s a way to express data in text. It kind of has roots in JavaScript, lots of curly braces and quotes. It’s a very simple kind of key value pair format, very common in web services. So this is a library for reading and writing JSON. And it happens to have a clause in its library that it cannot be used for evil.  Otherwise, it’s a very normal licence with this one additional clause. And I had received several requests from some of the large Open Source repositories or groups like the Eclipse  Foundation, and some of the Linux repositories, asking that I remove org.json from Unirest,  because they couldn’t host it. They couldn’t put Unirest in their repositories because it was linked to org.json, and because org.json had this clause about not being able to be used for evil!

Clare: Does that mean they were doing evil? Or is it just because it was a legal grey area and they weren’t sure whether they were doing evil or not?

Ryan: I think that’s it. I think it’s a legal… How do you defend that in a court of law? What is evil?  Like how you define evil, you know, is not something lawyers want to do! It might be something philosophy majors want to do, but the lawyers did not like it. And so I was concerned about that. At first, I was kind of like – “Pfft, whatever! You can’t defend that in court anyway. Why do you care?” – And people just kept asking me about it. I had this huge issue with all these different groups, that it was one thing, when it was just, you know, some random developer, but when you have the Eclipse Foundation coming to you asking to have it removed… and Google had actually, also they made their own clean room implementation of org.json for the Android operating system, which runs Java. So if you write an Android app, you’re probably writing on Java.

Clare: When you say clean room implementation, what does that mean?

Ryan: So in order to say that you didn’t steal any of the internals of the application, you basically figure out what the edges look like. You kind of trace it, and then you make it operate as the other thing operates. The term comes from the eighties, when Hewlett Packard did a clean room implementation of IBM’s ROMs for the PC – or was it Compaq? Either Compaq or HP – They were the first ones to make clones of IBM Personal computers. And that’s kind of where the term comes from.

So Google had done a clean room implementation of this library. I wasn’t really a fan of theirs because they also had not maintained it in several years. And it actually wasn’t any longer a match for what org.json had in its own signatures. And I was using some of those newer things. So I couldn’t also switch to Google’s version. So I did my own clean room implementation of the library that matched the methods. Basically what I did was, I wrote a  whole tonne of unit tests for their library.

Clare: Oh, wow. Okay, so that sounds like quite a big job.

Ryan: It was a big job, but it was actually pretty fun.

Clare: Yeah, I like doing things like that too.

Ryan: So without looking at their software, without knowing what it does internally, I wrote unit tests that documented its behaviour. We would kind of think of these as characterisation tests. And then I basically removed their library from my software, in which case I now have a whole bunch of breaking changes because the software is not there. And I have to fill it in.  And I started out just, I commented out all of the tests, started at the top and uncomment them one by one implementing exactly what it was doing. And so today, I don’t have a  dependency on org.json. I also was not really interested in writing my own JSON parser because it is actually fairly complicated. And so what I did was I made essentially a wrapper around two different implementations, using the two major JSON parsers that exist that have friendly licences. And it’s almost guaranteed, if you have a Java project, that you have one of the two of them in your project. And so my stuff just basically says – “Well, you can use it. Bring your own JSON library that’s gonna back this thing.” – but its signature is the way it looks and the way it behaves. So it’s the same, it’s always the same, regardless of which of the two you’re using.

Clare: And now you’re free to do as much evil as you like!

Ryan: Yes! Now it can be used for evil! That was the one you know, when I started the whole thing,  I was like – “Yeah, I’m kind of sympathetic to this. I maybe you shouldn’t use it for evil.”

Clare: Maybe you just need to get them to define evil. Then we’ve got a whole can of worms. So I  know that you’ve been involved in helping with various security vulnerabilities in Open  Source software. So how do you coordinate getting hundreds of teams and thousands of projects for instance, to patch Log4j?

Ryan: So Log4j, for those listening who are not aware, is a logging framework for Java. It is one of the most popular logging frameworks for Java, and you will find it in almost everything. It’s everywhere. And it had a very major security vulnerability about a month and a half back,  which allowed someone to execute commands on whatever server or whatever hardware it was running on. You could pass the command if – as long as it went into the logger in any way whatsoever, like getting logged at an info level or an error, whatever – It would execute something on the server. And so this was a very major security vulnerability, one of the most egregious ones I’ve seen in a long time. And it was very important that everybody get patched because we could see from looking at server logs, that almost immediately, people were trying to attack everywhere.

Clare: And when you say ‘we’ – who are you talking about in that context?

Ryan: So I work for John Deere Intelligent Solutions Group. We analyse agronomic data, and we make reports and such for farmers to look at the data that comes off of their equipment.  And those are all on web and mobile applications. So we have a lot of web servers, and these attacks are coming from bots, you know, people programme these things and they just kind of crawl over the internet looking for a response, basically doing pings, trying to poke through. And if they get something that comes back from the other side, they know – “there’s somewhere where I can attack” – So we started to see those immediately.

And this was a big co-ordinated effort, and I was just one person. I’m a senior staff developer, and I kind of oversee a whole little sub-section of where I work. And so, I was co ordinating with the teams that I work with and trying to analyse all of our applications to see who was vulnerable. And there’s software you can use to help with… some of that same  software that I mentioned, that would help you with the licences – can also, of course, tell you – “these are your dependencies, this is where it is.” Internally, we use GitHub. So we started scripting, using its search engine to try to find anywhere that might say “Log4j” and then go and try to find out if it was really used. I think one thing for people to be aware of when this happens is first of all, don’t panic. And just because Log4j – or whatever library it happens to be the next time – exists, doesn’t necessarily mean that it’s exposed, and doesn’t necessarily mean it’s vulnerable. You gotta try to evaluate that, most of our applications actually weren’t vulnerable. Sometimes Log4j existed because it was in some downstream dependency. But for the most part, we use a different logging framework, called logback,  which is the other logging framework for Java that’s popular.

And we just lucked out, you know, it could have been logback that had that same problem,  but it wasn’t this time. And I think it was very stressful for the maintainers of Log4j – they came out with several patches very quickly and there was a lot of scrutiny on them. Like every security researcher in the world was analysing that library. And so they came out with a patch, and then they had to come out with the second patch to patch the first one, because they hadn’t quite got everything, and then they came out with a third one. I think they’re at four now, each time closing it a little bit more and a little bit more. I think it’s done now. But how you co-ordinate that with all these teams, for something that egregious, is really kind of an emergency thing. And all the teams really came together. I think the developers really understood the gravity of the situation when I was explaining what was going on. And so there was a lot of co-ordination on, we use MS Teams internally, we created an entire channel just for that. We started spamming the other channels and like,  you know – “Here’s the steps. Here’s how you find out what the problem is. Here’s how you find out if you’re vulnerable. Here’s what you need to do to patch it.” – And I think at the company or at least in my division, all of our stuff has good CI pipelines and we deploy to production quite often, sometimes many times a day. So for us, getting that patched and pushed out wasn’t really a big deal. And we did it pretty quickly. I think if releasing is hard for you, patching is also going to be hard.

Clare: Yeah. So it sounds like the key elements here were first of all delegation and collaboration – so not making it one person’s responsibility, but making sure everybody was empowered to make the changes that needed to be made, and understood the importance of that. And then a part of that was good communication. So you let people know what they were looking for, how to fix it, making sure they had everything they need, that you could then  delegate that responsibility and say like – “Okay everybody, this is what you need to do.” And then the other thing that sounds like made a really big difference was the fact that you did have those CI pipelines. So CI, for those that don’t know is continuous integration. And it means that you’re continuously integrating what you do with your finished products, and you’re able to say – “Okay, we can push this, we can push this right out into the outside world” – and that’s a really nice little sales pitch for continuous integration. This is why continuous integration is really good, right?

Ryan: Yeah. And do it with confidence that you’re not going to break stuff, and do it with small iterations. So if you’re going out to production and the only thing that’s changed is Log4j is gone from whatever number it was to a new patch version, you could probably be pretty confident that you’re not going to break something else with that.

Clare: Okay, we’re out of time. So I’d love for you to tell me something about you that’s true and something that isn’t true, but don’t tell me which is which.

Ryan: Okay, well me and my family have a little tradition that we started, where we’re trying to take our family’s photograph in front of all 99 counties’ courthouses – but there’s 100  courthouses because one county has two – in the state of Iowa, here in the United States. It’s  a fun little deviation. And once we got accidentally locked in one of the courthouses and had to spend the entire day there, because we went to use the bathroom and then got locked in.

Clare: Okay, so either you’ve been taking photos of lots of courthouses, or you once spent a whole day in a courthouse because you got locked in by accident. I love it. I’m not going to interrogate you any further, but I will let listeners know that we will reveal the answer in our next episode. So there’s a little inducement to listen to the next episode, to find out which one of those things was true and which one of those things wasn’t true.

[music]

We’ll reveal which one of Ryan’s answers was true and which one was false in our next episode, which will feature Alex Herbert talking about LGBT+ History Month.

But meanwhile, here’s the answer from Dr. J. Harrison’s episode on inclusive teams, where they told us that either when they skateboard and surf they are ‘goofy-footed’, or they smashed their leg badly when skateboarding.

Dr. J: I fell off the skateboard at less than walking pace, and managed to smash my ankle so badly, it took me 18 months to get to walking again, and I now have to walk with a stick because of all of the tendon and ligament damage that I did to my feet. So, kids, when you’re in your thirties, and you’re playing around on skateboards, be careful!

[music fades]

Clare: The next question is: Where can people find you, and do you have anything coming up that you’d like to plug?

Ryan: I don’t have anything I need to plug right now. You know, COVID is hard! I’ve been meaning to get out more. But you can find me on Twitter. My handle is @ryber – which it has been since eighties BBS days. I’m also ryber on GitHub, if you want to find me there. And I have a  blog. It’s linked to from my Twitter and it’s on GitHub.

Clare: Brilliant. Okay, so very last question is – what is the best thing that’s happened to you in the last month or so? Could be either workrelated or not.

Ryan: I injured my shoulder last year, and I got what’s called frozen shoulder. And over Christmas, they did a little procedure on it. And then I had to do a bunch of physical therapy. But my shoulder works now. And I can sleep on it, and I can reach all the ways I need to reach. So over the last month, that’s been my concentration, is on getting healthier and getting my shoulder healthier, and it feels great!

Clare: Oh, I get that! And I understand why that would be a big deal, because I have arthritis actually in both shoulders, but more in my right than in my left. And all of that stuff. You know, certain movements are awkward and when you have things wrong with your shoulders, you suddenly realise how much you use your shoulders. For most things, anything to do with arms, shoulders are also involved!

Ryan: If you start thinking about them too much, they’re pretty weird, like the fact that your arm does all these weird… all these weird motions. It’s kind of bizarre when you start thinking about like, what is it that actually moves my arm like that?

Clare: It’s pretty clever, the things that we can do with our arms! They do move in a lot of different ways. And I hadn’t thought about that. So now I am. Thank you! (laughs)

Okay, thank you so much for talking to me. I really enjoyed it.

Ryan: I enjoyed it too.

Clare: It was great to meet you.

[music]

As always, to help you digest what you’ve just heard, I’m going to attempt to summarise it.

Open Source software is software that’s available for anyone to use, and for anyone to potentially contribute to, but it’s not exactly free. There are licences associated with its use. Details vary, and you should check with your legal team.

But who maintains Open Source code? Often, maintainers are individuals who are often doing it for free, which can lead to burnout. And if something isn’t being maintained, this might be why. Sometimes it’s whole communities that are maintaining a particular codebase, and sometimes it’s corporate entities. Don’t assume you can just amend Open Source software. Being responsible for  Open Source software means considering all its users, which means thinking about what the overall aim is and staying true to that, and also trying to avoid breaking changes. So if you want to make a contribution to an Open Source codebase, have a conversation with its maintainers before submitting a pull request. But in general, it’s a great way of forging connections with people you might otherwise never meet.

Open Source can be vulnerable to malicious actors. You can’t assume maintainers are able to do due diligence when checking pull requests, and malicious actors can be devious, spreading vulnerabilities across multiple pull requests. You should regularly update any code you use, but also don’t assume that all updates are safe. Pay attention to security patches, and for big vulnerabilities, get everyone involved. Keep people informed, give teams what they need to fix things themselves, rather than taking it all on the shoulders of one individual. And don’t assume that all of your code is affected by a particular security vulnerability. It might not be. Continuous integration makes a big difference to your ability to patch and respond quickly when there are security vulnerabilities. And the more quickly and easily you can release new versions of your product, the better you can respond in times of emergency.

Okay, that’s not all. Stick around for extra content.

[music fades]

Working in the public sector means that at Made Tech, we really care about making a difference. So for this final ‘Making Life Better’ segment, myself and my colleagues will be sharing suggestions for small things we can do to make the world a better place. So I have Ciara with me, who is our  Community Manager in the South West region, and she wanted to talk a little bit about neurodiversity.

Clare: So Ciara, I know that what you originally spoke to me about was the concept of trying to fit in. Do you want to expand on that a bit?

Ciara: Yeah. So I think basically the first thing was that everyone is kind of neurodiverse, everyone has a different brain. I think being neurodivergent myself, it was more apparent to me from quite a young age that maybe I thought differently, or maybe that some of my reactions to situations were a bit abnormal or a bit quirky, I guess. And so I think for a long time, that really scared me, and I was trying really hard to fit in and to just do everything that everybody else was doing. But I guess just kind of backfired in terms of you never really feel really good if you’re trying to change who you are to fit in with other people.

See, I think professionally and personally, if you can find ways to do what you’re already doing, that will make it productive as well. So yeah, if one of those things is you’re a bit more  ’out there’ or quirky or you think differently, then just use those to create different kinds of connections, maybe. That helped me in a way, and just being empathetic that other people might be feeling the same way as you. So if you can be yourself, then other people might be more likely to be able to be their selves as well.

Clare: Yeah, I love that. Not just the being yourself, but also that thing of creating a space for other people to also be themselves, and being able to celebrate your own differences, rather than trying to squeeze yourself into a box that you don’t fit into.

Ciara: Yeah. I guess it obviously takes confidence, and when you’re younger you might not have that, and then as you go through life, you’d get a bit more confidence to do that. But I think that even when you’re a ‘grown-up’ it can still be hard. So having other people being themselves around you definitely helps.

Clare: Fantastic. Thank you so much, Ciara.

Ciara: Oh, well, thanks for having me. I’ve always wanted to be on a podcast! Clare: And now you have!

[music]

And that’s the end of another episode. If you’re enjoying the podcast, please do leave us ratings and reviews, because it pushes us up the directories and makes it easier for other people to find us.

I’ve got a few talks coming up. You can see the details on my events page on medium, which is linked to from my Twitter profile. And you can find that at @claresudbery, which is probably not spelled the way that you think. There’s no I in Clare, and Sudbery is spelled E R Y at the end, the same as  ‘surgery’ or ‘carvery’.

You can find Made Tech on Twitter at M A D E T E C H. Do come and say hello. We’re very interested to hear your feedback and any suggestions you have for any content for future episodes, or just to come and have a chat.

Thank you to Rose, our editor; Gina Cady, our podcast co-ordinator; Fiona Egan, our transcriber; Richard Murray for the music (there’s a link in the description); and the rest of our internal Made  Tech team – Kyle Chapman, Jack Harrison, Karsyn Robb and Laura Plaga. Also in the description is a  link for subscribing to our newsletter. We publish new episodes every fortnight on Tuesday mornings.

Thank you for listening and goodbye.

[Music Outro]

[Recording Ends]

Back to the episode