Alistair Cockburn pointed us to an excellent article by Melissa Perri about the differences between a product manager and (Scrum) product owner. The article clarifies some confusion. I’d like to repeat and emphasize some points that have been omitted (and where I also disagree).
Foremost, a product manager works on products for a market (i.e. many customers). I have never seen a product manager work on a project with one customer. For a product owner this is undefined; they could be working on a product for a market or on a project for a specific customer.
Continue reading “Product manager vs. product owner”
My primary goal in becoming a professor was to turn my (hoped-for excellent) research and teaching into startups. For that reason I created the Startupinformatik program and set-up my teaching to support it. Sadly, I’ve been noticing over the years that things don’t seem to get easier but harder. Specifically, “the system” (I’ll explain below) seems to view professors with mistrust rather than as the natural allies they should be when it comes to leading students to create a startup.
Let me illustrate this using two experiences:
Continue reading “Professors and startups”
During my talk at the inner source summit, I was asked about the following worry with establishing inner source at a company:
But if we lay all source code open within the company, don’t we run the risk that a disgruntled employee has it too easy to steal all code and publish it on the web?
The main answer to this question is to weigh benefits against risks. The benefits of inner source have been explained elsewhere, for example, in said talk of mine. The risks may seem less clear. So, could it happen that an employee steals all source code? What damage would it do?
Continue reading “But what if someone steals my inner source code?”
According to my hosts, this object took 34h to print.
I’m seeking advice on how to frame the research question for a research project (Ph.D. thesis) on software product management and open source. The simple heuristic “non-differentiating -> open source it, competitively differentating -> keep it closed” doesn’t cut it because of secondary effects like development efficiency resulting from open sourcing, market opportunities resulting from platform compatiblity, etc.
The best I could come up with so far are three different but related questions. These are:
- For a non-differentiating function, which open source component to use?
- For a chosen open source component, how to manage this dependency?
- For a competitively differentiating function, when to open source?
Questions 1 and 2 are well-defined. Question 3 remains unwieldy. The heuristic mentioned above would answer “never”, but this is not true, as explained. Overall competitive situation and compatibility considerations may still lead to open sourcing unique intellectual property.
I’m seeking comments as to how practitioners (or other researchers) would look at this question. Any comments are appreciated.
John Mark Walker, in a thread started by Matt Asay, nudged me to provide my opinion on the subject matter. Here we go as a Twitter thread. (I’m trying out Twitter collections and threading for the first time; advice on how to do it better is appreciated.)
I presented on open source foundations earlier this week to economist friends at TU Munich. I naturally got the question about freeriding: Why does anyone contribute to open source projects, if they could do something else with their time? The cinch: This time we are talking about companies, not invididual people, so the arguments about altruism and signaling don’t apply. So, why do companies contribute and don’t just freeride?
I don’t think this question has been answered well yet in economics, and I’m not sure established theory has a ready answer.
To make it short: I believe the most direct reason why companies contribute to open source projects is to lower their cost of consumption of that very project. Specifically, contributing to a project builds competence in that project, and employing committers builds additional foresight and influence. General compentence makes the company use the software more effectively, avoiding costly bugs and rework. Foresight and influence helps the company avoid misalignment of their products with the evolving open source software they depend on. Such misalignment can also lead to costly rework and missed market opportunities.
I’m not aware of any RoI model that helps an engineering manager determine how much to contribute to achieve how much lower consumption costs and risks. Because of the step function from contributor to committer status for the involved employees, the investment return is not a linear function, that much we can say. The rest remains imperfect science for now.
Continue reading “Why companies don’t always freeride on open source projects”
A friend’s post alerted me to the potential overreach of copyright and commercial law when it comes to the human body. The particular post was about tattoo artists who tried to make money of sport professionals who had integrated the tattoos into their professional persona: The company who had bought the tattoo artists’ designs claims that the copyright to the art extends to the performances of professionals showing the art. Hence they wanted money for any performance, here as part of the professionals appearing in video games.
It is easy to extend this to high-tech. The consequences could be dire, if the enhanced human body would become subject to overreaching intellectual property rights held by companies. Imagine a pacemaker for your heart that has only been licensed to you and you lack the necessary data and rights to make it work over time. I’m sure some company will come up with a pacemaker that needs to get a license key every year or so from the company’s license server. Would the company let the person die, if he or she fails to pay the annual license fee? In case you wonder whether anyone would accept such a pacemaker into their heart (pun intended): Just imagine being poor enough to not be able to pay for the medical procedure. Or imagine requiring a particularly innovative pacemaker function that only this one manufacturer offers and you can’t pay for the perpetual license.
If this seems far-fetched, you should note that this is already happening in other contexts. For example, John Deere, a leading manufacturer of tractors and other farming equipment is only leasing its tractors and the software to farmers. John Deere argues that farmers don’t own the tractor and its data any longer, John Deere remains the owner. As a consequence, all data from the farmers’ tractors is planned to end up in John Deere data centers and farmers who don’t keep paying might be cut of their equipment and its data.
The Internet and interconnectedness is making it happen. It is indeed time to clarify ownership and limits of ownership, in particular when it comes to the human body and its rights. Indeed an interesting time for lawyers (and everyone else).