Posted on

CTO vs. VP of Engineering

In tech companies, startups and large companies alike, of the many roles you need to define, two seem to be particularly confusing to German startups: The CTO and the VP of Engineering role. Many German startups I’ve seen simply have a person titled CTO who does both (and sometimes neither). These two roles are very different! They require different skill sets and while temporarily one person may be able to fill both shoes, longer term they are better filled by two different people. In more detail:

Continue reading “CTO vs. VP of Engineering”
Posted on

The Argument For a Moral Machine in Autonomous Driving

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.

Continue reading “The Argument For a Moral Machine in Autonomous Driving”

Posted on

Too Many Points of Failure (at Theranos)

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.

Continue reading “Too Many Points of Failure (at Theranos)”

Posted on

Why Do Episodic Volunteers Stay in FLOSS Communities?

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.

Posted on

Should The Public Sector Use Open Source Software? 1/4

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”
Posted on

What Software Vendors Don’t Seem to Understand About University Teaching

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”
Posted on

The Uni1 Project (2016)

Abstract: The aim of this project outline is to describe how universities and other higher education institutions (HEIs) can work with businesses to conduct teaching projects for and with students. Both parties stand to benefit; the projects generate recruitment, outsourcing and innovation (ROI) for businesses and provide HEIs with new partners for cooperation, a source of funds, and a boost to the attractiveness of their teaching.

Keywords: Industry university collaboration, research-to-industry transfer, business model, teaching

Reference: Dirk Riehle. “The Uni1 Project (2016).” Friedrich-Alexander-Universität Erlangen-Nürnberg, Dept. of Computer Science, Technical Report, CS-2018-05. Erlangen, Germany, 2018.

The report is available as a local PDF file and on FAU’s OPUS server.

Please note that this report is a translation to English (by FAU’s Sprachendienst) of the prior report Das Uni1 Projektkonzept (2016).

Posted on

How my Ph.D. Students Work With Supporting Students (Hint: Not Scrum)

As mentioned in a previous blog post, my Ph.D. students are often experienced software developers who take on the role of a chief programmer in the development of the software system supporting their research. In this work, at any point in time, each of my Ph.D. students is typically supported by 2-7 Bachelor and Master students who contribute to the system under development. Taking a long-term perspective, my Ph.D. students develop quality software rather than throw-away prototypes.

The chief programmer idea is key to making such work successful. While I usually conceive and direct the research, the size of my group has led me to let my Ph.D. students take care of any actual development themselves. (Usually…) In this role, as the chief programmer, they become the central point of coordination and integration of engineering work. In academia, this is a necessity, because an engineering dissertation is typically a multi-year project, while final thesis students, the main source of junior programmers supporting the chief engineer, are only around for six months. Thus, the chief programmer becomes the central technical hub and provider of sustained knowledge of the system under development.

Continue reading “How my Ph.D. Students Work With Supporting Students (Hint: Not Scrum)”