Thinking about FOSS, systemically
This is the script of the talk of the same name debuted at FOSSY 2023. I’m sharing it in full to allow those who didn’t attend the conference or won’t able to listen to any recordings to engage with this conversation.
Systemic. Do we understand what that word means?
Well, we, systems practitioners, start our journey by learning about something called General Systems Theory. General Systems Theory states that:
“Systems are a set of elements dynamically interrelated to perform activities aiming at achieving a specific goal, while consuming energy, materials or data (input) and producing new forms of energy, materials or data (output).” — L.V. Bertalanffy. General System Theory: Foundations, Development, Applications as cited by V. V. G. Neto, R. Araujo, R. P. dos Santos on New Challenges in the Social Web: Towards Systems- of-Information Systems Ecosystems.
This is the paradigm that is the guiding principle of systems thinking:
“Rather than reducing an entity to the properties of its parts or elements, systems theory focuses on the arrangement of and relations between the parts which connect them into a whole.” — F. Heylighen, C. Joslyn. What is Systems Theory?
The bigger picture.
Every minoritized person has at least a notion of what systems thinking is. It is, fundamentally, what allows so many of us to identify and fight to dismantle oppressive structures that exclude us.
I want to acknowledge first that systems thinking has been present in indigenous cultures and religions around the world—this isn’t a new concept. But it’s important to understand that General Systems Theory specifically—and, by extension, the academic definition of systems thinking—is proposed in opposition to what some authors may call reductionist thinking or conventional thinking.
Conventional thinking reduces a complex world to its parts. It assumes our world is stable, predictable, and objective.
On the other hand, systems thinking embraces how the world is uncertain, unstable, and experienced and understood from multiple worldviews.
I don’t want to give you the impression that conventional thinking isn’t useful—it can be! But human life is complex, and so are the things we build and the situations surrounding them. In fact, to some authors, the latter can be called messes.
In a continuum, you’ll find difficulty on one end and mess on the other. Difficulty would be the equivalent of a simpler problem and mess, of a complex situation.
Some authors say we can solve simpler problems, but we manage complex situations. We cope with them. Why is that?
Messes have more serious implications, multiple actors involved, intertwined and independent aspects and factors in different guises, and it often happens over a longer time-scale.
But most importantly, messes are hard to pin down. They’re hard to conceptualize.
Conventional thinking isn’t that great to cope with messes. Why?
We may ignore interconnections when we don’t look at the bigger picture.
We may assume the problem has a single cause instead of understanding that multiple intertwined factors may lead to that situation.
We may assume a single person is to blame instead of understanding how the situation that led to a problematic outcome came to be.
We may hyperfocus on an outcome—something we can measure—rather than on processes by which we can achieve beneficial change.
Let’s use what we learned so far to explore a complex problem within free software, starting with one worldview: I’m partially sighted. I was born with multiple bilateral colobomas. I used Linux distributions daily for more than a decade—until the accessibility tools I used started to fail. It got to a point I could barely read what was on a screen with what I had. No amount of Linux expertise I accumulated over the years could help me.
And I say deteriorating because, I really want to emphasize this, it used to be great! I can’t put into words how heartbreaking it feels to realize your favorite free software just became inaccessible. That brings us to factor number one: accessibility in accessible software can decline.
You can find multiple accounts written by people like me with details on why this is happening (I included one on my recommended reading). It has a lot to do with how we’re in the middle of a transitional moment—GTK3 to 4, Xorg to Wayland, and so on. That’s our second factor right there: transitions in underlying technologies.
One may think: well, if you’re so unhappy, just use something else. Many of us did just that—we ended up switching to proprietary OSes, which, I honestly hate. I’m actually using a proprietary OS right now to present this talk. But here’s the deal (and another factor to consider): working native accessibility tools are of no use if software isn’t accessible in the first place.
During my Human-Computer Interaction classes in college, the topic of accessibility was a footnote, not something extensively discussed and—most importantly—taught. It felt like it wasn’t treated as a requirement—even though there are legal implications and ramifications. Accessibility is seen as an extra feature, not a requirement.
That may be why not every developer knows how to develop accessible systems. And the developers who do know sometimes will move on to other opportunities, often not having someone to take their place. Accessibility as a specialty, not a commonality.
One could argue that this is a clear consequence of how prevalent the medical model of disability is in society. The medical model of disability perceives disability as a deviation from the “norm”. I have to conform the best way I can to this concept of normalcy to be treated like any other person.
But another worldview of disability is the one proposed by the social model of disability. It tells us my disability is a social experience—as in, it’s the result of an exclusionary society. With the right tools and accommodations, I’m just like any other person.
Those exclusionary factors are structural—and they’ve been here before we were even born. They all have social, economic, and political origins, repercussions, and implications.
They’re part of a reality that fails, harms, excludes, oppresses and kills marginalized people every single day. And this isn’t a separate reality from free software. Free software was built in this reality, it inherits and perpetuates its models, concepts, and power structures.
That’s why, as software freedom advocates, it’s our duty to question and dismantle them. How can we talk about freedom without liberation?
Systemic problems require systems thinking to promote true systemic change.
And it starts with you.
We need you to start thinking systemically. And we need you to never stop.
Now I promised you in the abstract of this talk that I would give you something, something you could hold on to to transform our spaces. As an academically inclined systems enthusiast, I need to be honest with you and say there’s a huge chunk of literature I just can’t cover here due to time constraints. But the chapter I’m using as my main reference for this talk, it tries to make sense of some of those things by talking about something they call purposeful intervention, of which the outcome is systemic change.
It is guided by three purposeful orientations:
Make sense of relationships between different entities associated with a complex situation. Understand in order to improve.
Surface and engage contrasting perspectives associated with this situation.
Explore and reconcile power relations, boundary issues, and potential conflict between entities and/or perspectives.
“Gently disrupt, unsettle, and thereby provoke new systems thinking.” — Martin Reynolds and Sue Holwell. Introducing Systems Approaches.
And that’s what I want to inspire in you. This is not an one and done conversation. This should be just the beginning.
Organize, intently.
Think, systemically.
Change, radically.
“A systems approach begins when first you see the world through the eyes of another.” — C. West Churchman as cited by Martin Reynolds and Sue Holwell in Introducing Systems Approaches.