Gilles Gravier – InnerSource in Government #InnerSourceSummit2025 ![rw-book-cover](https://img.youtube.com/vi/tPBfnu2CQqE/maxresdefault.jpg) But we'll be talking about open source in government and in particular how um I've been working for the last few years with the state administration of Geneva uh to set up an inner source program and if you were listening to what VJong had to say about inner source at Danger saying it's easy it's not always easy so I'll be talking about the parts that are slightly less easy than a than a diner. Um, so this is going to be short. I'm just going to talk about what we were doing uh before looking at politics because we're doing inner source for a state administration, how we built the strategy, how we are implementing it right now and what's stopping us from doing as much as we would want and where we are going to be looking at for for the future. So that's that's our program for today. And so in in in terms of pre-existing context um just uh just to to tell you a little bit of where we are um we've been doing open source because here um at state administration of Geneva inner source starts with open source very often inner source is used as a stepping stone uh in order to go to open source but in our case we started as open source we've been doing open source for a long time using a whole bunch of applications which you see um mentioned here uh on the uh on the slide. I won't go into all the details. Um our education services are also using open source and uh and sometimes we've tried to do open source which wasn't really open source. For example, in 2016 where we published our e voting code but we put all kinds of rules in order to access it and the open source community basically told us no go back to the drawing board. this is not open source if you have to sign NDAs and agreement not to publish stuff if you find vulnerabilities and so on. So it hasn't been such a uh such a an easy pass from uh from the beginning but we are trying and uh and I joined um I joined the team uh in order to get this uh get this more in place. When I arrived, we didn't have any kind of inner source. We had some some internal tools to help people communicate about what they're doing. And um and we had we used Jabber. Yeah, we use Jabber. Uh sorry about that. Um and that's it. And that's it. Nobody not everybody knows that there's a Jabber room for inner source. Not everybody knows that we're doing Inner Source. So So it's, you know, it was time to actually set things in motion. So in order to do that uh we went back to the drawing board in particular because we are a state administration so politics gets in the way or actually politics supports things. So we as I said we started with open source and um and interestingly enough because Geneva is a is a republic people say canton of Geneva but it's a canton and a republic. Uh the official name is Republican Canton of Geneva as you can see on my uh on my screen right here where my finger is pointed. So republic republic means public in Latin means it means the thing of the public. So the thing of public means that if the public gives to the republic the republic should give back. As such, we built an open source strategy that says that we publish as open source things that uh that we develop because it's funded by the public. So that's that's where we started with our open source uh strategy. And why am I talking about open source strategy? Because as you see the political objectives we had in in addition to being a republic was to satisfy the Canton leadership. They wanted to see things. They wanted to see we're doing open source. They want to uh they wanted us to show our excellence, our competence by sharing code, by being uh referred to by other Cantons, by other administrations. They wanted us to drive intercanton collaboration. So create projects across cantons and some of these can be done as inner source other can be done as open source depending on like um gun said whether the code that is being shared and developed makes sense outside of our uh our two or three or four cantons working together or whether it's only for us because it's internal and it's very specific. Um we want to be a more attractive recruiter. In order to do that, we communicate but also we provide an internal environment that is um um attractive to developers and open source contributions as well as inner source development methodologies which look a lot like open source are tend to be an attractive factor for developers. So that's something that that that we tie to inner source. And then we wanted to foster inter team collaboration. we're structured in various uh directions. Um and um and historically these tend to work in silos. Um you know, for example, we have five or six different libraries to enter dates that were developed by each team. Um and uh and and because they're not looking at what the rest of the group is doing. So, so these silos are making uh development extremely redundant and uh and wasting a lot of time, a lot of energy, a lot of money and and so can we abolish these silos. So, as you can see from these political objectives, we need to be better at doing our stuff. Um some of them actually directly map into inner source. And so this is where we decided that when we created our open source strategy, we actually had inner source in our in our design uh elements as well. So uh how did we design it? We basically took the official IT strategy of the state administration and uh and we built from there. And this was not necessarily easy because we did not we still do not have an open source program office. So we don't even have an inner source program office course. Um we're in the process of designing that. I'll talk about it later which will include inner source um as its uh one of its um uh areas of uh influence and expertise. So we decided to align our open source and inner source strategy to the existing access of the existing IT strategy right one strategy to rule them all one inner one open source strategy that includes inner source uh and uh and it's driven inner source as open source from the same team so as I said we don't have an ospo we have a few dedicated people that are today hosted inside a development organization which which is not the best place to store to to have an open source team um or an insource team. It should be much higher in the organization so that they influence um legal innovation, HR and so on. But despite that we worked with this team to create a strategy. We build it on three strategic axis which are part of our IT strategy which is to position the Geneva state as the key regional player for IT technologies to better serve the citizens with creative solutions tailored to their needs and to create a culture of excellence and better risk control and of course breaking down silos by mutualizing resources. Now um when um when we created that uh that strategy, we actually did collaborative workshops, internal collaborative workshops. So very inner sourcy where we shared information, we shared our guidelines, we had um discussions, we uh we did brainstorming sessions, we got people involved that wanted to be involved and uh and once we did that, we got it approved by our management and we published the actual strategy online. You have the URL here. Um, Kent Geneva is a French-speaking Canton, so the strategy is in English. Um, but it's published uh on our GitHub and uh we haven't yet people do any poll requests for for adding stuff to it. We're hoping not many people do, but it is published there. Um, we we try to publish a lot of our open source related activities on our GitHub because it helps with our own visibility. So this is where it gets interesting hopefully um how did we implement that and and as I said unlike um Paul Gunk's case it's not easy it wasn't always easy it's not going to be easy for the future um because we have a lot of um we have a lot of um uh history to to drive. So first of all, we don't have an OSPO. We don't have an ESPO. I'm pretty sure I mentioned it already a few times and I will keep mentioning it. Um, we we did that series of workshop to create the elements of the strategy and prioritize which elements we needed to put in place first because we got so many ideas uh and show little time and resources that we had to to uh to prioritize. We aligned that with the various elements of our general IT strategy and we made sure that this um inner source and open source strategy well covered both open source and source. Now, um we what was hard to do is getting the management on board. And unfortunately, this being a um um a uh government organization, we have to get politic politicians politicians politicians politicians, sorry about that. Uh on board, including our director general. Um so that was a little hard because not everybody wants to talk to him. They people have to follow the hierarchy. You talk to somebody who talks to somebody who talks to somebody. At some point, you just send an email to the guy and they say, "Why did you contact him directly?" Um, but it worked. We got the the director general to actually sign our strategy and uh and and give it their stamp of approval. Unfortunately, at this point, we're still inside the developer organization. So while we had the approval from the from the director general, it still required a lot of communication and education to get people to listen to what we're doing. Um we also created trainings, educational programs where we explain how to um to how to contribute uh how to contribute open source code, publish open source code. Um as Wgong mentioned, uh we also have a GitHub and a GitLab. GitLab is for internal code. GitHub is for our external code. So we developed uh inner source mode on GitLab. And for code that then makes sense to publish as open source. We have tools that synchronize our internal GitHub GitLab repository to our external GitHub repository and uh and educating people on how to do that was really significant. We created licenses. We did workshops on using selecting licenses and so on. We have an actual team that supports our our developers in publishing their code whether it is published uh as open source or internally um as inner source and um and we uh we also uh started engaging using this strategy as a communication tool and using the uh our existing tools like GitHub and and so on uh with our external partners for example now we're asking people who asked to develop code for uh to make that code available as open source or at least open sourceable even if the development part of the code actually takes place in a more of an open inner source mode with code shared with them. Um and we've started to push for the creation of an open source program office. Um and as I speak today um actually no as of yesterday uh I understand that uh that we are going to have the approval for creating an OSPO and of course this being an administration we can't call it a program office because in our organization a program is something very specific. So we're not going to call it the OSPO. We're going to call it something else. Maybe the open source governance organization or whatever. Um but it will have a name and it will exist and that OSPO or whatever it's going to be called um will have uh as its core responsibility to drive internal uh development and inner source. So that's where we are today uh with all of these things in place or done. And um it wasn't as uh as I mentioned it wasn't that easy in particular uh administrations full of hierarchy full of red tape full of people who get in the way full of people who are afraid to go beyond people who get in the way. So if somebody is blocking you from doing something nobody wants to write to their to their N plus one which is tends to be your N plus2 because the person who get in the way is your management. So so sometimes it gets a little slow. I being an external resource, I'm a consultant. I tend to ignore some of these rules and directly contact people and then then people in my team look at me why I say what you talk to who um but it works um in general and uh and that helps a lot. So so having external resources in your organization maybe a way uh when they play candid oh I didn't I was not supposed to talk to him. uh it may be a way to uh to circumvent some of the red tape, some of the blocking uh people uh if if your internal team are too used to not being able to do that. Um and I worked in so many organizations uh where this is the case that uh that it came naturally that uh that that was the best way to go. Now um as I mentioned a little bit earlier our strategy was approved by the director general but it was not really communicated meaning the director general didn't actually do a full communication saying yes we have a new strategy follow it um which means that it's it's hard because when you go talk to somebody in particular because we're as I said inside a development organization and not part of say the CTO organization or better the COO organization which would be ideal um ask me if if you want during the uh the Q&A why I think CO would be better, but um because we're somewhere deep down uh it it actually requires a bit of additional effort to get people to to listen to what you have to say about the way to develop because not all the development is done in our development organizations. We have IT uh teams, we have network teams, we have communications teams, we have database and product teams and all these people do their own development as well and they don't necessarily report or even listen to what the official development organization that develops uh client solutions clients being citizen solutions. So it's a mess and and communication having proper communication from the director general would be a significant plus it's not there. Um, also it was interesting because when we started talking about inner source, uh, a lot of people just came and said, "Oh, yeah, I know. Uh, it's really great. We're going to do inner source and, uh, why not actually take all of the code that is on our GitLab um, and put set a flag on every piece of software that is in our source." And it's like wait if the code is internally uh internal if it's accessible by anybody internally whether it's labeled in your source or not people can look at it read it learn from it clone it use it possibly contribute to it or at least do a merge request on GitLab and it becomes the facto inner source. It doesn't really need to be labeled as inner source. Uh and and and that got me some really uh blank stairs like why don't um and and you know I understand what they want uh is that if you label code as inner source it means it's ready for consumption but it's the same thing as with open source right you're not going to publish your code once it's ready for consumption you're publishing as soon as you can sometimes it's buggy code sometimes there's something that says it's being developed right now don't worry uh don't complain too much if you find a bug fix it. Um, if you wait for the code to be fully ready for consumption, chances are you're never going to publish it. So, so the idea of having something that says this is inner source code um took some time to um to uh dispel and uh and people started saying okay yeah I we understand everything is in source. Um we have some strange rules on our GitLab. For example, um all of the code is open. Anybody can contribute actually. Uh more importantly, anybody can modify the code. We didn't configure the code so that people have to actually do merge request. You can just edit a file which the the the rational being that we're all one team and everybody should be able to edit the code. As a result, it's a mess. um it's not at all using the the the typical methodologies that we have in in open source where you have contributors where you have um um people who do uh um uh approvals of contributions and mergings and things like that. So so it's a bit of a mess. We have these strange rules um and uh but on the other hand we do have some really really cool tools. So inside our GitLab, we have all of our uh CI/CD tools and and code quality testing and so on. Um so that's that's really nice to have GitLab for that. But um we also um have uh very very nice tools that let us publish direct your code uh to GitHub using synchronization. And that's cool because that those synchronization tools let us actually uh accept um pull requests um and issues on the external GitHub and then we can fix them internally uh on the GitLab and then that gets put back externally. Of course, it would be much better if anything that has to be that needs to be open source uh was developed directly on GitHub, but you know it takes time to change the uh the mindset. So for now people develop internally on GitLab whether it's inner source or open source and by default anything that's developed on GitLab is considered inner source. Um but um but hopefully we'll will will change at some point. Normally we have a an open-source first uh strategy which includes not only looking for new solutions should first look at open source options and if we don't find open source options then we look for non-opensource but it's also uh it also applies to develop development. If we're going to develop software or make software developed then it should be made open source if uh by default unless security IP whatever reasons prevent it and that's interesting because that was part of our strategy developed three four years ago and it actually appeared in the Swiss federal law two years ago. Uh there is a law that's called the Elmeta uh in French and the um it has a different name in German but I never remember it. Um and that law that that federal law actually states that any state organization, federal organization that develop code or has code develop must make it open source unless and so um we we apply that we were there before the federal law and uh and we're doing this as open source and then moving on progressively uh also as inner source for stuff that doesn't need to be made uh that doesn't need to be made public uh or should not. For example, you know, if we're developing tax software, uh some rules for defining default taxation are not public. Uh some rules for fraud detection wouldn't be public and so on. Uh another roadblock is we have a new director general and so it was hard to get the original director general to prove it and they still didn't communicate about it. The new director general was very hesitant about open source. They were not like opposed to open source, but uh they're they're they're really like looking at it as a kind of a necessary evil if you want. Yeah, these guys are doing it. It really needs to be done, but they're not happy about the fact that that it it's something that was decided by their predecessor, which is always the case, right? When you have somebody new in a decisional role, they tend to look at what was done before as well, not my stuff, so not necessarily good. Fortunately, fortunately, um we actually had some really bad press recently that said, "Oh, wait. Geneva is all Microsoft and there are state administration. They shouldn't be doing uh Microsoft." And so, so now the new director general is finally understanding the value of open source in particular as a communication tool. So, so this is where we are going to actually have uh the funding for creating an open source program office through participating in in funding open source projects and and and being a a lot more visible around our open source activities which means also uh having this OSO means we're going to have a stronger tool for driving inner source. So it's interesting uh here a little bit of a a sidetrack here but bad press is still good press in the sense that sometimes you get things to move and in particular our director general which I'm happy they they decided to move. So I have um one more slide where is where we're going now. So the new director general now that they understand uh the interest of open source uh we're going to have him actually support the open source strategy, promote the open source strategy and uh and communicate about it so that once we have formalized the creation of an open source inner source program office or government governing office or whatever um it will have a lot of strength We still don't know where it's going to be um hosted. Uh hopefully not inside the development organization, but that's going to be a political issue. Um we have support from our the magistrate that is above our director general, so inside the Swiss the Geneva government. So that's really good. Next step after creating the OSPO is creating a governance model uh and implementing it uh better than what we do today, which is very ad hoc. Uh and since you're still trying to put in place the program office uh div defining a governance model is a little tricky because we don't have official stakeholders. We only have uh informal ones. Some of them change and decide not to be law anymore whatever. Um we're going to push for leveraging inner source more um in particular using tools like internal communications where um uh we we have an internal mailing list that talks about our open source and inner source activities and every time somebody publishes something new as inner source or open source but as inner source we have them write an article and uh and talk about what they're doing because uh by doing that we are hoping that um that uh people will see that and it will motivate them to actually do the same thing. Publish code, make it properly documented, have open APIs, generic implementation so that other teams can use the code um and and then in that in turn they could be visible uh as a success story. We're we are also looking at we have screens on the walls that display dynamic content uh so gamifying by having posts about who's the biggest contributor to our inner source repositories and channel or things like that. And and I forgot to mention it and it is really important. Um we um we are implementing a developer portal uh so that people can actually go and search for existing code rather than ask on our Jabber uh inner source channel. Does anybody know of a library that does this or that? Um because this is not really efficient uh way of looking for code. Actually you could ask that to an AI that uh that runs on the portal and scans all of the repositories and you probably get a better answer. they're asking on a on a Jabber channel. So that's that's where we're going now. So you see we have quite a few things to do. We're despite the fact that we've been doing this for three years, we're still very very much in the infancy of the unders source program because administrations go really slowly. And I will uh finish this slide and talking about in administrations going slowly by quoting Albert Einstein who um when he retired was asked by a journalist, so where do you want to go? uh spend the end of your life uh uh once you retire and and they said uh I want to go to Geneva because everything takes 10 to 20 more years to happen over there and this is where we are in Geneva. They're not going to take 10 to 20 years but it's going to take some time., Gilles Gravier – InnerSource in Government #InnerSourceSummit2025, YouTube, 01kche1rd789zfcaeh3xzqjtv9.