The FOSS reality distortion field

Social Experience Design Sustainable FOSS
,
#1

I just read Ariadne’s fedi thread re:IRC, also touching on the Fediverse (thanks for the link @onepict).

I think that “FOSS reality distortion field” is a good idea/concept to keep in mind and further explore what it entails. I also see that as part and in scope of Social Coding FSDL. The biases and dogma’s of the FOSS movements are hampering and impairing it in so many ways.

Strong mostly wrt technical aspects, of a range of FOSS-related weaknesses, by far the biggest weakness of FOSS and Free Culture movements is imho the inability to execute based on shared vision and follow overarching strategies at ecosystem-wide scopes, to coordinate against the powers-that-be. (And where we are able to do so, as argued elsewhere on the forum, I feel that effectively by followig Radically Transparent Strategy we still end up on the losing side. This transparency is only possible in a minority of cases).

Fozzy folks need to take a helicopter view perspective more often to see how they are positioned and how that relates to the world outside the familiar cultural environment.

One example is that, while forge federation is exciting, in itself connecting forge softwares isn’t by any means enough to gain a competitive position against the centralized walled garden of Github. Because Github is positioned to cover the entire field of software development in an all-encompassing gradual and smart EEE strategy.

Another example is that fedi devs aren’t very good at perceiving the actual needs of the fedizens. Product development is basically skipped and the discussion is on adding individual features to existing software codebases and then immediately delve down into deep technical territory.

3 Likes
#2

“Reality distortion field” seems just another term for “echo chamber”, it’s just a way of saying “perspective” with the highlight on lacking other perspectives. Any perspective can never be holistic, we need multiple perspectives to see all of anything.

Radical transparency is misguided delusional nonsense. A better term is “candor”, and it is something to use consciously. So, we should mindfully recognize when we are candid and when not. When we aren’t comfortable being candid, we can figure out why and work on addressing the underlying issues. As we resolve the issues, we can live with ever more candor. Jumping to radical transparency as a rule is reckless and dysfunctional.

This is a matter not of FLO-centric perspectives but of programmer-centric perspectives. And yeah, it bothers me so much and has been my top concern since getting involved in FLO. I see proprietary software as user-centered but with the goal of short-term capturing of user attention and monetizing it and locking people in. Proprietary development does many things right but for unethical ends. FLO development has some of the ethics in place but does lack context often.

But a contrasting example from IRC/Matrix/Discord would be Zoom vs Jitsi. Zoom has only a few features that Jitsi lacks, and they could trivially be added if Jitsi had about 10 times more funding. Meanwhile, Zoom has all the marketing budget and weak network-effect capture and is mostly just grotesque profit. 90% of the time, everyone could just move to Jitsi, and all Jitsi needs is some modest funding and marketing. There’s no awful distortion field in that case that I see.

3 Likes
#3

I’m not even sure it’s that. The biggest problem I see is people expecting extra work from volunteer programmers on non-programming tasks, when they are already feeling overwhelming by them within the projects they work on. As I said in the 'verse;

There’s a whole layer of social development work in Free Software that needs to be acknowledged and valued, both by coders and users, and ideally funded along with the funding of nuts-and-bolts technical development. Until that happens, coders and users can only continue to talk past each other and play tennis with these community management tasks that each side thinks is the other’s job.

Where this connects with Ariadne’s concept of the Reality Distortion Field is that she’s pointing out the blind spots programmers have when it comes to UX. But this isn’t a problem that can be solved by telling them off and expecting them to do even more (unpaid) work. The likely consequence of doing this is a reduction in the number of programmers willing to work on Free Code projects, so it’s an existential threat to everything we’ve accomplished over 30 years, and I wish people would bloody well stop doing it.

2 Likes
#4

Welcome to Social Coding, @strypey, and happy to see you here :hugs:

I agree with you for the first part. This is why Social Coding Movement was started. The last part is not being implied though. It is part of the wicked problem to be solved. There’s a common process or a prevailing pattern in the project lifecycle of many FOSS projects, that leads to frictions and the perceived gap between ‘techies’ and non-technical folks (or other stakeholders).

Many FOSS projects start on the basis of a developer being motivated “to code cool things”, “to learn new technology”, “to create a popular FOSS project / be a FOSS maintainer”. And that is great, and goes fine… up to a point.

The focus and scope of this movement is on those projects that want to transition beyond the levels of “personal hobby project”, towards FOSS projects that are (holistically) sustainable in the long term. And where this sustainability also naturally includes the ability to earn a decent living from that work.

2 Likes
#5

Great. This is an interest I share, as you know. It’s a big motivator for the hosting co-op I’m in the process of bootstrapping. I want to apologize for the strident tone of some of my recent posts. I hope that final sentence of that last comment here gives some indication of why I get so fired up about this stuff.

I presume you’ve already started looking at case studies of Free Code projects that have assembled a sustainable community? Examples off the top of my head include;

  • Firefox/ Mozilla
  • Linux and its Foundation
  • LibreOffice/ Document Foundation
  • VLC/ VideoLan
  • Blender and its Foundation
  • Drupal and its Association
  • WordPress and its Foundation
  • Koha and its Community
  • GNOME and its Foundation
  • WikiMedia and its Foundation
  • KDE/ KDE_e.V.
  • Apache and its Foundation

If we can identity some common properties in their origin stories, we can start identifying social design patterns and antipatterns, and documenting them. For example, one of the problems Nolan identifies in the blog post I linked above is;

One reason this situation is so frustrating is that, increasingly, I find that issue triage takes time away from the actual maintenance of a project. In other words, I often only have enough time to read through an issue and say, “Sorry, I don’t have time to look at this right now.” Just the mere act of responding can take up a majority of the time I’ve set aside for open source.

So I presume that one pattern we’ll see in all successful Free Code communities is a division of labour in which those with weaker technical skills triage issues, freeing up the core contributors to spend their time fixing them. Another pattern I’d expect to see is regular use of a community forum or chat group, so that issue trackers don’t get flooded with general chatter, user helpdesk etc.

4 Likes
#6

Nolan is an inspirator, and we have more references to their articles, in:

Not specifically. Social Coding Movement was planned to launch as a co-shared community, yet for several reasons that launch never officially happened. Social coding wants to focus not only on the entirety of the Free Software Development Lifecycle (FSDL), but also the emergence of ecosystems where FOSS can thrive. If the ecosystem is unhealthy, the FOSS projects are too. Fediverse is an example, where currently we are in precarious situation to lose the ecosystem we created ourselves from the ground up (very rare), to the regular corporate forces.

My notes on major Fediverse challenges allude to why we are in this weak position. All of these challenges are social in nature, btw. Ironically the Fediverse is also the technology landscape that has the potential to offer the socio-technical support needed to tackle these challenges at scale.

Part of the wicked problem that ails grassroots FOSS/Free Culture movements is the eternal fragmentation, reinvention of wheels, people unaware of other initiatives or trying to lure people away from them to their own ventures. We have a Splinterverse. See also: FOSS Strategies: Why does Big Industry work and Big FOSS ecosystems don't?

One interesting insight I found when looking into alternative adoption models. In FOSS we can’t have the same systems as Big Industry has. We don’t want hypercapitalism, and our culture and values are completely different. And with our social dynamics. There are other adoption models based on a hedonistic motives for collaborating in an ecosystem. In FOSS in particular it is intrinsic motivation that leads to participation.

Wrt the examples you found… yes, they are potential case studies. But also they are really big projects all, and not typical for the stages where projects start to face real difficulties. They are much further along an evolutionary path, if you will. Also some of these examples display “flaws” to be avoided (which makes them interesting case study, btw). Think Mozilla which some argue only exists by the grace of Google’s funding.

Oh, we have a thread going to ask input on this movement’s possible direction: What do you expect or hope to see in Social Coding Movement?

1 Like
#10

Indeed, it’s a chicken and egg problem. How do we develop the socio-technical toolsets to do good toolset development?

For sure, but that’s exactly why I think their histories can be mined for useful insights. Some of them started out as proprietary software (Mozilla, Blender, LibreOffice). How did they assemble a community around the liberated code? How did itch-scratching hobby projects like Apache and Linux grow to what they are today? What evolutionary stages did both types go through along the way?

It would exist without that funding, but it would work very differently. Arguably it would be more community-run, instead of being run by NGO-industrial complex types.

1 Like
#11

Welcome to the conversation :slight_smile:

Absolutely! Thanks for this link, plenty of great thinking collected on that page alone.

1 Like
#12

Coming back to the Ariadne’s concept of the Reality Distortion Field, my understanding of what she identifies in the thread is a tendency for most people’s expectations of UI and feature sets to evolve over time, as they are conditioned by the UX they have on the dominant platforms, while the UX of Free Code alternatives - and therefore the hardcore of ethical tech evangelists who only use those - stays static. Over time, the gap between the UX people expect, and the UX that Free Code apps offer, gets greater and greater. But since the fundamental features of a chat platform (for example) stay roughly the same, Free Code evangelists will promote apps as replacements that seems like antiques to the people evaluating them.

One possible way out of this is for ethical tech developers and promoters to actively experiment with proprietary platforms (in a way that keeps them from becoming dependent on them of course), to gain a better understanding of UX expectations. Another strategy could be to develop a practice of UX design that is completely separate from coding. There are various (mostly proprietary) tools for designing UI as wireframes with no functional code. People with no coding skills could learn to use these and design app UI, which back-end developers could then use as inspiration - or even just adopt if they’re released under a suitably freedom-respecting license. Ideally, we could create an entirely Free Code suite of these user-friendly UI design tools, which could be hosted as part of code forges like CodeBerg (or even built into the forge platforms like Forgejo that they use).

#13

Agree on what you are saying.

I think that when we consider software development in general, numerous stakeholders are involved. Many people in different roles that bring their own expertise and skillsets. The better these stakeholders are able to communicate and collaborate the higher the chances that the delivered solutions match needs and expectations.

Companies organize around these stakeholders and development processes and even they are struggling to streamline delivery of high quality end products. In FOSS, grassroots movement, there’s no organization structure around the stakeholders. Hardly anyone is paid to persist and spend time and effort to do the hard work and the chores involved. It creates a radically different environment and dynamics to take into account.

Stakeholders need to find each other on their own accord. Without payment, as volunteers, they need to find proper motivations and rewards to be in this way involved. And incentives that keep them going, when demands grow as a result being successful in what they do. In this coordination of the whole developer process is where a lot of things are lacking in the FOSS movement.

I think I understand much of the dynamic that leads to “reality distortion”, and the often harsh criticism that FOSS paricipants reap from their voluntary and passionate efforts, is quite frustrating to behold. Yet also in a way somewhat understandable when you adopt the perspective of people using FOSS products. (I have also ranted myself at times, e.g. about Gnome giving me hard times yet again. It is to my shame, but I’m only human too :sweat_smile: )

The suggestions you make about improving UX are good and proper. When considering the entire Free Software Development Lifecycle (FSDL) there countless good/best-practice patterns lying around, waiting to be collected and recommended for use. The problem is: How are they collected? Who is doing that work? Why would someone be involved with that? Why would they do the chores?

Here we bump into the same kind of incentive system that is a requirement for a well-oiled crowdsourcing of that work.

This work cannot be done as a traditional community organization, as these don’t have these incentives in place and would require facilitators working full-time to coordinate, animate and do the chores. Hence this initiative hasn’t been formally launched yet, and is a DoOcracy until then. As mentioned in the feedback topic I am interested to look into the concept of Software Guilds as a natural way to crowdsource collectively, with a motivational framework in place to let that happen.

1 Like