This is a list, inspired by the Five Geek Social Fallacies, of common patterns or behaviours that developers of free/open source software (FOSS) fall into when they try to develop software for users who are not technical, or for whom non-technical users would be the most obvious userbase. Hopefully writing these down (which frankly is cathartic more than anything) is helpful to some in recognising these thought patterns and avoiding them when developing software – I’ve got some of my own thoughts on this at the bottom.
Tantacrul – Achieving Excellence in Open Source Software Design #FOSSDesign
Open Source Software and Corporate Influence — Andrew Lilley Brinker
Open source software projects are frequently enmeshed with the interests of corporations. We should update mental models of who works on open source accordingly, and build or modify power structures to be more resilient to corporate capture.
Tyranny of Permissionlessness
open source’s narrow focus further empowers those with other ways to exclude
Histomat of F/OSS: We should reclaim LLMs, not reject them
A few days ago, I came across a blog post titled On FLOSS and training LLMs that articulates a growing frustration within the free and open source software…
The Few, the Tired, the Open Source Coders
The open source movement runs on the heroic efforts of not enough people doing too much work. They need help.
Pluralistic: The (other) problem with automatic conversion of free software to proprietary software (23 Apr 2026) – Pluralistic: Daily links from Cory Doctorow
Here's an interesting stunt: a project called Malus.sh will take your money, and in exchange, it will ingest any free/open source code you want, refactor that code using an LLM, and spit out a "clean room" version that is freed from all the obligations imposed by the original project's software license:
Home-Cooked Software and Barefoot Developers
The emerging golden age of home-cooked software, barefoot developers, and why the local-first community should help build it
Aaron Boodman on Twitter / X
There is this tension in dev tooling right now: Lots of people want to self-host, and not depend on a service. Lots of people also want the vibes of open source - being part of an open development community, having the code, etc.But builders still need to make a living...— Aaron Boodman (@aboodman) January 23, 2024
Front Page — Free Software Foundation — working together for free software
The technology overrunning our communities isn't built for the benefit of humanity: it's built so that billionaires can control us. Our lives don't have to be this way. The FSF empowers users with free software, technology built through global collaboration, mutual respect, and above all, freedom. The FSF will always continue to resist the encroachment of nonfree software. We're fighting to protect all computer users and build a better future.
Working in Public: The Making and Maintenance of Open S…
An inside look at modern open source software developer…
Open Source Resistance
A direct-action manifesto for maintainers keeping open source alive on company time.
Nicholas Carlini - Black-hat LLMs | [un]prompted 2026
Dependency Cultures - Richard Feldman | SSW 2026
Ten quick tips to SNIFF out sustainable and secure scientific software
Modern computational biology depends heavily on open-source software tools, analysis pipelines, and containerized workflows developed and shared by the research community. While there is extensive guidance (including Quick Tips and Simple Rules articles) on how to build robust and sustainable scientific software, far less has been written for researchers in the role of software users evaluating whether an existing tool is reliable, secure, and sustainable enough for their work. Here we present ten quick tips to help researchers critically assess the tools they adopt. Our tips are organized around a framework that centers on key evaluation features: source, network, interaction, fit, and fragility (SNIFF). These dimensions prompt researchers to consider who maintains a tool and why, whether it is embedded in a broader ecosystem, how actively its developers and users engage, whether it matches the intended use case and licensing requirements, and how robust its dependencies and security practices are. By applying these tips, researchers can make more informed decisions, reduce the risk of relying on abandoned or insecure software, and contribute to a more sustainable scientific software ecosystem.
