Category: 2.5 Inner Source
-
Escalating levels of complexity in inner source projects
Yesterday, I discussed what makes a good pilot project in inner source. The main thrust of the suggestion was not to start with a big bang but rather to choose a relevant but not too large project. This begs the question of complexity of projects, specifically viewed from an inner source perspective. How should you…
-
Getting Started With Inner Source
I received several requests recently for my inner source charter document to provide it in DOC format, after I thought this work had fallen dormant (or perhaps the PDF version was sufficient). So I wanted to add my thoughts on how to take first steps in inner source, in particular in the selection of a…
-
Open source and inner source at IAV (in German)
The house magazine of IAV Automotive Engineering GmbH, a major supplier to the German automotive industry, interviewed Markus Blonn and me about open source and inner source at IAV (in German). We had a good time as you can see 😉
-
Upcoming talk on ten years of inner source case studies at UC Santa Cruz
Abstract Inner sourcing is the use of open source best practices within companies to improve engineering productivity. In 2006, I introduced inner source to SAP. After becoming a professor, my group helped further companies introduce inner source to their engineering organizations. Using three generations of projects, we report about our experiences and how we are…
-
Internal component marketplaces vs. transfer pricing of inner source
I was recently asked why I argue against company-internal marketplaces for software components yet emphasize the need for pricing components that cross company boundaries within the same holding company (also known as transfer pricing). The answer is simple: Setting up an internal marketplace is a managerial choice and pricing the movement of code (IP) across…
-
Agile feature teams vs. inner source
Agile methods reacquainted developers with the idea of working from business value rather than focusing on technical concerns only. Agile methods are therefore often equated with feature-driven development, in which work is driven by features prioritized by business value irrespective of technical consequences. This thinking can create code silos and wreak havoc on software architecture…