For a while now I am arguing fiercely that the Forge Federation ecoystem needs to forge (no pun intended) an Ecossytem Alliance. With the involved projects entering entire new domains on the Fediverse, now is the best opportunity. And the best chances to avoid the major challenges that plague the Fediverse at large.
Today in Forge Federation chatroom I reacted to a comment by @Gusted which was in reaction to prior discussion about Mastodon:
And IIRC other Fediverse projects complained about [Eugen] pushing [Mastodon-specific] protocol extensions or something.
This is a real problem, in which something I mentioned earlier. Going from a toy project to a more “community” project, Mastodon is undoubtedly grown up software, however like with these actions it still acts as a “toy project” where decision get made overnight.
My response was:
It is true that Mastodon creates their own protocol extensions. Less true that they are “pushing them”. It is just that they are the biggest player, and others need to follow them to be compatible. This is called post-facto interoperability, where a dominant player leads the ecosystem.
Contrary to many others, and despite the fact that broader ecosystem collaboration would be a win-win to them, I do not hold their approach against them. They are their own FOSS project, make their own strategy, and they deliver a Microblogging app, so will design extensions that match new app features.
I feel it is the responsibility of the Ecosystem Alliance to be interesting enough and offering sufficient incentives for a broader collaboration beyond project scope. The Fediverse at large, unfortunately, has no alliance at all. It is everyone for themselves in completely ad-hoc, inward / project-focused anarchy. And it may be what eventually fully stalls the progress of fedi, sets it on a death march.
If a well-organized alliance was established from the start, with well-defined processes to turn project-specifics into ecosystem knowledge and tools, then outlook may be different. It would be a no-brainer to be part of the larger whole.
But, what is hopeful is that, more decentralized form of organization, i.e. ecosystem alliances in specific domains may be way more successful and much easier to organize and keep together. After all the scope of “Fediverse” is too large. If e.g. ForgeFed is discussing an AP Issue Tracking vocabulary extension, why would Mastodon have any interest in that at all? But Forgefriends, ForgeFlux, Gitea et al would pique their ears and listen intently.
You feel it coming… I am advocating - again - for such alliance to be forged for Federated Free Software Development. And I want to be part of the alliance with Social Coding and the Social Coding FSDL.
I also would like to mention that without a well-oiled ecosystem alliance in place, the forge federation space will imho almost certainly get in a similar post-facto intreroperability situation, where a major player dominates the space.
This will be like e.g. Mattermost Focalboard or Trelly finally gaining interest to federate their boards, to find all kinds of Gitea specific stuff in it. Or, if Trello is first in some new area of the FSDL vice versa, when that is also stuff that happens to be available in Gitea.
Below, knitting subsequent related comments together, so as to archive the discussion here (will not 1-to-1 copy the chat, too much work):
[if only a] well-organized alliance was established from the start, with well-defined processes
I’ll have to add that this should match the dynamics of the playing field, i.e. the culture we have. So not arguing for formal steering bodies and all that.
Less true that they are “pushing them”. It is just that they are the biggest player, and others need to follow them to be compatible.
Which is in fact pushing IMO. It’s like Google with Manifest V3 extensions, you could choose to still use Manifest v2, but as user you will need to use side-loading and as a browser(e.g. Firefox) you will need to be compatible, without having a say into that standard, which is just forcing something down to someone with extra steps.
I do not hold their approach against them
Their approach are in my book a factor of a toy project, to which I circle back to that there is no willingness to move away from being a toy project which implies certain problems as ^^ mentioned.
My follow-up:
I think it would be smart to care for the ecosystem, and it would be social too. But FOSS projects are independent, and they are not restricting the 4 freedoms or anything. I agree that it is very regrettable. But in the case that there’s no productive alliance that can make any decision and set practical steps forward at the ecosystem level, should Mastodon be responsible to arrange that? Or spend long lengths of time involving in the discussions, if they don’t yield furtile results for their project?
Though I hate to mention it, I’ve found there to be a different kind of “Tragedy of the Commons”. One that works at protocol level, not the usage of FOSS itself. Where people must reach beyond the scope of their own work, to uphold the health of the ecosystem that they ultimately depend upon. The substrate below their project. There is a need for substrate formation where this is organized and people collaborate.
Later, in response to @Gusted:
Well I can’t speak for Eugen of course, there should be a willingness for participation. If that works or doesn’t work out is pure speculation.
Here you could argue that the willingness exists. Both Claire (core team) and Nightpool are giving good feedback and mingling in the discussion where things are core to Mastodon’s concerns. Eugen himself is sort of doing so too, but that communication is in the Mastodon issue tracker, so not really accessible and insights not reaching the wider ecosystem for richer/broader interactions.
And of course, for any Fediverse project holds… any extension made is ultimately only found in codebases and, sometimes, short blurbs of docs, and aboveall cross-linked closed issues on the trackers. Every project is doing in small ways, what Mastodon does on larger scale because they are bigger, move faster.
Currently “Adding Fediverse Support” is becoming like this:
- Implement AS/AP et al
- Ensure compatibility with App A, test
- Ensure compatibility with App B, test
- …
- Fix breakage with new release of App C
- Arbitrage: Who is at fault?
- Risk: Both point to each other as incompatible
- Rinse and repeat in maintenance cycle that gets worse and worse
Ad-hoc interoperability means ever growing complexity, and going to an asymptote of having no interop at all, just one-by-one app integrations.
The protocols must be nurtured, be maintained, updated. There’s a ton of challenges there, as can be witnessed in popular protocols that cannot mature anymore as it would break to many old installs.
A recent, and imho very important insight, is to not consider AS/AP as an open standard to just implement. As implementer you must realize that you are holding a framework. Which means that you have to design for each and every new domain and if you want any interop with other projects at all, that must be a collective and sustained effort.
