Research project on how FOSS project sustainability is affected by mismatched upstream/downstream conceptualizations
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Mel Chua f4b146e316
2 years ago add project description 2 years ago
_config.yml Set theme jekyll-theme-tactile 2 years ago Create 2 years ago Create 2 years ago Create 2 years ago Create 2 years ago Create 2 years ago Create 2 years ago formatting fix 2 years ago Create 2 years ago remove redundant headers 2 years ago fix formatting 2 years ago


The Mismatches project is a research project on how mismatched conceptualizations between upstream maintainers and downstream users of a Free and Open Source (FOSS) digital infrastructure project interact to affect the community health and thus sustainability of such projects.

It is part of the Ford/Sloan cohort on digital infrastructure research and is based at RIT. Steve Jacobs and Mel Chua lead the research team.

This webpage is a placeholder that currently summarizes a broad overview of what we're trying to do; stay tuned for updates.

Project summary

What is your research question?

How do mismatched conceptualizations between upstream maintainers and downstream users of a Free and Open Source (FOSS) digital infrastructure project interact to affect the community health and thus sustainability of such projects?

More specifically: how do developers who maintain commonly-used FOSS projects compare to developers who use those same projects in terms of how they conceptualize:

  1. ontologies of an ideal, well-maintained and sustainable FOSS project community, i.e. which elements are present, how they relate, etc.
  2. which parties are responsible for which elements, and
  3. the state of that FOSS project relative to their ontologies of ideal projects?

Why is it important to answer?

In order to address systems-level problems together, we must first have shared conceptualizations of what those systems and their problems might be. Unknowingly holding different conceptualizations can lead to problems being overlooked, dismissed, or addressed with the wrong resources. In our combined 2 decades of work with FOSS community "upstreams" and the corporations/government agencies/NGO "downstreams" that rely on their products, we've noticed many of these types of mismatches, and have spent a great deal of time addressing misconceptions on both sides.

These communication issues stem in part from fundamentally different ontologies, or conceptions of reality, regarding "how FOSS communities work." These are not simply disagreements over how project communities are doing relative to a shared scale, or even what those shared scales might be, but completely disjoint conceptualizations of what FOSS project communities are and how they operate in the first place.

This project investigates how the diversity of conceptualizations both helps and hinders efforts to improve FOSS community health. Studying these interacting ontologies can inform how upstreams and downstreams develop shared understandings of what improvements are needed, and can also make-visible what inefficiencies still require intervention after conceptualization and communication gaps have been addressed.

What methods will you use to answer it?

We propose a narrative interview methodology with a publicly viewable dialogue structured over multiple rounds. Interviews will be situated within a critical FOSS infrastructure project - something that a lot of projects use, and that would be disruptive if it went down.

We will interview both (A) maintainers of these widely used FOSS projects and (B) technical downstream users of the same regarding their conceptualizations of (1) how healthy FOSS communities work, (2) who is responsible for aspects of that health, and (3) the state of that particular FOSS project's community.

Interview excerpts answering these questions will be circulated amongst participants in subsequent interview rounds, first within groups (maintainers see other maintainers' responses, downstreams see other downstreams' responses) and then across groups (maintainers see downstream responses, downstreams see maintainer responses). To foster public dialogue, transcript excerpts will be made available under an open license as the interviews progress, with participant consent.

Transcripts will be analyzed for ontologies, or underlying conceptualizations of FOSS projects presupposed by interview narratives. Ontological shifts will be tracked as participants respond to each other. Analysis will also be public and open-licensed, giving the FOSS community an opportunity to see how research of this sort is done.

What data or resources will you use to answer it?

This project relies on three sets of data/resources.

The first is the interview corpus with upstream and downstream developers that we will collect as part of the project. We expect to interview at least 3 upstream and 3 downstream (for a total of 6) developers for the target FOSS community.

The second is existing literature, both scholarly and non-scholarly (i.e. books, blogs, etc.) on FOSS community dynamics. These serve as sources of additional conceptualizations of FOSS communities as well as venues to engage in dialogues about them.

The third consists of analytics and metrics on software projects such as those run by, Bitergia, Black Duck and CHAOSS. These will be used to identify which project communities to approach regarding participation at the outset, as well as a means for discussing project health and growth during the study/intervention.

What is your vision of success?

We want to be able to identify these different conceptualizations and then identify and codify the mismatches in terms of how easy they are to address and what might be effective in resolving them. It may be that we are able to identify overall problem and challenge types within these efforts and then be able to provide “recipes” for them to achieve greater stability. It is our sense that these “recipes” will be in the areas of human communication, management, social engineering solutions vs. technological solutions; though there may be software tools around organization, scheduling etc that might be part of suggested best practices that emerge.