Spring Summit 2019

Details appearing shortly

I will share the story of InnerSource at Bosch, which started about a decade ago. In my talk, I will share interesting details about the beginnings and the evolution of InnerSource at Bosch as well as many lessons that we learned along the way.

Thales Inner Source Software (TISS) Community is born from the Thales Digital Transformation call for initiatives in 2016. As key differentiator with previous tentative to promote source code sharing and reuse, it has been designed from the beginning to tackle key aspects of the Open collaboration: legal, tools and cultural change. Today, this community is organized like an “internal” open source foundation and is continuously growing within the company. Thomas Froment, as leader of the Community, will present his feedback from experience, enlightening how they are trying to implement Inner Source in this multinational company (65 000 employees, including 25 000 engineers over 56 countries). Key topics that will be addressed: Governance, Legal, Tooling, Promotion & Incentives, transparently sharing about successes, failures, open issues and the challenges they are facing in 2019 for scaling TISS at the group level.

Collaborative practices are adopted naturally by participants in today’s open source projects. Many people in IT culture have been ‘raised’ with teamwork and open communication as an integral part of open source culture. Not so for the giants that with their strides make bigger steps, but at the same time find themselves reluctant to change. It is not uncommon during an InnerSource implementation to see the industrial habituated patterns rear their ugly head. Humans can be exceptionally creative in both positive and negative ways. Just as different motivations propel human ingenuity forward, equally they can hold us back. What are the possible reasons behind your InnerSource losing traction and what we can do the get things back on track?

Red Hat, the world’s leading provider of Open Source Enterprise solutions, has open sourced an assessment tool, called Open Source Maturity Assessment (OSMA), to allow organisations to understand their current maturity regarding their knowledge, adoption and ability to effectively utilize Open Source / Inner Source technologies within their organisation. The assessment poses a number of questions with multiple choice answers around the following key areas: Business Goals, General Knowledge of Open Source, Development Standards and Tools, Upstream Community Participation, Governance & Legal Policies and Senior Management Support. The results of the assessment are used as a starting point to give an organisation a better understanding of their business goals regarding Open Source / Inner Source software and methodologies, the focus areas to address (under the areas of consume, contribute, create and strategy/governance) and recommended next steps. During this workshop, we will:

• Have each individual attendee run through the assessment tool to determine their organisation’s maturity
• Analyse the results to highlight areas for an organisation to focus on
• Hold an open discussion on organisation maturity, including issues encountered and ways to increase the maturity level The assessment itself is Open Source and the code can be found at https://github.com/boogiespook/osma.

It is a simple LAMP stack, allowing questions and responses to be customised for an organisation. The maturity tool has been presented and then used by a number of organisations, large and small, to help them understand where they are on their Open Source journey.

This presentation covers InnerSource Discovery Phase at Zalando and best practices that are currently adopted throughout the company.

When Elbit Systems launched its InnerSource program, it decided to drive cultural change through gamification. Shelly Nizri offers an overview of the Software Guild, an innovative gamification approach to increase engagement and encourage collaboration in the organization. Join in to learn how the company prevailed despite humble resources and conquered all challenges in the spirit of InnerSource

So you have decided that Inner Source is the way to go for your enterprise. Good for you! The rest is just a piece of cake. You only need to explain to your employees what this is all about. Oh yeah, and talk to the people from corporate tax, should be no problem, you know a guy there. Then get the legal department to answer some simple questions, and off you go! Ok, tooling is an issue, too. And governance… Alright, so you haven’t thought about all the minor details, but you just get everybody’s attention and spread the word. Easy! Right?!? Well, let me talk a little bit about our journey at Daimler TSS. We haven’t solved everything yet, but we’re on a good path, and maybe our experience can help you a bit, too.

GitHub is the platform on which most Open Source Software is written; generating massive amounts of value by connecting developers across the globe to work on some of the most ambitious problems. Understandably, businesses wanted to join that network and reproduce it within their own organizations as InnerSource. These same businesses are now struggling to find workflows that that are flexible enough to evolve with their corporations and the ever-changing way that Open Source is developed. GitHub has a vision of helping Enterprises implement InnerSource practices by investing and building upon their networks while keeping customer data and business practices secure.

Join Brent Beer while he shares some of GitHub’s recent successes and plans for the future.

One of the main questions that any company willing to try InnerSource is how this can be integrated with their current way of developing. Even more, some of them have recently started with Agile and this may be seen as ‘yet another software development approach’. Agile and InnerSource are defined in both cases and [e.g.: in the Wikipedia] as software development practices. However it seems that it is still not clear how each of them can complement the other. This talk aims at bringing on the table some thoughts on how Agile is being used by some large corporations, and how InnerSource is being applied by some others. We do not aim at stating facts, but at opening a fruitful discussion with the audience with the goal of bringing more uses cases and sharing experiences among the attendees.

How do you bring a legacy Enterprise Resource Planning (ERP) to “The Cloud”, with the promise of enabling new business models and reducing costs? How do you tackle an enormous technical and organizational debt accumulated over decades? How do you initiate a radical transformation and how do you put people in motion? These are the challenges that the newly hired CTO of a business unit within Softplan, large Brazilian company, accepted a couple of years ago. In this talk, we explain how we had the opportunity to work with the CTO, and to support hims with a data-driven approach. After introducing the notion of software analytics, we explain how we have used metrics first to diagnose the problems, and then to support a continuous improvement process. We review a series of specific experiments done in this context, discussing both successes and challenges. We emphasize the human aspects of the transition and explain how metrics can be powerful when it comes to trigger conversations and to drive behavior change. We explain how our initial recommendations were to inspire teams to adopt practices that can be seen “in action” on GitHub. When we embarked on this journey, we did not know about the InnerSource Commons. Nevertheless, some of the problems that we encountered are very similar to those enlisted in the Patterns Catalog. In the talk, we map our experiments to problems described in the catalog. We compare our solutions to those embodied in the patterns.

During the last InnerSource Commons and Patterns sessions, there have been a set of issues raised by the community. Those are related to the discoverability, findability, awareness, documentation, and others. In this talk, Kristof Van Tomme and Daniel Izquierdo will discuss the use of a Developer Portal as a way to centralize and deal with all of these related patterns. After the introduction we will split out into discussion groups to work on key patterns that the audience believes need to be included in most innersourcing portals.

Over the last 10 years, Red Hat Consulting has offered services around open source process and culture, alongside its normal technology based offerings. Whilst Red Hat is an Enterprise software solutions company, it also is the leading proponent of how open source works and why it produces good software, using a community powered approach. This paper discusses: If it is possible, open source should be considered in favour of inner source as an approach for an organisation If Inner Source is the only option, what should be considered during this phase of a project

An informal, but hopefully informative, presentation on the challenges of implementing InnerSource at a medium-sized, non-technical company. Harvard Business Publishing’s mission is to improve the practice of management in a changing world, and our areas of focus are in publishing and learning pedagogies. We thoughtfully recognize that while we are not a “technology” company, we treat software engineering as a core competency that can make or break our strategy. Adopting InnerSource was seen as a key component in our long term plans but fell far short of our expectations. We’d like to share our experience not as an any inherent indictment of InnerSource but as cautionary tale of intent and aspiration versus every day and unexciting, but very real, constraints.

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. Many engineers lack background in open source and the ideas and mechanics of open code development. Even those with that background face a new set of constraints and motivations when trying to work openly within the enterprise. The Inner Source Learning path gives a simple, easy to understand introduction to inner source. It introduces key terms, concepts, and principles for effective inner sourcing along with explanations and real examples. It is intended to bring newcomers up to speed as well as provide those with experience a common vocabulary to use when discussing more advanced concepts. The Inner Source Learning path will be freely hosted by O’Reilly Media at https://www.safaribooksonline.com/learning-paths for your use and sharing. In this session we’ll review the content of the learning path and how you can use and share it.

Crowdsourcing is emerging as an alternative outsourcing strategy which is gaining increasing attention in the software engineering community. However, crowdsourcing software development involves complex tasks which differ significantly from the micro-tasks that can be found on crowdsourcing platforms such as Amazon Mechanical Turk—the latter are much shorter in duration, and typically very simple and do not involve any task interdependencies. To achieve the potential benefits of crowdsourcing in the software development context, companies need to understand how this strategy works, what challenges arise, and what factors might affect crowd participation. Research to date on crowdsourcing software development has tended to focus on the ‘crowd’ or the technical platform, with little research from the perspective of the customer who is seeking to leverage the crowdsourcing development model. The findings from an in-depth case study of crowd-sourcing software development in a Fortune 500 company are augmented with an analysis of over 13,000 crowdsourcing competitions over a ten-year period on the Topcoder crowdsourcing platform, one of the most popular platforms for software development, are drawn on to evaluate the effectiveness of crowdsourcing in a software development context.

Metrics are an important part of the InnerSource journey. The InnerSource Commons has been a great place for discussion around the topic. Specifically the InnerSource Patterns community delivered a pattern focused on first steps with metrics [1] where no specific metrics are detailed, but this gives a starting point to discuss when, how and what to measure. This talk aims at detailing these set of metrics and KPIs for further discussion across the community. This is based on work in progress in the GrimoireLab/CHAOSS community, a Linux Foundation Project. The proposed set of metrics are split into three main areas: Activity, Community and Process. [1] https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/introducing-metrics-in-innersource.md

Details appearing shortly

Culture is hard to describe, and even harder to emulate. So how do you even start to establish an open source-like culture? What are the underlying principles on which these cultures are built? For the past 13 years, I’ve been reading and thinking about these questions, trying to understand what makes some open source projects succeed and causes others to fail. In this talk I want to introduce 7 mental models and surprising insights that I have adopted along te way that have transformed the way I think about business. I will present the insights together with references to the books from which they were derived, and explain why I believe they can help an organisation to build an open source-like culture.