Posted on

What’s Wrong in Software Product Line Engineering? Insufficient Collaboration between Product and Platform Unit

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.

Continue reading “What’s Wrong in Software Product Line Engineering? Insufficient Collaboration between Product and Platform Unit”

Posted on

What’s Wrong in Software Product Line Engineering? Lack of Resources in the Platform Organizational Unit

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.

Continue reading “What’s Wrong in Software Product Line Engineering? Lack of Resources in the Platform Organizational Unit”

Posted on

Commercial Open Source in the Cloud

The brouhaha around Redis Labs taking some enterprise modules of its popular open source in-memory database Redis closed source has somewhat calmed down. However, I didn’t see any discussion of what I thought was the most interesting conclusion of the affair: A core strategy of commercial open source,

the dual-licensing of the software under an aggressive copyleft and a commercial license may not work when cloud providers are involved.

To recap: Redis Labs develops and provides to the market the open source in-memory database Redis. It follows the commercial open source playbook: “Free-loading” users can use the software for free under the AGPLv3 license. Paying customers receive a commercial license. Those with a commercial license do not have to open source their application code, while non-paying users may have to. These are the effects of the AGPLv3 for the free version. It does not apply to in-house solutions, even if hosted in the cloud, but it does apply to software vendors that provide on-premise or hosted solutions to third parties, that is, their customers. To avoid having to open source, software vendors purchase the commercial license and Redis Labs makes some money.

Continue reading “Commercial Open Source in the Cloud”

Posted on

Open Data: Source of Public Income or Invaluable Common Good?

Not surprisingly, this huddling panel at the 2018 Berlin Open Data Day came to no specific conclusion, just different opinions on business models and who should earn what income.

Some nuggets of insight: Leave it to public institutions to decide for themselves — open data should be freely available, otherwise some commercial business models break down — cities should be neutral to startups and establish collaborations for everyone’s benefit — leave it to companies to generate value from open data and they will give back #muwhaha — don’t monetarize open data at all — if users don’t pay, public institutions won’t have the funds to provide open data — open data should be considered public infrastructure and follow established practices — the data belongs to the public anyway — selling data is too expensive for a city.

In related news, some cheap laughs for public institution bashing from one panelist. Personally, I find this less than helpful.

One amusing quote from another panelist:

In theory, we all agree, in practice, we do not.

I guess more sustainability research is needed.

Posted on

Best of “As a Developer, I Want…” Student User Stories, Raw and Unfiltered

Over on Twitter, the ever amazing and amusing time sink, @AdamPridmore, @KevlinHenney, and @JensColdewey are discussing the merit of software developers as stakeholders in user stories.

Despair not! I’ve got the goods. From my Scrum student projects (I run those day-in, day-out), here is the classic one:

As a developer, I want to learn Java to be able to program and earn a top grade.

I looked through the last few feature archives (the place where stories go to rest) from my student projects. Here are some fine exemplars of developer user stories. Have fun!

Continue reading “Best of “As a Developer, I Want…” Student User Stories, Raw and Unfiltered”

Posted on

If GitHub Was Like Berlin…

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.

Continue reading “If GitHub Was Like Berlin…”

Posted on

Classifying Open Source User Consortia

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.

Continue reading “Classifying Open Source User Consortia”

Posted on

Clarification of “Why I Still Teach Scrum”

Teaching Scrum at University is challenging. Students are typically at the beginning of their career and don’t understand the challenges of communication and coordination in software engineering well. In a prior post on Why I Still Teach Scrum I had made a cryptic remark to that end and through various channels was asked to clarify the remark.

Scrum is a framework that needs tailoring for the specific situation at hand. The specific challenges of teaching Scrum at a University are, in no particular order, and most certainly incomplete:

  • Comparatively little practical experience of students
  • Widely differing capabilities as the gap between students can be large
  • Transient teams as Scrum projects typically last only a semester
  • Zero-Sum-Thinking by some students as to teamwork and grade

Continue reading “Clarification of “Why I Still Teach Scrum””

Posted on

Uncovering the Periphery: A Qualitative Survey of Episodic Volunteering in Free/Libre and Open Source Software Communities

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.

The paper can be downloaded as a PDF file.