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 company boundaries is a taxable event that you need to deal with: It is not a choice.
Let me take it in steps.
Continue reading “Internal Component Marketplaces vs. Transfer Pricing of Inner Source”
Open source license compliance is not for the faint of heart. Among many things, a company needs to tell the recipients of a distribution which open source software is used in their products. In the case of mobile apps, free or not, the user is the recipient and the app is the distribution. Downloading an app from the app store makes me a user. Lets see what we can learn about open source using an example app.
The following four screenshots show how I made my way from finding an app through installing and starting it. I could not find any information about the distributed open source code along the way.
Continue reading “Open Source License Compliance in Free Mobile Apps”
This is obviously wrong. The use of dual licensing and the ability to provide superior service for open source are unrelated forms of competitive advantage, and without further circumstances, a business should exploit both advantages. Let me explain.
Dual (or multiple) licensing is a strategy, in which a company develops software, releases it under an aggressively reciprocal (“viral”) license like the AGPLv3 and then offers commercial customers who don’t like the open source license the option to acquire a proprietary license for the software. This is a positional advantage of the vendor, because it is the only company that can apply this strategy (courtesy of being the copyright holder). While I mix things up a bit, it is closely related to what’s been called the open core model or single vendor open source. To maintain this positional advantage, vendors need to follow the commercial open source intellectual property rights imperative.
Continue reading “Some Argue That Dual-Licensing in Commercial Open Source Indicates a Lack of Ability to Provide Superior Service”
You may have seen the video below by Boston Dynamics. It shows a robot dog dancing to Uptown Funk by Bruno Mars. It is fun and funny to watch, but people also expressed serious worries about robot inroads into human behavior. However, there is no explanation by Boston Dynamics and it is not at all clear whether this is a simple magic trick created to fool the onlookers or real artificial intelligence (AI) progress.
Continue reading “The Dancing Robot Dog: Magic Trick or Real Artificial Intelligence?”
Update 2018-10-16: MongoDB is facing the same problem and decided to go closed source, see the press release.
The brouhaha around Redis Labs taking some enterprise modules of its popular open source in-memory database Redis closed source has somewhat calmed down. However, I didn’t see any discussion of what I thought was the most interesting conclusion of the affair: A core strategy of commercial open source,
the dual-licensing of the software under an aggressive copyleft and a commercial license may not work when cloud providers are involved.
Continue reading “Commercial Open Source in the Cloud”
Much open source research assumes that all open source projects are alike and that if you take enough of them, you can claim generalizability for your conclusions. GitHub is the main source of such mischief, because of its size and availability.
If GitHub was like Berlin, and projects on GitHub were like the people of Berlin, then treating all projects the same is like saying that a person from Mitte is like a person from Kreuzberg is like a person from Spandau.
Continue reading “If GitHub Was Like Berlin…”
One of the most difficult aspects of Scrum is the role of the product owner. Most software vendors have a product management function, typically split into strategic and technical product management. Technical product management is usually equated with Scrum’s product owner role, that is, the guy or gal who writes business-value-oriented user stories and epics, grooms the product backlog, and then some. This is separate from breaking down business-oriented features into technical tasks, which is left to the engineering team.
The problem: A person who can do this well is hard to find. It is easy, though, to find someone who believes they can be a good product owner. In practice, most successful software vendors I have seen have a business-oriented strategic product manager for a given product or major component, and have a senior engineer play the product owner role, reaching all the way into product development, that is, not only writing users stories but also breaking them down into tasks.
I’m a strong believer in product management. It is the most critical function in product development. It took me many years to accept that good Scrum product owners cannot be groomed from MBA or other business-oriented degree programs. Almost always will you need someone with a technical background to fill that role or it will go off the rails. However, there are really few people who’d like to take on that job; they’d rather be programming. Therefore, you’ll have to ask a senior engineer or other engineering leader to collaborate with the strategic product manager and turn the roadmap into features that can go into a product backlog.
So, as I said there rarely is a (stand-alone) Scrum product owner; usually it is a senior engineer adding to their busy schedule to make things work out.
Agile methods reacquainted developers with the idea of working from business value rather than focusing on technical concerns only. Agile methods are therefore often equated with feature-driven development, in which work is driven by features prioritized by business value irrespective of technical consequences. This thinking can create code silos and wreak havoc on software architecture and component quality. Developer complaints are legion, in particular for never getting the time to fix things or do them right in the first place.
Continue reading “Agile Feature Teams vs. Inner Source”
Abstract: User experience design is an important part of software product development, and yet software product line engineering has largely ignored this topic. This paper presents a set of industry best practices for user experience design in software product lines. We conducted multiple-case case study research using two different product lines within the multinational company Siemens AG: in a healthcare software division and in an industrial automation software division. We performed a preliminary exploratory study that will serve as a baseline for future research in the design, implementation, and management of user experience design in the context of software product lines. Practitioners can use our findings and the resulting best practices to improve their user experience design, particularly within
healthcare and industrial automation software product lines.
Keywords: User experience design, UXD, user interface design, software product lines, SPL, engineering best practices, case study research, handbook method
Reference: Nikolay Harutyunyan, Dirk Riehle. “User Experience Design in Software Product Lines.” In Proceedings of the 52nd Hawaii International Conference on System Sciences (HICSS 2019), to appear.
The paper is available as a PDF file.