According to Wikipedia, “a chief programmer team is a programming team organized in a star around a “chief” role, granted to the software engineer who understands the system’s intentions the best. Other team members get supporting roles.” Amusingly, this set-up is alive and well in academia, and for good reason. At least my research group is using it and it works well for us.
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, you are not delivering a product, and every time you hear product, you need to think artifact.
The confusion is worst when we talk about a product vision. As always, there are many competing definitions and confused ones at that, but we can safely assume that a product vision is at least a particular type of vision. About a vision, by definition, we know that it is time-less. It describes an abstract future state that we want to achieve, but never actually can reach. As such, a vision serves as a guiding north star for the decisions we make about on-going work. IBM’s vision is (shortened) “client success”, SAP’s is “improved economy”, etc. Any number of management books expound on what a vision is so you can read more there.
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. A product, in contrast, is an artifact (not an undertaking) that is born but typically has no planned end date. Most vendors, selling products to a market, hope they can do this forever.
The terms project and product are used with continued confusion. Both open source and agile methods are particularly bad offenders, leading people astray. Adapted straight from the textbooks:
- A project is a human undertaking with the goal of creating an artifact. Its life-cycle is determined by a start date and an end date.
- A product is a human-made artifact for a market of customers with an open-ended llfe-cycle. It is born with no end date in sight.
Not always, but typically, a project is used to create a custom artifact, while a product is (by definition) made for a market, that is, many different customers.
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.
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.
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.
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.
In three previous posts I had reported about our research into problems with product line engineering. Three important specific problems (of several more) were:
- Lack of resources in the platform organizational unit
- Insufficient collaboration between product and platform unit
- Political power play between product units
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.