InnerSource Summit 2024

Perhaps the hardest part of making Open Innovation work is overcoming the internal silos and other organizational barriers that inhibit the flow of useful knowledge. InnerSource arose to address quite similar challenges, and has much to teach those who wish to open up their innovation processes outside their firm.

In today’s rapidly evolving technological landscape, the concept of “empathetic engineering” has emerged as a vital approach for creating more inclusive, user-friendly, and socially responsible products and solutions. InnerSource, the practice of applying open source development principles within an organization, aligns closely with empathetic engineering. Both approaches emphasize collaboration, transparency, and inclusivity. InnerSource fosters a culture where engineers share knowledge, collaborate across teams, and collectively solve problems. This collaborative spirit enhances empathy by exposing engineers to diverse viewpoints and user experiences. In this talk, Brittany Istenes will share how she approaches new projects identified for InnerSource through the empathetic engineering mindset that creates strong, sustainable and secure InnerSource projects.

In the rapidly evolving landscape of software development, your organization may already be experiencing enhanced developer productivity through AI-powered coding tools like GitHub Copilot. As AI continues to advance, one key trend is personalization. It’s natural to desire an AI that intimately understands your codebase. To achieve this, source code for fine-tuning and RAG (Retrieval-Augmented Generation) becomes crucial. When considering the characteristics of code ideal for AI to feed, certain traits emerge: usability at an enterprise scale; openness and accessibility to AI, being well-maintained and easily comprehensible and lastly, being well-documented. Upon reflection, you’ll realize these are precisely the hallmarks of open-source code. However, code with these open-source-like qualities doesn’t naturally arise within corporate environments. Such code isn’t merely a “product” but a manifestation of culture. Ask yourself: Is your code confined to specific projects? Is it consistently maintained? Is it written to be universally understandable? If not, now is the time to start cultivating these practices. Waiting to prepare your codebase for AI enhancement three years from now may be too late. This session will provide valuable insights and strategies to prepare your organization for the AI-driven future of software development. We’ll explore how adopting InnerSource principles can create a codebase that’s not only more efficient and collaborative today but also primed for AI augmentation tomorrow. Join us to learn how to position your organization at the forefront of the AI revolution in software development through the power of InnerSource.

How the InnerSource Programs Office working group can help you as someone responsible for InnerSource enterprise-wide 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 include: Providing guidance on configuring version control systems for successful InnerSource implementation; documenting metrics for ISPOs to track InnerSource KPIs across the business; reviewing the adoption of an IEEE framework for Open Source that has been tailored for InnerSource. We invite you to join us! Find the #ispo-working-group channel in the InnerSource Common’s Slack.

Micaela Eller will discuss how InnerSource practices, traditionally focused on code, can be extended and adapted to non-code assets such as models, containers, documentation, configurations, and more. Organizations adopting InnerSource methodologies and an open governance framework applied to no/low code areas create a highly collaborative environment, which lowers cost due to improved efficiency, higher quality and reduced redundancy, and accelerates innovation by leveraging a global community of experts to collectively solve big problems and apply InnerSource practices to deliver a repeatable and reusable solution, thus solving once to solve for many.

CICD pipelines often give some headaches to developers : it’s slow, complex, hard to maintain and it always fails ! Does this sounds familiar to you ?! That’s what we have faced so let’s suit-up like adventurers to track some solutions. Together we will try to build a real CICD supplychain that’s secured and maintainable. And this will lead us to an opportunity to have an Innersource approach in our company 😉 We’ll start at level 0 with a reminder of the key notions of CICD, then we will create some templates and improve them into reusable components. Next, we’ll implement a centralized and monitored approach of our components catalog. The final step in our journey is embracing the InnerSource methodology. We’ll explore how to open our catalog to the community, encouraging usage and fostering contributions of new components. Come with us on this fantastic DevOps journey!

This talk will discuss how OpenChain ISO/IEC 5230 (the international standard for open source license compliance) and ISO/IEC 18974 (the international standard for open source security assurance) support the work of InnerSource program offices. While supply chain management is often seen as external relationships between customers and suppliers, internal supply chain management is just as critical. Using industry standards in this context ensures alignment with broader market expectations, and ensures that remediation, catch-up and process mis-match is minimized.

At SAP, InnerSource practices are increasingly becoming adopted as an essential part of our software development process, promoting collaboration, innovation and efficient code reuse. Ensuring consistency and quality across numerous repositories is challenging. To address this, we built an internal repository linter to standardize configurations and InnerSource-relevant content, while also providing automated fixes for detected issues. This session will share our journey of developing and piloting this tool to enhance repository quality and uniformity. Participants will gain insights into the rationale behind the linter, its implementation and the standards it aims to enforce.

Join us to discover how InnerSource can transform your organization’s data strategy by enabling the creation of a unified Data Mesh that leverages the collective expertise of all divisions. This session is ideal for those looking to enhance data collaboration and drive innovation within their organization. We will address the unique challenges faced by multi-division organizations. Using practical examples from our case study, we will demonstrate how InnerSource can facilitate the creation of a common data platform across all divisions. This includes establishing a contribution framework, managing shared codebases, and fostering a collaborative environment where divisions can work together to enhance the data platform. Learn how InnerSource can help overcome barriers to collaboration and control, leading to a cohesive and efficient Data Mesh.

In 1914, Booz Allen Hamilton pioneered the field of management consulting. Today, we are trusted as the largest provider of AI to the federal government. Our goal is to provide technically differentiated solutions that solve complex client problems at scale, and to do that, we are championing a culture of internal reuse. This includes applying InnerSource principles, through a Backstage developer portal, to improve velocity, quality, and developer experience for a technical workforce of 14,000. InnerSource principles of transparency and self-service can be at odds with corporate hierarchy, program silos due to varied client contracts, and the “need to know” mindset required when handling classified information. To get the best of both worlds, our Backstage team has learned to lean into that tension and deploy change management techniques to build community and rally support for new ways of working. This session will explore corporate barriers to InnerSource adoption and lessons learned along the way.

Like Open Source, InnerSource relies on self-motivation and personal interests even if it is happening within a company. How do you start an InnerSource movement that people want to join of their own volition and get a flywheel spinning? This presentation will touch on several ideas you can experiment with to apply innersourcing at scale: culture challenges and ways to think about them; tooling as a marketplace of buyers and sellers; marketing by leveraging the community, process consulting; motivation and career planning. All growth comes from stepping outside what you already know.

A healthy InnerSource community is built on trust. People can’t work together unless they have some level of trust in the people they are working with. Transparency helps teams discover code and information easily and quickly. High quality documentation is the key to this success. We will look at what makes high quality documentation and how it can make work easier for users across teams. If people trust the software documentation they find, they are more likely to reuse and contribute to the code. We will discuss how high quality documentation can build trust across teams and in turn, how that trust helps build your organization’s InnerSource program.

Many change initiatives falter in the middle, often due to resistance from managers who face changes from all directions. To successfully drive InnerSource adoption, it’s crucial to generate a desire for change among middle managers. This presentation outlines strategies to empower these managers, equipping them with the necessary tools and approaches to lead InnerSource efforts effectively. There are three key tactics for fostering a desire for change in the middle: provision of thorough training and encouragement of ongoing learning to ensure managers are equipped to support InnerSource practices; identifying and addressing common risks and sources of resistance by conducting detailed risk assessments and developing proactive strategies; and lastly maintaining engagement and motivation through alignment of incentive programs with InnerSource goals. Understanding your organization and stakeholders is vital for building effective change leaders. Managing resistance proactively helps create a smoother transition and a supportive environment. Using these three tactics supports organizations to develop a culture that naturally embraces InnerSource methodologies, leading to long-term success and engagement.

Leading organizations have recognized multiple advantages of utilizing InnerSource programs. Innersource is applying open-source practices to your internal software development. This session will outline the best practices to initiate and support an InnerSource effort and the benefits for organizations.

Exploring how platform engineering teams can improve developer experience and increase platform adoption by using InnerSource practices. This talk will discuss the role of InnerSource in building self-service platforms that empower developers, how the collaborative development and shared ownership model can lead to more flexible and user-friendly platforms and the processes, and cultural shifts that enhance developer productivity and satisfaction.

So you have decided that Inner Source is the way to go. Good for you! This has the power to substantially enhance your software development. The rest is a piece of cake. You only need to explain to your employees what this is all about: Inner Source is like Open Source, it just stays within the company. Easy enough. Oh yeah, and talk to the people from corporate tax, should be no problem, you know someone there. Then get the legal department to answer some simple questions, and off you go! Alright, tooling is an issue, too. And governance… Ok ok, so you haven’t thought about all the minor details, but you just get everybody’s attention and spread the word. Done in no time. Right?!? You may find it’s just not working that smoothly. Why is that? In this session, we will explore how to unlock the huge potential of InnerSource, illustrated with our journey at Mercedes-Benz. We will discuss what factors can make an InnerSource project successful, what some of the stumbling blocks can be, and how to overcome (at least some of) them. In particular, we will also take a look at how AI-tools can spike up the acceptance, the usage, and the implementation of Inner Source.

  </div>

This talk will distill the essence of successful InnerSource implementation into three main pillars: strategic tool integration, legal clarity, and a thriving developer community. By addressing these areas, organizations can navigate the path to InnerSource success more effectively. Identifying and integrating the right tools are crucial steps that can present significant technical barriers. The presentation will outline common tool-related challenges, and propose solutions for smoother adoption processes. The intricacies of legal compliance and license management are often underestimated. An exploration of these legal challenges will offer guidance on creating a compliant and supportive legal environment for InnerSource. The ‘Human Factor’ cannot be overstated. Resistance to change and the necessity of community building, development of sense of belonging whithin the organization will be examined, highlighting methods to foster a collaborative and inclusive culture. Join Thomas Froment for an in-depth analysis of challenges, leveraging 8+ years of feedback from experience on InnerSource deployment across various French companies and organizations.

Open source AI is being defined as I write this. What would that mean for innersource initiatives? Would the data to train the foundational models be themselves open source (internally atleast) and what are the consequences of doing that. This talk is a to expand the conversation the OSI is having with Open Source AI but with an Inner Source slant.

Unlocking DevEx at enterprise scale requires a strategic shift towards collaboration and flow. Join our session to explore empowering thousands of engineers with rapid feedback loops, reducing cognitive load, and fostering team empowerment. We navigate the transition from siloed to collaborative cultures through InnerSource principles, implementing self-service methodologies, and harnessing Backstage as an internal developer portal. We share real-life examples and lessons learned at scale, marrying technical innovation with cultural evolution.

In today’s dynamic software development landscape, organizations often face the challenge of managing diverse agile teams, each utilizing different methodologies to drive innovation and deliver value. The integration of InnerSource principles presents a promising solution for effective governance and enhanced collaboration among such varied teams. This abstract explores how InnerSource can facilitate the governance of different agile software teams, fostering a cohesive and collaborative working environment. Agile methodologies have revolutionized software development, emphasizing flexibility, customer collaboration, and iterative progress. However, the diversity in agile practices, such as Scrum, Kanban, and Lean, can lead to siloed teams, inconsistent processes, and communication barriers. InnerSource, which incorporates the transparency, collaboration, and meritocracy of open-source development within an organization, offers a structured approach to address these challenges.

We have a whole lot of InnerSource Patterns that teams using InnerSource can rely on. In this 90 minute workshop, participants can bring their InnerSource challenges to the table. Together, we’ll select the challenge that people want to work on and we will problem-solve using existing patterns and new pattern ideas. Based on our work together, we will submit a draft pattern of any new ideas to the InnerSource patterns community.

Most InnerSource practitioners may have heard of OSPOs - but have you heard about ISPOs? If an OSPO can be defined as the center of gravity for an organization’s open source operations and structure, then an ISPO performs a similar role for InnerSource. Last year, InnerSource Commons launched an ISPO Working Group for those involved in enabling InnerSource within their organizations. Clare has been conducting research with a number of members of the ISPO Working Group. In this session, Clare will share information about the emergence of ISPOs. She will explore the typical goals of an ISPO, the people involved and the type of activities undertaken by those working in the space.

The “InnerSource Portal” is a well known InnerSource Commons pattern. There is growing awareness in the community that Backstage, the open source project created at Spotify, is a solution to implement that pattern. From this perspective, Backstage can support InnerSource initiatives. But we also see the parallel perspective in our work with companies that adopt Backstage as the presentation layer for their internal developer platform. Many of these companies are not familiar with the InnerSource Commons, but would benefit by running a first experiment in this context. From this perspective, InnerSource practices can support Backstage implementation by addressing issues that are critical for the success of the Backstage rollout. In practice, “adopting InnerSource to drive the adoption and evolution of a Backstage implementation” is not so trivial. There is still a lack of documented best practices and detailed guidance. The InnerSource patterns are a great resource, but they need to be tailored and extended to this particular context. This is the gap that we aim to bridge in the session, by sharing our hands-on experience in the form of concrete “implementation recipes”. Some recipes are technical, addressing questions related the codebase organization, release process, etc. Other recipes are organizational, addressing questions of evangelization, engagement and governance.

Most InnerSource patterns and best practices assume that all projects within an organization should be hosted on a single, unified developer platform like GitHub Enterprise, with all developers and stakeholders contributing to it. However, large enterprises often face challenges in providing such a universal platform due to financial constraints, feature limitations, historical reasons, and other specific requirements. These challenges result in fragmented developer platforms that are not inclusive of all members and are not conducive to InnerSource activities. In this session, we will discuss the introduction of an InnerSource portal with a software catalog and other special capabilities to address and mitigate these issues. You will learn how to implement this portal using a customized version of Backstage, an open-source framework for building developer portals, based on our platform engineering project.

In this session we’ll recall some interesting stories and adventures of setting up InnerSource practices and culture in various organizations. We’ll explore things that can (and will) go wrong, and how to mitigate them. Make sure your experience is made better by avoiding common pitfalls!

Running an InnerSource initiative in any non-trivially sized company is a non-trivial undertaking. While the return on investment is usually very positive overall, a substantial investment is required, nonetheless. How much largely depends on the size, organisational complexity and culture of your organisation. Some of the “homework” is pretty obvious, such as establishing a collaboration platform for your developers. Some isn’t, such as an IP-policy for InnerSource. There is homework that should be taken care of at the beginning of your InnerSource journey while some can be tackled later on in your InnerSource journey. In this talk, we’re sharing our InnerSource “laundry list” - based on 15 years of InnerSource experience at Bosch. We will also make the case for a decent sized InnerSource team and will share some of our learning from running InnerSource with and without such a team.

In the process of learning more about the relationship between Agile and InnerSource, the academic body of knowledge is always a good starting point. However, it is surprising to see that there is still a need for more background knowledge. This talk intends to summarize and present the work done gathering those references and also the learning that has been enriched by our own experiences. The topics of culture, governance, roles, documentation, or motivations will be covered in this talk. We started this discussion in Galway in 2019 (“Thoughts on Adopting InnerSource and Agile”). Five years later, we will revisit this theme in the hope of fostering further discussions at the InnerSource Commons.