Spring Summit 2018

Today, we know that InnerSource is a great way to efficiently develop software by leveraging communities that transcend organizational and geographical boundaries aka silos. We also know now, that InnerSource is an excellent segway into true Open Source development for companies lacking a software DNA. Back when Bosch started with InnerSource, there was not enough technical, legal, collaboration, social, and commercial experience within Bosch to start open source right away. Getting an InnerSource initiative off the ground in such a setting is challenging. Stefan will go back to the origins of InnerSource at Bosch and share the surprising story of how he managed convince upper management to engage in InnerSource using rather unconventional means. This included three key elements:

1. start with InnerSource first and not with open source right away,
2. start with tooling (here Eclipse IDE for automotive) and not with the Bosch products and
3. start with “capturing the nations flag” and not with slides Now Stefan is proud that Bosch is active contributing to Eclipse Internet of Things projects.

Now Stefan is proud that Bosch is active contributing to Eclipse Internet of Things projects.

Over the years, we’ve all seen software development methods come and go. Many of us have grown sceptical of the promises of new approaches as a result. Danese, Jim and Georg, three long time practitioners of InnerSource, have experienced firsthand how InnerSource stands out and has the potential to truly transform the world of corporate software development. In this talk, they will share three compelling arguments for why InnerSource matters.

“Inner source is a great idea! Go do inner source!” You’re the dedicated champion for inner source in your company. What do you do now? How do you realistically affect the behavior of dozens or hundreds of teams to the point where robust and pervasive inner sourcing is a normal part of the way that engineering is done?

This presentation shares principles, practical anecdotes, and relatable examples on this situation gleaned from experience at Nike. While not claiming all of the answers, it is insightful summary of over a year of work in the area.

Company has decided to start an InnerSource initiative in order to foster collaboration across organizational boundaries all over the world. We understand the adoption of open source development paradigm within organization is becoming very popular and essential to business of company. As far as I know, many companies have experimented with this model, but so far it’s not always clear where to start. So I want to share our experience from Edge Platform InnerSource case, with use case, DevOps, Tools, Product development, and development infrastructure and so on and expect audience to capture some insights. But further discussions are needed to understand the various models of InnerSource that companies are adopting.

In 2006, I introduced inner source to SAP. After becoming a professor, my group helped further companies introduce inner source. Using three generations of projects, we report about our experiences and how we turn those into a practical handbook for inner source governance.

Wayfair has a sizable (over 1200 people) engineering organization. It’s comprised of many small sprint teams that can work efficiently and effectively on their own. This structure, however, makes it difficult to coordinate work that spans big chunks of the department, like introducing new frameworks or upgrading shared infrastructure. We introduced a concept called working groups, based on Inner Source principles, that let us run these kinds of projects with the efficiency that we expect from any other team. During this poster session I will give an overview of the projects we’ve tackled with working groups, their pros and cons, and how we’re planning to iterate on this pattern.

Innersource has a very positive influence on prototyping and predevelopment. A company with many products in different domains can trigger cross domain solutions by internally publishing of APIs and libraries. Sharing these within the company has been enabling reuse in different Business Units leading to surprising synergies across different applications.

While there are a lot of talks and blogposts about APIs and the importance of an API’s Developer eXperience, most are about public API products. And while a lot of the best practices for API products are also applicable to private APIs, there are significant differences in the circumstances and trade-offs they need to make. The most important difference is probably in their budgets: as potential profit centers, API products can afford to invest a lot more money in documentation and UX driven developer portal improvements. Internal APIs rarely have that luxury. In this talk I will explain the differences between public and private APIs, introduce upstream developer experience, and explain how it can improve downstream DX. Introduce experience design (a.k.a. gamification), and describe how it could be used on internal developer portals. Lastly I will talk about the importance of SDKs and the different strategies an organisation can take to build them, including an innersourcing strategy that could help to improve the DX of APIs at the heart of your organisation’s digital transformation initiative.

FusionX was the first Bosch Internal Open Source Community and has been active for the past 9 years. Our mission is to empower fellow Bosch engineers to build prototypes, tools and new products connecting to our products much more quickly than before. Over the years, we have seen all of that happen and more. I will share examples and insights into how the community worked, what we developed and what the success factors and challenges were we encountered along the way.

We’ve done step 1: we have a platform, repositories and a group of initial users. Now we are looking for step 2, getting the developers of big infrastructure projects involved. They are worried they won’t have time to participate in InnerSource. We have teams–they have good softwre and are willing to share it, but they have concerns about the quality of code that others will be contributing; and their ability to mentor others outside the group. This is our next hurdle. This poster talk is an inverted advice booth–please visit us and share your ideas and advice.

        Another topic: we have a one hour meeting with the company president about InnerSource; what should we emphasize and try to get from him (in terms of support for the InnerSource Program).            

In this presentation, we present the research approach and preliminary results from an ongoing research project on mining inner source best practices. Because inner source is the use of open source software development best practices and the establishment of an open source-like culture within organizations, we need to understand the best practices used and established in the open source world to learn from them. So far we collected development activity information from over 450,000 open source projects to quantify their performance and predict their success. From the best projects, we plan to mine the used process and practices. Using case study research, we will then apply these open source practices in inner source and validate which can jump the chasm from open to inner source.

No metric is important but that one that is directly linked to the strategic goals of your company. Success is basically measured when the goals are achieved.
Measuring things is ‘easy’ if you know where to mine the data, but having a strategy requires context expertise, a detailed method to formalize the measuring process and a strategy regarding to awareness, process improvement, transparency and motivational actions among other key areas.

Metrics are not the panacea, but help to understand the current structure and methodology followed by a software development team. And how far this is from other similar organizations.

Topics include:

• Goals using metrics
• Areas of analysis
• A formal approach such as the Goal-Question-Metric one
• Strategy when using metrics
• Some examples

Breaking silos and foster collaboration across the several business units is one of the main goals of any InnerSource inititive. However, how can we know if this is actually taking place? This talk will also focus on the usual data sources available when building the infrastructure needed in this types of initiatives and the traces left by the members of the new community. Those traces are the ones parsed, stored and curated in order to produce valuable metrics for the organization. I will go through the usual data sources such as GitHub, Jira or Slack as some examples of how to understand and measure collaboration across the organization.

Inner source (IS) enables and requires developers to collaborate more than traditional SD methods such as plan-driven or agile development. To better understand IS, researchers and practitioners need to measure IS collaboration. However, there is no established method yet for doing so. In this talk, we present a method for measuring IS collaboration by measuring the patch-flow within an organization. Patch-flow is the flow of code contributions across organizational boundaries such as project, organizational unit, or profit center boundaries. We demonstrate the capability of the patch-flow measurement method by applying it at a software developing company. In this company, we found that about half (47.9%) of all code contributions to IS projects constitute patch-flow between organizational units, almost all (42.2%) being between organizational units working on different products. Such significant patch-flow indicates high relevance of the patch-flow phenomenon. Our patch-flow measurement method is the first of its kind to measure and quantify IS collaboration. It can serve as a base for further quantitative analyses of IS collaboration.

Disagreements and misunderstandings are common even in the most high-performing organizations. Fortunately, a potential solution offers us a path forward from vagueness and confusion: intentional relationship design. Taken from the therapeutic profession, IRD enables us to establish clarity in our work relationships early on so we can avoid conflict later. In this talk, I’ll show how you can use it to establish expectations, set boundaries and uncover communication preferences to build trust and harmony—especially as your teams aim to InnerSource.

Applying InnerSource with our teams we found out how it is the most powerful way of developing, learning fast, breaking silos and scaling organization. InnerSource enables establishing open source software development best practices and open source-like culture to every internal development. You can still develop proprietary software, but internally open up its development. In this session, I share our experiences how we scaled our organization using InnerSource with roles, metrics at my previous organization Intuit, and the internal open source culture and practices at Microsoft.

Developing a technological Cloud Native platform, that brings non functional capabilities to the company was always a challenge for us, as a foundations platform team. When adopting an Open Source mindset, we looked on how to increase agility and start a cultural change at our own organization, to drive a cultural change in business units adopting our platform. We changed our organization to think like an open source organization (structure, engineering practices and collaboration) and soon became an Inner Source organization to the company, leading more than Inner Source – leading a cultural change. I will describe the transition that we made and how we took the first steps as Inner Source in the company

We’ll discuss some sure fire ways to ensure that you set your InnerSource Journey up for failure. Following these tips, you can guarantee that InnerSource will never succeed

Those of us establishing InnerSource programs encounter similar problems. Developing Patterns is a way of capturing proven solutions to these problems. Let’s work together and provide solutions for the larger community! This workshop will provide a brief introduction of the InnerSource patterns, and the standard components of patterns. Then we’ll break out into groups to draft patterns for pervasive problems. Attendees: If you’ve got a problem that you’d like us to cover in the workshop, let us know in advance! Email: erin.bank@ca.com

Pattern languages show how patterns fit together to solve classes of problems around a topic area. We’ve been creating InnerSource Patterns in the ISC since 2016; this work has been, perhaps by necessity, somewhat fragmented. We’ve discovered, for instance that there are different flavors of InnerSource and multiple dimensions along which InnerSource programs might be described. This presentation shares some insights around InnerSource pattern languages, what they might look like, how they might be used and how they might be created.

During the last months a set of companies in Spain have been working on a maturity model to give a general framework for C-level and other areas of work in InnerSource.
This talk will present some internal discussion around the topic of the maturity model and a potential implementation based on the main InnerSource principles such as Collaboration or Transparency. In addition to this, it is expected to open some discussion around the topic of this type of models that are usually initiated as a set of good practices, but at the end they are seen as pure bureaocracy within organizations.

The Siemens Inner Source platform started as a way for one division to maintain a standard stack across its product range. From these beginnings, it quickly grew into something much bigger: A state-of-the-art development environment, a tool to build platforms within the company. It also became a highly visible example for a collaborative, agile way of working within Siemens. In this keynote, we will review the platform´s history and the key reasons for its success so far, as well as challenges past and present.

InnerSource – what we call Bosch Internal Open Source (BIOS) internally – is a great tool for a variety of use cases in a corporate setup. One of them being internal tooling were we think InnerSource is quite a natural fit. Thanks to our constant efforts of pushing BIOS forward over the last nine years we’re finally able to convince the corporate sector IT at Bosch to start the adoption of InnerSource. The first internal tool which will become a BIOS project is the so-called Open Source Desktop (OSD), a Linux based OS altenative for Bosch associates. Apart from providing details on the first steps we took, we will also give some insights on the preconditions which are key for a successful InnerSource project and give a brief overview about the areas where OSD is used within Bosch.

Those of us establishing InnerSource programs encounter similar problems. Developing Patterns is a way of capturing proven solutions to these problems. Let’s work together and provide solutions for the larger community! This workshop will provide a brief introduction of the InnerSource patterns, and the standard components of patterns. Then we’ll break out into groups to draft patterns for pervasive problems. Attendees: If you’ve got a problem that you’d like us to cover in the workshop, let us know in advance! Email: erin.bank@ca.com

Inner sourcing at NOKIA core networks and the people seemed like a match made in heaven. For the senior management, it is a R&D Efficiency program. For developers, it is an opportunity to express themselves. The journey had its share of successes and failures that made us to do several course corrections on the way. Soon the fantasy of inner sourcing/reuse and the expectations of delivering on the corporate targets had its own ways of coming together. The honey moon was soon over and we had the onerous task of making that heady cocktail, just the right mix between the open source dare and the corporate flair. We are still looking for that elusive mix… This talk will explore the things that worked, things that didn’t, people aspirations, frustrations

In open source, projects often differ significantly from one another. Consequently, it is no surprise that inner source projects and even programs can have a variety of different shapes as well. When adopting inner source by founding a new inner source program, or even when managing the evolution of an existing initiative, it is crucial to understand what different shapes (classes) of inner source projects and programs exist. In this talk, we present a classification framework laying out different classes of inner source projects and programs. We apply the framework to eleven companies doing IS and discuss differences of their inner source programs. The presented classification framework is the first of its kind to classify and structure the space of existing inner source program. After hearing this talk, you will be able to apply the framework to your own company.

Data scientists are not developers. And yet, they are constantly writing source code. Writing software is complex, even more so in the domain of data science. Software Engineering is the reification of decades of failures and successes on delivering software products. Perhaps open source is one of the most paradigmatic cases: with innovative practices, we have seen how globally distributed teams, mixtures of paid and volunteer developers, reusing tens of pieces of code, have been consistently delivering high quality software. What can data science learn from Software Engineering and Open Source? In this talk, we will show how data science teams can learn from Software Engineering and Open Source, to embrace an Inner Source approach, to reuse code and results and to deliver high quality results, that are easier to promote to production.

Everybody can install a software forge, prescribe that “we are doing inner source now” and call it a success by definition. Many go a step further and even start to measure metrics about its effectiveness. Metrics are tricky though, they often just frustrate developers, are easy to game and very rarely tie back to anything the business understands – cyclomatic complexity and KLOC anyone? This talk will propose some metrics used by a venture capital fund that manages companies like Docker, Twitter, Blabla Car and Hello Fresh to measure the success of their investments. We will show the economic impact of those metrics on concrete examples of their application at large companies like Allianz, Continental and Zalando. As many of those metrics have to do with the application of inner source (open source in the boundaries of enterprises), we will also demystify the probably greatest misperception about inner source which is hampering especially middle management to adopt it – the fear that every developer from now on just does whatever he or she wants.

Inner source is the application of open source methodologies to internally-developed software. While simple to define, inner source can be difficult to explain and implement successfully. This presentation introduces the key terms, concepts, and principles for effective inner sourcing along with explanations and real examples. It is content that is accessible to newcomers while at the same time refreshing to those with experience. The same information in this presentation is also delivered as an O’Reilly Oriole, available freely at https://www.safaribooksonline.com/oriole/. We’ll review the Oriole, how to use it, and other Orioles related to inner source that are on the way.