Dirk Riehle's Industry and Research Publications

Is inner source collaboration like shipping boxes between companies? (Hint: No!!)

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.

At the highest superficial level, it appears they may be right. After all, if a developer from company A in holding company G makes a code contribution to an inner source project hosted by company B in the holding, they are just shipping code, aren’t they? Slap a price on it, aggregate it over time, and tax liability be gone! Well, at least documented and predictable.

Let me explain how this approach is wrong by explaining what is actually going on in inner source collaboration between the involved parties. On the left side of the following table, you can see the steps in inner source collaboration that lead up to a code contribution. On the right, I’m trying to map it to the analogy of shipping boxes.

#Inner source collaborationShipping boxes
1.A developer would like to make a contribution and explains it to the project community on a mailing list. This is to avoid redundant work and make sure the future contribution fits into the project roadmap.The box provider declares to the receiver that they will soon receive a box.
2.The contributor starts their work. A large code dump on the project will invariably be rejected, so the smart contributor breaks down their work into small contributions that they submit to the project in steps.The box provider manufactures the box and its content as a whole.
3.The contributor discusses their contribution with a project committer, refining and adjusting the design. Both sides perform intellectual work as they discuss the design and source code.The provider ships the box to its receiver.
4.The contributor loops over submitting incremental patches (merge requests) and a committer reviews them, rejecting or accepting them. This review and integration work of the committer can be substantial.The receiver checks the content of the box.
5.The internal tax accountant accounts for the provision of the intellectual property.The provider invoices the receiver and is paid.

I formatted in bold the critical differences: In inner source software development, the involved parties loop over steps 2-4 many times a day. Ownership of the intellectual property is distributed over the involved parties. Boxes, in contrast, are manufactured and shipped once and ownership of the intellectual property is clearly allocated and paid for.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.



Share the joy

Share on LinkedIn

Share by email

Share on X (Twitter)

Share on WhatsApp

Featured startups

QDAcity makes qualitative research and qualitative data analysis fun and easy.
EDITIVE makes inter- and intra-company document collaboration more effective.

Featured projects

Making free and open data easy, safe, and reliable to use
Bringing business intelligence to engineering management
Making open source in products easy, safe, and fun to use