Abstract: Inner source software development is the use of open source development’s best practices inside a company. In inner source, developers collaborate on reusable software components across company-internal organizational silo boundaries for mutual benefit. As such, inner source goes against the grain of traditional management techniques. In this article, we present two conceptual models of management accounting for inner source. We derived these prototypes by performing a literature review and triangulating the results with interviews of industry practitioners. We demonstrate how the conceptual models can be used for monitoring and controlling inner source projects and to determine their future viability.Continue reading “Management Accounting Concepts for Inner Source Software Engineering [ICSOB 2022]”
Abstract: Inner source is the use of open-source practices within companies. It enables more efficient software development, shortens time-to-market, and lowers costs through increased company-internal collaboration. While existing studies examine social and organizational impact factors on inner source adoption, only a few have looked at measuring and economically assessing inner source. This article presents an overview of current research regarding inner source, its measurement, economic assessment, and impact on businesses and their processes. Based on a systematic literature review we build a research model for economic inner source assessment. This research model shows thematic dependencies between the economic impact of inner source and its measurement. Additionally, it proposes research questions and hypotheses on measuring, economically assessing, and subsequently adopting inner source.Continue reading “A Research Model for the Economic Assessment of Inner Source Software Development [HICSS 2023]”
Abstract: A key part of taxation, controlling, and management of international collaborative programming workflows is determining the costs of a supplied software artifact. The OECD suggests the use of the Cost Plus method for calculating these costs. However, in the past, this method has been implemented using only coarse-grain data from the costs of whole organizational units. Due to the move to inner source software development, we need a much more fine-grain solution for computing the detailed time spent on programming specific components. This is necessary, because a more accurate work time distribution is required to fulfill the fiscal and administrative challenges posed by collaborating across organizational boundaries. In this article, we present a novel method to determine the time spent on an individual code contribution (commit) to a software component for use within cost calculation, especially for taxation purposes. We demonstrate the usefulness of our approach by application to a real-world data set gathered at a large multi-national corporation. We evaluate our work through feedback received from this corporation and from the German Ministry of Finance.Continue reading “Calculating the Costs of Inner Source Collaboration by Computing the Time Worked [HICSS 2022]”
Inner source is the use of open source practices within companies. Engineers generally love it, but any open-source-style collaboration across business unit boundaries will usually get stopped dead in its tracks by the financial compliance department. That’s because financial compliance is likely to worry that to the tax authorities such inner source collaboration will look like attempts at profit shifting.
Below, please find a 20min. presentation on inner source and transfer pricing that I prepared for a workshop at the German Ministry of Finance. It is aimed at non-technical people.
You can also skim the slides, though the video offers significantly more information. Feel free to shoot any questions you might have my way.
In 2006, we set-up SAP forge to make finding and collaborating on inner source projects easy. The advice of how to design a forge or portal for this purpose hasn’t really changed over the years. The most important advice is:
Make the forge available at one place (and one place only) with a memorable URL like forge.acme.corp
The second most important advice is on the design of the home page of the forge. There are a couple of independent mechanisms that should be present. In order of descending importance (read: prominence of screen real estate given):Continue reading “How to Make Finding Inner Source Projects Easy”
Eberhard Wolff just published the recording of my lunch chat on Software Architektur TV with him. Our topic was inner source and how to tear down firm-internal silos for better code reuse, more knowledge sharing, and generally more satisfied employees. Check it out below (local copy) or visit Eberhard’s site for it!
Or, just take a look at @teapot4181‘s fabulous visual summary.Continue reading “Video for Breaking Down Organizational Silos with Inner Source (in German)”
This coming Friday, December 11th, 2020, at noon CET, I’ll be a guest in Eberhard Wolff’s Software Architektur lunch chat. Our topic is how to break down organizational silos using open source methods, which is, you guessed it, using inner source. Join me through Software Architektur TV and send us your questions in advance (or live)!
Slowly but surely, non-software vendors have been waking up to realize that Silicon Valley, specifically, software vendors, are out to eat their lunch. In 2011, Marc Andreessen stated that software is eating the world, in 2015, Geoffrey Immelt said that GE is in the information business, and now in 2020, Volkswagen declared itself to be(come) a software-driven automobile vendor. However, this is more easily said than done, and the path to taking charge of your software future is fraught with possibly serious mistakes. One such mistake is to create your own internal software organisation. A better choice is to leave developers close to the products, but set-up an inner source program to connect them across the organization. Let me revisit this topic.Continue reading “How Non-Software Vendors Fail and How Inner Source Can Help”
Most corporate compliance departments believe developer collaboration in inner source projects is like shipping boxes with stuff (products) between the involved parties, for example, companies in a holding. Therefore, they don’t have to change anything about tax accounting and transfer pricing.
They couldn’t be more wrong.Continue reading “Is Inner Source Collaboration Like Shipping Boxes Between Companies? (Hint: No!!)”
Inner source is the use of open source best practices inside companies to develop shared components for use in the company’s products. Inner source software doesn’t have to become open source (but might). Like open source software development, inner source software development is inherently asynchronous, distributed, and multi-timezone.
Inner source is a match made in heaven for the new world of work-from-home.
All signals are clear: Many people love working from home, and developers are no exception. They will only return to the office, if forced, and it will come with a price for the company. Hence, those companies will be better off which can make work-from-home work out for their developers. This is in clear conflict with agile methods practices of co-location, regular stand-ups, etc.Continue reading “Inner Source and Work-from-Home”