ForgeFed versus FSDL: How do they relate?

Summary: ForgeFed models an ActivityPub vocabulary extension that represents the common denominator of functionality that is found in common Code Forge applications which lends itself to be federated. So that implementers, current and future forges, can become part of the Fediverse and interoperate. However, their focus on forges comes with the risk that their specifications are less attractive to the huge ecosystem of developer tools that operate on overlapping domains and aspects of the FSDL. This topic is created to evaluate and mitigate that risk.

Positioning / objective / vision:

  • ForgeFed: Federating Forges (application domain)
  • FSDL: Federated Free Software Development (business domains)

Prior discussion:

References:

As a precursor I recommend reading Repositioning ForgeFed? on the Forgefriends forum, as this discussion is a continuation of that thread. I created #158 in the ForgeFed issue tracker so the point is on the backlog.


Namespaces, vocab extensions and domain separation

In this #158 comment fr33domlover wrote, regarding project scope:

Perhaps the text at forgefed.org is misleading then?

It may also be that ForgeFed consciously and deliberately chooses a specific scope to focus on. And that is fine. It is a valid choice.

What ForgeFed does → Federating Forges, is a subset of the scope of “Federated Software Development” with the breadth of the FSDL. Forge implementers will directly benefit from what ForgeFed creates.

This is less the case for all those projects / products where the overlap to a typical forge is smaller. But this is an area where a huge amount of potential is regarding federated software development. This is the scope where Github and Gitlab and their respective ecosystems are. Consider some (just random) examples:

  • Bugzilla: Will find most overlap with Issue Management, but with their feature set might be content to adopt ForgeFed spec as-is if they ever considered federation.
  • Trello: Has most overlap with Project Management, some Issue Management, and may be harder to convince adopting ForgeFed as-is.
  • MatterMost Boards and FocalBoard: For MatterMost Boards there is the same tough sell, while FocalBoard would likely find the spec to be not suitable or overkill and not even consider implementing it.

Such players are in the same Core Domains as where forges are. They implement support based on proprietary forge platforms, or even entirely model their own product around them. In these areas lies the opportunity for federation to break open walled gardens. The attractiveness of any forge federation ecosystem is determined by versatility and extensibility to other aspects of the FSDL.

Ecosystem benefits

The ForgeFed project doesn’t and probably shouldn’t be concerned with all that. The FSDL scope is simply too large. But, if possible it shouldn’t also close the door for the opportunities to have an emergent ecosystem around the FSDL, where the project itself is already operating.

There are benefits to ForgeFed and implementers if somehow the FSDL can be kept in consideration:

  • Ecosystem strength and synergy. There are only a handful of forge implementers, but numerous projects in the developer tool space. Ecosystem community has great growth potential.
  • Momentum. Yes, network effects. More implementers of the specs, more eyes, expertise, feedback, reviews, contributions. More codebases, libraries, docs, articles, blogs. Material that inspires others to enter the field.
  • Ecosystem expansion. More additional domains that are specified and implemented, independently done by other projects than ForgeFed. The stuff that will eventually see Github et al shit their proverbial pants.

Key considerations

  • Positioning: What does ForgeFed want to be? How does it see itself within the broader FSDL scope?
  • Impact: How does the choice on positioning impact project work and efforts put into aligning with the FSDL?
  • Effort: Given limited time and resources, need for progress and practicality, how can positioning and impact be balanced best?

Hot take

Finally, here’s my hot take (an opinion) for the need of starting an FSDL Ecosystem Alliance which I’ll add to the kick-off prep notes:

Fedizens are highly excited about Forge Federation, and often express how this collective effort will liberate the landscape from Walled Garden dominators such as Github. However…

Given prior experience on Fediverse evolution, combined with the fact that the likes of Github and Gitlab operate on the broadest scope of Software Development and leveraging their ecosystem and network effects to maximum extent, forge federation will NEVER become a serious threat to their proprietary platforms and services if it does not organize strategically and with the same broad scope: the FSDL.

Hence the vision and mission of a FSDL Ecosystem Alliance should be as follows…

Vision: Federate the Free Software Development Lifecycle
Mission: Liberate Free Software Development