as causes for problems in software product line engineering. Of several more, I want to pick a third and final one, before we turn to the root cause of it all in the next blog post. This third cause is the political power play between product units as they try to prioritize requirements for the platform organization.
As previously posted, we analyzed current problems in product line engineering. One case study was a healthcare software product line, one was a business software product line, and one was a telco carrier software product line. All developers in their respective product line were homogeneous in time and culture (one main location, one social culture), that is, we had no problems of globally distributed software development. This both made the analyses easier but also limits the generalizability of our conclusions.
We presented our analysis using cause-and-effect chain diagrams. The following figures shows an excerpt of these diagrams.
A few years ago we analysed several highly successful software product lines. You can find the details in our corresponding publication. We had been brought in, because the business owners of each product line felt that something was amiss and that productivity could still be improved. In this short blog post series I’ll discuss the problems we found and what to do about it.
Much open source research assumes that all open source projects are alike and that if you take enough of them, you can claim generalizability for your conclusions. GitHub is the main source of such mischief, because of its size and availability.
If GitHub was like Berlin, and projects on GitHub were like the people of Berlin, then treating all projects the same is like saying that a person from Mitte is like a person from Kreuzberg is like a person from Spandau.
An open source software user consortium is a non-profit organization (foundation, consortium, working group) created for the purpose of funding and managing the development of non-differentiating open source software made available to foundation members and the general public. Its purpose is to establish a software ecosystem in which vendors and suppliers can provide products and services on an equal playing field to the software user companies. User companies are everyone who needs software and who is not a software company.
We are currently sampling what’s out there (and there is plenty, see recent prior posts on the topic). Examples are the Kuali Foundation or the openKONSEQUENZ consortium or the OpenMDM working group. For sampling, we want to understand the differences between these organizations.
Abstract: Free/Libre and Open Source Software (FLOSS) communities are composed, in part, of volunteers, many of whom contribute infrequently. However, these infrequent volunteers contribute to the sustainability of FLOSS projects, and should ideally be encouraged to continue participating, even if they cannot be persuaded to contribute regularly. Infrequent contributions are part of a trend which has been widely observed in other sectors of volunteering, where it has been termed “episodic volunteering” (EV). Previous FLOSS research has focused on the Onion model, differentiating core and peripheral developers, with the latter considered as a homogeneous group. We argue this is too simplistic, given the size of the periphery group and the myriad of valuable activities they perform beyond coding. Our
exploratory qualitative survey of 13 FLOSS communities investigated what episodic volunteering looks like in a FLOSS context. EV is widespread in FLOSS communities, although not specifically managed. We suggest several recommendations for managing EV based on a framework drawn from the volunteering literature. Also, episodic volunteers make a wide range of value-added contributions other than code, and they should neither be expected nor coerced into becoming habitual volunteers.
Keywords: Community management, episodic volunteering, free software, open source software, peripheral developer, volunteer management
Reference: Ann Barcomb, Andreas Kaufmann, Dirk Riehle, Klaas-Jan Stol, and Brian Fitzgerald. “Uncovering the Periphery: A Qualitative Survey of Episodic Volunteering in Free/Libre and Open Source Software Communities.” Transactions on Software Engineering. To appear.
Abstract: User experience design is an important part of software product development, and yet software product line engineering has largely ignored this topic. This paper presents a set of industry best practices for user experience design in software product lines. We conducted multiple-case case study research using two different product lines within the multinational company Siemens AG: in a healthcare software division and in an industrial automation software division. We performed a preliminary exploratory study that will serve as a baseline for future research in the design, implementation, and management of user experience design in the context of software product lines. Practitioners can use our findings and the resulting best practices to improve their user experience design, particularly within
healthcare and industrial automation software product lines.
Keywords: User experience design, UXD, user interface design, software product lines, SPL, engineering best practices, case study research, handbook method
Reference: Nikolay Harutyunyan, Dirk Riehle. “User Experience Design in Software Product Lines.” In Proceedings of the 52nd Hawaii International Conference on System Sciences (HICSS 2019), to appear.
We just finished redoing our original analysis of paid vs. volunteer work in open source for Gitee, a Chinese-dominated code hosting platform from China. We wanted to understand where China stands in open source. Previous blog posts looked at base data, e.g. the half/half split between paid and volunteer work, as well as developer behavior, e.g. that dominantly paid developers still volunteer in their spare time.
In this third and final blog post, I would like to look at projects and how commercially dominated (or not) they are. For the purposes of this analysis, a developer is a (pure) paid developer, if 95% or more of their commits are done during regular working hours, and a developer is a (pure) volunteer, if 95% or more of their commits are done outside of these working hours. Obviously, this is a very conservative definition. How commercial a project is then depends on the percentage of (pure) paid developers and how non-commercial depends on the percentage of (pure) volunteer developers. The following figures shows how many projects exist for the percentage distributions of either pure paid or pure volunteer developers. Please observe the logarithmic y-axis.
We just finished redoing our original analysis of paid vs. volunteer work in open source for Gitee, a Chinese-dominated code hosting platform from China. We wanted to understand where China stands in open source. The previous blog post explained the half / half split between paid vs. volunteer time in terms of total work on open source.
So far, we only discussed commits, now I would like to discuss committer behavior, in particular, whether there are pure paid developers, who only work Mon-Fri, 9am-5pm, i.e. during regular working hours, and pure volunteers, working only outside those hours. Compared to our data for the Western world, the Chinese data is less conclusive. The following figure bins developers into the respective categories, and the following table spells out the bins (categories) explicitly. For the figure, please note the logarithmic scale of the y-axis.