New Open Source Tools to Enable InnerSource #InnerSourceSummit2025

New Open Source Tools to Enable InnerSource #InnerSourceSummit2025 🔗 **Source:** [New Open Source Tools to Enable InnerSource #InnerSourceSummit2025](https://www.youtube.com/watch?v=z1vcy9aveEE) > [!note]+ Document Notes > tags: [innersource, open-source-tools, shell, ai-discovery, repository-management] > author: InnerSource Commons > source: YouTube > reference: https://www.youtube.com/watch?v=z1vcy9aveEE > date created: 2024-12-28 19:30 > > # 🏷️ Title: New Open Source Tools to Enable InnerSource #InnerSourceSummit2025 >  ## 🧰 Action Inbox - [H1] Review Shell's inner source maturity model for organizational adoption — 05:23 #innersource - [H2] Evaluate AI-powered discovery tool Fleming for code repository search — 09:14 #ai-tools - [H3] Test repo repair tool Avanti for automated repository standardization — 15:42 #automation ## 🧭 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 - [Shell Inner Source Enablement Team](https://shell.com) - [Project Fleming](https://github.com/shell/fleming) ## 📝 Summary - Shell's Inner Source Enablement Team presents two open-source tools to enable inner source practices - Fleming provides AI-powered semantic search across repositories, Stack Overflow, and documentation for ~$400/month - Avanti (repo repair tool) automatically generates documentation and templates to meet inner source maturity standards - Both tools address the dual challenge of making code discoverable and ensuring repositories meet quality standards - Shell is migrating these tools to the Linux Foundation and seeking community collaboration ## 📖 Main Content Shell's Inner Source Enablement Team, established in 2023, developed two significant open-source tools to address barriers in inner source adoption. The team found that cultural change alone was insufficient - technical tooling was essential to make code repositories more shareable and discoverable. The first tool, Fleming, is an AI-powered discovery system that provides semantic search across multiple data sources including GitHub repositories, Stack Overflow, and internal documentation. Built using open-source models from Hugging Face and BERT, it runs entirely on CPU infrastructure at approximately $400 per month per endpoint. The system addresses the critical problem that repositories cannot be reused if they cannot be found, particularly in large organizations like Shell. The second tool, Avanti (repo repair tool), automates the process of bringing repositories up to inner source maturity standards. It generates comprehensive reports and provides editable templates for documentation, license files, contributor guides, and other essential components. The tool integrates with GitHub Copilot instructions to ensure consistent coding practices aligned with inner source standards. Both tools support Shell's inner source maturity model, which defines bronze, silver, gold, and platinum standards for repository quality. The model was developed collaboratively with developers across global offices and has evolved through multiple versions based on community feedback. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/z1vcy9aveEE?t=0) — [H1] Introduction and agenda overview - Key idea: Shell presents two open-source tools to enable inner source practices - Evidence: "Today we're going to be talking about inner opensource tools that we've developed to enable innersource" #### ⏱️ [02:45](https://youtu.be/z1vcy9aveEE?t=165) — [H2] Shell's inner source journey and team formation - Key idea: Inner Source Enablement Team established in 2023 during organizational restructure - Evidence: "The inner source enablement team has been at Shell since 2023 and we've been working on making the organization more inner source enabled" #### ⏱️ [03:30](https://youtu.be/z1vcy9aveEE?t=210) — [H3] Culture and tooling dual approach - Key idea: Culture change alone insufficient; technical tooling changes necessary - Evidence: "We found that culture was only one part of the story... we also found that we needed to make tooling changes too" #### ⏱️ [04:15](https://youtu.be/z1vcy9aveEE?t=255) — [H2] Team member introductions - Key idea: Christian leads inner source strategy, Amber handles technical innovation - Evidence: "I'm a senior applied innovation engineer... I currently run as the inner source technical lead" #### ⏱️ [05:23](https://youtu.be/z1vcy9aveEE?t=323) — [H1] Inner source maturity model components - Key idea: Comprehensive standards including documentation, licensing, security measures - Evidence: "Having a proper readme is incredibly important. having proper tagging, commented code, having protected branches" #### ⏱️ [06:45](https://youtu.be/z1vcy9aveEE?t=405) — [H3] Developer collaboration in maturity model development - Key idea: Maturity model developed collaboratively with global developer community - Evidence: "This maturity model is developed in collaboration with the developer population... Representatives from as far a field as Brazil, India, Amsterdam" #### ⏱️ [08:30](https://youtu.be/z1vcy9aveEE?t=510) — [H1] Discovery problem and motivation for AI tool - Key idea: Repositories cannot be reused if they cannot be discovered - Evidence: "A repository can do everything that you want... but if it can't be found then it can't be reused" #### ⏱️ [09:14](https://youtu.be/z1vcy9aveEE?t=554) — [H2] Fleming AI discovery tool architecture - Key idea: Natural language search leveraging AI across multiple information sources - Evidence: "We built a natural language search leveraging AI to provide enhanced results" #### ⏱️ [10:30](https://youtu.be/z1vcy9aveEE?t=630) — [H3] Fleming cost efficiency and technical details - Key idea: CPU-only infrastructure costs approximately $400 per month per endpoint - Evidence: "It runs entirely on CPU infrastructure... it costs us roughly about $400 a month including our front end pieces" #### ⏱️ [12:15](https://youtu.be/z1vcy9aveEE?t=735) — [H2] Fleming search capabilities and filtering - Key idea: Semantic search with quality filtering based on maturity model - Evidence: "You can filter on languages like Python... you can also filter on that inner source maturity model" #### ⏱️ [13:45](https://youtu.be/z1vcy9aveEE?t=825) — [H3] Fleming expansion to other Shell teams - Key idea: Backend technology adopted by multiple teams beyond inner source - Evidence: "Other teams are adopting this backend technology such as the shell's data foundation team" #### ⏱️ [15:42](https://youtu.be/z1vcy9aveEE?t=942) — [H1] Repo repair tool motivation and functionality - Key idea: AI-powered tool to automatically bring repositories up to maturity standards - Evidence: "What if we could leverage AI to help and also how could we make the fixes easier to implement" #### ⏱️ [17:20](https://youtu.be/z1vcy9aveEE?t=1040) — [H2] Avanti repo repair tool features - Key idea: Generates comprehensive documentation and templates with editing capabilities - Evidence: "It will give you a how to use guide, a contributor guide, license files... everything in here is actually editable" #### ⏱️ [19:30](https://youtu.be/z1vcy9aveEE?t=1170) — [H3] Customizable maturity models in Avanti - Key idea: Tool allows organizations to define their own inner source maturity criteria - Evidence: "People can define a maturity model for themselves" #### ⏱️ [20:45](https://youtu.be/z1vcy9aveEE?t=1245) — [H2] GitHub Copilot integration approach - Key idea: Copilot instructions align teams with inner source standards automatically - Evidence: "Can we help co-pilot to align teams and standards automatically?" ## 📚 References - [Shell Inner Source Enablement](https://shell.com) - [Project Fleming on PyPI](https://pypi.org/project/fleming/) - [University of Erlangen-Nuremberg collaboration](https://www.fau.eu/) - [InnerSource Commons](https://innersourcecommons.org/) ## 🗣️ Paraphrase - Shell developed two open-source tools to overcome technical barriers in inner source adoption beyond cultural change initiatives - Fleming provides cost-effective AI-powered search across repositories and documentation using CPU-only infrastructure at $400/month per endpoint - Avanti automates repository standardization by generating documentation templates and integrating with developer workflows through GitHub Copilot ## 📰 Newsletter Shell's Inner Source team has open-sourced two powerful tools that address core challenges in enterprise code sharing. Fleming offers semantic search across repositories for just $400/month, while Avanti automatically generates documentation to meet quality standards. Both tools will migrate to the Linux Foundation, creating community-driven solutions for inner source adoption. For developers struggling with code discoverability and repository standardization, these tools provide practical automation that reduces friction in collaborative development. Resources: [InnerSource Commons](https://innersourcecommons.org/), [Fleming Documentation](https://pypi.org/project/fleming/), [Shell Open Source](https://shell.com) ## ✅ Action Items #### OSPO - License Compliance: Review Fleming and Avanti licensing models for organizational adoption - Community Engagement: Engage with Linux Foundation migration of Shell's inner source tools - Strategic Alignment: Evaluate inner source maturity models against existing governance frameworks #### Community - Maintainers: Collaborate on Fleming and Avanti development through Linux Foundation - Contributors: Test tools in different organizational contexts and provide feedback - Ecosystem: Share inner source maturity model implementations across organizations ## 🧪 Hypotheses - Organizations with AI-powered repository discovery see increased code reuse rates compared to traditional search methods - Automated documentation generation reduces time-to-inner-source-compliance by 60-80% for development teams - CPU-only AI infrastructure provides sufficient semantic search quality at significantly lower operational costs than GPU solutions - Collaborative development of inner source maturity models increases developer adoption rates versus top-down mandates ### 📊 Methodology - A/B testing of Fleming versus standard GitHub search across large enterprise repositories - Time-motion studies of manual versus Avanti-assisted repository standardization - Cost analysis of CPU versus GPU infrastructure for semantic search workloads - Survey research on developer satisfaction with collaborative versus imposed maturity standards ### ❓ Questions - How do different inner source maturity model criteria affect actual code reuse outcomes across organizations? - What impact does semantic search have on cross-team collaboration patterns in large enterprises? - How can organizations measure the ROI of inner source tooling investments beyond adoption metrics? ### 🔮 Future Research - Comparative analysis of inner source maturity models across industries - Long-term impact studies of AI-assisted documentation on code maintainability - Integration patterns between inner source tools and existing DevOps pipelines ### 💡 Implications - Practice: Automated tooling can significantly reduce barriers to inner source adoption in large organizations - Policy: Organizations need collaborative approaches to developing inner source governance standards - Security: AI-powered code discovery requires careful consideration of information access controls - Education: Developer training should include inner source maturity concepts alongside traditional software engineering practices - Funding: CPU-only AI solutions provide cost-effective alternatives to GPU infrastructure for enterprise search applications ### 🧠 Learning Styles Assessment Reading level estimate: 12-14 (technical conference presentation) #### 👀 Visual learners - Present: Conference slides with tool architecture diagrams - Improve: Interactive demos showing search interfaces and generated documentation #### 🔊 Aural learners - Present: Video presentation with speaker explanations - Improve: Podcast-style discussion of implementation experiences #### 🗣️ Verbal learners - Present: Technical terminology definitions, tool comparisons - Improve: Case study narratives showing before/after scenarios #### 🧩 Kinesthetic learners - Present: GitHub repository examples, hands-on tool demonstrations - Improve: Step-by-step deployment guides, configuration labs #### 🧠 Logical learners - Present: Cost analysis, technical architecture decisions - Improve: ROI calculations, decision trees for tool selection #### 🧑‍🤝‍🧑 Social learners - Present: Collaborative development stories, community feedback processes - Improve: Discussion forums, peer implementation sharing #### 🧘‍♀️ Solitary learners - Present: Technical documentation, self-serve tooling - Improve: Personal reflection prompts on inner source practices #### 🌿 Naturalistic learners - Present: Organizational ecosystem thinking - Improve: Sustainability impact of code reuse, infrastructure efficiency ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Video has structured presentation format - Improve: Provide slide deck with proper heading hierarchy and alt text #### Keyboard navigation - Present: Standard YouTube controls available - Improve: Ensure tool interfaces meet keyboard accessibility standards #### Contrast and readability - Present: Conference presentation slides visible - Improve: High-contrast versions of technical diagrams #### Text resizing and reflow - Present: Video content scalable - Improve: Responsive documentation for tool deployment guides #### Media and captions - Present: Video content available - Improve: Professional captions and transcript with technical terminology #### Forms and interactions - Present: Standard video interface - Improve: Accessible forms for tool feedback and collaboration ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global Shell developer participation mentioned (Brazil, India, Amsterdam) - Improve: Showcase diverse organizational contexts beyond enterprise energy #### Inclusive language - Present: Technical presentation uses accessible terminology - Improve: Define technical jargon for broader audiences #### Neurodiversity support - Present: Structured presentation format with clear agenda - Improve: Multiple content formats (visual, audio, text) for different processing preferences #### Representation - Present: Mixed gender presenter team - Improve: Showcase diverse organizational roles and perspectives #### Psychological safety - Present: Collaborative development approach emphasized - Improve: Clear contribution guidelines and community standards ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Logical progression from problem identification to tool development to open source release - Inductive strength: Evidence from Shell's implementation supports broader applicability claims - Causal reasoning: Clear connection between tooling changes and inner source adoption barriers - Analogical strength: Energy company experience applicable to other large enterprises #### Fallacies - Appeal to authority: Minimal - focuses on technical evidence rather than organizational status - Hasty generalization: Minor risk - Shell's experience may not generalize to all organizational contexts #### Tone of voice - Overall tone: Professional, collaborative, technically focused with emphasis on community contribution ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attack rhetoric identified - Reverse victim/offender: Not applicable to technical presentation - Emotional cues and rhetoric: Positive, solution-oriented language encouraging collaboration ## 🎯 Conclusion - Shell's open-source tools Fleming and Avanti address critical technical barriers in inner source adoption through AI-powered discovery and automated standardization - The dual approach of semantic search and repository quality automation provides a comprehensive solution for large organizations - Migration to Linux Foundation creates opportunity for community-driven development and cross-organizational collaboration ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] AI-powered discovery tools enable cost-effective inner source > [!quote] [New Open Source Tools to Enable InnerSource](https://youtu.be/z1vcy9aveEE) by [[Shell Inner Source Team]] via [[InnerSource Commons]]. Published 2025. Accessed 2024-12-28. > --- ## Full Transcript [00:06] So thank you for having us. Um this is [00:08] uh the second time that we've [00:10] participated albeit now this is directly [00:13] in the inner source common summit and [00:16] today we're going to be talking about [00:18] inner opensource tools that we've [00:20] developed to enable innersource. So the [00:23] agenda very briefly is that we'll talk [00:25] very briefly about innersource at shell. [00:27] I'll introduce uh myself and Amber can [00:30] introduce herself. We'll talk about the [00:31] inner source maturity model um which [00:34] addresses some of the things we've just [00:36] heard from IBM and then we'll launch [00:38] into the products themselves. First, the [00:40] AI powered discovery tool. I'll give a [00:43] brief explanation as to the why and [00:45] wherefore of it and the same thing goes [00:47] for what we call the repo repair tool. [00:48] We'll briefly outline our commitment to [00:50] open source and then we'll open it up [00:52] for any questions. I do recognize that [00:54] time is of the essence. [00:57] So the inner source enablement team um [01:00] has been at Shell has been at Shell [01:01] since 2023 and we've been working on [01:05] making the organization more inner [01:06] source enabled despite the fact that the [01:09] organization has been going through a [01:11] significant restructure over the past 18 [01:13] months. We found that culture was only [01:16] one part of the story. So what we do uh [01:20] events which try to influence the [01:22] culture. So for example, every year we [01:24] host something called Openfest and we [01:26] get speakers from industry and speakers [01:27] from within Shell to try and provide the [01:30] power of example to influence the [01:32] culture. But we also found that we [01:34] needed to make tooling changes too. And [01:35] we developed two significant tools to [01:37] help our teams make their code more [01:40] sharable. And we've deployed this for [01:42] the inner source community as [01:43] open-source projects. It's an extension [01:45] of our innersource ethos. So who are we? [01:49] Well, technically my title is inner [01:51] source lead and I lead um ISET. Um I [01:55] have been working for the company since [01:57] March 2023 and been given the brief of [01:59] trying to encourage spread and put [02:02] forward inner resource behaviors and a [02:04] strategy towards getting that [02:06] implemented within Shell. Amber is our [02:09] senior applied innovation engineer. [02:11] Amber, do you want to introduce yourself [02:12] briefly? [02:14] >> Yes. Hi everyone. Uh my name is Amber [02:16] Lindsey Rigg. Like Christian said, I'm a [02:18] senior applied innovation engineer at [02:19] Shell. What that means is that I am very [02:22] lucky and get to work on a lot of new [02:24] technology in Shell, including edge [02:25] computing, blockchain, time series data, [02:28] but what I'm most passionate about is [02:30] inner source, and I currently run as the [02:33] inner source technical lead, helping [02:34] develop all our new technologies on our [02:36] platform. [02:39] >> Thank you for that. So when we when I [02:43] when the team began working and we were [02:45] looking at what is it that makes code [02:47] more easily sharable and what we found [02:51] was is that there are certain things [02:53] that you can do to make your code [02:55] repository more sharable with others and [02:58] documentation is certainly part of it [03:00] but also making sure that you have a [03:02] license file there is also very [03:04] important. We've been working with the [03:05] University of Alang and Nuremberg and [03:07] one of the things that they one of the [03:09] projects that they've been working on is [03:11] talking about what are the tax [03:13] implications of knowledge flow transfers [03:15] between company um companies that say [03:18] are located in Germany, UK, US and is [03:21] does that create a tax implication for [03:23] intellectual property? So license file [03:25] goes some way to dealing with that. [03:27] Having a proper readme is incredibly [03:29] important. having proper tagging, [03:30] commented code, having protected [03:33] branches. Um we also made our in our [03:36] particular setup we have sonar cube as a [03:39] security measure and we also tried to [03:41] make sure that dependabot um doesn't [03:43] identify any higher critical issues. We [03:45] want to make sure that there's a clear [03:46] commit history and a developer guide and [03:49] a how to contribute guide and um then we [03:52] have developed the bronze and silver and [03:54] gold and platinum standards on top of [03:56] that. We're trying slowly to move shell [03:58] developers up the value chain. It has [04:00] become a mark of prestige for some [04:03] developers to have a gold marked [04:07] repository and that is a culture change [04:10] as well as a technical change. By the [04:12] way, one of the things that we found [04:13] that was critical was making sure that [04:16] this maturity model is developed in [04:17] collaboration with the developer [04:19] population. We have regular working [04:21] group meetings where we talk to [04:22] developers from across the organization. [04:25] Representatives from as far a field as [04:26] Brazil, uh, India, Amsterdam and so on [04:30] come and talk to us and provide their [04:32] feedbacks. As you can see, it's an [04:34] evolving thing because we're on version [04:35] 2.4. [04:38] So, let's talk about the AI powered [04:39] discovery tool. What we found is is that [04:41] a reposi you can do everything that you [04:43] want in terms of trying to make your [04:45] repository mature but it's being set to [04:48] open just isn't sufficient. If it can't [04:50] be found then it can't be reused. When [04:53] we started this project um we GitHub [04:56] didn't have a standard search [04:59] improvement on their road map. They [05:01] weren't that there wasn't any talk about [05:03] using the large language models at their [05:04] command in order to improve their [05:06] search. And we were told that if AI [05:09] generates less code, then it's less [05:10] necessary. However, the best code is the [05:12] kind that you don't have to program [05:14] again. And furthermore, what we also [05:16] wanted to embed was effective search [05:18] across information resources. I was very [05:20] interested to hear IBM talking about [05:22] searching across Stack Overflow. Ours [05:24] does. It searches across Stack Overflow [05:27] and SharePoint as well as GitHub and it [05:29] didn't exist within Shell at this point [05:31] for the purposes of developers. So we [05:33] built a natural language search levering [05:36] leveraging AI to provide enhanced [05:38] results. [05:40] So here are some of the key features. [05:42] Amber, do you want to take it away [05:43] please? [05:44] >> Thanks Christian. So the AI discovery [05:47] tool is a semantic search tool that runs [05:49] entirely on CPU infrastructure. So we [05:52] have multiple endpoints running and it [05:54] costs us roughly about $400 a month [05:57] including our front front end pieces. Um [06:00] we currently use open-source models uh [06:02] from hugging face using BERT for the uh [06:05] cosign similarity. And if you use the [06:08] tool, what you first do is you can type [06:10] in a query using either keywords or [06:12] natural language and it will provide you [06:15] a list of repos which are relevant to to [06:18] your query or your search. Then from [06:20] there you can start filtering. For [06:22] example, I love writing in Python. So I [06:24] can filter on languages like Python. I [06:27] also want to make sure that the code I'm [06:28] looking into is of good quality. So I [06:31] can filter on things like sona cube men [06:33] dependabot and most importantly what you [06:35] saw that Christian was showing the inner [06:38] source maturity model you can also [06:39] filter on that. So people don't just get [06:42] the repos are useful they also get high [06:44] quality repos that they can trust and [06:46] they can connect with people and use [06:48] like Christian said as well because we [06:50] use these small models we actually have [06:52] expanded it to different data sources in [06:54] shell. uh example is our stack overflow [06:57] area as well as a lot of shell internal [06:59] documentation and we can handle both [07:01] structured data and unstructured data. [07:04] Um when people search they basically [07:07] configure and query all these multiple [07:08] endpoints at the same time and we aren't [07:11] the only team now using this in shell. [07:13] Other teams are adopting this backend [07:15] technology um such as the shell's data [07:18] foundation team and they're using it to [07:20] actually search for data that they can [07:22] reuse. And this is targeting one of the [07:24] biggest problems that we have in shell [07:25] is that we have a lot of really good [07:27] information, a lot of really good code, [07:29] but we are so large, we are so [07:31] disconnected. Could you go to the next [07:34] slide please Christian? Great. One of [07:36] our main focuses uh when developing the [07:39] AI power discovery tool was making sure [07:41] that it was cost efficient but also [07:42] carbon efficient. So the way we worked [07:45] it uh the way that we've worked on it is [07:47] that it entirely runs on CPU avoiding [07:49] any GPU infrastructure. So each [07:52] endpoint, so Stack Overflow, GitHub, and [07:55] also our internal documentation is only [07:57] about $400 a month, making it highly [07:59] cost effective. This is this is how [08:02] we've addressed this and how we've made [08:03] it so efficient is by having small [08:05] commute computes that we can then scale [08:08] up if we need to individually. So it [08:10] means I can change one endpoint but keep [08:12] the others the same and keep the cost [08:14] down low. Additionally, we are also [08:16] using um open source tools like hugging [08:19] face and BERT to make sure that we can [08:21] benefit from the community driving [08:23] innovation and actually avoid licensing [08:25] cost. Another really important part of [08:28] how we're able to get these very small [08:30] models to work is that we do a lot of [08:32] work in our data preparation. So, we [08:35] ensure what we put into our corpuses are [08:37] well structured and we actually do this [08:40] with genative AI. Could you go on to the [08:42] next slide here, Christian? [08:45] So when we launched uh last year uh we [08:48] launched the project Fleming during the [08:50] inner source common summit as in the [08:52] keynote this allows you to use all the [08:54] things that we have in the AI power [08:56] discovery tool but even more so it [08:59] supports the multiple endpoints with [09:00] semantic search it will be cheap to run [09:03] like I said the $400 a month we've also [09:05] included a generic uh front web front [09:08] end that you can easily deploy and then [09:10] we've also included a virtual readme [09:12] generator So this is something we see a [09:14] lot. We see a lot of really good code [09:16] and a lot of good repos, but the [09:18] documentation is very poor. So with poor [09:20] documentation, it's really hard for us [09:21] to put this into the search tool for [09:23] people to find. So we actually use [09:25] genative AI to prepare the data so that [09:28] we can then use easier and smaller [09:30] models on the data itself. [09:33] Please take a look. We have this all now [09:35] public for anyone to use. You can [09:37] install it by Pi Pi. It's a Python [09:39] package and you can run it on Spy Park, [09:41] Pi Spark, sorry. And if you are [09:44] interested as well, you can also launch [09:45] this as well on data bricks. We have [09:48] Mosaic AI integrations and you can do [09:49] long-term serving on their serving [09:51] endpoints. So what's next? If you go on [09:54] to our web page, you'll see that it's [09:55] been a little bit quiet recently. This [09:57] is because we're currently migrating [09:58] this tool over to the Linux Foundation [10:00] and it might come out with a new name in [10:02] a few months. We've also got some [10:04] tooling that we kept back cuz we want to [10:06] release it when we go to the Linux [10:07] Foundation. So to even reduce costs even [10:10] more, we've actually developed a Visual [10:12] Studio Code extension. So that means all [10:14] you need is the tooling and the serving [10:17] of the endpoint and you can take the [10:19] Visual Studio Code extension, download [10:22] it onto your VS Code and start using the [10:24] endpoints and searching, bringing the [10:26] tooling straight to the developers where [10:28] they work. [10:32] >> Thank you for that, Amber. But as our [10:35] friends at IBM pointed out is that [10:37] getting people to actually get their [10:39] repos up to the standards of the [10:41] maturity model can be very challenging. [10:44] In 2024 we ran a number of clinics um in [10:48] order to get people to adhere to the in [10:51] order to adhere to the maturity model. [10:52] And it worked in a hackathon-like style [10:54] setting. We had to we had dashboards [10:57] which refreshed every so often to show [10:59] how people were progressing. We still [11:01] have those dashboards. However, we asked [11:03] ourselves um what if we could leverage [11:06] AI to help and also how could we make [11:09] the fixes easier to implement. So this [11:11] year what we've created is something [11:13] called the repo repair tool. So Amber [11:16] would you like to go through the key [11:17] features please? [11:19] >> Yes. So it's currently developed on [11:21] plotly dash uh Python back back end and [11:25] what a developer can do is that they can [11:27] take their repo URL put it in there and [11:30] they can ask for a generation of a [11:31] report on what they need to do to make [11:33] their repo better and meet our inner [11:35] source maturity models. So for example, [11:38] it will give you a how to use guide, a [11:39] contributor guide, license files, [11:41] maintainer lists, shell code of conduct, [11:44] issue templates, PR templates, and even [11:46] how to enable things like Sony cube or [11:48] dependable. And what's really [11:50] interesting is that that piece that we [11:51] showed you in project Fleming that we've [11:53] open sourced of generating virtual [11:54] readmes, we've actually included in here [11:56] in this development as well. So if [11:58] someone wants to have a virtual readme [12:00] generated for their repo, they can just [12:02] click a button and get a virtual readme. [12:04] and it takes away a lot of the effort [12:06] that developers um go through when [12:08] trying to do documentation. Another part [12:11] is they can look at it in the web URL, [12:13] but they can also download a full [12:14] report. So if you're a manager and you [12:16] have someone who you're working with who [12:18] you need to say, I need you to get these [12:20] repos up to standard, you can download [12:22] that report and give it to your team [12:24] members to say like this is what you [12:25] need to do. Please go away and do it. Um [12:29] and also everything in here is actually [12:31] editable. So if someone doesn't like the [12:34] read me introduction or they want to [12:36] update the contributor guide to be [12:37] reflective of their work, they can [12:39] actually edit it in the repo repair tool [12:42] and the results will come out and they [12:43] can then copy and paste it into their [12:45] repo and make changes. So it's making it [12:48] really easy for people to get their [12:49] repos up to standard. And once it's up [12:52] to standard, it's really easy for us to [12:53] then put it into the AI powered [12:55] discovery tool and then for people to [12:57] find it. [13:03] So we're making this open source as [13:05] well. Um we are the pro the provisional [13:09] title is project Avanti. Avanti is [13:11] Italian for forward and we are also [13:14] building an additional feature because [13:16] one of we we've had conversations with a [13:19] number of firms about what it is that [13:21] they define as an inner source maturity [13:23] model. And the answer is mixed. People [13:26] have different opinions on what should [13:27] go into the maturity model. Different uh [13:30] there are different criteria that people [13:32] have. Some things are some more [13:33] important than others. So what we put in [13:36] is an additional feature so that people [13:38] can define a maturity model for [13:39] themselves. [13:41] We're leveraging the virtual readme [13:43] functionality and we are going to be [13:44] launching this via the Linux foundation. [13:47] Once we have got this out there, we will [13:50] communicate this via the inner source [13:51] commons so that people can actually use [13:54] it. [13:56] Amber, do you want to pick up on the [13:58] co-pilot instructions element, please? [14:00] >> Yes. So, a lot of us now are getting [14:03] copilot integrated into our normal [14:05] workdays and how we should use it. So, [14:07] how can we actually use this tooling um [14:09] in our standardizing approaches of [14:11] innource? Can we help co-pilot to align [14:14] teams and standards automatically? And [14:16] can we change how co-pilot answers so [14:19] that improves documentation, naming and [14:21] testing across the repos? Next slide, [14:23] please. [14:27] Well, the answer is yes, you can use [14:30] copilot to improve your repos, but this [14:32] has to be in tangent with other pieces. [14:34] So, as you saw with the repo repair [14:36] tool, we gave people virt uh we gave [14:38] people virtual reads, license files, [14:41] contribution guides, and much more. So, [14:43] what we've done in shell if we've [14:45] created a GitHub template that when [14:47] someone creates a repo, they create it [14:49] from this template. And this template [14:50] has everything in it such as readme, [14:52] licensing, contribution guidelines, how [14:55] to use all the PR templates, all the [14:57] issue template so that from day one, [15:00] people should have those basic standards [15:01] in their repo. We've also included the [15:04] co-pilot instructions uh markdown file [15:07] that will help to guide co-pilot. This [15:09] means that when people are using [15:11] co-pilot in their coding um in their [15:14] code and using it in agent mode, it's [15:16] not just going off and doing it in a [15:17] random way. is actually following um the [15:20] inner source standards. So it has the [15:22] right structure for an innource project. [15:25] Um so we've got clear documentation and [15:27] consistent coding styles. And this means [15:28] from one developer to another that [15:30] actually coding in the same way and [15:32] we're getting a very nice consistent um [15:36] uh code stack within our organization. [15:39] The co-pilot instruction file tells [15:40] co-pilot how to behave, what patterns [15:43] follow, what not to do, and really how [15:45] to support reuse and readability. So [15:47] this setup just mainly ensures that [15:49] people from day one can have their repos [15:51] in a source ready making it easier to [15:53] share, reuse and collaborate. And it [15:55] also just provides another tool which [15:57] helps people to feel confident when [15:58] sharing their code. [16:04] So this is all part of our commitment [16:06] because our adoption of inner source [16:08] practices is a reflection of our [16:10] commitment to open-source values, [16:12] sharing, collaboration and open [16:14] innovation. Now you may be wondering why [16:17] why we're open sourcing all this. Well, [16:18] there's a very simple reason is that [16:20] Shell is not a software company. Never [16:22] have been, never will be. But never the [16:25] nevertheless we do operate in a digital [16:27] space even though our business is mainly [16:29] energy. And quite frankly, we would like [16:32] to get your ideas in there. We one of [16:34] the reasons why we all are inner source [16:36] pract practitioners is to benefit from [16:39] the diversity of ideas within our talent [16:42] pools to me expand the reuse of code to [16:45] build uh to use the cognitive space that [16:48] people have to in order to enhance the [16:50] the products that we're building. So are [16:54] looking for more collaborators on on [16:57] this work. We're looking for people to [16:59] use it to use it in a variety of [17:01] different scenarios. And we always [17:03] welcome feedback. We would really we [17:06] would really like to see more uh [17:08] collaborators [17:10] download the the tools that we're [17:11] putting out there, provide us with [17:13] feedback, add contribute to our [17:15] codebase. We're always looking for that. [17:17] And so we welcome we welcome anybody's [17:20] participation and feedback in building a [17:23] uh better open source tools to [17:24] facilitate in source.