Most open source these days, certainly the most widely used open source, is developed by companies. Open source, by definition, is competitively non-differentiating, so companies can join forces in its development. To so do peacefully, however, they need good governance that preempts conflicts among the participating companies. Such governance is usually provided under the auspices of an open source foundation, of which the big three are the Apache Software Foundation, the Eclipse Foundation, and the Linux Foundation. Despite these existing foundations, many companies interested in developing a new open source software keep opting to create their own consortium.
I’m happy to report that the eigth article in the Open Source Expanded column of IEEE Computer has been published.
Managing Your Open Source Supply Chain—Why and How?
Open source, software supply chain
Nikolay Harutyunyan, Friedrich-Alexander-University Erlangen-Nürnberg
Computer vol. 53, no. 6 (June 2020), pp. 77-81.
Abstract: More than 90% of software products include open source components, most of which are not directly added by your own developers. Instead, they are an inseparable part of the software supply chains that virtually all companies depend on. This article covers the related risks of ungoverned open source use and provides industry best practices to practitioners.
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.
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.
Software product management is easily the least well understood yet most important business function in software companies. I have been teaching Software Product Management by Case for about ten years now, and it is time I change a gear or two. Hence, I’m asking whether anyone is interested in helping me teach this course, whether in small or large capacity. For details, please see this slide deck:
A main reason why I became a professor is to create and guide student startups, in general, and from my research projects in particular. It has been a bumpy ride, to say the least, but I guess, every learning curve is. Data points (startups) are still not plenty, but I can nevertheless discern some learnings. Without further ado, the usual bullet list of insights:
Learning is by person. Large companies can talk about organizational memory and capabilities building all they want, in a startup, knowledge walks in the door (and out) by person. A new person basically starts over and makes all the same mistakes the person they replace also made… two years later. So, avoid losing good people.
Today, Andreas (Andi) Bauer presented some of our work on managing open source dependencies in software products. Please watch the talk below (local copy). The presentation is based on the same-name research paper.
Today, Nikolay Harutyunyan presented some of our work on openKONSEQUENZ, a user-led open source consortium that develops software for local energy distributors. Below, please watch the talk (local copy); the talk is based on the same-name research paper.