@smallcircles @sri @ben imho, current situation is quite like at the very begining of Mastodon when GNUSocial advocates where fighting hard the new tech, because they want the old one back.

One big problem is seeing AtProto as a replacement/competitor and not as a friend.

@jsalvador @smallcircles @ben We have a lot of folks who like to cling on to the old stuff instead of marching forward. Technology isn't meant to be standing still. We have to keep evolving our software but also the communities around them should also grow too.

Community can be a double edged sword, it can be both extremely powerful but there are instances when it can be toxic as well.

@smallcircles @jsalvador @ben These are really great reads. Thanks for sharing.

One thing I've always told our people working on the Linux App Ecosystem is to manage for success. Once you start creating a market, you should assume that you will be co-opted because you've proved that the market worked. It's easy for others to put in the work and jump in with your extraordinary resources and pull people away.

@smallcircles @jsalvador @ben

My cousin had some idea about some app related to health care and she was worried about someone stealing the idea. I said nobody is going to take your idea and steal it because they would hold all the risk.

But if you went through with the idea and it makes money that's when people will steal the idea because you took the risk and it panned out and so investors will come in and pay for a competing product if they are locked out of the idea.

@sri @jsalvador @ben

Thank you. I agree, both on the market and esp. on the nature of ideas. Though before there is a market you have a technology adoption model (TAM) where pioneers evolve the technology base and thereby prime the market that will eventually exist, then early adopters follow, etc. For #fediverse we are still in this very early stage, even though some products e.g. Mastodon are quite mature. And able to influence the type of market, market conditions. Take the #Flohhmarkt project, for instance, aimed at an audience of individuals buying, selling, bartering stuff via classified ads. They also receive @nlnet support, and the technology they R&D might be such that is isn't directly attractive and applicable for hyperscalers, allowing early entrants to establish good positions and mature services that allow them to compete should a hyperscaler enter the market as a laggard.

@sri @jsalvador @ben @nlnet

It would be even better if on #fediverse as a whole the developer ecosystem were able to move beyond the app-centric development model that dominates. Basically the app-centric approach constitutes a "poor man's TAM", facilitating technology uptake on the basis of how #FOSS projects are typically developed where the individual devs are in charge and there's hardly need to coordinate and collaborate at ecosystem levels. Here the grassroots environment within our ecosystem failed miserably. Apparently we are too fiercely independent to be able collaborate at scale. When a big player joins you get app-by-app competition, and their product development process is likely to easily blow the FOSS project out of the water.

If we had a more service-oriented #ActivityPub fediverse, a fedi of apps and services, then - depending how this is designed - it might be much harder to 'win' the market, as the competition becomes more on quality of service than feature sets.

@sri @jsalvador @ben @nlnet

The fediverse has been weirdly stuck for many years, driven by app developers who attended first and foremost to their own app projects and only secondary to the technology base the entire app is built upon. There was also hardly funding to do anything else. It may be pragmatic approach, but its not smart, eventually weakening the entire ecosystem. And here we are today, with a mountain of protocol decay and tech debt holding us back.

For many years people, me included, have argued that we should focus on getting robust extensibility mechanisms in place, fill the #ActivityPub holes, and not handwave it to say "yeah it is #LinkedData this and that sorta kinda". #Interoperability requires way more rigour at the protocol level.

Nice effect that #ATProto had, was it opened people's eyes to the benefits of having a sound technology base. The ATProto ecosystems excites newcomers, whereas fedi only frustrates with its high barrier to entry and whack-a-mole dev.

@sri @jsalvador @ben @nlnet

Today we see a big uptake in interest in the #ActivityPub C2S part of the specs, to implement the Social API, and there is again an opportunity to reboot and give the ecosystem a big boost.

I'd say the most important projects in the #ActivityPub ecosystem are the ones where people focus on building reusable libraries, SDK's and developer tools that honor the original promise of the AS/AP specs: to allow heterogeneous decentralized social networking. The conceptual architecture of fedi of "addressible actors exchange activities with object payload" is ultra-powerful, a universal distributed message bus of sorts. And the easier it gets to model services on top of this model, the more excitement and new entrants we'll see in the ecosystem.

I am highly in favor that we not dogmatically focus on keeping compatibility at all cost to the existing installed base, where somehow this powerful architecture has devolved into "social media microblogging" galore.

@sri @jsalvador @ben @nlnet

What is interesting re:Technology adoption models is that #fediverse with its app-centric evolution de-facto follows the TAM that is typically practiced in the business world. The success of fedi depends on the individual product development of fedi apps. This while #FOSS is typically very bad at product development, and this partly due to the (social) dynamics being very different than in the biz world.

There exist very different TAM's that DO take the social dynamics within grassroots movements into account, aligning much better to our environment, for example taking Joy and Curiosity into account as motivators why people start FOSS projects. See: https://discuss.coding.social/t/challenge-fixing-the-fediverse-technology-adoption-lifecycle/38#alternative-adoption-models-4

At Social coding commons by means of Social experience design a new type of TAM is part of the research effort. One that is explicitly tailored to a grassroots ecosystem that develops the technology base on which it stands, and create positive feedback loops and flywheel effects.

@sri @jsalvador @ben @nlnet

In my opinion where it concerns social network innovation, when we continue to follow the app-centric model we have today we enter a dead-end street. Though it gives interesting applications it will not constitute the future of social networking.

To me it is really crazy that a new fedi app that, say, enters a Video domain would need to adopt Peertube namespaces in their #ActivityPub extension model. If you look at that model it is no different than taking on dependencies in regular #FOSS development. As soon as the Peertube namespace is in your project, then Peertube is in charge of that part of the design, an upstream dependency. But Peertube doesn't care about you. It is an end-user product doing their own product development.

And then things worsen when the new fedi app entry pushes their own extension properties into this ball of mud. It is a design approach that basically assures loss of interoperability and severe whack-a-mole pain to devs.

@smallcircles @sri @jsalvador @ben @nlnet whats the alternative then ? Feditube?

@virtualpierogi @sri @jsalvador @ben @nlnet

When it comes to #interoperability there is no way around having consensus on what you interoperate on, and there must be alignment on some kind of Video related domain model that is robust and consistent.

If there were a robust #ActivityPub extension mechanism as well as good development practices and processes for the creation of extension into new business and application domains, then this mechanism can still facilitate app-specific extension on top of such a Video domain specification. It is very common for protocol design to have all kinds of extension points, look e.g. at #ATProto or #CloudEvents.

And more specialized domain extensions can also facilitate further extension in their design. Look e.g. at #ForgeFed AP extension, which allows custom forge-specific metadata collections to be sent with a federated Issue or PR.

@virtualpierogi @sri @jsalvador @ben @nlnet

It needs concerted effort, as argued in my blog post, to set all of this up. Things can start small and pragmatic, and then gradually evolve and mature, but we should take care it evolves in the proper direction.

There are trade-offs to consider every step of the way. If there'd more capabilities to introspect the functionality that an #ActivityPub actor offers, it would diminish the need for an upfront design-by-consensus process, but it would increase the complexity of the specifications.

I drew this in a diagram a couple years ago, and transferred it to our social coding forum at: https://discuss.coding.social/t/wiki-grassroots-standardization-processes/672?u=aschrijver

Here you see the fediverse devolve into non-interoperable app-by-app whack-a-mole development, keeping track of all the moving-target #FOSS projects one took a dependency on. Versus the #SolidProject that tries to hammer out full-blown specs upfront, which became a huge package to deal with, with high complexity to implement.

@virtualpierogi @sri @jsalvador @ben

Unfortunately there's a new threat, and it was addressed in the #FOSDEM keynote speech by @michiel of @nlnet .. and that is the mad dash to incorporate #AI into everything and vibe-code stuff together in a heartbeat.

I think this is particular bad for the fediverse #SocialWeb still lacking its robust foundations. The #LLM's will have no problem figuring out how to mix'n mash the existing protocol decay and tech debt into new applications that are rushed into production. Finally non-protocol-experts are enable on the ecosystem and can onboard themselves without involving themselves in endless plumbing of the most low-level technical implemention details of #ActivityPub devs.

But the ecosystem will rot and decay as a result of it. Furthermore if a slew of AI-generated fedi apps are launched in quick succession and some of them find good uptake (until they break in unexpected ways), it will serve to attract unwanted corporate attention I'm afraid.

@virtualpierogi @sri @jsalvador @ben @michiel @nlnet

By their design #LLM's will always follow the old way of doing things here, and I really wonder how this is going to turn out. People should be very wary here. #AI application trends towards a point-of-no-return, where only the AI can still keep track of the generated code mess.

A good example here is this Microsoft distinguished engineer saying that their aim is for one dev employee creating 1 million lines of code in one month. Once you get there, you cannot ever go back without ditching all AI stuffz and starting over.

Btw, the talk by Michiel Leenaars is mentioned my blog post, but I'll drop it here too. A very interesting recommended watch:

https://fosdem.org/2026/schedule/event/FE7ULY-foss-in-times-of-war-scarcity-and-ai/

@smallcircles @sri @jsalvador @ben @michiel @nlnet
Ive seen that godot is passing through the same problems , the first solution that comes to mind is whitelisting the commits that come from real coders that contribute quality code. So you have to apply for a green card so to speak to commit your code.

@virtualpierogi @sri @jsalvador @ben @michiel @nlnet

Yes, I've noticed that in #FOSS realms there's a rapid change to the development processes that are followed. Where projects no longer allow people to just contribute PR's.

In many github projects for instance you should first start a Discussion and get dev team's consent to create an Issue, which you may then create a PR for. Any other direct contributions are either disallowed or immediately closed.

There was also this Vouch reputation system that got popularity real quick. And there'll be more changes like that I think.

https://github.com/mitchellh/vouch

https://news.ycombinator.com/item?id=46930961

I've been looking at #ForgeFed and how it is set up. Currently it models very much the application model of what constitutes a typical "Code forge", but this is restrictive and going from lowest common denominator between forges. There's opportunity here to focus on the domain of "Software development" and the (social) coding processes between all stakeholders.