Pith. sign in

REVIEW 3 major objections 5 minor 33 references

Exploring Fairness Interventions in Open Source Projects

T0 review · 3 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper claims that a curated set of 62 open source machine-learning fairness interventions is mostly dormant: only 32 percent have seen a commit in the past year, and about half support both bias detection and mitigation, with…

desk verdict The 62-tool dataset is a genuine contribution, but the abstract's '50% both detection and mitigation' claim is not what the body's numbers support. read the letter →

arxiv 2507.07026 v1 pith:BTWOJ5U2 submitted 2025-07-09 cs.SE

Sadia Afrin Mim , Fatema Tuz Zohra , Justin Smith , Brittany Johnson This is my paper · ORCID
classification cs.SE
keywords machinelearningfairnessopensourcesoftwareinterventionsbiasmitigationdetectionGitHubrepositoryminingMLlifecyclepractitionertoolselection
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to give practitioners a usable map of the open source machine-learning fairness ecosystem by systematically gathering 62 fairness interventions from GitHub and labeling their features. It claims that only 32% of these tools have seen a commit in the past year, and that about half support both bias detection and mitigation, with active tools favoring inprocessing mitigation. The authors argue this matters because practitioners often do not know which fairness tools exist and struggle to compare them; the compiled dataset and category scheme are meant to lower that barrier. If the figures hold, the community's fairness-tool infrastructure is small, heavily Python-based, and thinner on maintenance than its variety suggests.

What carries the argument

The carrying object is the curated dataset of 62 interventions plus the coding scheme used to label it. The scheme has four research-question axes: availability and compatibility (language, platform type, license), algorithm coverage, distinguishing factors (detection vs mitigation, guidance vs analysis, generic vs special purpose), and ML lifecycle support, where preprocessing means changing data before training, inprocessing means adding fairness constraints during training, and postprocessing means adjusting outputs after training. Active status is determined with a classification rule adapted from prior work: a repository is active if it had any commit in the past year and inactive if it had none or was archived or read-only. Two authors independently labeled each repository and reconciled disagreements, which is the procedure that turns documentation snippets into the reported percentages.

What would settle it

Re-run the GitHub keyword search without capping results at 10, classify the additional repositories with the same two-author labeling, and recompute the active share and detection/mitigation split; if the added set shifts either percentage by a noticeable margin, the reported ecosystem profile is an artifact of the search cap. A simpler check: pull the public commit history for the 62 repositories on a fixed date and verify the active/inactive labels against the 365-day rule.

Watch

Extended reading notes

Core claim

The central claim is that the open source fairness intervention landscape can be characterized by a small set of reusable features, and that measured on those features it is dominated by Python-based, generic, analytic tools, with only 32% actively maintained as of 2024 and about half offering both bias detection and mitigation, mostly in the inprocessing phase. The authors arrive at this by curating 62 interventions, classifying each by language, platform type (tool, toolkit, package, library, framework), license, supported algorithms and domains, guidance-versus-analytic role, and ML lifecycle phase (preprocessing, inprocessing, postprocessing). They also report that active interventions skew toward classification models and inprocessing mitigation, while the inactive tail holds more preprocessing and postprocessing support.

Load-bearing premise

Everything the paper counts on follows from the 62 repositories it found, and those were gathered by taking only the top 10 GitHub search results per keyword from a starting list of 10 known tools; if that sampling missed a meaningful slice of fairness tools, the reported percentages describe the sample, not the whole ecosystem.

Editorial extensions

If this is right

  • A practitioner who filters for actively maintained tools is left with roughly one in three of the 62, mostly Python libraries and toolkits aimed at classification models.
  • About half of the interventions can both detect and mitigate bias within one package, so the other half require pairing a detector with a separate mitigator.
  • Active projects cluster on inprocessing mitigation, so teams wanting preprocessing or postprocessing support may need to accept less-maintained tools.
  • Generic, domain-agnostic tools dominate; teams working in healthcare, LLMs, or energy will find few special-purpose options.
  • The published dataset gives a direct comparison basis for license, language, platform role, and lifecycle phase when choosing a tool.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper: the 32% and 50% aggregates are sample-dependent; re-running the GitHub search without the top-10 cutoff could shift them, and the authors' own internal-validity note says the limit may have missed repositories.
  • Beyond the paper: the phase finding suggests a testable temporal hypothesis that inprocessing support correlates with newer repositories, which one could check by regressing last-commit date against lifecycle phase.
  • Beyond the paper: the dataset could be maintained as a live registry with automated commit and license checks, turning a snapshot into a monitoring signal for the fairness-tool ecosystem.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. This paper presents a qualitative analysis of 62 open source machine learning fairness interventions. The authors compiled the dataset by starting from 10 tools from their prior taxonomy and expanding via GitHub keyword searches, then manually coded each intervention for language, platform, license, algorithm coverage, guidance versus analytic support, generic versus special-purpose support, and support for bias detection and mitigation across the ML lifecycle. Two authors independently coded and reconciled labels. The findings report that 32% of the interventions are actively maintained, that roughly half provide some mitigation support, and that active interventions tend to emphasize inprocessing mitigation. The paper also discusses practitioner-facing implications and threats to validity.

Significance. If the claims hold, the paper provides a useful dataset and a structured characterization that can help practitioners navigate the fairness tool landscape. The strengths include the public dataset, the transparent coding process with two independent coders and reconciliation, and the explicit enumeration of threats to validity. The scope is broader than prior work such as Lee and Singh's six-toolkit analysis. However, the quantitative findings should be viewed as descriptive of the curated 62-tool sample rather than the entire open source fairness ecosystem, and the abstract overstates some conclusions relative to the body.

major comments (3)
  1. [Abstract and Section IV-C] The abstract claims that "50% of them offer both bias detection and mitigation capabilities," but the body reports that 32 of 62 interventions "also include bias mitigation capabilities" and Figure 5 labels this 51.6% group as "Detect and Mitigate / Mitigate only." The text explicitly notes that some interventions, e.g., fairness-in-ml, are dedicated solely to mitigation. Therefore the subset offering both detection and mitigation is strictly smaller than 32 (or 50%), and the abstract's "both" claim is not supported by the paper's own data. This is a load-bearing numeric claim that must be corrected.
  2. [Abstract and Section IV-D] The abstract states that the interventions offering detection and mitigation do so "mostly during inprocessing." However, Section IV-D reports that about 50% of active interventions include inprocessing mitigation, while inactive interventions skew toward preprocessing and postprocessing. No aggregate percentage across all 62 interventions is reported. The claim "mostly during inprocessing" is therefore not established for the full dataset, only for the active subset. The abstract should be revised to reflect the scope of the actual finding.
  3. [Section III-A and Section VI (Internal Validity)] The dataset construction begins with 10 seed tools from the authors' prior taxonomy and is expanded by GitHub keyword searches, retaining only the top 10 results per keyword. As the authors acknowledge in the Internal Validity threat, this may overlook relevant repositories. Since every aggregate percentage in the abstract and findings is computed from this sample, the representativeness of the 62-tool set is load-bearing. The paper should either justify why top-10-per-keyword sampling yields a representative view of the open source ecosystem or explicitly frame all quantitative findings as descriptive of the curated dataset rather than of the broader ecosystem. The Introduction's claim of a "comprehensive exploration" and the abstract's implicit generalizability currently conflict with this acknowledged limitation.
minor comments (5)
  1. [Throughout] There are numerous typos and spelling inconsistencies, including "preprocesing" for "preprocessing" (Sections III-F, IV-D), "thieir" in the Introduction, and inconsistent capitalization of "preprocesing/inprocessing/postprocessing." A careful proofreading pass is needed.
  2. [Figure 5] The pie chart legend "Detect and Mitigate / Mitigate only" is ambiguous because it merges two conceptually distinct categories. Separating "Detect and Mitigate" from "Mitigate only" would make the data easier to interpret and would align the figure with the text's distinction between these groups.
  3. [Section IV-B] The sentence "52 of them work on ensuring fairness for classification algorithms, and 34 of them work on regressions" gives counts that sum to more than 62, which is possible only if the categories overlap. Please clarify whether interventions can support multiple algorithm classes and, if so, note that these counts are not mutually exclusive.
  4. [Figure 1] The figure lists "Langest" while the text and repository name appear to be "Langtest." Please verify consistency between the figure labels and the actual tool names.
  5. [Section III-A] The keyword list is described as derived from the About sections of seeds, but the actual derivation process is not described in enough detail to assess its completeness (e.g., how many repositories were analyzed, whether the keyword set was validated). A brief description of this step would strengthen the methodology.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: empirical survey with minor, non-load-bearing self-citation.

full rationale

This paper is an empirical survey, not a derivation chain, so most circularity patterns do not apply. The central numeric claims—32% active, 50% detection/mitigation support—are computed from a manually curated dataset of 62 GitHub repositories, collected via GitHub API keyword searches and labeled by two independent authors with a collaborative verification phase. Nothing in the paper defines the findings in terms of the inputs: no fitted parameter is renamed as a prediction, no equation reduces to itself, and no prior result is invoked to forbid alternatives. The only self-referential elements are (1) seeding the dataset with 10 tools 'curated in prior work [24]' (Section III-A), which is an author self-citation but does not determine the aggregate statistics, and (2) grouping ML lifecycle phases 'as with prior work [24]' (Section III-F), which is also independently supported by an external citation [32]. These are minor and not load-bearing. The paper even acknowledges in Section VI that limiting searches to the top 10 results per keyword may have missed repositories, an honest sampling limitation rather than a circularity. The abstract's '50% of them offer both bias detection and mitigation' slightly overstates the body, where Figure 5 labels the 51.6% group 'Detect and Mitigate / Mitigate only' and the text notes some interventions are mitigation-only; however, this is a reporting-accuracy issue, not a circular derivation.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The paper contributes a descriptive dataset; no mathematical parameters are fitted and no new entities are postulated. The axioms above are the domain assumptions needed to interpret the percentages as statements about the broader ecosystem.

assumptions (4)
  • domain assumption GitHub keyword search with top-10 results per keyword yields a representative sample of open source fairness interventions.
    Underlies all dataset-level percentages; the authors limit to top 10 results per keyword (Section III-A) and acknowledge the limitation in Section VI Internal Validity.
  • domain assumption Repository commit activity within the past year is a valid proxy for an intervention being actively maintained.
    Used to classify active vs inactive status (Section III-B), following a model from prior work [25].
  • domain assumption READMEs, About sections, and related papers accurately describe the intervention's true capabilities.
    All feature categorization (languages, platforms, algorithms, lifecycle phases) relies on documentation rather than executing the tools (Sections III-C through III-F).
  • domain assumption The three-phase ML lifecycle (preprocessing, inprocessing, postprocessing) is an appropriate and sufficient framework for reporting mitigation support.
    The paper maps techniques into these phases (Section III-F), following prior work [32], but this is a modeling choice that shapes all RQ4 results.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Exploring Fairness Interventions in Open Source Projects." pith.science (2026). https://pith.science/paper/BTWOJ5U2

@misc{pith2026250707026,
  author       = {Pith},
  title        = {Pith review of: Exploring Fairness Interventions in Open Source Projects},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BTWOJ5U2}},
  note         = {Machine review of arXiv:2507.07026}
}
read the original abstract

The deployment of biased machine learning (ML) models has resulted in adverse effects in crucial sectors such as criminal justice and healthcare. To address these challenges, a diverse range of machine learning fairness interventions have been developed, aiming to mitigate bias and promote the creation of more equitable models. Despite the growing availability of these interventions, their adoption in real-world applications remains limited, with many practitioners unaware of their existence. To address this gap, we systematically identified and compiled a dataset of 62 open source fairness interventions and identified active ones. We conducted an in-depth analysis of their specifications and features to uncover considerations that may drive practitioner preference and to identify the software interventions actively maintained in the open source ecosystem. Our findings indicate that 32% of these interventions have been actively maintained within the past year, and 50% of them offer both bias detection and mitigation capabilities, mostly during inprocessing.

Figures

Figures reproduced from arXiv: 2507.07026 by the authors.

Figure 1
Figure 1. Available Fairness interventions in Open Source [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Programming Language Supported Across Interven [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Distribution of different Fairness Software Interven [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (2 more)
Figure 6
Figure 6. Figure 6: Distribution of Generic and Special Purpose interven [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 5
Figure 5. Figure 5: intervention Distribution: Detect vs Detect and Mitigate [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

33 extracted references · 30 canonical work pages

  1. [1]

    Assurance of machine learning/tinyml in safety-critical do- mains,

    Z. Iqbal, “Assurance of machine learning/tinyml in safety-critical do- mains,” in 2022 IEEE Symposium on Visual Languages and Human- Centric Computing (VL/HCC) , pp. 1–2, IEEE, 2022

    work page 2022

  2. [2]

    A survey on bias and fairness in machine learning,

    N. Mehrabi, F. Morstatter, N. Saxena, K. Lerman, and A. Galstyan, “A survey on bias and fairness in machine learning,” ACM Computing Surveys (CSUR), vol. 54, no. 6, pp. 1–35, 2021

    work page 2021

  3. [3]

    Lipsitz, The possessive investment in whiteness: How white people profit from identity politics

    G. Lipsitz, The possessive investment in whiteness: How white people profit from identity politics . Temple University Press, 2006

    work page 2006

  4. [4]

    Gender bias in translation using google translate: Problems and solution,

    T. N. Fitria, “Gender bias in translation using google translate: Problems and solution,” Language Circle: Journal of Language and Literature , vol. 15, no. 2, 2021

    work page 2021

  5. [5]

    Olf-ml: An offensive language framework for detection, categorization, and offense target identification using text processing and machine learning algorithms,

    M. N. Hasan, K. S. Sakib, T. T. Preeti, J. Allohibi, A. A. Alharbi, and J. Uddin, “Olf-ml: An offensive language framework for detection, categorization, and offense target identification using text processing and machine learning algorithms,” Mathematics, vol. 12, no. 13, p. 2123, 2024

    work page 2024

  6. [6]

    Software fairness,

    Y . Brun and A. Meliou, “Software fairness,” in Proceedings of the 2018 26th ACM joint meeting on european software engineering conference and symposium on the foundations of software engineering , pp. 754– 759, 2018

    work page 2018

  7. [7]

    The landscape and gaps in open source fairness toolkits,

    M. S. A. Lee and J. Singh, “The landscape and gaps in open source fairness toolkits,” in Proceedings of the 2021 CHI conference on human factors in computing systems , pp. 1–13, 2021

    work page 2021

  8. [8]

    Towards ethical data-driven software: filling the gaps in ethics research & practice,

    B. Johnson and J. Smith, “Towards ethical data-driven software: filling the gaps in ethics research & practice,” in 2021 IEEE/ACM 2nd International Workshop on Ethics in Software Engineering Research and Practice (SEthics), pp. 18–25, IEEE, 2021

    work page 2021

Show all 33 references
  1. [9]

    A taxonomy and catalog of runtime software-fault monitoring tools,

    N. Delgado, A. Q. Gates, and S. Roach, “A taxonomy and catalog of runtime software-fault monitoring tools,” IEEE Transactions on software Engineering, vol. 30, no. 12, pp. 859–872, 2004

    2004

  2. [10]

    Taxonomy of automated software testing tools,

    K. Shaukat, U. Shaukat, F. Feroz, S. Kayani, and A. Akbar, “Taxonomy of automated software testing tools,” International Journal of Computer Science and Innovation , vol. 1, pp. 7–18, 2015

    2015

  3. [11]

    Bias and unfairness in machine learning models: a systematic review on datasets, tools, fairness metrics, and identification and mitigation methods,

    T. P. Pagano, R. B. Loureiro, F. V . Lisboa, R. M. Peixoto, G. A. Guimar˜aes, G. O. Cruz, M. M. Araujo, L. L. Santos, M. A. Cruz, E. L. Oliveira, et al. , “Bias and unfairness in machine learning models: a systematic review on datasets, tools, fairness metrics, and identificat...

    2023

  4. [12]

    ” ignorance and prejudice

    J. M. Zhang and M. Harman, “” ignorance and prejudice” in software fairness,” in 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE), pp. 1436–1447, IEEE, 2021

    2021

  5. [13]

    Survey on causal-based machine learning fairness notions,

    K. Makhlouf, S. Zhioua, and C. Palamidessi, “Survey on causal-based machine learning fairness notions,” arXiv preprint arXiv:2010.09553 , 2020

    2010 arXiv

  6. [14]

    Fairness in machine learning: A survey,

    S. Caton and C. Haas, “Fairness in machine learning: A survey,” arXiv preprint arXiv:2010.04053, 2020

    2010 arXiv

  7. [15]

    A survey on datasets for fairness-aware machine learning,

    T. Le Quy, A. Roy, V . Iosifidis, W. Zhang, and E. Ntoutsi, “A survey on datasets for fairness-aware machine learning,” Wiley Interdisciplinary Reviews: Data Mining and Knowledge Discovery , vol. 12, no. 3, p. e1452, 2022

    2022

  8. [16]

    A review on fairness in machine learning,

    D. Pessach and E. Shmueli, “A review on fairness in machine learning,” ACM Computing Surveys (CSUR) , vol. 55, no. 3, pp. 1–44, 2022

    2022

  9. [17]

    Do the machine learning models on a crowd sourced platform exhibit bias? an empirical study on model fairness,

    S. Biswas and H. Rajan, “Do the machine learning models on a crowd sourced platform exhibit bias? an empirical study on model fairness,” in Proceedings of the 28th ACM joint meeting on European software engineering conference and symposium on the foundations of software engine...

    2020

  10. [18]

    Fairea: A model behaviour mutation approach to benchmarking bias mitigation methods,

    M. Hort, J. M. Zhang, F. Sarro, and M. Harman, “Fairea: A model behaviour mutation approach to benchmarking bias mitigation methods,” in Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineeri...

    2021

  11. [19]

    In-processing modeling tech- niques for machine learning fairness: A survey,

    M. Wan, D. Zha, N. Liu, and N. Zou, “In-processing modeling tech- niques for machine learning fairness: A survey,” ACM Transactions on Knowledge Discovery from Data , vol. 17, no. 3, pp. 1–27, 2023

    2023

  12. [20]

    Bias mitigation post-processing for individual and group fair- ness,

    P. K. Lohia, K. N. Ramamurthy, M. Bhide, D. Saha, K. R. Varshney, and R. Puri, “Bias mitigation post-processing for individual and group fair- ness,” in Icassp 2019-2019 ieee international conference on acoustics, speech and signal processing (icassp) , pp. 2847–2851, IEEE, 2019

    2019

  13. [21]

    Mitigating bias in face recognition us- ing skewness-aware reinforcement learning,

    M. Wang and W. Deng, “Mitigating bias in face recognition us- ing skewness-aware reinforcement learning,” in Proceedings of the IEEE/CVF conference on computer vision and pattern recognition , pp. 9322–9331, 2020

    2020

  14. [22]

    Assessing and mitigat- ing bias in medical artificial intelligence: the effects of race and ethnicity on a deep learning model for ecg analysis,

    P. A. Noseworthy, Z. I. Attia, L. C. Brewer, S. N. Hayes, X. Yao, S. Kapa, P. A. Friedman, and F. Lopez-Jimenez, “Assessing and mitigat- ing bias in medical artificial intelligence: the effects of race and ethnicity on a deep learning model for ecg analysis,” Circulation: Arrh...

    2020

  15. [23]

    Uncovering and mitigating algorithmic bias through learned latent structure,

    A. Amini, A. P. Soleimany, W. Schwarting, S. N. Bhatia, and D. Rus, “Uncovering and mitigating algorithmic bias through learned latent structure,” in Proceedings of the 2019 AAAI/ACM Conference on AI, Ethics, and Society , pp. 289–295, 2019

    2019

  16. [24]

    A taxonomy of machine learning fairness tool specifications, features and workflows,

    S. A. Mim, J. Smith, and B. Johnson, “A taxonomy of machine learning fairness tool specifications, features and workflows,” in 2023 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), pp. 222–225, IEEE, 2023

    2023

  17. [25]

    Is this github project maintained? measuring the level of maintenance activity of open-source projects,

    J. Coelho, M. T. Valente, L. Milen, and L. L. Silva, “Is this github project maintained? measuring the level of maintenance activity of open-source projects,” Information and Software Technology , vol. 122, p. 106274, 2020

    2020

  18. [26]

    Identifying and characterizing unmain- tained projects in github,

    J. J. de Sousa Coelho et al. , “Identifying and characterizing unmain- tained projects in github,” 2019

    2019

  19. [27]

    When a toolkit is not enough: A review on what is needed to promote the use and uptake of immunization-related resources,

    S. Jaffe, A. Meghani, J. C. Shearer, A. Karlage, M. B. Ivankovich, L. R. Hirschhorn, K. E. Semrau, and E. McCarville, “When a toolkit is not enough: A review on what is needed to promote the use and uptake of immunization-related resources,” Global Health: Science and Practice...

    2024

  20. [28]

    {TensorFlow}: a system for {Large-Scale} machine learning,

    M. Abadi, P. Barham, J. Chen, Z. Chen, A. Davis, J. Dean, M. Devin, S. Ghemawat, G. Irving, M. Isard, et al. , “ {TensorFlow}: a system for {Large-Scale} machine learning,” in 12th USENIX symposium on operating systems design and implementation (OSDI 16) , pp. 265–283, 2016

    2016

  21. [29]

    Composing con- tracts: an adventure in financial engineering,

    S. P. Jones, J.-M. Eber, J. Seward, and S. Peyton Jones, “Composing con- tracts: an adventure in financial engineering,” in ACM SIGPLAN Inter- national Conference on Functional Programming (ICFP’00), September 2000

    2000

  22. [30]

    Cwalina, J

    K. Cwalina, J. Barton, and B. Abrams, Framework design guidelines: conventions, idioms, and patterns for reusable. net libraries . Addison- Wesley Professional, 2020

    2020

  23. [31]

    Fairkit-learn: a fairness evaluation and comparison toolkit,

    B. Johnson and Y . Brun, “Fairkit-learn: a fairness evaluation and comparison toolkit,” in Proceedings of the ACM/IEEE 44th International Conference on Software Engineering: Companion Proceedings , pp. 70– 74, 2022

    2022

  24. [32]

    Fairness in machine learning: A survey,

    S. Caton and C. Haas, “Fairness in machine learning: A survey,” ACM Computing Surveys, vol. 56, no. 7, pp. 1–38, 2024

    2024

  25. [33]

    Py-holmes: Causal testing for deep neural networks in python,

    W. McQueary, S. A. Mim, M. N. Raihan, J. Smith, and B. Johnson, “Py-holmes: Causal testing for deep neural networks in python,” in Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering , pp. 602–606, 2024. 8

    2024

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.