Repositioning ForgeFed? Scope to Code Forges or Free Software Development Lifecycle (FSDL)

Discussions Ideas
5

Yes. I support all the Q’s. Still the question remains, especially relating to Q6, how to best slice the model. Let’s look at one example: Ticket.

{
  "@context": [
      "https://www.w3.org/ns/activitystreams",
      "https://forgefed.peers.community/ns"
  ],
  "type": "Ticket",
  "id": "https://example.dev/alice/myrepo/issues/42",
  "context": "https://example.dev/alice/myrepo",
  "attributedTo": "https://dev.community/bob",
  "summary": "Nothing works!",
  "content": "<p>Please fix. <i>Everything</i> is broken!</p>",
  "mediaType": "text/html",
  "source": {
      "content": "Please fix. *Everything* is broken!",
      "mediaType": "text/markdown; variant=CommonMark"
  },
  "assignedTo": "https://example.dev/alice",
  "isResolved": false
}

Doesn’t have too many custom properties just yet. In fact there’s just two now. The assignedTo and the Boolean field isResolved are defined in the namespace https://forgefed.peers.community/ns.

Now suppose I’m working for Mattermost, and developing the Focalboard project. I bump into ForgeFed and say “Wow, we could provide project boards for any federated forge repository”.

What ForgeFed calls Ticket they call Cards or Tasks, but that maps well. Here’s a Focalboard task:

focalboard-task
focalboard-task802×861 34.4 KB

What we see here:

  • isResolved is meaningless to them. Instead they have a Status property with a custom enum that represents board columns.

  • They have ability to add custom properties on the fly and define custom card types (which might be modeled as "type": ["Ticket", "focal:ReminderCard"] or something).

  • Not shown in this screenshot, but they have time-tracking fields that have some correspondence to time-tracking found in code forges as well.

  • They have a Reviewed property that might be mapped onto some ForgeFed construct, except that ForgeFed will likely model reviews in the context of Merge Requests / PR’s and may be incompatible.

The developer pushes ahead and after some months Focalboard proudly releases their ‘ActivityPub federation support’. The federated message they send across the Fediverse look something like:

{
  "@context": [
      "https://www.w3.org/ns/activitystreams",
      "https://forgefed.peers.community/ns",
      "https://mattermost.com/focalboard/2.0/ns"
  ],
  ...
}

Weird things here. All their message have reference to a namespace full of Code Forge stuff in it, even for Mattermost uses where no forge is involved.

Anyway, suppose this integration is exceptionally well received. Mattermost / Focalboard extension providers love the well-designed Focalboard AP extension. So in short time many Marketplace Extensions also add federation support, extending onf ForgeFed and "https://mattermost.com/focalboard/2.0/ns" namespaces.

Now Trello wakes up. They are a bit late to the party, but see the opportunity of federated boards clearly now. They start building their own support. Except they find that in order to get a good position in the market and catch up to Mattermost, they should build on their extension as well. The Mattermost namespace became a de-facto standard. So taking what they must, their federation msgs look like:

{
  "@context": [
      "https://www.w3.org/ns/activitystreams",
      "https://forgefed.peers.community/ns",
      "https://mattermost.com/focalboard/2.0/ns",
      "https://mattermost.com/extensions/jira/4.0/ns",
      "https://trello.com/remote/engineering/board"
  ],
  ...
}

This is getting messy, and Trello is none too happy they have to reference a namespace of their competitor. Also with ForgeFed initiative well under steam and powering ahead, there’s a continuous addition of properties to this ‘core’ namespace that were define in extension to it. This causes some projects and vendors in this new ecosystem, who are less reliant to code forge integration, to ditch the ForgeFed namespace altogether.

All in all there’s an explosion of complexity. Not all vendors document their extension that well, and it becomes very hard to track evolution of every single namespace. Adding federation support is becoming less attractive, as the ecosystem becomes fragmented. If only they had organized better from the start.

Enter the FSDL

Consider the situation where everyone had mapped their extension against the Free Software Development Lifecycle, a crowdsourced set of specifications with some processes and governance in place, so that tool providers can add their extensions to it or expand / evolve existing ones based on consensus in the broader ecosystem.

Trello’s federated messages might look like this now:

{
  "@context": [
      "https://www.w3.org/ns/activitystreams",
      "https://w3id.org/fsdl/task-management/1.0",
      "https://w3id.org/fsdl/project-management/2.0",
      "https://w3id.org/fsdl/time-tracking/draft/latest",
  ],
  ...
}

Sourcehut might implement:

{
  "@context": [
      "https://www.w3.org/ns/activitystreams",
      "https://w3id.org/fsdl/revision-control/3.0",
      "https://w3id.org/fsdl/task-management/1.0",
      "https://sourcehut.org/mail/mailing-lists/ns#",
  ],
  ...
}

And Codeberg on their Gitea instance, might be allowing other Gitea hosters to use their CI and have:

{
  "@context": [
      "https://www.w3.org/ns/activitystreams",
      "https://w3id.org/fsdl/task-management/2.0",
      "https://w3id.org/fsdl/project-management/2.0",
      "https://w3id.org/fsdl/continuous-integration/1.0",
      "https://codeberg.org/CI/Woodpecker/notifications",
  ],
  ...
}

I don’t know if the above is the best way to go about it. But my general plea is that the evolution of the ecosystem that federation support enables should be well considered, and also saying that there’s a huge potential and opportunity to consider the broader context of Software Development (same as what Github considers in scope for their platform already) that warrants such a more holistic approach.

The example with the namespaces is not just hypothetical. This is happening now in the Fediverse. If I want to create a video platform I likely have to extend upon a Peertube namespace. The mistake of never thinking about the evolution of the ecosystem at large has already been made. The W3C SocialCG / SocialHub community that was meant to dedicate to that has languished. Individual projects that already are successful and popular, just go their own way. Other developers try to bring improvement, but way after ‘damage is done’. For instance there’s an effort to create a single big Turtle specification for the Fediverse, that has these namespaces in it:


# ActivityPub and Community
@prefix as: <http://www.w3.org/ns/activitystreams#> .
@prefix sec: <https://w3id.org/security/v1> .
@prefix toot: <http://joinmastodon.org/ns#> .
@prefix pt: <https://joinpeertube.org/ns#> .
@prefix mz: <https://joinmobilizon.org/ns#> .
@prefix lm: <https://join-lemmy.org#> .
@prefix yf: <https://yuforium.com/ns/activitypub> .

(Which IMHO is the wrong approach, as this obviously does not scale and makes no sense if you are in a particular domain)

Without an approach that defines the standardization processes and governance very clearly - not just for core forge features, but for extensions on top of that - the whole ForgeFed ecosystem will imho inevitably end up where the current Fediverse is: A state where ad-hoc interoperability (everyone extending on the fly, not contributing back to the ecosystem) and post-facto interoperability (the dominant leader in the ecosystem you must follow) leads to innovation that grinds to a halt and an ecosystem that can no longer easily evolve.

I have summarized some of the great challenges we face in: Major challenges for the Fediverse.

3 Likes