SX perspectives: App-centric fediverse vs. needs-based peopleverse

Social experience design 🎭 Peopleverse vision
, ,
#1

Meme displaying a wall plug full of connectors plugged in and wires all messy. The text reads "ERR 404: SOCIAL_WEB_NOT_FOUND. Reboot your fediverse and try again".
Meme displaying a wall plug full of connectors plugged in and wires all messy. The text reads "ERR 404: SOCIAL_WEB_NOT_FOUND. Reboot your fediverse and try again".888×499 76.8 KB

Microbloggoverse entanglement

Not long ago SocialHub featured a long thread about fragmentation of SocialHub discussions due to the forum being federated. My own observation was that “becoming part of the fediverse” was a mixed bag (and on itself a fairly meaningless statement). On one hand we finally removed the member sign-up barrier, so that any fedizen can participate from their own fediverse account. On the other hand the “sense of community” deteriorated and AP-related developer discussions become more dispersed in fragmented fleety microblogging channels than they probably were before, without building an archive and knowledgebase of these discussions.

This morning I happened to notice one such interesting discussion where @jdp23 tried to bring the discussion into SocialHub’s context by adding mention of the appropriate AP actor for the #fediversity category. It did not have the desired effect, and rather served to cause a load spike that may have dragged the forum down (a known issue). Jon writes:

(In a discussion on SocialHub, @trwnh asked what kinds of developer-focused discussions were happening elsewhere on fedi and what the barriers were to bringing them to SocialHub. This is certainly a good example! So, as an experiment, I’m going to try tagging @ fediversity @ socialhub.activitypub.rocks to see how that works.*)

[…]

* EDIT: it didn’t work. In fact it may well. have caused a load spike on SocialHub that made SocialHub unavailable for a few minutes, although it’s possible that was just coincidence. In any case I edited this post to remove the tag to keep anybody else from unintentionally also temporarily crashing SocialHub!

Technosphere vs. sociosphere

For a long time it struck me how the fediverse isn’t designed as one usually designs software. It is more that what emerged in the early days - based on working early ‘prototypes’ that explored the ActivityPub protocol, such as Mastodon - was taken for granted. With a working proof-of-concept that communicated in federated fashion taken as-is, the fediverse was seen as ‘universal wall plug’ for connecting apps and fedizens. Any announcement of a project or product “joining the fediverse” a reason to celebrate.

:question: But what does it mean to be federated?

Today an app-centric development approach determines how the fediverse evolves. The protocol and existing installed base is seen as a technical connection point to code support for. And app developers are focused on bringing designated app features into federation. Mostly first to federate between their own app’s instances and then opportunistically with other apps where there may be interoperability. Every app feature - scoped to the particular FOSS project - pushed onto the wire in this ad-hoc tech-focused manner introduces protocol decay and contributes to “Big ball of mud” and “Whack-a-mole driven development” (retain app-by-app interop against moving targets) anti-patterns that makes the next integration more complex than the one before.

:eye: The current fediverse represents a technosphere.

Today we have created a fediverse that allows app developers to advertise their federated product features. The app dev is the primary stakeholder, and their Needs drive development. These in turn indirectly represent Needs of people using their app (“users”) via product development or ‘issue-driven design-by-consensus’ often seen in FOSS projects. The secondary stakeholder group are usually called just “Users”, an easy app-centric abstraction that developers love to use. “Users” do not equate to “Fedizens”. At best fedizens are considered tertiary stakeholder group, but mostly app-centric development considers them to be just potential users. On the app-centric fediverse it is all about the app.

:point_right: A future peopleverse represents a sociosphere.

The current app-centric fediverse has a measure of success. Social networking use cases of existing centralized platforms have been successfully ported to ‘federated space’. A communication medium resulted, having the characteristics of a Microblogging platform, representing an ‘application domain’. It is fair to say that app-centric fediverse evolution has a viable future. Yet I would add that imho an exclusively app-centric fediverse does not represent the future of social networking (and even stronger I think such ‘technospheric approach’ has no future at all, where we get the fediverse we dreamed of). Above all the approach does not do justice to the promise of the ActivityPub protocol to provide us with an interoperable social graph of addressible actors to exchange meaningful social activities with. And then model anything on top of that foundational technology base. More specifically, to use using domain-driven design terminology, to model ‘business domains’.

SX envisions a peopleverse where the needs of people in their daily lives are central and social networking technologies are supporting them online. SX is a solution development method that - based on the SX Pyramid of perspective - starts to investigate personal needs of all people involved in a solution, and then scales to take inter-personal relationships into account, to ultimately consider how societal constructs are modeled that can satisfy these needs. SX thus rises above app development and includes entire ecosystems and grassroots movements to its scope. Only here a true peopleverse may emerge over time.

#2

Cross-linking to old “Community has no boundary” advocacy that is an example of a needs-based design approach to deliver solutions, instead of tech-focused plumbing to connect apps to other apps…

Must read is the following SocialHub thread, that contains a ton of useful info:

At the time I made the beginnings of a crowdsourced design doc at fedi.foundation (which wasn’t finished because of lack of interest to participate in a multi-author developer portal).

Quoting the most recent post that relates to the observed community fragmentation that is the result of forum software “adding federation support” from a pure technical and app-centric perspective.

I will necro-post on this thread. For a long time, in the context of Groups support for the fediverse I have stated that we need more than just group support bolted onto a microblogging use case. That a paradigm shift is needed, where we recognize that Community is everywhere, and has intricate meaningful relationships to other Communities and actors across the fediverse. A paradigm shift I dubbed…

:point_right: “Community has no Boundary”

We must design meaningful community spaces, where people in the right social context can communicate effectively and engage in collaborative creative events in safe spaces.

In recent days in various discussions I mentioned the implicit but very detrimental “Big Ball of Mud” anti-pattern to the evolution of the fediverse, that is the result of an incomplete grassroots standardization process.

No one is taking care of the design of the fediverse as a whole.

Here I’m talking about the conceptual design, not protocol plumbing and tech details on the wire. What are we building all of us together? What does it mean to become part of the fediverse? We do not ask those questions enough → we do not focus on the design of the social layers of the tech stack!

By just focusing on glueing our apps together with other apps we are able to duplicate existing corporate social media, and add an extra beneficial sauce of decentralization benefits and richer features sets through basic levesl of interoperability.

This is the topic that has my fascination, the major fedi challenges. What we see and facilitate through the FEP Process is natural organic emergence and discovery of best-practices that are funneled into a standardization process. This is what we want… a fediverse of cocreation and value exchange between communities.

:point_right: “App-free computing”

But the problem starts by how we subsequently consider fediverse as just some Ethernet LAN where we attach our plug’n play App device to. Or a wall plug to get to the juice…

[duplicate image removed, see top post]

Going beyond the limiting abstraction of the app. Another theme I’ve long been advocating for. It is now part of my “working in commons” activities around elaboration of Social experience design (SX) methodologies, and focus on these missing social layers of the Open social stack. Most importantly though, to adopt a design approach that is focused on Needs of all participants engaged in social experiences together. SX provides a form of needs-driven development.

That is a totally different perspective than “I attach my Forum to the fediverse, and now I am part of the fediverse”. The app by app integration approach. Where the represented needs are those of the App developer who wants to push as many features as possible onto the fediverse, but may be less interested how other apps deal with, and what the overall impact is on how social experiences satisfy the Needs of a particular use case.

In the SocialHub community fragmentation discussion the pros and cons of the technical wire implementation of the ActivityPub plugin can be discussed and weighed to evaluate whether it turned out net positive or net negative to healthy community formation. But it a whole discussion after the fact, where ad-hoc coding without design of the social layers / conceptual architecture of the fediverse is now the reality to deal with.

Effectively what it boils down to when you consider the whole fedi dev community as a whole, is that highly distributed teams with different cultures, different programming languages are coding microservices they launch into production, without design for their interaction with others. That can never come beyond a fedivers that just marginally works, imho.

#3

Image of ballet dancers choreographing a performance. Title text reads: "Distributed, domain-driven, and event-driven software and human systems". Further texts read: "A globally choreographed dance where small dancers orchestrate solo steps in their local workflows, and in concert with each other. We know when to move and when to hold our poses, in service to the WHOLE system.
Image of ballet dancers choreographing a performance. Title text reads: "Distributed, domain-driven, and event-driven software and human systems". Further texts read: "A globally choreographed dance where small dancers orchestrate solo steps in their local workflows, and in concert with each other. We know when to move and when to hold our poses, in service to the WHOLE system.1122×651 82.3 KB

:bust_in_silhouette: ← Autonomy vs. Connected ecosystems → :people_hugging:

Following up to discussion on shared vision and substrate formation on a paradox I’d formulate as:

The paradox of decentralization is that the more a technology ecosystem decentralizes, the more need there is for cohesive coordination to assure that the foundational technologies can support that decentralization, without the ecosystem falling apart.

I was just watching “Navigating sociotechnical complexity with DDD and friends” by Xin Yao (RECOMMENDED WATCH) and it occurred to me that a) the entire presentation is fully aligned to how SX is evolving, and b) slides made in a business organization and management context, also have a deep anology to the fediverse ecosystem and the missing socio-cultural and socio-technical richness in our technosphere development approach…

LinkedIn post by Mathias Verraes, CEO of Aardling, reading "Decouple and Connect, the paradox in large-scale software development. From an engineering perspective, software wants to be decoupled. From a business value perspective, software wants to be deeply connected. That's the fundamental friction that software design, and Domain-Driven Design specifically, attempts to address.
LinkedIn post by Mathias Verraes, CEO of Aardling, reading "Decouple and Connect, the paradox in large-scale software development. From an engineering perspective, software wants to be decoupled. From a business value perspective, software wants to be deeply connected. That's the fundamental friction that software design, and Domain-Driven Design specifically, attempts to address.1129×665 265 KB

The fediverse constitutes large-scale software development at an ecosystem scale. Fediverse app developers are first and foremost focused on the abstraction of their own “app” and decoupled federation features in that app’s context (i.e. have well-designed apps).

What they certainly don’t want is whack-a-mole driven development (WDD), caused by protocol decay, that resulted from ad-hoc app-centric development practices - the tech debt introduced by predecessors who “joined the fediverse” before them. Yet this is what they get when ignoring concerns that are beyond direct project scope. For a healthy future of the fediverse we want all our solutions to be(come) deeply connected, and it becomes essential that coordination at ecosystem level takes place to design for that.

The bottom-up FEP Process represents a retroactive process whereby app-centric and ad-hoc interoperability features are refactored into slightly more generic and useful designs for the ecosystem at large, and advertised for adoption. The fitness formula is the adoption rate of the FEP document, and where other app devs fall in line they fix the tech debt. This makes the FEP Process inadequate and insufficient on its own. The FEP represents only a single gear in a larger grassroots standardization process.

Diagram credit Paul Rayner and Eric Evans titled "DDD bas born sociotechnical.. to decouple and connect". It shows a central square with 3 elipses connected to it. Central concept "DDD. Ubiquitous (attention to) Language" relates to business complexity where Strategic design models answer "What software are we building? Why are we building it?", then technical complexity is tackled by Tactical design models that answer "How do we build and connect software for long-term changeability?", and finally there is a social complexity angle where - in this diagram - Visual collaborative modeling is used to answer "Who work and create value together? Who else do we need to align understanding with?"
Diagram credit Paul Rayner and Eric Evans titled "DDD bas born sociotechnical.. to decouple and connect". It shows a central square with 3 elipses connected to it. Central concept "DDD. Ubiquitous (attention to) Language" relates to business complexity where Strategic design models answer "What software are we building? Why are we building it?", then technical complexity is tackled by Tactical design models that answer "How do we build and connect software for long-term changeability?", and finally there is a social complexity angle where - in this diagram - Visual collaborative modeling is used to answer "Who work and create value together? Who else do we need to align understanding with?"1121×653 103 KB

The diagram above above lays the sociosphere vs. technosphere split at Strategic design (“What fediverse are we building?”) vs. Technical design (“How do we build, connect to, evolve fediverse social web technologies?”). And then it adds a 3rd focus area to deal with the “social complexity” in the ecosystem itself where people must collaborate. Where the question becomes “Who work and create value together? Who else do we need to align understanding with?”.

:point_right: Ubiquitous attention to language is precondition to fostering connected ecosystems.

I recently commented again about the lack of common language in the fediverse ecosystem, resulting in endless Babylonian speech confusions. Interesting reformulation domain-driven design’s concept of Ubiquitous language.

:keyboard: Digital transformation fallacy → :robot: technosphere

An interesting observation in the video, which aligns to insights made for SX, is that a combined approach of bottom-up emergence and top-down design activities are needed. Xin Jao mentioned how there is a difference between software systems which are ‘complicated’ versus the (techno)social environment they operate in, which are ‘complex’. A complicated software system represents a “Ferrari”, while a complex social environment is like a “Jungle”.

The best approach to model complex social environments is in the analogy where we have a complex jungle with roads and created open areas where complicated systems help manage the jungle’s sustainable resource exctraction (to gather the juice of delightful “social experiences” :stuck_out_tongue_winking_eye:). In other words we have software systems as islands of organization to help turn chaotic commons into chaordic ecosystems. This aligns to the diagram on SX scope on the Social coding commons landing page, where the ‘sociosphere’ envelops the ‘technosphere’.

However - Xin Jao continues - people shy away from chaos and complexity, afraid of dealing with it. And to cope they simplify and imagine that complex chaotic jungle can be replaced by complicated automated Ferrari’s. They turn the SX scope diagram inside out in their approach, where layers tech envelop, contain and control the chaotic sociosphere. I think this can be clearly seen in the trend / hype / fad of Digital Transformation.

From now on I will call this the Digital transformation fallacy…

The digital transformation fallacy is the false belief that technology alone can solve social problems.


Update: I followed-up on SocialHub in this comment: