Gilles Gravier – InnerSource in Government #InnerSourceSummit2025

Gilles Gravier – InnerSource in Government #InnerSourceSummit2025 🔗 **Source:** [Gilles Gravier – InnerSource in Government #InnerSourceSummit2025](https://www.youtube.com/watch?v=tPBfnu2CQqE) > [!note]+ Document Notes > tags: [innersource, government, open-source] > author: Gilles Gravier > source: InnerSource Summit 2025 > reference: https://www.youtube.com/watch?v=tPBfnu2CQqE > date created: 2024-12-19 10:30 > > # 🏷️ Title: InnerSource in Government: Geneva's Journey from Open Source to Inner Source >  ## 🧰 Action Inbox - [H1] Create governance model for inner source implementation — post-OSPO establishment #governance - [H2] Develop developer portal for code discovery — replace Jabber-based search #tooling - [H3] Implement proper GitLab permissions and merge request workflows — fix current mess #process ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Geneva State Open Source Strategy](https://github.com/etat-de-geneve) - [InnerSource Commons](https://innersourcecommons.org) ## 📝 Summary - Geneva state administration implements inner source program starting from existing open source practices - Political support crucial but insufficient without proper organizational placement and communication - Government bureaucracy creates unique challenges requiring external consultants to circumvent red tape - Success depends on aligning inner source strategy with existing IT strategy and political objectives - Key lesson: Don't wait for code to be "ready" - publish early and iterate like open source ## 📖 Main Content The Geneva state administration's inner source journey demonstrates that government organizations face unique challenges when implementing collaborative development practices. Unlike typical corporate inner source initiatives that serve as stepping stones to open source, Geneva started with established open source practices and worked backward to create inner source programs for internal collaboration. The initiative required navigating complex political structures, from securing director general approval to managing changing leadership priorities. The lack of a formal Open Source Program Office (OSPO) created organizational challenges, with the team embedded within a development organization rather than positioned at the strategic level needed for cross-departmental influence. Technical implementation involved using GitLab for internal development with synchronization tools to GitHub for public releases. However, permissive internal access controls created chaos rather than collaboration, highlighting the need for proper governance models even in trusted environments. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/tPBfnu2CQqE?t=0) — [H1] Introduction and Context - Key idea: Geneva started with open source first, then moved to inner source (reverse of typical pattern) - Evidence: "Inner source starts with open source very often inner source is used as a stepping stone in order to go to open source but in our case we started as open source" #### ⏱️ [02:15](https://youtu.be/tPBfnu2CQqE?t=135) — [H2] Failed Open Source Attempt (2016) - Key idea: Publishing code with restrictions isn't open source - Evidence: "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" #### ⏱️ [03:45](https://youtu.be/tPBfnu2CQqE?t=225) — [H2] Pre-Inner Source State - Key idea: Minimal collaboration infrastructure existed before formal program - Evidence: "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" #### ⏱️ [04:30](https://youtu.be/tPBfnu2CQqE?t=270) — [H1] Political Foundation Strategy - Key idea: Republican government structure supports open source philosophy - Evidence: "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" #### ⏱️ [06:00](https://youtu.be/tPBfnu2CQqE?t=360) — [H2] Political Objectives Driving Inner Source - Key idea: Leadership wanted visibility, collaboration, and talent attraction - Evidence: "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" #### ⏱️ [07:45](https://youtu.be/tPBfnu2CQqE?t=465) — [H2] Silo Problem - Key idea: Redundant development across teams wastes resources - Evidence: "We have five or six different libraries to enter dates that were developed by each team" #### ⏱️ [09:30](https://youtu.be/tPBfnu2CQqE?t=570) — [H2] Strategy Alignment Approach - Key idea: Built inner source strategy on existing IT strategy foundation - Evidence: "We basically took the official IT strategy of the state administration and uh and we built from there" #### ⏱️ [11:15](https://youtu.be/tPBfnu2CQqE?t=675) — [H2] Collaborative Workshop Process - Key idea: Used inner source principles to develop inner source strategy - Evidence: "We actually did collaborative workshops, internal collaborative workshops. So very inner sourcy where we shared information" #### ⏱️ [13:00](https://youtu.be/tPBfnu2CQqE?t=780) — [H1] Implementation Challenges - Key idea: Government hierarchy makes direct communication difficult - Evidence: "Unfortunately, this being a um um a uh government organization, we have to get politic politicians politicians politicians politicians, sorry about that" #### ⏱️ [15:30](https://youtu.be/tPBfnu2CQqE?t=930) — [H2] External Consultant Advantage - Key idea: Outside consultants can bypass bureaucratic rules - Evidence: "I being an external resource, I'm a consultant. I tend to ignore some of these rules and directly contact people" #### ⏱️ [17:45](https://youtu.be/tPBfnu2CQqE?t=1065) — [H2] Communication Gap Problem - Key idea: Strategy approval without communication limits effectiveness - Evidence: "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" #### ⏱️ [19:30](https://youtu.be/tPBfnu2CQqE?t=1170) — [H2] Inner Source Labeling Misconception - Key idea: Don't wait for perfect code before sharing internally - Evidence: "If you wait for the code to be fully ready for consumption, chances are you're never going to publish it" #### ⏱️ [21:15](https://youtu.be/tPBfnu2CQqE?t=1275) — [H3] GitLab Permission Problems - Key idea: Too-permissive access creates chaos instead of collaboration - Evidence: "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" #### ⏱️ [23:00](https://youtu.be/tPBfnu2CQqE?t=1380) — [H2] Open Source First Strategy - Key idea: Default to open source development unless security prevents it - Evidence: "We have an open-source first uh strategy which includes not only looking for new solutions should first look at open source options" #### ⏱️ [25:30](https://youtu.be/tPBfnu2CQqE?t=1530) — [H2] Bad Press as Catalyst - Key idea: Negative media coverage motivated leadership support - Evidence: "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" ## 📚 References - [Geneva State GitHub](https://github.com/etat-de-geneve) - [Swiss Federal Open Source Law (Elmeta)](https://www.admin.ch/gov/en/start/documentation/media-releases.year.html) - [InnerSource Commons](https://innersourcecommons.org) ## 🗣️ Paraphrase - Government inner source requires different approaches than corporate programs, often starting from existing open source practices rather than building toward them - Political alignment and high-level communication are essential but insufficient without proper organizational structure and governance - Technical implementation should follow proven open source practices rather than assuming internal trust eliminates need for proper workflows ## 📰 Newsletter Geneva's inner source journey offers valuable lessons for any organization implementing collaborative development practices. Their experience shows that starting with open source principles provides a strong foundation, but success requires both political support and proper technical governance. Key takeaway: Don't let perfect be the enemy of good when sharing code internally. Like open source projects, inner source succeeds through early sharing and iterative improvement. The upcoming Open Source Program Office (OSPO) creation demonstrates how external pressure and strategic communication can overcome bureaucratic inertia. Resources: [InnerSource Commons](https://innersourcecommons.org/), [Geneva's Strategy](https://github.com/etat-de-geneve), [OSPO Guide](https://todogroup.org/guides/) ## ✅ Action Items #### OSPO - Governance model design: Create formal stakeholder structure and decision-making processes - Organizational placement: Position OSPO at strategic level (CTO/COO) not buried in development teams - Communication strategy: Ensure leadership actively promotes and communicates open source/inner source strategies - Policy development: Establish clear guidelines for open source vs inner source classification #### Community - Developer portal implementation: Replace ad-hoc Jabber searches with searchable code repository - Success story program: Internal newsletter highlighting inner source contributions and impact - Gamification elements: Wall displays showing contribution metrics and recognition - Training programs: Educational workshops on contribution workflows and license selection #### Developer Experience - GitLab governance: Implement proper merge request workflows and permission controls - Synchronization tooling: Maintain GitHub/GitLab sync for open source publication - API standardization: Promote generic implementations for cross-team reuse - Documentation standards: Establish requirements for inner source code readiness ## 🧪 Hypotheses - External consultants can accelerate inner source adoption by bypassing internal bureaucratic constraints - Government organizations benefit from open source first strategies that include inner source for sensitive code - Bad press about vendor lock-in can motivate leadership support for open source initiatives - Starting with open source practices provides better foundation than typical inner source stepping-stone approach ### 📊 Methodology - Comparative analysis between corporate and government inner source implementations - Survey of developer satisfaction before/after proper governance implementation - Measurement of code reuse rates across teams after developer portal deployment - Assessment of political support sustainability across leadership changes ### ❓ Questions - How can government organizations maintain inner source momentum across political leadership changes? - What organizational level provides optimal positioning for OSPO effectiveness in government? - How do synchronization tools between internal and external repositories affect developer workflows? ### 🔮 Future Research - Best practices for government open source program office establishment and governance - Impact of federal open source mandates on cantonal/state implementation strategies - Developer portal effectiveness in reducing code duplication across government teams ### 💡 Implications - Practice: Government inner source requires political strategy alongside technical implementation - Policy: Federal open source mandates can accelerate local government adoption - Security: Sensitive government code can use inner source practices while maintaining confidentiality - Education: External consultants provide valuable perspective for overcoming bureaucratic obstacles ### 🧠 Learning Styles Assessment Reading level estimate: Grade 12 #### 👀 Visual learners - Present: Organizational charts implied, strategy diagrams referenced - Improve: Process flow diagrams, before/after organizational structures, timeline visualizations #### 🔊 Aural learners - Present: Conference presentation format with spoken delivery - Improve: Podcast-style discussion with Q&A segments #### 🗣️ Verbal learners - Present: Clear explanations, government terminology defined, analogies used - Improve: Glossary of terms, comparison tables between approaches #### 🧩 Kinesthetic learners - Present: Workshop processes described, hands-on strategy development - Improve: Step-by-step implementation checklist, interactive governance model builder #### 🧠 Logical learners - Present: Strategic alignment framework, cause-effect relationships clear - Improve: Decision trees for open source vs inner source, success metrics dashboard #### 🧑‍🤝‍🧑 Social learners - Present: Collaborative workshops, team coordination challenges - Improve: Peer review processes, cross-team collaboration guides #### 🧘‍♀️ Solitary learners - Present: Individual consultant experience, self-directed problem solving - Improve: Self-assessment tools, independent learning modules #### 🌿 Naturalistic learners - Present: Ecosystem thinking about government structures - Improve: Organizational ecosystem maps, sustainability frameworks ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive content - Improve: Alt text for any diagrams, ARIA labels for complex structures #### Keyboard navigation - Present: Standard video controls available - Improve: Chapter markers, transcript navigation #### Contrast and readability - Present: High contrast video presentation - Improve: Transcript formatting with proper contrast ratios #### Text resizing and reflow - Present: Video scales appropriately - Improve: Responsive transcript layout #### Media and captions - Present: Audio content available - Improve: Closed captions, downloadable transcript #### Forms and interactions - Present: Basic video interface - Improve: Interactive timeline, searchable transcript ### 🌍 DEIB Assessment #### Cultural breadth - Present: Swiss government context, multilingual environment mentioned - Improve: Cross-cultural government collaboration examples #### Inclusive language - Present: Professional government terminology - Improve: Plain language definitions, avoid bureaucratic jargon #### Neurodiversity support - Present: Structured presentation format - Improve: Clear section breaks, summary bullets #### Representation - Present: Single presenter perspective - Improve: Multiple voices from different government roles #### Psychological safety - Present: Honest about failures and challenges - Improve: Encouraging tone for similar initiatives ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Political objectives logically lead to inner source benefits - Inductive strength: Geneva's experience provides patterns for other governments - Causal reasoning: Clear cause-effect between organizational placement and influence - Analogical strength: Open source principles apply well to inner source implementation #### Fallacies - Appeal to authority: Director general approval as validation - valid given government context - Anecdotal evidence: Single organization experience - acknowledged limitation but valuable case study #### Tone of voice - Overall tone: Pragmatic and honest about challenges, includes humor about bureaucracy, realistic about timelines ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attacks on accusers - Reverse victim/offender: No victim/offender reversal - Emotional cues: Frustration with bureaucracy expressed constructively, humor used appropriately ## 🎯 Conclusion Geneva's inner source journey demonstrates that government organizations can successfully implement collaborative development practices, but require different strategies than corporate environments. The key insight is that political alignment, proper organizational positioning, and technical governance must work together - missing any element significantly reduces effectiveness. The upcoming OSPO creation, motivated partly by external pressure, shows how persistence and strategic communication can overcome bureaucratic obstacles. Other government organizations can learn from Geneva's experience by ensuring high-level political support, proper organizational placement, and realistic timelines for cultural change. Future success will depend on implementing proper governance models and developer tools while maintaining the political support necessary for sustained investment in collaborative development practices. --- ## Full Transcript [00:05] But we'll be talking about open source [00:07] in government and in particular how um [00:10] I've been working for the last few years [00:12] with the state administration of Geneva [00:15] uh to set up an inner source program and [00:17] if you were listening to what VJong had [00:20] to say about inner source at Danger [00:22] saying it's easy it's not always easy so [00:26] I'll be talking about the parts that are [00:28] slightly less easy than a than a diner. [00:31] Um, so this is going to be short. I'm [00:34] just going to talk about what we were [00:36] doing uh before looking at politics [00:38] because we're doing inner source for a [00:40] state administration, how we built the [00:42] strategy, how we are implementing it [00:44] right now and what's stopping us from [00:46] doing as much as we would want and where [00:48] we are going to be looking at for for [00:51] the future. So that's that's our program [00:53] for today. And so in in in terms of [00:56] pre-existing context um just uh just to [00:59] to tell you a little bit of where we are [01:02] um we've been doing open source because [01:04] here um at state administration of [01:06] Geneva inner source starts with open [01:08] source very often inner source is used [01:11] as a stepping stone uh in order to go to [01:14] open source but in our case we started [01:16] as open source we've been doing open [01:18] source for a long time using a whole [01:19] bunch of applications which you see um [01:23] mentioned here uh on the uh on the [01:26] slide. I won't go into all the details. [01:28] Um our education services are also using [01:31] open source and uh and sometimes we've [01:34] tried to do open source which wasn't [01:36] really open source. For example, in 2016 [01:38] where we published our e voting code but [01:41] we put all kinds of rules in order to [01:43] access it and the open source community [01:44] basically told us no go back to the [01:46] drawing board. this is not open source [01:48] if you have to sign NDAs and agreement [01:50] not to publish stuff if you find [01:52] vulnerabilities and so on. So it hasn't [01:54] been such a uh such a an easy pass from [01:59] uh from the beginning but we are trying [02:02] and uh and I joined um I joined the team [02:06] uh in order to get this uh get this more [02:09] in place. When I arrived, we didn't have [02:12] any kind of inner source. We had some [02:14] some internal tools to help people [02:17] communicate about what they're doing. [02:19] And um and we had we used Jabber. Yeah, [02:23] we use Jabber. Uh sorry about that. Um [02:25] and that's it. And that's it. Nobody not [02:28] everybody knows that there's a Jabber [02:30] room for inner source. Not everybody [02:31] knows that we're doing Inner Source. So [02:34] So it's, you know, it was time to [02:36] actually set things in motion. So in [02:39] order to do that uh we went back to the [02:41] drawing board in particular because we [02:44] are a state administration so politics [02:48] gets in the way or actually politics [02:50] supports things. So we as I said we [02:52] started with open source and um and [02:55] interestingly enough because Geneva is a [02:58] is a republic people say canton of [03:00] Geneva but it's a canton and a republic. [03:03] Uh the official name is Republican [03:05] Canton of Geneva as you can see on my uh [03:08] on my screen right here where my finger [03:11] is pointed. So republic republic means [03:15] public in Latin means it means the thing [03:17] of the public. So the thing of public [03:20] means that if the public gives to the [03:22] republic the republic should give back. [03:24] As such, we built an open source [03:26] strategy that says that we publish as [03:28] open source things that uh that we [03:31] develop because it's funded by the [03:33] public. So that's that's where we [03:35] started with our open source uh [03:37] strategy. And why am I talking about [03:38] open source strategy? Because as you see [03:41] the political objectives we had in in [03:43] addition to being a republic was to [03:46] satisfy the Canton leadership. They [03:48] wanted to see things. They wanted to see [03:49] we're doing open source. They want to uh [03:52] they wanted us to show our excellence, [03:54] our competence by sharing code, by being [03:57] uh referred to by other Cantons, by [03:59] other administrations. They wanted us to [04:02] drive intercanton collaboration. So [04:05] create projects across cantons and some [04:08] of these can be done as inner source [04:10] other can be done as open source [04:11] depending on like um gun said whether [04:15] the code that is being shared and [04:17] developed makes sense outside of our uh [04:20] our two or three or four cantons working [04:22] together or whether it's only for us [04:25] because it's internal and it's very [04:27] specific. Um we want to be a more [04:29] attractive recruiter. In order to do [04:31] that, we communicate but also we provide [04:33] an internal environment that is um um [04:38] attractive to developers and open source [04:41] contributions as well as inner source [04:42] development methodologies which look a [04:44] lot like open source are tend to be an [04:47] attractive factor for developers. So [04:48] that's something that that that we tie [04:50] to inner source. And then we wanted to [04:53] foster inter team collaboration. we're [04:56] structured in various uh directions. Um [04:59] and um and historically these tend to [05:04] work in silos. Um you know, for example, [05:08] we have five or six different libraries [05:10] to enter dates that were developed by [05:13] each team. Um and uh and and because [05:16] they're not looking at what the rest of [05:17] the group is doing. So, so these silos [05:19] are making uh development extremely [05:22] redundant and uh and wasting a lot of [05:25] time, a lot of energy, a lot of money [05:28] and and so can we abolish these silos. [05:31] So, as you can see from these political [05:33] objectives, we need to be better at [05:35] doing our stuff. Um some of them [05:37] actually directly map into inner source. [05:40] And so this is where we decided that [05:42] when we created our open source [05:44] strategy, we actually had inner source [05:47] in our in our design uh elements as [05:50] well. So uh how did we design it? We [05:53] basically took the official IT strategy [05:56] of the state administration and uh and [05:59] we built from there. [06:02] And this was not necessarily easy [06:04] because we did not we still do not have [06:08] an open source program office. So we [06:11] don't even have an inner source program [06:12] office course. Um we're in the process [06:15] of designing that. I'll talk about it [06:17] later which will include inner source um [06:20] as its uh one of its um uh areas of uh [06:25] influence and expertise. So we decided [06:27] to align our open source and inner [06:29] source strategy to the existing access [06:32] of the existing IT strategy right one [06:36] strategy to rule them all one inner one [06:39] open source strategy that includes inner [06:41] source uh and uh and it's driven inner [06:45] source as open source from the same team [06:47] so as I said we don't have an ospo we [06:49] have a few dedicated people that are [06:52] today hosted inside a development [06:54] organization which which is not the best [06:56] place to store to to have an open source [06:58] team um or an insource team. It should [07:01] be much higher in the organization so [07:03] that they influence um legal innovation, [07:06] HR and so on. But despite that we worked [07:10] with this team to create a strategy. We [07:12] build it on three strategic axis which [07:15] are part of our IT strategy which is to [07:18] position the Geneva state as the key [07:20] regional player for IT technologies to [07:22] better serve the citizens with creative [07:24] solutions tailored to their needs and to [07:26] create a culture of excellence and [07:28] better risk control and of course [07:30] breaking down silos by mutualizing [07:32] resources. Now um when um when we [07:36] created that uh that strategy, we [07:37] actually did collaborative workshops, [07:39] internal collaborative workshops. So [07:41] very inner sourcy where we shared [07:43] information, we shared our guidelines, [07:45] we had um discussions, we uh we did [07:47] brainstorming sessions, we got people [07:49] involved that wanted to be involved and [07:52] uh and once we did that, we got it [07:54] approved by our management and we [07:55] published the actual strategy online. [07:58] You have the URL here. Um, Kent Geneva [08:02] is a French-speaking Canton, so the [08:03] strategy is in English. Um, but it's [08:06] published uh on our GitHub and uh we [08:09] haven't yet people do any poll requests [08:11] for for adding stuff to it. We're hoping [08:14] not many people do, but it is published [08:17] there. Um, we we try to publish a lot of [08:19] our open source related activities [08:23] on our GitHub because it helps with our [08:25] own visibility. [08:28] So [08:29] this is where it gets interesting [08:31] hopefully um how did we implement that [08:35] and and as I said unlike um Paul Gunk's [08:38] case it's not easy it wasn't always easy [08:41] it's not going to be easy for the future [08:43] um because we have a lot of um we have a [08:46] lot of um uh history to to drive. So [08:50] first of all, we don't have an OSPO. We [08:52] don't have an ESPO. I'm pretty sure I [08:54] mentioned it already a few times and I [08:55] will keep mentioning it. Um, we we did [08:59] that series of workshop to create the [09:02] elements of the strategy and prioritize [09:04] which elements we needed to put in place [09:06] first because we got so many ideas uh [09:08] and show little time and resources that [09:10] we had to to uh to prioritize. We [09:13] aligned that with the various elements [09:15] of our general IT strategy and we made [09:17] sure that this um inner source and open [09:21] source strategy well covered both open [09:23] source and source. Now, um [09:28] we what was hard to do is getting the [09:30] management on board. And unfortunately, [09:33] this being a um um a uh government [09:38] organization, we have to get politic [09:40] politicians politicians politicians [09:44] politicians, sorry about that. Uh on [09:46] board, including our director general. [09:48] Um so that was a little hard because not [09:51] everybody wants to talk to him. They [09:54] people have to follow the hierarchy. You [09:55] talk to somebody who talks to somebody [09:57] who talks to somebody. At some point, [09:58] you just send an email to the guy and [09:59] they say, "Why did you contact him [10:01] directly?" Um, but it worked. We got the [10:04] the director general to actually sign [10:06] our strategy and uh and and give it [10:10] their stamp of approval. Unfortunately, [10:13] at this point, we're still inside the [10:15] developer organization. So while we had [10:17] the approval from the from the director [10:19] general, it still required a lot of [10:20] communication and education to get [10:23] people to listen to what we're doing. Um [10:26] we also created trainings, educational [10:28] programs where we explain how to um to [10:32] how to contribute uh how to contribute [10:35] open source code, publish open source [10:37] code. Um as Wgong mentioned, uh we also [10:40] have a GitHub and a GitLab. GitLab is [10:42] for internal code. GitHub is for our [10:45] external code. So we developed uh inner [10:48] source mode on GitLab. And for code that [10:51] then makes sense to publish as open [10:53] source. We have tools that synchronize [10:55] our internal GitHub GitLab repository to [10:58] our external GitHub repository and uh [11:01] and educating people on how to do that [11:04] was really significant. We created [11:07] licenses. We did workshops on using [11:09] selecting licenses and so on. We have an [11:12] actual team that supports our our [11:15] developers in publishing their code [11:17] whether it is published uh as open [11:19] source or internally um as inner source [11:23] and um and we uh we also uh started [11:27] engaging using this strategy as a [11:30] communication tool and using the uh our [11:32] existing tools like GitHub and and so on [11:35] uh with our external partners for [11:37] example now we're asking people who [11:39] asked to develop code for [11:41] uh to make that code available as open [11:43] source or at least open sourceable even [11:46] if the development part of the code [11:47] actually takes place in a more of an [11:49] open inner source mode with code shared [11:51] with them. Um and we've started to push [11:55] for the creation of an open source [11:56] program office. Um and as I speak today [12:00] um actually no as of yesterday uh I [12:03] understand that uh that we are going to [12:05] have the approval for creating an OSPO [12:08] and of course this being an [12:09] administration we can't call it a [12:11] program office because in our [12:13] organization a program is something very [12:15] specific. So we're not going to call it [12:17] the OSPO. We're going to call it [12:18] something else. Maybe the open source [12:20] governance organization or whatever. Um [12:23] but it will have a name and it will [12:25] exist and that OSPO or whatever it's [12:28] going to be called um will have uh as [12:30] its core responsibility to drive [12:32] internal uh development and inner [12:34] source. So that's where we are today uh [12:38] with all of these things in place or [12:40] done. And um it wasn't as uh as I [12:44] mentioned it wasn't that easy in [12:46] particular uh administrations full of [12:50] hierarchy full of red tape full of [12:52] people who get in the way full of people [12:54] who are afraid to go beyond people who [12:57] get in the way. So if somebody is [12:58] blocking you from doing something nobody [13:00] wants to write to their to their N plus [13:03] one which is tends to be your N plus2 [13:05] because the person who get in the way is [13:07] your management. So so sometimes it gets [13:09] a little slow. I being an external [13:11] resource, I'm a consultant. I tend to [13:14] ignore some of these rules and directly [13:16] contact people and then then people in [13:18] my team look at me why I say what you [13:21] talk to who um but it works um in [13:24] general and uh and that helps a lot. So [13:27] so having external resources in your [13:29] organization maybe a way uh when they [13:33] play candid oh I didn't I was not [13:34] supposed to talk to him. uh it may be a [13:37] way to uh to circumvent some of the red [13:39] tape, some of the blocking uh people uh [13:42] if if your internal team are too used to [13:44] not being able to do that. Um and I [13:46] worked in so many organizations uh where [13:49] this is the case that uh that it came [13:52] naturally that uh that that was the best [13:54] way to go. [13:56] Now um as I mentioned a little bit [13:58] earlier our strategy was approved by the [14:00] director general but it was not really [14:03] communicated meaning the director [14:05] general didn't actually do a full [14:06] communication saying yes we have a new [14:08] strategy follow it um which means that [14:12] it's it's hard because when you go talk [14:14] to somebody in particular because we're [14:15] as I said inside a development [14:17] organization and not part of say the CTO [14:20] organization or better the COO [14:22] organization which would be ideal um ask [14:25] me if if you want during the uh the Q&A [14:27] why I think CO would be better, but um [14:31] because we're somewhere deep down uh it [14:34] it actually requires a bit of additional [14:36] effort to get people to to listen to [14:38] what you have to say about the way to [14:40] develop because not all the development [14:42] is done in our development [14:43] organizations. We have IT uh teams, we [14:47] have network teams, we have [14:48] communications teams, we have database [14:50] and product teams and all these people [14:52] do their own development as well and [14:54] they don't necessarily report or even [14:57] listen to what the official development [14:58] organization that develops uh client [15:01] solutions clients being citizen [15:02] solutions. So it's a mess and and [15:05] communication having proper [15:06] communication from the director general [15:08] would be a significant plus it's not [15:11] there. Um, also it was interesting [15:15] because when we started talking about [15:17] inner source, uh, a lot of people just [15:19] came and said, "Oh, yeah, I know. Uh, [15:22] it's really great. We're going to do [15:23] inner source and, uh, why not actually [15:26] take all of the code that is on our [15:29] GitLab um, and put set a flag on every [15:35] piece of software that is in our [15:36] source." [15:39] And it's like wait if the code is [15:42] internally [15:43] uh internal if it's accessible by [15:45] anybody internally whether it's labeled [15:48] in your source or not people can look at [15:50] it read it learn from it clone it use it [15:56] possibly contribute to it or at least do [15:59] a merge request on GitLab and it becomes [16:01] the facto inner source. It doesn't [16:03] really need to be labeled as inner [16:04] source. Uh and and and that got me some [16:07] really uh blank stairs like why don't um [16:10] and and you know I understand what they [16:13] want uh is that if you label code as [16:15] inner source it means it's ready for [16:18] consumption but it's the same thing as [16:20] with open source right you're not going [16:22] to publish your code once it's ready for [16:24] consumption you're publishing as soon as [16:26] you can sometimes it's buggy code [16:29] sometimes there's something that says [16:30] it's being developed right now don't [16:32] worry uh don't complain too much if you [16:34] find a bug fix it. Um, if you wait for [16:37] the code to be fully ready for [16:38] consumption, chances are you're never [16:40] going to publish it. So, so the idea of [16:44] having something that says this is inner [16:46] source code um took some time to um to [16:51] uh dispel and uh and people started [16:54] saying okay yeah I we understand [16:56] everything is in source. Um we have some [16:59] strange rules on our GitLab. For [17:01] example, um all of the code is open. [17:04] Anybody can contribute actually. Uh more [17:08] importantly, anybody can modify the [17:09] code. We didn't configure the code so [17:11] that people have to actually do merge [17:13] request. You can just edit a file which [17:16] the the the rational being that we're [17:18] all one team and everybody should be [17:20] able to edit the code. As a result, it's [17:23] a mess. um it's not at all using the the [17:25] the typical methodologies that we have [17:27] in in open source where you have [17:29] contributors where you have um um people [17:33] who do uh um uh approvals of [17:37] contributions and mergings and things [17:39] like that. So so it's a bit of a mess. [17:41] We have these strange rules um and uh [17:43] but on the other hand we do have some [17:45] really really cool tools. So inside our [17:47] GitLab, we have all of our uh CI/CD [17:50] tools and and code quality testing and [17:53] so on. Um so that's that's really nice [17:55] to have GitLab for that. But um we also [17:59] um have uh very very nice tools that let [18:02] us publish direct your code uh to GitHub [18:06] using synchronization. And that's cool [18:08] because that those synchronization tools [18:10] let us actually uh accept um pull [18:14] requests um and issues on the external [18:17] GitHub and then we can fix them [18:19] internally uh on the GitLab and then [18:21] that gets put back externally. Of [18:23] course, it would be much better if [18:26] anything that has to be that needs to be [18:28] open source uh was developed directly on [18:31] GitHub, but you know it takes time to [18:33] change the uh the mindset. So for now [18:36] people develop internally on GitLab [18:38] whether it's inner source or open source [18:40] and by default anything that's developed [18:42] on GitLab is considered inner source. Um [18:46] but um but hopefully we'll will will [18:49] change at some point. [18:51] Normally we have a an open-source first [18:56] uh strategy which includes not only [18:58] looking for new solutions should first [19:00] look at open source options and if we [19:02] don't find open source options then we [19:05] look for non-opensource but it's also uh [19:08] it also applies to develop development. [19:11] If we're going to develop software or [19:13] make software developed then it should [19:16] be made open source if uh by default [19:19] unless security IP whatever reasons [19:22] prevent it and that's interesting [19:24] because that was part of our strategy [19:27] developed three four years ago and it [19:30] actually appeared in the Swiss federal [19:32] law two years ago. Uh there is a law [19:35] that's called the Elmeta uh in French [19:38] and the um [19:42] it has a different name in German but I [19:43] never remember it. Um and that law that [19:46] that federal law actually states that [19:48] any state organization, federal [19:50] organization that develop code or has [19:52] code develop must make it open source [19:54] unless and so um we we apply that we [19:58] were there before the federal law and uh [20:00] and we're doing this as open source and [20:03] then moving on progressively uh also as [20:06] inner source for stuff that doesn't need [20:08] to be made uh that doesn't need to be [20:10] made public uh or should not. For [20:13] example, you know, if we're developing [20:14] tax software, uh some rules for defining [20:17] default taxation are not public. Uh some [20:20] rules for fraud detection wouldn't be [20:22] public and so on. Uh another roadblock [20:25] is we have a new director general and so [20:28] it was hard to get the original director [20:29] general to prove it and they still [20:31] didn't communicate about it. The new [20:33] director general was very hesitant about [20:35] open source. They were not like opposed [20:37] to open source, but uh they're they're [20:39] they're really like looking at it as a [20:42] kind of a necessary evil if you want. [20:44] Yeah, these guys are doing it. It really [20:46] needs to be done, but they're not happy [20:48] about the fact that that it it's [20:50] something that was decided by their [20:53] predecessor, which is always the case, [20:56] right? When you have somebody new in a [20:57] decisional role, they tend to look at [20:58] what was done before as well, not my [21:02] stuff, so not necessarily good. [21:05] Fortunately, [21:07] fortunately, um we actually had some [21:09] really bad press recently that said, [21:11] "Oh, wait. Geneva is all Microsoft and [21:13] there are state administration. They [21:15] shouldn't be doing uh Microsoft." And [21:17] so, so now the new director general is [21:19] finally understanding the value of open [21:21] source in particular as a communication [21:22] tool. So, so this is where we are going [21:25] to actually have uh the funding for [21:28] creating an open source program office [21:30] through participating in in funding open [21:31] source projects and and and being a a [21:34] lot more visible around our open source [21:37] activities which means also uh having [21:41] this OSO means we're going to have a [21:43] stronger tool for driving inner source. [21:44] So it's interesting uh here a little bit [21:47] of a a sidetrack here but bad press is [21:51] still good press in the sense that [21:53] sometimes you get things to move and in [21:55] particular our director general which [21:56] I'm happy they they decided to move. [22:00] So I have um one more slide where is [22:02] where we're going now. So the new [22:05] director general now that they [22:06] understand uh the interest of open [22:09] source uh we're going to have him [22:12] actually [22:14] support the open source strategy, [22:17] promote the open source strategy [22:20] and uh and communicate about it so that [22:23] once we have formalized the creation of [22:26] an open source inner source program [22:28] office or government governing office or [22:31] whatever um it will have a lot of [22:33] strength We still don't know where it's [22:35] going to be um hosted. Uh hopefully not [22:39] inside the development organization, but [22:41] that's going to be a political issue. Um [22:43] we have support from our the magistrate [22:46] that is above our director general, so [22:48] inside the Swiss the Geneva government. [22:50] So that's really good. Next step after [22:52] creating the OSPO is creating a [22:54] governance model uh and implementing it [22:58] uh better than what we do today, which [22:59] is very ad hoc. Uh and since you're [23:02] still trying to put in place the program [23:03] office uh div defining a governance [23:06] model is a little tricky because we [23:08] don't have official stakeholders. We [23:10] only have uh informal ones. Some of them [23:13] change and decide not to be law anymore [23:15] whatever. [23:17] Um we're going to push for leveraging [23:18] inner source more um in particular using [23:22] tools like internal communications where [23:25] um uh we we have an internal mailing [23:27] list that talks about our open source [23:29] and inner source activities and every [23:31] time somebody publishes something new as [23:33] inner source or open source but as inner [23:36] source we have them write an article and [23:39] uh and talk about what they're doing [23:40] because uh by doing that we are hoping [23:43] that um that uh people will see that and [23:47] it will motivate them to actually do the [23:49] same thing. Publish code, make it [23:51] properly documented, have open APIs, [23:54] generic implementation so that other [23:56] teams can use the code um and and then [23:58] in that in turn they could be visible uh [24:01] as a success story. We're we are also [24:03] looking at we have screens on the walls [24:06] that display dynamic content uh so [24:08] gamifying by having posts about who's [24:10] the biggest contributor to our inner [24:12] source repositories and channel or [24:14] things like that. And and I forgot to [24:16] mention it and it is really important. [24:18] Um we um we are implementing a developer [24:22] portal uh so that people can actually go [24:24] and search for existing code rather than [24:26] ask on our Jabber uh inner source [24:29] channel. Does anybody know of a library [24:31] that does this or that? Um because this [24:33] is not really efficient uh way of [24:35] looking for code. [24:37] Actually you could ask that to an AI [24:39] that uh that runs on the portal and [24:41] scans all of the repositories and you [24:43] probably get a better answer. they're [24:44] asking on a on a Jabber channel. So [24:47] that's that's where we're going now. So [24:48] you see we have quite a few things to [24:50] do. We're despite the fact that we've [24:52] been doing this for three years, we're [24:53] still very very much in the infancy of [24:55] the unders source program because [24:58] administrations go really slowly. And I [25:01] will uh finish this slide and talking [25:03] about in administrations going slowly by [25:06] quoting Albert Einstein who um when he [25:10] retired was asked by a journalist, so [25:13] where do you want to go? uh spend the [25:15] end of your life uh uh once you retire [25:18] and and they said uh I want to go to [25:20] Geneva because everything takes 10 to 20 [25:23] more years to happen over there and this [25:26] is where we are in Geneva. They're not [25:28] going to take 10 to 20 years but it's [25:29] going to take some time.