(This topic is copied from this chatroom discussion)
Welcome fr33domlover I am not directly involved with forge federation projects, but I regularly jump in these rooms as a general advocate for anything Fediverse and hoping to inspire applications that will take fedi to its full potential. I don’t know if I’m able to attend a meeting and really don’t have free time to spend. But there’s one point of advocacy I made on a number of occasions and will make again now…
A code forge is a bundled set of tools that help make software development more efficient. It represents an application and the features it offers relate to an ‘application domain’ (that of ‘code forges’). For the federation you can slice it like that and then call your AP specification project e.g. “ForgeFed”.
But in doing so you might sell yourself short, and with high risk to squander a unique opportunity. By specifying the application domain the specifications become most usable and obvious to use for code forges. They may and likely will become much harder to use in more general context of the top-level ‘business domain’ of Software Development. (A ‘business domain’ is a particular field of expertise, not to be confused with commercial businesses).
IMHO one of two different approaches should be chosen for the ForgeFed project:
- ForgeFed is repositioned to model the various business domains of software development.
- ForgeFed will clearly limit its scope to a single business domain of software development.
(In both cases ForgeFed may not be the best name for the project, but that is another matter)
For the rationale to 1) it is best to start looking at Github. With its popularity, network effects and FOMO it has established a real dominant position in software development community. There’s much more than the code forge alone, as Github is the center for an enormous ecosystem of vendors that offer value-added services and tools covering the entire software development lifecycle. It cements Githubs position, and they can selectively adopt attractive new features into their platform, making them a de-facto walled garden. Gitea and others eternally trying to catch up.
Now with ActivityPub federation the entire software development lifecycle can be opened and democratized! That is the humongous opportunity that exists. If the ForgeFed specifications were to grow (hypothetically) and encompass Project, Board, Comment, CI Pipeline or whatever other concepts, then there is a need to split into business domains. Project and Board for instance are also concepts that exist in Trello, and a Trello board might federate with a Github or a Gitea board. But Trello won’t do that, or won’t become aware if things are tightly interwoven with other forge features they don’t offer.
So to me it makes sense to slice according to business domains. Instead of application domain of ‘code forge’ there’d be sub-domains of Revision Control, Project Management, Task Management, Quality Assurance, etcetera. There’d be a whole set of different specifications that evolve separately, each at their own pace and likely with different people involved in that. But they can be collected under one ‘umbrella’, and I suggested a name for that to be: Free Software Development Lifecycle or FSDL.
Now I can understand that - and this was mentioned by dachary.org - that such a larger scope needs a different organization and people committed to it. I think it does not need all that much extra effort, because it is something that will grow incrementally over prolonged period of time. The upfront effort is more the repositioning it involves (these specs may live at fsdl.forge.es where multiple parties are already collaborating).
But if this idea is too much and no one feels like being involved then we come to option 2)
This is the approach that there eventually may be the establishment of a FSDL, but not right now. In that case (and it looks like ForgeFed is already much scoped like this), ForgeFed may deliberately restrict to one particular sub-domain, do that really well, launch it in production, and then see what the future holds. That sub-domain looks to be Revision Control and aligns to the typical functionality that Git offers, but then on the code forge’s end.