I will explain a bit from my perspective re:ForgeFed. When activity on ForgeFed stopped there were still a bunch of open discussions on talk.feneas.org (via Archive.org) and many features of code forges not covered in the specifications. I think part of the focus of devs was also to hone in on the smallest common denominator in the exchange formats. But this doesn’t have to be like that. ActivityPub specifies that if you encounter properties or Objects you don’t understand, then you just ignore them. So a Github → Gitlab federation may have all the features, while the same Github → Sourcehut sync omits some of them.
My interest regarding the Fediverse lies in advocacy / helping to unleash its full potential. And that refers to ability to model social interactions in ANY app domain, create integrations between apps that weren’t easily possible before, and even go beyond apps towards task-oriented interfaces where building blocks are all across the fedi.
When looking just at Code Forges and what they currently offer, it is easy to get a limited understanding of how they might federate. Looking at the needs people have wrt software development one could say: “No one needs a Code Forge”. Instead people need Revision Control, Issue Management, Task Tracking, etc. And code forges just happen to bring some of those together.
If you look at Github, its dominance and the network effects + FOMO it creates, this is only in part caused by the product itself. Most of their dominance is cemented by the broader ecosystem they enable through their open API interfaces. A gazillion +1 other products and services consider Github-integration in some form or other a natural feature to add to their products, and they add that independently without GH devs + sales etc. having to spend any effort.
The federation specifications, that start with stuff most code forges offer in-the-box, enable us to go just as broad and facilitate an ecosystem that can rival that of Github’s.
When you realize that, and see the opportunities, it is also clear that ForgeFed is only at the very early start of its evolution, and that the domains that are involved go beyond Forges (The ‘forge’ concept may even be the wrong way to slice things. A Forge indicates an app-domain, and when looking at software development activities we deal with ‘business domains’).
ForgeFed is a great start. For things to mature further and reach their full potential, specifications need to evolve separately and with a community / standards body behind it, that works towards the vision of what it can be. From there specs can gradually mature, and branch out in different directions as-needed to cover more development activities.
All this does not exist yet, and no one has the focus currently to go in that broader direction. We look at code forges as they exist now. When going from needs the top-level objective might be:
- Successful free software development
Successful means well-oiled project with contributors and community around it, and software that is loved by people and fulfills real needs they have, adds value.
Recently with @CSDUMMI I started working on Social Coding Movement with the realization that so much of FOSS devolves too quickly in deep levels of tech-talk, but that software development is in large part a social process. I defined the Free Software Development Lifecycle (FSDL) as the area to analyse and find best-practices for, which can then be supported by federated tools that anyone creates. In addition I defined a sub-section to the co-shared social coding community forum to look into Social Coding Foundations i.e. building healthy ecosystems, people, processes that can evolve open standards.
To come back to ForgeFed as a TL;DR an option is that this becomes part of #fsdl and the specs will then be broken down into business domains such as Issue Management, Revision Tracking, Testing, CI, what-have-you…