 We end up with these things that are really hidden, these closed and potentially distributed that code platform system that we're working on. And really, when we see it in government, the traditional practices favor that very, very binary thing that we see, but not the worst. And really what we want to start to really think about is how we add a few more colors in our option so that we can have this kind of continuum of inner source becoming that key capability or that key piece for us to get better neurons in the big organization. So, inner source is really, those open source practices behind the firewall. And what we started to really look at or around those areas of improving discovery, improving collaboration and the transparency. So for us, it is really starting to rethink about how we do engineering practices inside the organization. So a little bit about our road to inner source. So we really started to think about what our core principles would be. Now, so much of the work that we've done is standing on the rest of the community around the inner source commons and the open source community as a whole. So much of that was really starting to think about those core principles that we looked at. The openness, being able to discover code internally and the documentation of knowledge that follows. Transparency, being able to look across the organization, following these practices as open source practitioners would probably be very, very friendly with. And the collaborative, which typically hasn't been done when teams are working very, very solid in their organizations. But this is a way of starting to really rethink but also change how we engage, how we start to do mentorship, how we start to do learning, how we start to really bring that network effect into play to really think on how we scale this more importantly. So what we really started to think about are these core foundations for us in a source journey. And we started with the platform. And last year we started on a journey of taking, moving towards the central source code platform. And along with that really the practices of the people. In any kind of transformation, the journey we see that there's three key pieces that come in there. The practices, establishing guidelines, working off what we start to see in the industry as well as the commons as a really critical partners. So much great work has been done out there. We didn't want to necessarily reinvent the wheel. We wanted to be able to get to change faster by leveraging what's being done already. People as well, I think we start to see that engagement across the organization is such an important part, raising awareness. All of these things that we thought would have been a little bit more obvious, but interesting. And I'll share a little bit later, the lessons learned as we go through and all this. If there were a few assumptions that I made a mistake on, there was a really good learning journey to understand the organization. So last year we began this journey. We migrated what was a fairly disparate platform from the big buckets, skip path to the world, into a central managed skip path repository, which really started our journey and enabled that platform. And that was a bit of a bottleneck as well, because I mean, I'm quite a factor in the tech. So my great, a very large set of repositories were probably halfway through and were probably discovered probably about just under 10,000 code repositories in the organization that will be part three through their journey. So it's a bit of a challenge. And that's sort of based down at least for our options. And then what we did do very early on before the platform was ready was really establish this community practice, what we call the InSource Working Group inside the organization. We've brought in a number of different divisions involved it to really establish this group that we could start to, you know, set up communications channels, monthly sync cups and as well as at least funding repositories we could start to work on to build out the practice. And interestingly, the leadership was actually very, very supportive of the whole thing. So I'm going to go into a little bit of detail about why we've done other challenges. But going on some of the other pieces we started to frame these sorts of three stages and this builds up the commons in terms of maturity models and things about, you know, these stages of InSource adoption. I think the obvious piece is yes, you know, at zero we've got closed source code. And that's the devolved assumption for most of the organization. Moving up to the next level, reading the source, being able to really see all that code that's available and then going on to accepting contributions or then going on to something that is potentially community-oriented. Thanks. And so that's where we started to really frame about not only how we think about InSource coming into the organization but also how we start to reward success. But there was a really interesting sort of quote that came about in our adoption of open source. So when we first started off there, you know, you know, if a familiar was studying with open source, his commission was. But in certain organizations, which is fairly structured, I found teams that were engaging in coming and knocking on the door and saying, oh, do we need to get permission from you guys for these projects? And, you know, perhaps a blind spot on my part in thinking that, oh, okay, anyone just can't do it, just open up your project internal, adopt some practices and you could go. But it actually meant we had to spell it. We had to be very, very clear to say, okay, you can't do it, and this is where we started to really frame it into two different models. Much like the wider community, we have this kind of model where we created open source, or open source in this case, the teams can do it in what we call a project initiated model. They release it out there, and it supports the two layers of the triangle at the bottom to say that kind of readable source, or yes, contributions, because it's owned by the team. We then step across the community side, which is very much like we see with a lot of the open source foundations, where these projects may be done essentially. All of those sorts of things we see are generally utility, or things that may be bigger than an individual project team. And so that's a kind of multi-model model, those sorts of things. What we will now start to really think about is if a project does want to be donated essentially, what are the sorts of criteria that will be accepted? Much like an open source foundation, those foundations, all those sorts of things. What are these sort of acceptance criteria as well as the ongoing expectations for those sorts of things? People throwing code repository over the wall, and it's dedicated to game platforms. That's not necessarily always bad, but we just need to be cognizant that these things probably should have some shape of the game going along. And so as part of all of this, we started to really sit down with the working group and develop some practice guidelines. Now, we didn't want this to be the typical government, and they would say now must do this, and then we run it to be somewhat organic. And so we came up to really align around those principles around these three core areas. And these are these sort of fairly lower areas, a sort of pattern that we start to see around standard documentation, the briefings and the contributing markdown documents. Obviously switching to internal is such a key piece of any of that. As well as, you know, licensing. And I'll go a little bit more into how we went about creating an inner source license inside the organization. The other piece is, and this was interesting that the kind of merge and pull requests both never really existed inside the organization which we'll find now. So we also then had to go along the way and explain why merge requests and pull requests were such an important part, how we go about doing that, how in fact can change from traditional change change advisory boards in enterprise organizations to something that gives us a better time to market, as well as confidence. The reality is we're a somewhat low trust organization or at least we have to have confidence in the code that we're putting into our systems because our citizen data is actually you know, dated and verified. But that actually aligns very nicely with the kind of open source practices too. Issue trackers, now I think there's always this kind of piece about, you know in an enterprise organization, we've probably got some JIRA here, it's a balance over there and really setting a good expectation that a lot of teams will still maintain and do that. A lot of people really love JIRA for some reason. But at the same time, you know, there is, you know, we need to have something that is accessible and it's actually visible to those teams who do want to contribute and learn about things. And that's where we start to see, label-laying and licensing companies, or label-laying and ticketing practices that can start to enable vibration and scale. That's one of the kind of decision-making processes coming and thinking about documentation as code. Architecture decision records, design documents that get placed in the code repositories. Very, very fundamental shift to how we operate in government. Probably very fundamentally different to how enterprises operate in some cases too. And that became not just about saying, yeah, we're not going to do open source and you've got to do it. It actually meant that we had to kind of bring the organization on with this as well. And finally, that kind of piece about actually team roles we have team structures. These are very, very important we start to really think about. And so, you know, I think we're probably fairly familiar with the types of roles that we see in the open source community, both from computers to code reviews and maintenance. You know, these are the sorts of things that we're now starting to formalize in roles that people can come up with, particularly just in the shepherding of the hosting process. And that one is, you know, just, you know, and ongoing pieces we start to see how these sources fit. I mean, I think government likes to have formal roles and things. We're trying to avoid that kind of delegation of control, but it's certainly something that we want to enable and encourage from operation. So, an important part because, you know, the government, while it looks like a single entity is not that each agency is, you know, its own legal entity, it has a very wide set of different teams and also vendors as well. So we sat down with our legal department and worked through what we call the Galtech publics of license. Now, that one is something specific to Galtech for collaboration is based on you know, permission, you know, sort of permissive licenses, basically MIT with a few extensions. And that really started to program our expectations on the use of code, both by other agencies as well as vendors. As well as what happens when contributions are contributed back to who wants them. And that sort of set of expectations to those teams were starting to open source of their projects in most, you know, common practice, putting license while in the repository, potentially putting it in source code files, you know, is the way we've gone about doing those sorts of things. So that was just a bit of kind of a hygiene piece, but an important part to really get confidence as we started to roll it out. Now, you know, mentioned it's always a critical part. It's really quite interesting. We started off this journey in management. It was like, yes, we love the idea of going through it. But then, you know, the next question is always how do you measure it? Now, this was not something that was necessarily funded. This is something that a group of us started after working community. We've worked with now source for management platform to get resources available to start to open these sorts of things up. But at the end of the day, we started to think about what are really these core placements that we could start on. What's the easiest thing to get started? And obviously, the most obvious piece is kind of project disability, knowing if it's internal or if it's closed. That's that kind of binary piece we want to start to see how we get more nuance in there as we go forward. This practice was another piece that we wanted to say, yeah, we have, you know, an already inscribed tool that we'll actually go on and look at a project and see have you put in a reading, have you put in a licensing file, and then give you a bit of a report back. And the kind of next jump is to say, well, let's also make it an easier or a greater pool of advice to give you those files if you're lacking them as well. So this is not just about the measurement but also the enablement as well. And then finally, kind of these three stages of adoption which we're getting to next, as I showed that kind of the triangle. We want to see not just the breadth of how many people are starting to use in the source, but also, how many are starting to contribute, how many are starting to have multiple maintenance or contributors as well. So still a very basic metric and that's the thing that we're starting on. Next, once we get a bit more volume, we can really start to get more nuance in there. But because practices still have basic, we wanted to really get things moving first and then we start to report. But even though we're telling it to really kind of punch the numbers on project visibility, probably not as fast as we were expecting because we got some gating in there, but at least the numbers are starting to show where we can really start to think about improving. So inside of GoTem, we've actually done working groups obviously dog-frooding everything that we do. A lot of our internal platforms, CICD, our cloud platforms are starting to in the source or the code that we can. Things like how do you provision accounts in all of these CSPs? How do we start to make a monitoring, IDC, all of this kind of stuff? But the other kind of bigger discussion is, in fact, how do we change things for the organization? Now, as much as this we don't necessarily want to make it a mandate, having open source pipeline of teams that can tell you as we can. And so that's a way we're really starting now to discuss with management. Is this something we do for GoTem? Is that something that potentially can roll out to the rest of the organization as well? So a few of the lessons learned that touched a little bit on that. Having code platforms available on RAIN is such a big part. Migration is really actually kind of that. So although we can do in a source across again a lot of different projects, it really changes the model. Having a central code platform means we have that network effect rather than jumping back and forth. And so at least it's an easier starting point than really sprawling out in a source portal and getting agreement for each of the project teams to share their resources or share them in a source project. So that gives us a little bit of a central visibility piece. But not necessarily something critical. See if the community is always such an important part. So I think the business source doesn't necessarily need to actually follow this. We need to go and sit down, brown bags or sharing with all of the different software engineering communities across the organization to raise awareness of the starting thing. Permission is not required, as I said. We didn't want to be the assumption that everyone needed permission to do in a source. It needs to be permissionless. But we also needed to make sure that was communicated and documented. Was the assumption, was the other way around, everyone needed to knock on the door and say please, please, can we do it? We didn't want that. And really finding the right allies and supporters. That was the other piece. Getting leadership to pull was easy. In the leaders, we presented pretty much what was the start of this day. And I said, yes, don't do it. Talking to the developers, I think everyone was probably kind of familiar with the source. And as part of that, they were kind of, yeah, we supported, but the middle management was always a challenge. As it is in so many big organizations, finding time, finding resources that the developers then can go and put on this sort of project to be heading the important line. And so I actually meant going down and knocking on doors. And helping those teams, helping them convincing them that there is actually benefit on those sorts of things too. So I actually meant in this kind of organization to go around and do a lot of manual work. And so finally, starting off on your own journey, I mean, we established a community of practice. The guidance and patterns that came out of the Commons was such a great resource. And I'm hoping that we can contribute some back in the future. We're starting small, you know, big bank governments do a big bank, trying to solve everything in one go, but at the end of the day, like most initiatives, it takes time to really grow and start. So with that, I would like to say thank you very much. If you on the other hand are interested in coming to join us on this journey, we're hiring, but come and join our working group, come and help us thrive in a source across the organization too. Thank you. We have a bit of a jam in the schedule so to be speaking in the southern export right now. However, Mike, are you in the room? I don't think so because I'm not in the room anyway. So, questions? Oh, here, sorry. So the British government did a very radical thing in their IT service. Decided to put the code on the public in harm, including their road maps. So, is there a step on how to bridge in a source with open source and absorbing open source integrity? Is there a way to come back and create that process? Probably it's other government agencies that can start to collaborate and use some of the work. I think for us, internally we solve the government agencies across Singapore, but there's a wider question on how do we bring this community into the open source more globally than the public sector across the globally. We have thought about that. But then, if we think about open source for everything, we would be going that route. In a source, it's kind of like intermediary things, but not everything can be released. And we still want to be able to get them. But I think as we go forward, at least on that previous diagram that I had, we're trying to push everything to the right of my views and projects. But I think as we go forward and so I would like to see more of that. But it involves trust, I think, in some way. So I'm confident in the organization to start to say let's go on an open source more. Let's go on a new route. Alright, just ask again. It's my question on the route. Okay. Given that we've got them, happy to allow Q&A, however, we are multiple tracks. If anyone is looking to shift to the other tracks, now is the right time to release them. If not, we will carry on with it. Sorry, I didn't know this. I have two other questions. I just want to ask you a few questions. And then the second, how do you get my views from the teams? Who do you want? Who do you want them to open up their code? That requires an additional effort on the site, but it's not the beneficiary of that. Okay. Other things, I'll make a quick point. What are they? Sure. The question was how do we get YM across different teams? I think, you know, that is a big piece and, you know, a funded working group to drive this thing, we can only go a certain way. A lot of my time I spent on being indoors and working with the development teams was managed to convince them to in a source. But I think the next stage is really to say when we can start to demonstrate some more value, get a few more numbers to show that this is actually something we want to continue working on, can we get funded? Can we get a core team effectively in the in a source common pattern level of a team that will actually then be helping teams not just about awareness, but in fact, opening up their code, providing the resources to either open it as is and provide advice to the team and maintenance actually ongoing as well. Or to sort of carve out a piece of a library that we can extract to that central thing. So, you know, that's the next bound. We kind of need to prove it to get there and to ask for money and to hire the right people. But, I mean, that's, you know, if things go well, that's the intention. So, I think one more, yeah, one more? Yes, sir. Could you share a little bit about the motivations why, you know, management was so resistant and probably how we tracked the people and not sure if they were really consistent? Sure. Yeah, so, you know, getting a bit more of an understanding of the question was about, you know, little management and understanding why there were so resistant to that. Really, it was, it was not a resistance to the concept. It was that they had existing projects with huge backlog, they needed to deliver and they had funding that they needed to address. You know, sharing money becomes the kind of the bigger piece, as I'm sure a lot of organizations face as well. Budget, if we're spending it to do something for the wider community or as a trade-off. And so, it really needed to sit down before that went through. I think conceptually they understood but it really was about how do we make it easy. So, we needed to come on our side and that's why we wrote scripts to help at least report on best practices and now the next step on how we actually automated becomes how do we produce fiction for those sorts of things. Documentation was the other part. But really sitting down was the only way that we could really do it and to talk through their concerns to understand it more and they're all really supported. It's just everyone's got to begin things to do and up to them in the balance. That was the solution. Thank you so much. This is...