The InnerSource Programs Office (ISPO) working group is dedicated to creating guidance and tools for teams responsible for implementing InnerSource within an enterprise. Our focus is on supporting these teams, rather than individual products or users. If you’re involved in an Open Source Programs Office (OSPO), platform engineering, Software Community of Practice, or any centralized group with InnerSource responsibilities, this working group is designed for you. Our working group follows a structured process, taking discussions and ideas through various traditional kanban stages to develop practical products that can benefit everyone. Some ongoing initiatives on our Kanban board include: (1) Providing guidance on configuring version control systems like GitHub and GitLab for successful InnerSource implementation. (2) Documenting metrics for ISPOs to track key performance indicators related to InnerSource across the business. (3) Reviewing the adoption of an IEEE framework for Open Source that has been tailored for InnerSource. We strive to be accessible and efficient, offering several avenues for participation, including biweekly working group meetings, a dedicated Slack channel, GitHub repositories, and a GitHub-based Kanban board. Our objective is to deliver valuable products through collaborative efforts, accommodating participants' availability. All projects within the working group undergo peer review as they progress through the Kanban board. To ensure that the working group aligns with your organization’s needs and produces reusable solutions, we invite you to join us. Find the #ispo-working-group channel in the InnerSource Common’s Slack. Your input and contributions are valuable in shaping the direction and impact of the ISPO working group.

We will be talking through how the FINOS InnerSource special interest group is working together within the ISC to revolutionize how FINTECH enterprises collaborate, innovate and develop a frictionless technology landscape.

Many of us are personally familiar with the struggle to advocate for adopting InnerSource practices. Effectively communicating the value of it to your business can be a challenging endeavor. While for some the value is self-evident, organizational decisions require a different set of justifications for these activities. Drawing on nearly 20 years of experience articulating value to executive audiences, Addie will share lessons learned in how to convince your boss that InnerSource is the smart business decision, including how to: - Define the criteria that matters to your stakeholders - Frame the value proposition for an executive audience - Form an internal champions team to advocate alongside you - Structure your asks and planned activities to meet stakeholder expectations Attendees will leave with immediately actionable strategies to help them get their organization moving toward InnerSource.

Teaching people how to do InnerSource by only watching videos can be exhausting, why not add custom-made training session where people can discover the power of InnerSource?

In the world of software development, collaboration can make the difference between a brittle last-minute release and a reliable, maintainable, pain-free project. Whether you’ve been coding for a day or a decade, your colleagues are there to help strengthen your work. But they can only help if you’ve given them the tools to do so. Attendees will leave with an understanding of how they can make their projects a welcoming, safe, and interactive space, and the benefits thus brings to both creators and collaborators. They’ll walk away with a ready-to-use checklist for shaping new projects.

Join us for this informal Ask Me Anything panel session with some of the folks behind InnerSource Commons. If you are curious about how InnerSource Commons is run, our mission, our future direction, or even just want to pose your most challenging InnerSource question to some of the folks who have been doing it the longest - this is your chance!

Last year in our talk “InnerSource is a Marathon, not a Sprint” we gave an overview of SAP’s InnerSource journey. This year we will go a bit deeper below the surface and talk in more details about how we run our InnerSource program, how do we set ourselves up for collaboration and specially, how do we incrementally document InnerSource internally to enable our employees to learn InnerSource and our teams to adopt it by themselves.

Code ownership is not always well understood, and the effects of ownership change depending on team and organisation culture. Sometimes, ownership is seen as a bad thing, as it can discourage collaboration and InnerSource. At other times, ownership is considered key to success. This talks looks at the BBC’s TV Application teams' software ownership principles, the pros and cons of this approach, and what the next steps of the journey are.

This session will explore the intersections between InnerSource and Open Source practices and draw insights from each approach. These intersections will help organizations develop holistic strategies to capitalize on the strengths of both models, leading to more effective collaboration, enhanced innovation, and increased community engagement. A case study of how Red Hat’s Open Source Program Office’s Training and Enablement Team is collaborating with InnerSource Commons will be also be shared, further demonstrating the open practices. After the session and exploring Red Hat’s collaboration with InnerSource Commons, the audience will be able to:: - Recognize the intersection of open source and innersource. - Identify opportunities for collaboration and innovation using open-source principles. - Discuss ideas to build and maintain strong communities by analyzing successful open-source community practices.

This is an interactive session for attendees to meet, ask questions and have more in-depth discussions on any burning issues coming up for them.

Do you have an InnerSource project but potential contributors have no easy way of discovering them? Do you find it difficult to attract contributions? This presentation will discuss how an InnerSource portal can raise visibility and attract contributors organization-wide. You will learn the benefits and challenges as well as the tools used in developing an InnerSource portal.

In this panel session, Clare, Hans, and Remy will discuss the topic of how and why InnerSource is practiced in public sector. Why is InnerSource practiced in these areas? What role does it play in their open source strategy? Does operating in a regulated environment change how InnerSource is rolled out?

In the world of InnerSource, a software development approach that encourages open collaboration within organizations, the reluctance to share code often mirrors the challenges faced by children when asked to share their toys. This engaging talk will explore the intriguing parallels between these two seemingly disparate scenarios and shed light on the psychological and cultural factors that drive such behavior. Drawing on developmental psychology and organizational dynamics, we will delve into the commonalities between children guarding their toys and adults guarding their code. Just as children cherish their toys, adults take pride in their code, viewing it as a reflection of their expertise and creativity. Fear of loss, concerns over competition, and a lack of trust can all stifle the willingness to share, whether it’s a favorite action figure or a meticulously crafted codebase. Through this thought-provoking discussion, we will examine the impact of organizational culture on code-sharing practices and explore strategies to foster collaboration and overcome barriers. By understanding the shared patterns between children and adults, we can illuminate the path to a more open, innovative, and collaborative InnerSource environment. Join us for an insightful exploration that will change the way you think about code sharing, drawing intriguing parallels between the child’s reluctance to part with their toys and the adult’s hesitation to share their code in the InnerSource ecosystem.

Development speed is stated as one of the benefits of applying InnerSource claimed by the 2023 respondants. InnerSource helps in this process by building a more homogeneous way of working with the standardization of processes and tools, by enabling developers to collaborate with others, other aspects as a similar cultural approach across the organization, and many more. However, can we zoom in and check which actions in the development process are contributing the most to this efficiency? Is it possible to learn from the existing stoppers in the contribution cycle? This talk will share thoughts and lessons learned in the development process and how by strategically analyzing certain steps (e.g. code review processes) it is possible to infer actions that will improve that velocity as well as lead to the improvement of the existing InnerSource practices.

This talk delves into Airbus' journey in embracing InnerSource. The key elements of this transformation include overcoming legal obstacles, cultivating a community, securing leadership buy-in, offering technical support, and creating incentives for participation. To understand the context of Airbus' InnerSource transformation fully, it is essential to consider the historical factors that shaped the current corporate structure. Issues related to taxation and IP management have played a role in determining the organization’s approach to InnerSource. Building an engaged community was instrumental in the success of InnerSource at Airbus. Early adopters played a pivotal role in kickstarting this transformation. Airbus is organizing Transform to OPen Software (TOPS) events, where Open Software encompasses both Open- and InnerSource, which. It provides a platform for external benchmarks, and internal enthusiasts to share ideas, best practices, and success stories. These events not only fostered knowledge exchange but also acted as catalysts for the InnerSource movement. This movement, while primarily driven from the bottom-up, crucially relies on the support from the leadership team. Leadership buy-in and balancing bottom-up and top-down approaches were instrumental in Airbus' journey by creating a permanent team fully managing these topics. This synergy between bottom-up enthusiasm from software engineers and top-down leadership support highlighted the organization’s dedication to continuous improvement and growth in this endeavour. Another crucial pillar has been the provision of robust technical support. Although we had the necessary technical stack in place, it was imperative to instrument it for key performance indicators (KPIs) to monitor the change and to facilitate the discovery of InnerSource assets. To encourage active participation beyond early adopters, Airbus implemented incentives for employees contributing to InnerSource projects. Recognitions and awards have been used to acknowledge contributors, fuelling enthusiasm for InnerSource across the organization. In conclusion, by removing legal hurdles, building a strong community, gaining leadership support, providing technical resources, and incentivizing participation, Airbus has successfully embraced InnerSource practices. However, While Airbus has made significant strides in its InnerSource journey, it’s important to recognize that there is still a way forward in continuing to enhance and refine these practices for even greater collaboration and innovation. It’s just the beginning.

At Amadeus, we rely on Jenkins pipelines to manage the Continuous Integration and Continuous Delivery (CI/CD) of our products, including the build, deploy, security and static analysis, cloud deployment, end-to-end tests, change management… Instead of copy/pasting our CI/CD script (Jenkinsfile) in the >1500 repos using the Java/Maven stack, we decided to fully innerSource a generic solution, using: - A framework owned by a team, benefitting from many InnerSource contributions, - Implementations of this framework, fully in InnerSource for the Maven stack. Thanks to this collaborative model, many people started using and contributing to the solution, for the benefit of the whole company. I will present the journey to get there, from the idea to the InnerSource implementation, collaboration model and common use cases.

It’s remote-first, not remote-only. For decades Open Source project communities have found a very delicate balance between being globally distributed - but making room for in person trust building. In this talk we will look at what corporate teams can learn from how distributed Open Source projects handle the need for in person communication. We will look at how communication purpose drives choosing the most effective type of communication medium.

Sometimes, there is no alternative to using InnerSource software development. In this talk, I look at the development of software platforms across business organizations within a multinational organization. Here, you can’t just create a new country organization to develop the platform everyone wants, and an InnerSource approach would be the best choice. However, using InnerSource creates new challenges, which I will discuss.

In today’s software development landscape, Developer Experience (DX) holds paramount importance. The effectiveness of developer collaboration, satisfaction, and overall productivity often defines the success of a project. With the rise of open-source principles, InnerSource — the practice of using open-source strategies within enterprises — has gained traction. This session unravels the journey of adopting InnerSource to enhance DX, enriched by firsthand experiences of evangelizing and learning.

Creating an “InnerSource Portal” is a well-known pattern. By providing a single place where all projects are presented, a Portal helps with discoverability. With some effort, it can grow into an online community space, fostering collaboration and engagement. All of this helps give visibility to InnerSource initiatives and their impact. InnerSource Portals have often been developed “from scratch”, but there is growing interest to build them on top of “Backstage”, an open source platform created at Spotify. A core feature is the “Software Catalog”, which provides a way to track projects and teams. Backstage provides a data store, integration capabilities and a unified presentation layer that makes the implementation of an InnerSource Portal easier and faster. But most importantly, Backstage is built on top of a plugin architecture, which makes it very flexible and easy to expand. We have used Backstage in several engagements, where the goal was to make the complex “digital ecosystem” of the company easier to grasp and navigate. The challenge was to design an environment that would cater to the needs of both business and technical stakeholders. By default, Portals built with Backstage tend to have a strong “developer-centric” user experience, with a focus on technical workflows. But with some work, it is possible to change that and to build Portals that are better suited for a diverse audience. In this session, we present several approaches to go beyond the “out-ot-the-box” capabilities of Backstage. We first discuss some UX and UI concerns and demonstrate that it is possible to build Portals that feel more like “collaborative spaces” than “technical tools”. We then demonstrate several plugins created on top of Backstage and explain how they relate to other InnerSource Patterns. Last but not least, we demonstrate some advanced use cases, where we have used AI and LLMs to deliver interesting and surprising insights about InnerSource activities through the Portal.

Scaling InnerSource practices in growing organizations poses unique challenges. This talk introduces the use of scorecards as a strategic tool to measure and enhance InnerSource projects. Discover how scorecards provide a quantifiable method to assess projects on parameters like code quality and community engagement. Learn how to integrate this approach to ensure efficient, transparent, and collaborative development in your organization. Join us for insights on supercharging your InnerSource journey!

This is an interactive session for attendees to meet, ask questions and have more in-depth discussions on any burning issues coming up for them.

InnerSource is actively embraced by many organizations to promote collaborative development. In organizations that are heavily working in silos, it presents numerous challenges that hinder the adoption of a collaborative development model. This discussion explores the misconceptions or hurdles faced by teams in embracing InnerSource and discusses how a governance model like Open Source Program Office (OSPO) or InnerSource Program Office (ISPO) can help overcome these obstacles. The misconceptions and misinterpretations held by teams often lead to inertia and resistance towards collaborative development. The first and common misconception seen is the fear of losing ownership or control of a project when opening it up to a wider community of external contributors. This misconception arises due to a lack of familiarity with inclusive development models. The essence of InnerSource lies in inclusive decision-making processes, empowering teams to drive projects and implementation collectively. The second misconception revolves around concerns that contributions from the community may introduce errors or break the software. Teams working extensively on a project possess in-depth knowledge of its components, testing procedures, and security aspects. In contrast, external contributors may lack this comprehensive understanding, potentially leading to mistakes. This hurdle is particularly prevalent in projects that are highly siloed, where implementation, testing, and documentation are highly restricted within the team. The third misconception involves teams choosing the least used or least maintained project for InnerSource experimentation. This approach may be adopted by teams being initially hesitant to adopt inclusive development with a wider community. However, selecting a project without active maintainers or limited resources for maintenance poses significant challenges in building a supportive community. Such initiatives are prone to failure, potentially leading to the misconception that InnerSource is not beneficial. It is crucial to understand that InnerSource does not automatically imply the availability of resources or an established community for maintaining a software project. To address these misconceptions and to overcome hurdles, OSPO/ISPOs can play a vital role by educating the teams through workshops and setting guidelines on InnerSource practices. By clearly defining the roles and responsibilities of maintainers, code owners, contributors, project stewards, community members, and managers, OSPO/ISPOs provide a framework for effective collaboration. Moreover, OSPO/ISPOs, as independent entities with visibility across teams, can impartially resolve conflicts and facilitate smoother adoption of InnerSource within the organization. By leveraging the expertise and guidance provided by OSPO/ISPOs, organizations can break down silos, foster collaboration, and drive innovation. The OSPO/ISPO serves as a catalyst for change, helping teams overcome inertia and embrace the InnerSource model for enhanced software development and increased value creation and long term success.

https://osr.finos.org/docs/osr-resources/innersource/ provides details of a session presented at the last FinOS Summit in London. Will be presenting a more evolved version and will provide more detail on the challenges faced by Financial instructions and how InnerSource and InnerSource licenses can help pave the way.