Challenge: Fixing the Fediverse Technology Adoption Lifecycle


These are just some notes related to my observation that:

  • On Fediverse Ad-hoc Interoperability dominates and hampers innovation.

Need to clarify some terminology that I frequently use relating to Social Coding #Foundations

“Any decentralized [ecosystem] requires a centralized substrate, and the more decentralized the approach is the more important it is that you can count on the underlying system.”

— Byrne Hobart. The Promise and Paradox of Decentralization

Glossary term Description
Substrate Both the people and processes that are involved with evolution of both ecosystem and open standards, and the deliverables they produce (specifications, documentation, reference implementations, etc.)
Substrate formation All the activities and processes that lead to a healthier substrate, and involves community-building, organization structure, communication channels, tools used, related projects, partnerships, etc.
Ad-hoc Interoperability Interoperability mechanisms that are invented on-the-fly and as-needed within an implementation project, and before they are part of the substrate. I.e. they are still application-specific and not readily accessible to others.
Universal Interoperability The vision of defining full semantic interoperability in a standards-compliant way. In theory the formal specifications allow deep integrations between heterogenous apps, as API semantics and heuristics are machine-readable.
Interoperability "Sweet spot" The proper balance between ad-hoc interop and universal interoperability, that allows individual apps to experiment and innovate and making sufficient information available at substrate levels for others to adopt that.

Ad-hoc Interoperability and striving for Universal Interoperability represent opposing directions into which an ecosystem can evolve. Both of these directions lead to a non-linear increase in the levels of complexity they bring.

I will not go into more detail in this topic, but highlight another insight I want to explore …

Technology adoption

So technologies follow this well-known model from inception to maturity that goes along a curve: The Technology Adoption Lifecycle. Another, more marketing-related, model that is often referred to is the Gartner Hype Cycle. Plotting them side-by-side:

Hype Cycle and Technology Adoption Lifecycle Plotted Together
(source: Mukesh Sharma, The Lifecycle of Technology Trends)

The technology adoption lifecycle is a sociological model that describes the adoption or acceptance of a new product or innovation, according to the demographic and psychological characteristics of defined adopter groups.

The Gartner hype cycle is a graphical presentation to represent the maturity, adoption, and social application of specific technologies.

Fediverse adoption

Thinking about Ad-hoc Interoperability, why it happens and what the impact is, I came to the insight that:

The levels of Ad-hoc Interoperability on the Fediverse result in a Technology Adoption Lifecycle that is broken.

Fediverse even after many years remains stuck in Innovation phase and some Early Adoption, but further maturity is only reached on the levels of indivual applications, in particular those targeting the Microblogging domain.

Technology adoption models are often used in business contexts, and have well-established methods to ensure their success ‘in the market’. And the corporations involved in doing so can afford money, resources and people needed to do so. Do rapid R&D cycles, dedicate to substrate formation, do large amounts of PR and marketing, etcetera.

In the free software movement and in particular with the grassroots culture of the Fediverse in mind the dynamics are totally different. A different adoption model is needed. One that - going from the definition - addresses the particular “demographic and psychological characteristics of defined adopter groups”. The needs, desires and expectations of fedizens and free software developers.

(On the Social Coding Foundations chatroom I discussed this with @dansup starting at this comment )

There are more consequences of ad-hoc interop and broken adoption model that I won’t go into, other than saying that imho they work to limit the imagination on what Fediverse can be. My criticism on Fediverse as a whole is that the technology is currently visionless. There’s no outlook on what it may bring. In my own advocacy I position as follows:

Fediverse (technical) → Peopleverse (social)

  • Social Networking Reimagined (technical): Strategic direction.
  • United in Diversity (social): Desired outcome.

Alternative adoption models

There are many alternative models that can be drilled-down to from the Technology Adoption Lifecycle Wikipedia page. They offer different perspectives and aspects that may apply better to the context of the Fediverse. Most of these models are based on solid research, yet I do not think they are directly applicable, but valuable only to provide handholds to improve the situation of Fediverse adoption.

Most valuable is going from the culture and look at why federated app projects are started and how they become successful.
Interesting alternatives are models that take intrinsic motivations into account Hedonic-motivation system adoption model (HMSAM) and matching motivations to expectations, such as Multi-motive information systems continuance model (MISC). Here’s a diagram that relates to HMSAM:

Overview of HMSAM, from Lowry et al, 2013

And the following YouTube video briefly presents the MISC model:

A post was split to a new topic: Question: Does having a technology vision help adoption?

Fixing the adoption lifecycle

On the premise above in this topic we’ll dive deeper in what is inhibiting the Fediverse to innovate and mature further, and how these issues can be tackled. Any ideas are welcome.

Some points mentioned in Matrix discussion:

  • [TODO]

Fixing the adoption lifecycle - part 2: Automating substrate formation

Copying from Matrix chatroom:

Related to this long fedi discussion, the fact that we need “substrate formation” but no one is really able to dedicate sufficiently to that, plus taking into account intrinsic motivations that drive a technology innovation lifecycle and taking the dynamics of FOSS/fedi into account with that…

An idea forming… So for REST API’s you can handcode them any way you want and many people do. On the other hand you might use OpenAPI and with that tap into a host of benefits. You can do codegen, generate docs, other folks can reuse/extend your API definition, etc.

What if the act of adding federation support involved something very similar? Where the data formats would be such that automated tools could pick them up, parse and transform them, and make them available elsewhere and to others automatically and in such way that they become part of the substrate? Without burdening the developer with doing so manually and while that at best only has beneficial outcomes to their own project in the very long run.

I was just browsing the web, going from the brilliant ideas of Bret Victor, coming to Ink & Switch and their tool Automerge, then looking at forks of that. Found the startup Living Spec. Now that’s going in a similar direction…

I also tooted the gist of this idea.

Looking at Living Spec, a startup about to launch, this is a snapshot of their product:

We can see how this might work if instead we’d have some (random, there can be more) aggregation space for Fediverse protocol documentation, extensions and best-practices.