Dirk Riehle's Industry and Research Publications

Category: 2. Building Products

  • Upcoming talk on industry best practices for corporate open source governance of software supply chains at UC Santa Cruz

    Upcoming talk on industry best practices for corporate open source governance of software supply chains at UC Santa Cruz

    Abstract Almost all software products today incorporate open source software either directly or through software supply chains, but many companies are not properly governing their use of open source, incurring potential risks. Since 2016, I have been researching industry best practices and processes around open source governance, focusing on software supply chains. I have interviewed…

  • Scrum’s product vision vs. project mission

    Scrum’s product vision vs. project mission

    As noted previously, Scrum uses the term product to mean artifact. This is fine, as long as the user of Scrum is a software vendor, developing a product for a market. It is confusing, however, if the user is a consulting firm, performing a custom project for a client. If you are a consulting firm,…

  • How project vs. product confuses agile methods terminology

    How project vs. product confuses agile methods terminology

    In a previous blog post I noted how the terms project and product are being confused in open source. However, it is agile methods, specifically Scrum, where it gets really bad. To recap: A project is a human undertaking to create an artifact. A project, by definition, has a start date and an end date.…

  • How UML is actually used (if it is used)

    How UML is actually used (if it is used)

    When I started our software architecture course about eight years ago, I was happy to find out about a book series on the architecture of open source applications. I was thrilled: Not only code, but architecture descriptions! I expected great material for my course. Sadly, I had to realize that none of the chapters in…

  • Internal component marketplaces vs. transfer pricing of inner source

    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…

  • How not to refactor your code

    How not to refactor your code