An InnerSource Transformation Story #InnerSourceSummit2025

An InnerSource Transformation Story #InnerSourceSummit2025 🔗 **Source:** [An InnerSource Transformation Story #InnerSourceSummit2025](https://www.youtube.com/watch?v=anl1zH5IoLk) > [!note]+ Document Notes > tags: [innersource, mainframe, ibm-z, transformation] > author: IBM InnerSource Summit > source: YouTube > reference: https://www.youtube.com/watch?v=anl1zH5IoLk > date created: 2024-12-19 14:30 > > # 🏷️ Title: An InnerSource Transformation Story #InnerSourceSummit2025 >  ## 🧰 Action Inbox - [H1] Create Z InnerSource team focused on mainframe-specific needs — establish dedicated team #transformation - [H2] Implement security-by-design in InnerSource templates — integrate code scans, vulnerability management #security - [H3] Document transition guides from legacy to modern tools — enable self-service onboarding #documentation ## 🧭 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 - [IBM InnerSource Portal](https://innersource.com) - [NIST Secure Software Development Framework](https://csrc.nist.gov/Projects/ssdf) ## 📝 Summary - IBM Z team transformed legacy mainframe development through specialized InnerSource practices - Created Z InnerSource team to adapt standard practices for 60-year-old platform with 99.99999% uptime requirements - Overcame cultural stigma around open source through documentation, security-by-design, and executive support - Successfully transitioned hundreds of custom tools from data sets to GitHub with proper documentation - Demonstrated grassroots approach leading to executive buy-in and incentive programs ## 📖 Main Content IBM's Z mainframe team shares their transformation story of implementing InnerSource practices for a platform that has operated since 1964. The Z stands for "zero downtime" with guaranteed 99.99999% uptime, creating unique requirements for security and reliability that influenced their InnerSource approach. The team faced significant challenges including hundreds of custom tools accumulated over 60 years, significant silos across 100+ components, and cultural stigma around open source practices due to licensing and security concerns. Their solution involved creating a specialized "Z InnerSource" team to adapt standard practices for their mainframe environment. Key innovations included comprehensive documentation for transitioning from legacy data sets to GitHub, security-by-design templates incorporating NIST frameworks, and community engagement through Hacktoberfest, showcases, and hackathons. The grassroots effort ultimately gained executive support and led to bounty programs incentivizing contribution to business-critical projects. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/anl1zH5IoLk?t=0) — [H1] IBM Z Background and Reliability Requirements - Key idea: Z stands for zero downtime with 99.99999% uptime guarantees in certain configurations - Evidence: "First GA in 1964 and our latest incarnation is the Z17" #### ⏱️ [02:45](https://youtu.be/anl1zH5IoLk?t=165) — [H2] Personal Story: The Code Discovery Problem - Key idea: Finding reusable code required building networks of people rather than searchable systems - Evidence: "10,000 lines of code, one data set... building this gigantic network of people" #### ⏱️ [05:20](https://youtu.be/anl1zH5IoLk?t=320) — [H2] Creating Z InnerSource Team - Key idea: Specialized team needed to adapt InnerSource for mainframe-specific requirements - Evidence: "Z inner source because we wanted to convey to the team that it is really for them" #### ⏱️ [07:15](https://youtu.be/anl1zH5IoLk?t=435) — [H2] Scale of Legacy Tool Problem - Key idea: Thousands of developers over 60 years created hundreds of duplicated custom tools - Evidence: "hundreds right so I said 1964... thousands of developers who have been working on it for 60 years" #### ⏱️ [09:30](https://youtu.be/anl1zH5IoLk?t=570) — [H2] Aaron's Journey: Reputation and Tooling - Key idea: Individual expertise led to catalog and reduction mandate for tool sprawl - Evidence: "built up a reputation... the question of we have too many tools we need to catalog them" #### ⏱️ [11:45](https://youtu.be/anl1zH5IoLk?t=705) — [H2] Proprietary Language Challenges - Key idea: Mainframe tools written in assembler and PLX don't fit traditional paradigms - Evidence: "tools written in assembler and a proprietary language called PLX... they don't play well" #### ⏱️ [13:20](https://youtu.be/anl1zH5IoLk?t=800) — [H2] Basic GitHub Structure for Mainframe Teams - Key idea: Standard GitHub files were foreign concept to mainframe developers using data sets - Evidence: "In a traditional landscape... we don't need this. We work in data sets" #### ⏱️ [15:40](https://youtu.be/anl1zH5IoLk?t=940) — [H2] Documentation as Primary Contribution - Key idea: Transition guides from legacy to modern tools became crucial for adoption - Evidence: "document how we transition how you go from one to the other" #### ⏱️ [18:25](https://youtu.be/anl1zH5IoLk?t=1105) — [H2] Success Stories: Inner to Open Source - Key idea: InnerSource pipeline successfully graduated projects like Pyrackf and PIPCS to open source - Evidence: "couple of projects that have gone through our inner source pipeline that have now become open source" #### ⏱️ [20:30](https://youtu.be/anl1zH5IoLk?t=1230) — [H2] Security by Design Framework - Key idea: NIST secure software development framework principles apply to InnerSource projects - Evidence: "do all of these things apply to inner source? We know that they apply to products certainly and I would say that they absolutely do" #### ⏱️ [23:15](https://youtu.be/anl1zH5IoLk?t=1395) — [H2] Car Analogy: InnerSource vs Open Source Trust - Key idea: InnerSource provides more confidence than open source because you can contact the authors - Evidence: "buying a car from somebody you know... I can call them and ask them" #### ⏱️ [25:45](https://youtu.be/anl1zH5IoLk?t=1545) — [H2] Community Engagement Patterns - Key idea: Hacktoberfest, showcases, and hackathons drove adoption through hands-on experience - Evidence: "I'm talking for 90 seconds and I insource a project in front of people and they're like, 'Wait a minute.' That's all it took" #### ⏱️ [28:10](https://youtu.be/anl1zH5IoLk?t=1690) — [H2] Executive Buy-in and Incentives - Key idea: Grassroots success led to executive support and company-wide point system for contributions - Evidence: "they actually contributed points... creating like a bounty type program to incentivize folks" ## 📚 References - [IBM Z Systems](https://www.ibm.com/z) - [Open Mainframe Project](https://www.openmainframeproject.org/) - [Ambitus Project](https://ambitus.io/) ## 🗣️ Paraphrase - IBM's mainframe team successfully adapted InnerSource practices for a 60-year-old platform by creating specialized processes that respect their zero-downtime requirements - The transformation addressed decades of tool duplication and silos by implementing modern collaboration patterns while maintaining enterprise-grade security and reliability standards - Community-driven adoption through documentation, events, and executive incentives demonstrated that even legacy platforms can embrace modern development practices ## 📰 Newsletter **MainFrame InnerSource: When Legacy Meets Modern Collaboration** IBM's Z mainframe team just shared an incredible transformation story that WordPress developers can learn from. Despite working on a platform from 1964 with 99.99999% uptime requirements, they successfully implemented InnerSource practices that reduced tool duplication and improved collaboration. Key takeaway: Even the most legacy systems can adopt modern practices with the right adaptation strategy. Their approach of creating specialized teams, comprehensive documentation, and gradual cultural change mirrors challenges many WordPress teams face when modernizing workflows. The team's emphasis on security-by-design and community engagement through events like Hacktoberfest offers practical patterns for WordPress plugin and theme developers looking to improve code sharing and collaboration. Resources: [WordPress Developer Handbook](https://developer.wordpress.org/), [GitHub for WordPress](https://github.com/WordPress/wordpress-develop), [WordPress Coding Standards](https://developer.wordpress.org/coding-standards/) ## ✅ Action Items #### DevRel - Developer advocacy: Present InnerSource transformation stories at WordCamps and meetups - Education: Create workshops on migrating legacy WordPress workflows to modern collaboration - Developer experience: Build documentation templates for transitioning custom tools to GitHub - Community management: Organize WordPress-focused Hacktoberfest participation #### OSPO - Policy & Governance: Develop contribution policies adapted for enterprise WordPress environments - License Compliance: Create scanning processes for WordPress plugin and theme contributions - Security Management: Implement security-by-design templates for WordPress InnerSource projects - Community Engagement: Fund WordPress InnerSource initiatives and documentation efforts #### WordPress - Core: Implement InnerSource patterns for component development and tool sharing - Documentation: Create transition guides for legacy WordPress development workflows - Community: Support InnerSource showcases and hackathons at WordCamps - Meta: Build internal tool catalogs and reduce duplication across WordPress.org systems ## 🧪 Hypotheses - Specialized InnerSource teams increase adoption rates in legacy environments compared to generic approaches - Documentation-first strategies overcome cultural resistance to open collaboration more effectively than technology-first approaches - Grassroots community engagement creates more sustainable executive buy-in than top-down mandates - Security-by-design templates reduce friction for enterprise adoption of InnerSource practices ### 📊 Methodology - Study design: Compare adoption rates between specialized vs generic InnerSource implementations across enterprise environments - Data sources: Track documentation usage patterns and community engagement metrics from InnerSource initiatives - Experiments: A/B test grassroots vs executive-mandated InnerSource rollouts to measure sustainable adoption ### ❓ Questions - How do security requirements in different industries affect InnerSource template design and adoption patterns? - What specific documentation patterns most effectively bridge legacy tooling to modern collaboration workflows? - How can incentive structures be designed to sustain long-term InnerSource contribution without creating perverse incentives? ### 🔮 Future Research - Comparative analysis of InnerSource adaptation strategies across different legacy technology stacks and industries - Long-term sustainability study of incentive programs for InnerSource contribution in enterprise environments - Cross-industry patterns of successful InnerSource community engagement and executive support models ### 💡 Implications - Practice: Legacy systems require specialized InnerSource approaches that respect existing constraints while enabling modern collaboration - Policy: Security-by-design should be integrated into InnerSource templates from the beginning rather than retrofitted - Security: Trust models differ between InnerSource and open source, affecting appropriate security measures and review processes - Education: Documentation-driven transformation strategies may be more effective than technology-driven approaches for cultural change - Funding: Executive incentive programs can accelerate InnerSource adoption but should complement rather than replace intrinsic motivation ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (technical presentation with industry jargon) #### 👀 Visual learners - Present: Slides showing system architecture, timelines, and transformation frameworks - Improve: Add workflow diagrams showing before/after tool discovery processes, security framework visualizations #### 🔊 Aural learners - Present: Live presentation with speaker narration and storytelling approach - Improve: Provide audio summary of key transformation steps and lessons learned #### 🗣️ Verbal learners - Present: Personal anecdotes, analogies (car buying), clear definitions of technical terms - Improve: More analogies connecting mainframe concepts to modern development, glossary of Z-specific terms #### 🧩 Kinesthetic learners - Present: Live coding demonstrations, hands-on hackathon examples - Improve: Step-by-step GitHub setup guides, template creation workshops #### 🧠 Logical learners - Present: Clear timeline from problem to solution, systematic approach to transformation - Improve: Detailed metrics on adoption rates, ROI calculations for InnerSource investment #### 🧑‍🤝‍🧑 Social learners - Present: Community engagement strategies, collaborative events description - Improve: Discussion guides for implementing similar transformations, peer networking opportunities #### 🧘‍♀️ Solitary learners - Present: Individual contributor stories, self-paced adoption strategies - Improve: Self-assessment tools for InnerSource readiness, individual learning paths #### 🌿 Naturalistic learners - Present: Ecosystem thinking about tool environments, organic growth patterns - Improve: Environmental impact considerations of tool duplication, sustainable development practices ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear presentation structure with headings and logical flow - Improve: Add slide descriptions, alt text for diagrams and code samples #### Keyboard navigation - Present: Standard presentation format accessible via keyboard - Improve: Ensure all interactive elements in slides are keyboard accessible #### Contrast and readability - Present: Professional presentation slides with adequate contrast - Improve: Verify all text meets 4.5:1 contrast ratio, especially code samples #### Text resizing and reflow - Present: Presentation scales appropriately for different screen sizes - Improve: Test readability at 200% zoom, ensure no content truncation #### Media and captions - Present: Video content available - Improve: Add closed captions, provide transcript download option #### Forms and interactions - Present: Basic presentation interaction - Improve: Ensure any interactive slides meet accessibility standards #### Standards reference - Follow WCAG 2.2 AA guidelines for presentation materials and supporting documentation ### 🌍 DEIB Assessment #### Cultural breadth - Present: Enterprise technology perspective from established company - Improve: Include examples from diverse technology stacks, global implementation patterns #### Inclusive language - Present: Professional technical language appropriate for audience - Improve: Define mainframe-specific jargon, avoid assumptions about technical background #### Neurodiversity support - Present: Clear structure with logical progression of ideas - Improve: Provide content outline upfront, use consistent formatting patterns #### Representation - Present: Multiple team members presenting different perspectives and roles - Improve: Highlight diverse contributor backgrounds, inclusive participation in events #### Psychological safety - Present: Acknowledges challenges and failures alongside successes - Improve: More explicit discussion of overcoming cultural resistance, support for risk-taking ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear progression from problem identification to solution implementation with measurable outcomes - Inductive strength: Multiple specific examples (tool discovery, security frameworks, community events) supporting general principles - Causal reasoning: Demonstrates clear cause-and-effect relationships between InnerSource practices and improved collaboration - Analogical strength: Effective car purchase analogy illustrating trust differences between InnerSource and open source #### Fallacies - Appeal to tradition: Slight tendency to justify mainframe approaches without questioning whether all legacy practices should be preserved - Hasty generalization: Some conclusions about executive buy-in based on limited sample size from single organization #### Tone of voice - Overall tone: Professional and encouraging with appropriate technical depth, balanced between confidence and humility about lessons learned ### 🛡️ DARVO Analysis - Deny: No problematic denial patterns observed - Attack: No attacks on external parties or critics - Reverse victim/offender: No victim/offender role reversals present - Emotional --- ## Full Transcript [00:05] Thank you very much everyone. While [00:06] Aaron is getting set up, I want to share [00:08] a story with you. Give you a little [00:10] background where we're coming from. So [00:12] as Russ was saying, he was asking what [00:13] does the Z stand for? And it stands for [00:15] zero downtime. So Aaron, myself and [00:17] Allison actually work at IBM under IBM [00:20] Z. So when we say zero downtime, we [00:23] actually guarantee 99.99999% [00:28] uptime in certain configurations, right? [00:30] So that equates to a ridiculous amount [00:32] of uptime and we really care about [00:35] reliability and we really care about [00:37] security. So there's a lot of focus we [00:39] do on that area and that's really what [00:40] we wanted to kind of share with you [00:41] today is our transformation story, how [00:44] we had to tweak some of the inner source [00:45] concepts so that they fit into our Z [00:47] paradigm. [00:49] So today we'll talk about you know [00:51] mainframe and Z a little bit more. We'll [00:53] go through the inner source and reducing [00:54] duplication. Everyone knows the value of [00:56] inner source that we have uh but it it [00:59] impacted us a little bit more uh with [01:01] documentation efforts how wonderful [01:02] that's been success stories and then [01:04] some tips and tricks later on. So like I [01:07] said Z is a monolithic mainframe right [01:11] the classic mainframe that you think [01:13] about. It was first GA in 1964 and our [01:16] latest incarnation is the Z17. As you [01:19] can see here, we continuously add [01:21] different features to it. Right? So you [01:23] can see we've added different [01:24] accelerators in terms of AI. We have [01:26] quantum safe security. We integrate with [01:28] hybrid cloud solutions and we talk about [01:31] having enterprisegrade reliability. So, [01:33] we're always thinking about how we can [01:35] incorporate security and quality into [01:37] everything we do, including the tools [01:40] that we use to generate code, to work on [01:43] code, to check things, all of the [01:45] automation that we have in our build [01:46] pipelines. We really care about the [01:48] reliability and scalability. [01:51] And specifically, the three of us are in [01:53] IBM Zos. So, this is the premier [01:55] operating system that runs on the [01:58] mainframe. So, it offers a lot of [01:59] different pieces. So, one thing I wanted [02:02] to share was a quick story about my [02:03] first day as an intern working on Z. So, [02:06] I arrive and my mentor is like,"Great, [02:09] we're going to go over to the lab [02:10] floor," which is ridiculously [02:12] impressive. So, we go over to one of the [02:14] main frames that he's running [02:15] transactions on. Tons of lights are [02:17] going off. He shows me the system. He [02:19] says, "Look, here's all the different [02:20] things that are scrolling through, all [02:21] the transactions that are happening. [02:23] We're running a test. Literally [02:25] thousands of things. It's scrolling so [02:26] fast you can't even tell what anything [02:28] says." and he just pulls a cord out, [02:31] right? Things were green, now they are [02:34] red. 10 seconds later, they're green [02:36] again. Right? And he's like, "This is [02:39] what we do, right? We have redundancy in [02:41] everything we have. We have a ridiculous [02:43] amount of testing and processes we have [02:45] in place to make sure that all of our [02:47] systems stay up." So, I had worked on [02:50] the the system verification test team [02:52] with Aaron early on, and that's what we [02:54] did. So as I went through my internship, [02:57] he actually said,"Hey, you're going to [02:59] write a workload now in a proprietary [03:01] language." All right, here's what I [03:03] wanted to do. So I sat down, I made a [03:05] design, right? Here's the workflow. [03:07] Here's what I want to do. I say, "Great. [03:09] Where's the book that tells me how to do [03:11] this proprietary language?" So I get the [03:13] PDF and I look at it and it's, you know, [03:14] basic commands. Here's like how to do [03:16] each piece. I'm like, "Does anyone ever [03:19] have like a a queue they've done before? [03:21] or does anyone have a library it could [03:22] have to have like a Q object that I can [03:25] pull from and put things into? And he's [03:27] like, okay, go talk to this guy over [03:29] here. I talked to that guy and he's [03:30] like, here's a snippet of code, right? [03:31] It's in this data set. I took a look at [03:34] it. Literally 10,000 lines of code, one [03:36] data set. And then I went and said, [03:38] okay, I also wanted to do this. Who has [03:40] code for that? So I wound up building [03:42] this gigantic network of people trying [03:44] to figure out what code we had today, [03:47] right? I mean, this was a million years [03:48] ago. trying to figure out what code we [03:50] had that I could reuse. And I was [03:52] thinking about it like when we were [03:54] gonna give this presentation. That's the [03:56] essence of inner source, right? Is I can [03:57] quickly find things now. We're [03:59] insourcing as many tools as we possibly [04:02] can. So we can reuse this information. [04:03] We can reuse libraries and things like [04:05] that. So we all know the inner source [04:07] benefits. We have a little bit of a a [04:10] different approach usually in Z as you [04:12] can imagine with the security and [04:14] reliability and for a long time it was [04:16] uh coached to us you know open source [04:19] you got to be careful with that right [04:21] because of the different licensing [04:22] pieces and things like that early on in [04:24] the open source world we were concerned [04:26] about it you know impacting the [04:28] operating system so there's a really a [04:31] stigma that we kind of had to overcome [04:33] so we wound up creating this uh specific [04:35] team focused on the Z team's use of [04:38] inner source called Z inner source [04:40] because we wanted to convey to the team [04:42] that it is really for them and it can [04:44] help them specifically no questions [04:46] about that. So we really wanted to kind [04:49] of adopt this this mechanism early and [04:51] make sure that it fit into the Z [04:53] guidelines into the processes and [04:54] procedures that we have around that. [04:58] So with that what couple of the big [05:00] things that we ran into snafu wise is we [05:03] have a ton of custom tools um hundreds [05:06] right so I said 1964 I'm not kidding you [05:09] 1964 so we have thousands of developers [05:12] who have been working on it for 60 years [05:13] we've acred a lot of essential tools [05:15] over that time we have a lot of [05:18] different components that comprise zos [05:20] so there's over a hundred different [05:21] components so a lot of tools were [05:23] duplicated across different components [05:24] that weren't even in the product at one [05:26] point and then slowly moved in those [05:29] tools became siloed like I needed it to [05:31] do this one specific thing for a [05:32] component not this other piece so here's [05:34] what I coded it up for so we really had [05:37] these significant silos worked on them [05:40] and because we have such a vast amount [05:42] of tooling we're always just trying to [05:45] you know keep basic maintenance improve [05:47] where we have to and add new tools if we [05:50] really have to so we inner source as you [05:52] can see helps a lot of these different [05:54] pieces here and I I would say that we [05:56] actually have two full-time engineers [05:58] right now that are working in the tools [06:00] space with a few of us and specifically [06:03] half of the stuff I've asked them to do [06:04] is say I want to make sure everything is [06:07] inner sourced early on. So once you get [06:10] you know here's a tool I need you to [06:11] write a read me for it write some [06:13] documentation maybe we should figure out [06:15] how to build it and then we put it in [06:17] inner source right so that everyone else [06:19] can then capitalize on that so with that [06:22] Aeron's going to take us through some of [06:23] the cool things we've done. Yeah. And [06:25] I'm actually gonna kind of start in the [06:27] same way that Mike did and [06:30] uh kind of mention some of my beginnings [06:32] as well because it kind of helps with [06:34] some of the story. So I came into SVT [06:37] and Mike was a mentor of mine. He [06:39] interviewed me and kind of in the same [06:41] way I started with tooling and started [06:43] to play in that landscape. And as Mike [06:46] already mentioned, you know, we have a [06:47] lot of areas where it's not really [06:49] documented well. it wasn't really you [06:52] know shared amongst people too much and [06:55] it brought us to the point where I [06:57] started working on tools in the same way [06:58] I started working on automation and [07:00] built up a reputation in this area and [07:02] eventually the question of we have too [07:05] many tools we need to a catalog them and [07:08] b reduce them uh became a goal and I [07:11] didn't know where to go and luckily [07:12] around the same time uh Jenna Wendy and [07:16] Michaela were actually doing some work [07:18] on the inner source portal uh I don't [07:20] know if You guys are going to talk about [07:21] the portal in depth later at some point [07:23] hopefully. Uh but I'll give a brief [07:25] overview where they built this portal. [07:27] Jenna kind of mentioned it earlier as [07:29] the the Google of our internal tools, [07:31] right? Where we can go and we can look [07:34] for a way to see what tools are out [07:36] there, what tools exist. So this is all [07:39] fine and dandy. Um but we ran into a [07:42] quick problem. As Mike had mentioned, we [07:45] have a lot of custom tooling. We have a [07:47] lot of proprietary tooling. We have a [07:48] lot of tools written in assembler and a [07:50] proprietary language called PLX. Um they [07:54] don't play well with traditional [07:55] paradigms. So that Ziners source piece [07:58] became really important. Right? So we [08:00] had a problem of needing to get those [08:02] tools a into GitHub and b to get them [08:05] you know playing in this basic structure [08:07] that was set out for us. Right? So in [08:09] this basic structure for anyone that [08:11] plays in GitHub, there's not too much [08:13] craziness going on here. We've got a git [08:16] and GitHub file. You get those for free [08:17] whenever you start and get. And then [08:20] some basics, some open source basics, [08:21] right? We've got a coners file so that [08:23] you know who this repo belongs to, who [08:26] do I need to go bug when I have [08:27] questions, who am I going to open my [08:29] pull request to, some issue templates, a [08:31] pull request template, nothing special [08:33] there, and then just some guidance on [08:35] how your team works, right? In a [08:38] traditional landscape of, you know, [08:40] mainframe developers, we don't need [08:42] this. We work in data sets. Why would we [08:43] have this? And then you know kind of as [08:46] years progressed we started to modernize [08:47] our stuff moved into git and now we're [08:50] trying to get these people involved and [08:52] intertwined in our you know ecosystem of [08:54] inner source as a whole right what [08:56] Michaela Wendy and Jenna have done is is [08:59] build a a a top tier layer that we kind [09:03] of nestle under right so that's where [09:05] that Z interource team kind of comes [09:06] under we try and partner with the larger [09:09] team to say hey you know we want to [09:11] participate but we also want to [09:12] contribute back we may be specialized [09:14] is, but there are also going to be areas [09:15] where we're not, right? We have a big [09:17] GitHub actions beta going on right now [09:19] and our Z interarchers team is driving [09:21] that going from archaic to front of the [09:23] line, right? So, depending on who you [09:26] talk to, right, mainframe is kind of [09:28] coming to the forefront and playing in a [09:29] lot of those spaces. You've probably [09:30] seen a lot go on in the the media with, [09:33] you know, IBM kind of forging ahead in [09:35] the traditional stack coming back, [09:37] right? So, with that comes one of our [09:40] main contributions, the documentation, [09:42] right? Uh it was mentioned before that [09:45] having good documenta uh having good [09:47] documentation and allowing people to [09:49] self-educate is going to be really [09:51] really uh positive towards your efforts [09:54] right and one of the first things we did [09:56] was we realized that you know trying to [09:58] bring these people into the age of [09:59] GitHub and all of these modern tools [10:01] CI/CD AI agentic we're going to need to [10:04] document how we transition how you go [10:06] from one to the other and that Z [10:08] interers team has done additional things [10:09] like provide additional tooling you know [10:11] we write some code ourselves to help us [10:13] progress from one to the other and you [10:15] know make sure that we are an active [10:17] participant in this right so in that [10:19] documentation we bring together a lot of [10:22] things right a base set of standards we [10:24] push good documentation not only on [10:26] ourselves but try and say in your [10:27] projects we require it as well or we [10:29] would like to have it um fostering that [10:32] inner source community and providing [10:34] back uh and also providing an adaptable [10:36] system right so not only guides on [10:38] getting started with inner source but [10:40] language and language stack guidance [10:42] security guidance as Mike will talk [10:43] about in a little bit and a little bit [10:45] about open source guidance because we've [10:47] started a journey of linking inner [10:49] source and open source together as well [10:50] as with our product uh cycle as well. [10:54] I'll also kind of leave a tidbit here of [10:56] while we talk about that inner source [10:58] community and reducing duplication some [11:00] competition is good in that realm right [11:03] we want to mimic the open source realm [11:05] and in the open source world we don't [11:06] always have teams working in a copacetic [11:09] nature so you know some of that [11:10] competition and driving innovation [11:12] through you know parallel projects is [11:14] also allowed as well so in that base set [11:17] of standards I'm going to kind of [11:18] handwave over this slide um we're asking [11:22] for a lot of uh things out of the people [11:24] that participate in inner source [11:25] especially in the Z realm you know we [11:27] want to maintain that code quality all [11:28] the things we've probably heard today [11:30] you know more consistency when you move [11:31] from project to projects and making it [11:33] easier to jump from one effort to the [11:35] next allowing for faster development [11:37] cycles with continuous uh integration [11:39] and development you know helping with [11:41] compliance Mike will talk about this a [11:43] little bit when he goes through uh some [11:45] of the security slides but just because [11:47] we are internal in nature does not mean [11:49] we will never be external right you saw [11:51] the NLP talk to start us off today. If [11:54] you maintain that compliance as you're [11:56] going through and building up that [11:57] project, you won't have to deal with it [11:59] on the way out, right? Uh improving [12:01] collaboration and communication. I'm [12:03] going to talk about some showcases that [12:04] we've run. Uh Hacktoberfest has already [12:07] been mentioned today, but just driving [12:09] ways to get the community involved and [12:11] to have people participate to put on [12:13] demos to show people, hey, you know, [12:15] it's this easy to insource something. [12:17] I've given so many talks in inner source [12:18] at IBM where similar to what I'm doing [12:20] right now. I'm not going to do it right [12:22] now because I'm not prepared for it. But [12:24] uh I go through and I'm talking for 90 [12:27] seconds and I insource a project in [12:28] front of people and they're like, "Wait [12:29] a minute." That's all it took. Right? [12:32] And it's about showing people the ease [12:34] that you can have to get in and get your [12:35] foot in the door. [12:38] Um so with that just a kind of you know [12:44] appreciation for some of the projects [12:45] that have come through our pipeline. [12:47] We've had a couple of projects that have [12:49] gone through our inner source pipeline [12:50] that have now become open source uh in [12:52] the Zpace. We've got Pyrackf which is a [12:55] security maintenance tool as well as [12:56] PIPCS that helps with uh dump management [12:59] and things of that nature. And then last [13:02] but not least, before I kind of hand [13:03] this back to Mike, I want to talk about [13:05] Ambitus, which is something that has [13:07] existed long before our inners source [13:09] process, but uh we've kind of connected [13:12] with in that inner source to open source [13:13] journey to enable, you know, uh a full [13:16] sweep through, right? Saying just [13:18] because your project is in source today, [13:20] you know, doesn't mean it won't belong [13:22] to something bigger later, right? And [13:24] ambitus is a project that Joe Bosshan in [13:26] the back of the room actually runs uh [13:28] that belongs to the open mainframe [13:30] project under the Linux Foundation and [13:33] really has helped drive the benefits of [13:37] inner source to our leadership in Z [13:40] right showing that just because it [13:42] starts as innource and just because we [13:44] are you know a smaller piece in a a very [13:46] legendary industry that's been around [13:48] for 60 years you know the inner source [13:50] projects can still hold some weight and [13:52] and kind of punch above their class and [13:54] I'll give this back to Mike. [13:57] >> So, I'm going to talk about security now [13:59] because that's my role, but specifically [14:02] sharing an analogy about open source. [14:04] Uh, going back to cars. So, one of my [14:06] first cars was a car I bought off eBay, [14:09] a 1966 Mustang. So, I saw five pictures [14:12] of it and it basically said doesn't run, [14:14] doesn't stop, doesn't drive, and I [14:17] bought it. I had no idea, right, what [14:21] condition it was in, what the person did [14:23] before me, how they took care of it, how [14:25] they drove it, all those fun things. So [14:28] that's kind of what happens with open [14:30] source, right? I I don't know besides [14:32] the specific guidelines that are [14:34] outlined today, what happened in the [14:35] past. So you kind of have to vet things [14:37] a little bit more appropriately. When [14:39] we're talking about inner source, I feel [14:40] like it's more like buying a car from [14:42] somebody you know, right? I don't know [14:44] when they last changed the oil, but I [14:46] can call them and ask them, right? So, I [14:48] have a little bit more confidence in the [14:50] security and reliability pieces of it. [14:52] And there's definitely, you know, the [14:54] zero trust side of me definitely [14:55] questions everything, but really there's [14:57] there's some confidence there that you [14:58] could have in things. So, I wanted to [15:00] touch upon some of the interesting [15:02] security by design items. So, uh, at the [15:05] the trust security page, we have this [15:08] wheel kind of outlining some of the the [15:10] things we're summarizing that we do at [15:12] IBM compared to the the secure software [15:15] development framework from NIST. So, [15:19] effectively what we're talking about is [15:21] do all of these things apply to inner [15:23] source? We know that they apply to [15:25] products certainly and I would say that [15:28] they absolutely do. So I'm a huge [15:30] advocate of part of our templates, part [15:32] of the different pipelines, we should [15:34] have code scans incorporated so that we [15:37] can make sure that we're running static [15:39] code analyzers, we're running secret [15:41] scans, uh dynamic scans. So anything [15:44] that we can, you know, effectively run a [15:46] tool, execute on the pipeline, get [15:48] feedback on the code we've written now, [15:50] it increases our confidence on the [15:52] different code quality that's coming in, [15:53] especially when it's been, you know, [15:55] potentially developed by AI. [15:58] There's other areas that I also think [16:00] apply. Privacy assessment is a critical [16:02] one, right? We don't want to store [16:03] different credentials or other [16:05] information about people that we [16:07] shouldn't be in source. Same thing with [16:09] vulnerability management. Having a a [16:11] plan for how you're going to manage [16:13] vulnerabilities and communicate that [16:15] people need to pick up new versions of [16:17] things. Using things like dependabot to [16:19] monitor for dependencies that need to be [16:21] updated, things like that are helpful. [16:23] And some of the other things I still [16:25] think apply. We're not going to pay for [16:26] a pull penetration test, right, for an [16:29] inner source project, but we certainly [16:31] should have specific test cases around [16:33] security, right? Maybe even have a [16:36] security engineer review some of the [16:38] tests or design some of the tests, not [16:41] necessarily go through a secure release [16:42] process, but I do a lot of code reviews [16:44] on inner source projects just to give [16:46] them feedback, right? And it could be as [16:48] simple as you're hard- coding an IP [16:50] here. We should extract that and pull it [16:52] out. or this thing hasn't been announced [16:54] yet so let's not broadcast it to even [16:56] the folks inside the company. Um, so [16:59] there's really a lot of different pieces [17:00] that kind of apply to different varying [17:03] degrees in the Z security space, right? [17:06] We certainly have a lot more rigor when [17:08] it comes to these things, but in a [17:10] general inner source project, it should [17:12] should be considered, right? Even with a [17:14] threat model, you don't have to have [17:15] reviews and approvals, but certainly you [17:17] want to think about how can an actor use [17:20] this? How could it potentially be used [17:22] maliciously? And think about those risks [17:24] and maybe you can address them with a a [17:26] small feature. [17:30] I will add to that last piece, [17:31] especially as you talk about the review [17:33] process. There have been so many times [17:35] where I've interfaced with a newer hire [17:37] or even, you know, someone more tenured [17:39] than me that's just less familiar with [17:40] the language or something like that. And [17:43] you have to tell them, hey, you may not [17:45] be doing this in the most efficient way. [17:47] You know, this will cause technical debt [17:49] for you in the future. If this becomes [17:51] something more, this is going to be a [17:52] pain in the butt to take out, right? So, [17:55] you get to help in more ways than one [17:56] with some of those reviews as well. Um, [17:59] but to kind of wrap up here before we [18:00] get to questions, I do want to talk [18:02] about some of the successful patterns [18:04] that we've seen used in addition to all [18:06] of the things that we've kind of talked [18:07] about today. Uh, laying out [18:09] documentation, you know, uh, having [18:11] these reviews with people, allowing [18:13] ourselves to have a team that enables [18:15] other people. We've also had some, uh, [18:17] great support from above us. Uh, first [18:20] things first, October Fest, I've [18:21] mentioned it a couple of times. We just [18:23] got through the month of October and it [18:25] was great. We basically allowed people [18:27] to come in and say, "Hey, all of these [18:29] projects are on the table. They're owned [18:31] by us. They're owned by others. You [18:32] know, some participation by the [18:34] community, some participation by the the [18:35] major team. And just come in, you know, [18:38] learn how to go through the process. You [18:40] can make zero code contributions as [18:42] well. You know, we accept designers, we [18:44] accept anybody. if you want to write [18:46] documentation, if you want to help us [18:47] with the design, if you want to help [18:48] with tests, you know, come one, come [18:50] all. And through the month of October, [18:52] we had tons of people come in and work [18:54] on projects, ask a bunch of questions. [18:56] So, that was great. Uh, something we [18:58] also did in the fourth quarter that I [19:00] really liked and I put on personally was [19:02] a showcase where we picked three [19:04] projects. We gave them 20 minutes each [19:06] or 15 20 minutes each and they just went [19:08] through and they talked about inner [19:10] source however they felt, right? They [19:11] had been participating in inource for [19:13] months. uh they had interacted with [19:15] inners source in one way or another and [19:16] we kind of gave them the stage to say [19:18] whatever they wanted positive or [19:19] negative right because we need the [19:21] negative feedback as well. We need to [19:23] take that up the chain. We need to uh [19:25] adhere those to the solutions that we're [19:27] going to provide as well to the [19:28] documentation that we have to the [19:29] processes that we have. And it went [19:31] great. People really liked it. They were [19:34] surprised about the projects that were [19:36] involved. Um for the first one that we [19:39] had, we had a lot of senior developers [19:41] that have been involved in the process [19:43] long before inner source but kind of [19:45] joined on. So it was good to have their [19:46] support. And last but not least, the [19:49] basic one, the one everybody knows are [19:51] hackathons, right? Uh coming up with [19:54] interesting ways to get people involved [19:56] and just trying to say, hey, you know, [19:58] we're going to bake in inner source at [19:59] the start. We're going to throw an AI [20:02] hackathon, but everyone has to start [20:04] with an innource pattern. all of these [20:06] projects will be insourced, right? You [20:08] get people involved without even getting [20:10] them involved, right? They get a basis [20:12] to say, "Hey, you know, I need these [20:14] files. I need my, you know, contributing [20:16] file. I need my uh my templates. I need [20:18] my, you know, how to get started so that [20:21] my project looks the part as well, [20:24] right? It can be in that portal that we [20:26] showed before that I'm hoping someone is [20:27] presenting on. Um, but you know, it [20:31] allows people to see how easy it is to [20:33] get involved by the paradigms that have [20:35] been set by us and above us. And uh, I [20:38] think that's all we got. So, [20:40] >> so while you're thinking of questions, [20:42] one thing I wanted to share is, you [20:44] know, we worked with our executive team [20:45] to kind of share the inner source [20:46] projects that have gone open source, [20:48] some of the inner source projects that [20:49] have gone into products and some of the [20:51] inner source projects that actually [20:54] contribute to our critical productivity [20:56] items or our required parts of our build [20:59] processes. So we we did get you know [21:01] executive buyin from that standpoint you [21:03] know sharing that people should [21:04] participate in the hackathons but also [21:06] they gave you know we have a companywide [21:09] points right like a credit card point [21:11] system and they actually contributed [21:13] points. So we wound up creating like a [21:14] bounty type program to incentivize folks [21:17] to work on side projects, right? The [21:19] inner source projects so that we could [21:21] see additional contributors to things [21:23] that were critical to the business, [21:25] right? So there really are additional [21:26] ways you can incentivize folks. I know [21:29] I've I've had people, you know, like [21:30] I'll pay for pizza or something like [21:31] that or buy them coffee and we'll sit [21:33] for two hours and work on a project. It [21:35] works out quite well. People like free [21:37] food. [21:37] >> I'll I'll also kind of add to that [21:39] because it was a side conversation that [21:40] I had with Wendy before. Um, a lot of [21:43] the chatter that we've had here almost [21:45] up until that final piece has been [21:47] grassroots, right? Bottom up. We really [21:49] focused on the community. We focused on [21:51] the people and driving things that way [21:52] rather than going top down.