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 55)”
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”
The house magazine of IAV Automotive Engineering GmbH, a major supplier to the German automotive industry, which had interviewed Markus Blonn and me about open source and inner source at IAV, translated the magazine article into English, woohoo!
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 escalate and grow your ambition for inner source projects? I see a 1 + 3 structure of levels.Continue reading “Escalating Levels of Complexity in Inner Source Projects”