(This is a copy of a topic I just posted to the Spritely community in the Social Framing category)
Contributing to Social Framing this topic consists of two parts:
- Envisioning a Peopleverse as a socio-technical outlook.
- Clarity on strategy (mission?) of realizing vision. Technology adoption.
Peopleverse is not a name for a technology direction, but an abstract concept of human-scale social technology that fits people’s daily lives and ties the online and offline worlds seamlessly together.
Spritely is a perfect technology that allows spanning up a Peopleverse, but that requires widespread adoption and strategies to tackle the risks that this doesn’t happen. Questions are:
- What is the technology adoption model of Spritely technology?
- Where is the sweet spot between formal spec work and community engagement?
- Given a competitive technology landscape how soon should Spritely broaden their audience?
With Fediverse mainstreaming there’s discussions that “Fediverse” is badly named, too technical sounding. On one hand I agree, on the other hand it is a passed station. The name stuck, and maybe organically another name will be adopted in time. Who knows.
But fact is that there’s a lot of technical focus when talking anything Fediverse. Servers, instances, timelines, federation, decentralization, boosting, etc. Not at all relevant for non-technical people that use fedi apps. What they get is a social experience. Federation is a technical concept, and should ideally be abstracted away from average people. Same as apps. What are apps but siloes of features? In an interoperable “social fabric” there might no be any apps. App-free Computing as coined by Chris Gebhardt of infocentral.org.
What I notice on the Fediverse is almost a complete absence of talk about where Fediverse might be in 5 or 10 years. And a general lack of imagination of what the possiblities are, which opportunities are within grasp. The technical focus and the pragmatism of FOSS devs may be the reason. The naming doesn’t help.
So how do FOSS devs generally envision their app? Well, we have ActivityStreams and Mastodon. How can we model our app features on top of that? There’s a dogmatic focus on what corporate Social Media have already done before. Completely foregoing the fact that we just have a core vocabulary here (AS) and an app in a Microblogging domain. That AS/AP is linked data where any semantic vocabulary extension can be modeled for new domains. And in a way to create interoperable building blocks where task-oriented services become available for people.
The Fediverse at large would benefit from having a shared (technology) vision.
Spritely luckily has an exciting techology vision that can be gleaned by outsiders. Though frankly it leans towards a more technical vision. But there’s the “Growing of a Networked Garden” and “Networked Communities” that lead to “Social Media Done Right”. And in the Spritely project Fantasary shows a technical vision of how far that can go.
I wouldn’t use the term “Social Media”. I use “social networking” instead, which is what humans already do for 1,000’s of years, and now also do online. Social Media are the Twitters and Facebooks where you broadcast yourself and get fed ‘engagement’ by the platform algorithms.
What should humane technology offer? An enrichment to our lives. The technology can only ever be supportive to our social interactions.
For the Fediverse (technical perspective) I defined a vision this social fabric to enable the emergence of a Peopleverse (social perspective). The peopleverse is an abstract, ethereal concept, indicating all those places where the technology seamlessly serves our daily lives and human activities. In this idea the Fediverse ‘spans up’ the Peopleverse, if done right.
The Spritely Institute landing page mentions “social media done right”. No. I think that is not enough. This is not about “media”, but broader. The title of an article I wrote is how I would phrase the urgent need we have:
I would like to mention a risk you may be well aware of, but mentioning nonetheless. If these risks are strategized internally in the institute, it may be an idea to discuss them more openly.
The Spritely community (or movement?) is a research community. Discussions are on deeply technical, academic levels to the extent that average devs are like “Very interesting, and all I can do is wait and see where this goes”. Spritely isn’t accessible to the average technologist yet.
It is understandable, as there’s so much of that deep technical work to be done, and Spritely Institute just started can’t handle a full-blown diverse community yet. AFAIU a gradual broadening of scope to encompass more diversity in skills and backgrounds is the strategy. Keep things sustainable, a prudent approach.
Spritely started as a kind of decentralized web successor to the AS/AP-based social web, a “Fedi vNext done Right”, yet with much more universal and fundamental technology base. A complete rethinking of the technology stack with exciting possibilities for decentralized computing. And… opportunities.
But the crux imho on that last bit is massive technology adoption. With Spritely technology comes a paradigm shift. A new and different approach to writing distributed apps. For real success in terms of adoption people it is not enough for people to “sprinkle a whiff of Ocaps” in their solution.
There is some real competition with other emerging technology / tech stacks. In that light the speed of evolution of Spritely should be weighed against the speed of adoption of the ‘competition’.
If we take the Fediverse as example. It looks like critical mass has been achieved (thanks Elon!) and adoption is moving beyond FOSS movement into corporate space. Things are going very fast now. Probably the first thing that companies with plans for the Fediverse will figure out is that after AS/AP became W3C Recommendations the “technology substrate” stalled, and there was only ad-hoc interoperability with apps coding their own AS/AP flavour and introducing Protocol Decay, i.e. tech debt at protocol level. I took notes on the stalled technology substrate.
“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.”
It is highly likely that corporations will take over the reigns from the FOSS movement in organizing the standards track. Which is a pity as that would be a missed opportunity for FOSS community to stay in control of the technology landscape they helped bring to success from scratch.
For Spritely the risk is that the Fediverse evolution moves onto a competing standards track, with maybe a DID and Verifiable Credentials, Self-Sovereign Identity direction, which are all picking up steam in various corporate and e-government circles.
Another example I’d like to give is Solid Project. The idea is very interesting, but from the start the objectives and scope weren’t really clear. I have argued about that in their community forum. On one hand a “control your own data” identity vault was a comprehensive scope, but the undertone was also “rebooting the semantic web”. In other words introducing a completely new paradigm, competing with Spritely.
My biggest gripe with Solid Project was their entire focus on writing specs and meanwhile neglecting community-building. I see the team or core members as aloof, largely unreachable by the community. Again, this is understandable, as there’s so much fundamental stuff to figure out.
But imho the inward, technical focus is hampering widespread technology adoption. Community members come, excited, and then they leave again. Possibly forever. Solid Project is also strategizing for a commercial application-first technology adoption. Which may be a sound approach, idk, but in my experience it is often enthusiastic developers that drive adoption from a bottom-up direction.
Solid Project and Fediverse are two extreme opposite in the way that technology evolution takes place. Both have problems. On one hand the (very) formal steering body of Solid creates ever more intricate specs, and on the other hand the Fediverse slides into ever more protocol decay by ad-hoc app development. I depicted this in a diagram some time ago:
For the Fediverse I questioned “Why can’t we seem to evolve the technology substrate?”. I came up with a set of major challenges for the Fediverse to overcome, none of which are really technical in nature. They are social problems, that may have socio-technical support to help overcome them.
The biggest insight was that in a grassroots movement (of fedizens in this case) the dynamics and culture as such that alternative technology adoption models should be applied. Models where the motivations to start and sustain FOSS projects are taken into account, and the proper incentives to contribute beyond direct project scope must be provided. And the expectation of the win-win to do so, must be clear.
Also, related, that the FOSS movement is strong in its technical abilities, at the project level, but extremely weak in all the non-technical areas and in collaboration on ecosystem levels where the technology landscape matures. Why can Big Industry have global supply lines and profitably exploit ultra-complex factories, and a small-scale FOSS project cannot even sustain itself?
For this reason I started Social Coding Movement. The movement will consider the entire Free Software Development Lifecycle (FSDL) and find best-practices and tools to support it. Social coding practitioners (projects, communities, software guilds) will crowdsource these to the Knowledge Garden, a pattern library.
In summary, what is Spritely’s strategy to tackling risks to come to widespread technology adoption? What is your adoption model, and what does that mean for approach in building the Spritely movement? Where is the sweet spot between formal approach and grassroots development (see diagram above)?