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).

The paper is available as a PDF file.

IAV Presents Side-window Entertainment at CES 2019, a 2017/18 AMOS Project

At CES 2019, IAV, a German automotive engineering firm, presented the side-window entertainment showcase. In this demo, you can see users interact with the side-window of a car. A camera records the view out of the window, another camera tracks the passenger’s focus, and a transparent OLED display overlaid on top of the window both shows the passenger interesting location-sensitive content as well as interacts with them. Below, please see a demo video and/or read the article (in German). The first version of the software was developed by students of TU Berlin in a 2017/18 AMOS Project.

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)”

Chief Programmer Teams Alive And Well in Academia

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.

Continue reading “Chief Programmer Teams Alive And Well in Academia”

Upcoming Industry Talk on Scaled Agile to Support the “Digital Transformation” in the Financial Services Industry by Munir Mahrufi and Sahar Khaksar of Deloitte Consulting GmbH

We will host an industry talk on “Scaling Scrum” in AMOS, our agile methods course. The talk is free and open to the public.

  • by: Munir Mahrufi and Sahar Khaksar, Deloitte Consulting GmbH
  • about: Scaled Agile to Support the “Digital Transformation” in the Financial Services Industry
  • on: January 31st, 2019, 10:15 Uhr
  • at: IAV DigiLab, Hallerstr. 6, 1. OG, Berlin (Charlottenburg)
  • as part of: AMOS speaker series

Continue reading “Upcoming Industry Talk on Scaled Agile to Support the “Digital Transformation” in the Financial Services Industry by Munir Mahrufi and Sahar Khaksar of Deloitte Consulting GmbH”

Scrum’s Product Vision vs. Project Mission

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.

Continue reading “Scrum’s Product Vision vs. Project Mission”

How Project vs. Product Confuses Agile Methods Terminology

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.

Continue reading “How Project vs. Product Confuses Agile Methods Terminology”

How Project vs. Product Confuses Open Source Terminology

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.

Continue reading “How Project vs. Product Confuses Open Source Terminology”

How UML is Actually Used (if it is Used)

When I started our software architecture course about eight years ago, I was happy to find out about a book series on the architecture of open source applications. I was thrilled: Not only code, but architecture descriptions! I expected great material for my course. Sadly, I had to realize that none of the chapters in this book series used UML, a staple of most academic software architecture courses.

Does this mean UML is not used in practice? Of course not. It is just not used in open source projects. This doesn’t imply that UML doesn’t have its uses. However, they may not be what tool vendors are telling you.

Continue reading “How UML is Actually Used (if it is Used)”