I have a strong aversion against letting people drag their feet from being responsible for their actions. I feel particularly strongly about this when delegating work to machines, which are not able to act using an appropriate moral value system. Starting a car and letting an autonomous driving unit take over is one such example: When faced with an impossible situation (run over an old lady or three children or commit suicide), it still has to be the driver’s decision and not a machine’s.
Ever since autonomous driving became a hot topic, I’ve tried to sell to our automotive industry partners the idea of a project to build a moral machine in autonomous driving. My definition of a moral machine (there are others) is:
I just finished reading John Carreyrou’s book Bad Blood, which presents the story of the rise and fall of one-time Silicon Valley unicorn Theranos through his eyes as the journalist who broke the story. In case you missed it: Theranos was a healthcare company promising to sell a machine that could perform quickly and reliably a large number of blood tests needed by medical doctors to aid their patient care. The hitch: The technology never worked and Theranos managed to hide this from investors and the public for a long time.
Abstract: Successful Free/Libre and Open Source Software (FLOSS) projects incorporate both habitual and infrequent, or episodic, contributors. Using the concept of episodic volunteering (EV) from the general volunteering literature, we derive a model consisting of five key constructs that we hypothesize affect episodic volunteers’ retention in FLOSS communities. To evaluate the model we conducted a survey and received responses from over 100 FLOSS episodic volunteers. We observe that three of the constructs (social norms, satisfaction and community commitment) are all positively associated with volunteers’ intention to remain, while the two other constructs (psychological sense of community and contributor benefit motivations) are not. Furthermore, exploratory clustering on unobserved heterogeneity suggests that there are four distinct categories of volunteers: satisfied, classic, social and obligated. Based on our findings, we offer suggestions for projects to incorporate and manage episodic volunteers, so as to better leverage this type of contributors and potentially improve projects’ sustainability.
Keywords: Community management, episodic volunteering, open source software, volunteer management
Reference: Barcomb, A., Stol KJ, Riehle, D., & Fitzgerald, B. (2019). Why Do Episodic Volunteers Stay in FLOSS Communities? In Proceedings of the 41st International Conference on Software Engineering (ICSE 2019), pp. 948-959.
The paper is available as a PDF file.
I was asked several questions by a journalist about open source and the public sector. I’m answering them here in sequence. This is the first of four blog posts and the first question was: Should the public sector use open source software?
The public sector and public governments should use the software that lets them provide the desired services best, long-term. How much open source software this involves is secondary, in my opinion.
That said: Like any industry, the public sector already uses substantial amounts of open source software by way of open source components built into commercial proprietary product. Estimates of the percentage of open source code in commercial products and services go as high as 80-90% of the total code. Open source is everywhere, including in Microsoft Windows and Office.Continue reading “Should The Public Sector Use Open Source Software? 1/4”
I often get approached by software vendors with the suggestion that I teach a course using one of their product tutorials. There are plenty of open source databases, operating systems, and cloud computing solutions who want to make it into my curriculum. Of course, vendors don’t always call their product tutorials by that name, but use labels like college-level courses or the like, but this doesn’t change the content: They are still product tutorials. I can’t teach those and no self-respecting professor will ever do this. Let me explain.Continue reading “What Software Vendors Don’t Seem to Understand About University Teaching”
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.