World of Opportunity: Expanding from ForgeFed to FSDL

Social Experience Design
#1

(This is a copy of my comment in Forge Federation General matrix, triggered by this discussion on the state of the ForgeFed project)

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.

THIS is the opportunity that lies in front of us now too !!!

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ā€¦

1 Like
#2

We keep coming back to this and I share your impression for the most part. Whenever I work on technical details, I think of you and the lack of vision this kind of activity inevitably projects. In some cases it indeed means the persons involved in the project do not see beyond the technical work. But it could also be that they do not have the inclination, time and skills to share their vision.

I fit that description, most probably. My work on forge federation looks like a patchwork of technical projects that are only loosely related with each other. And I did not take enough time to write down and explain why I chose to work on them and push in a given direction rather than another. Yet, it is driven by a vision that stays with me every day and that has been build over the past year. This vision matures slowly because Iā€™m not a visionary or a philosopher and when I try to write about it the result is rather messy.

You are at the other end of the spectrum, elaborating a vision that resonates with me for the most part. Your work is elsewhere and you cannot spent time working on technical details. And this space, Coding Social, is where we meet. It is an opportunity for us to discuss and figure out how the abstract vision meets the technical details.

Since this is a recurring theme in our discussions, it may be worth making it a new topic even :slight_smile:

1 Like
#3

The primary problem that ForgeFed has at the moment is that nobody has time to work on it (both at the technical / specification level and at the communication level). Hopefully someone will step up. And when that happens it is difficult to predict in which context this person will feel more comfortable doing their work. It may be in #fsdl. Or they may prefer to setup something entirely different.

2 Likes
#4

Yes, and that is a perfectly valid decision. You should not see this as a criticism on a ā€œlack of visionā€ on your part, or anything that you should be doing differently in how you spend your time. We had these discussions and I know and appreciate your stance. The reason I am mentioning it yet again, and at length is that the community around forge federation is growing. As decisions need to be made for various projectā€™s directions there can be contributors or people who want to be involved with the broader perspective.

Regardless of broader perspective the gaps and holes that are in ForgeFed need to be addressed in any case, or at least when impls adopt the current specs. That includes forgefriends. Take basic improvements, for instance "type": "Repository". This is not according to AP recommended best-practice which might be more like "type": ["Service", "forgefed:Repository"]. In other words supporting type as an array and deriving from an AS primitive type.

Where that ForgeFed improvement work happens and in what contex,t is the decision that is now at hand. I am advocating the FSDL to be that new place if ForgeFed devs donā€™t show up, but I also want to explicitly state that the person working on it will likely only address very specific, limited parts as-needed for app development and not worry about the entirety of the FSDL. And along the same vein, not be responsible for FSDL as the project maintainer.

FSDL has found a home on Social Coding, it is a crowdsourced effort, and hence it is for everyone and evolved by anyone. It will be a gradually growing suite of different specifications & docs. Parts may be hosted elsewhere. Like for instance the Friendly Forge Format which seems to fit into the specification framework as well. But how that fits together are separate decisions.

1 Like
#5

Iā€™d like to emphasize that, in my case, it is not my decision to make. I just lack the skills and time to share my vision. Iā€™ve learned to know my limits :slight_smile:

Where should I direct people to read and learn about what FSDL is? I kind of remember you wrote something but I misplaced it.

1 Like
#7

Lacking the skills and time are a practical decision, I guess :laughing:

Thereā€™s some FSDL-related discussion still on the forgefriends forum. Here at Discuss Social Coding thereā€™s not yet too much information, and also on the Social Coding website there isnā€™t. But Social Coding as a whole is not yet officially launched, so things will be further elaborate.

But the #fsdl category is where you can point to and anyone is free to create any discussion topic, and Iā€™ll gladly delve into things with them. Otherwise the various chatrooms are good starting points.

#8

(Copy-pasted to OP from the same Matrix discussion, where I am more likely to follow-up and pay attention)

You seem to have your vision set on the right path, that while the immediate goals of federating (share code and social communication in current mode of MRs/releases/issues/account profiles) will be a gamechanger in themselves, there is so much more to explore down the line.

This is the crucial and hard part. While being new here I will assume an effective and proficient standards body will be unlikely to form in the short- to midterm. Would be awesome to be proved wrong, though :wink:

On one hand, yes, individual efforts should explore and implement without being deadlocked by lack of response or consensus with the larger ecosystem. On the other hand, once a new interface is exposed, the cat is out of the bag and there is risk of divergence and incompatabilities leading to a different kind of deadlock where different implementations canā€™t talk, and/or resolving issues or progressing is prevented by wanting to keep compatability, or bad APIs proliferate way past their warranted lifetime due to ossification. But then again, perfect is the enemy of the good and I think itā€™s a mistake to hold back too much out of fear for this.

It seems to me that moving forward from here, individual projects (like gitea and forgefriends) should be free to start solving, while proactively inviting other stakeholders for feedback and collaboration, and take those into account but eventually should not have fear of pushing forward and release. And at least at this stage, it would be beneficial to explicitly be open to breaking APIs and not obsess over backwards-compatability in federation-related interfaces. Just do so with notice given ahead of time and communicate future and current breakage clearly in release notes/changelogs. Then eventually this should result in de-facto standard that can be formalized in a more formal spec. For now, iterate.

The dynamics Iā€™m bringing up can be seen in the rest of the fediverse and my last paragraph is how I think forgefed can do better.

Finally, I donā€™t know how many people here have eyes on Ethereum development but ETH2 (PoS) have from the outset multiple de-facto clients with separate teams on regular calls, in order to not have single-points-of-failure on organizational and human level. I think in regards to the above they have been successful and forgefed can draw inspiration from their process. One thing that comes to mind would be to run a federated network of dedicated instances of forgefed-compatible implementations that are continuosly up to date with latest releases (and can be federated with by devs for sake of testing new changes under development), which makes compatibility testing straightforward and a natural part of the development process, and will surface unforeseen issues immediately.

1 Like
#9

Right! With enough time all problems are shallow. For a given activity, in this case social coding, would it make sense for me to spend years learning how to write properly and express ideas in a convincing way? Would it make sense for me to spend a five years to make 100 millions ā‚¬ and then use that money to fund the development of social coding? Would it make sense for me to become a philosopher over a period of years and mix this with my developer background to better understand what software means for humanity? I can think of a zillion other ways to further social coding if time is not a constraint.

But time is a constraint, a limit to reckon with. If someone says they donā€™t have a particular skill, it does not mean they cannot learn it. It means that in the context of their activity in a given context, they cannot leverage a skill they do not have. And they should not feel guilty for that, on the contrary. There is a strength in knowing your limits.

#10

I think there is great value for all archetypes. With only visionaries, nothing gets done apart from bikeshedding. With none, things fall apart due to lack of direction and motivation. The last one swings both ways - even with people coming in with wildly different (and maybe even conflicting) end-games, ideologies, motivations, and visions, they can still build something great together where stars align. Talking about our motivations and finding common purpose is crucial but it can be equally important to put that aside and find common ground in what needs to be done, and collaborating towards that - even with someone you would perceive as being ā€œon the other sideā€.

Weā€™re complementary.

1 Like
#11

You misunderstand me, I think. I stated the full validity and perfect understanding of this. Like, I also refrained from memorizing the internet for practical reasons, itā€™s normal. They constitute decisions in life on where we wanna spend most of our precious time on this earth. :wink:

Well said, again @3nodeproblem and welcome to Discuss Social Coding. Appreciate you took the time to post here. Fostering diverse communities where people with different backgrounds, perspectives and skills can participate is an area Social Coding is interested in.

Delving a bit further in your splendid feedback on the topic ā€¦

I agree. My observation is even that in the contexts where we like work, free software project settings and fediverse, these standard bodies tend to NOT be formed, or they tend to languish after formation. There are unique challenges at work here, and they are investigated in #foundations category.

As for my personal stance. The fedi that I would prefer to code against, the one that fits my needs, is the fedi that does not yet exist by a long shot, and maybe never will. And of course, I could just start coding, but itā€™d be meaningless without broader adoption of things wrt where we currently are (the ā€˜microbloging-verseā€™).

Yess! This perfectly demonstrate the tricky balance that needs to be found. I call this ā€œthe sweet spot of interoperabilityā€, and explain a bit about (though with other findings still left out) in: Challenge: Fixing the Fediverse Technology Adoption Lifecycle.

I would be more in favour of having 2 processes that work and evolve in parallel. Where indeed experimentation and innovation in the form of implementations takes precedence, but at the same time ā€œsubstrate formationā€ is not neglected and matures in parallel so that open standards and all the work they bring does not lag too far behind.

Donā€™t think this is far from the intent you expressed, btw. But stating this, because on the fedi as it is now we made the mistake, and the open standards track came to a full stop shortly after the ActivityPub W3C recommendation became final. There was still strong community, but even that is falling apart with mostly a small group of insiders exchanging knowledge on app-by-app basis. I call it a ā€œTragedy of the Commonsā€ on substrate level.

Though not into blockchain at all, Iā€™m interested to learn more about the process. It seems quite prudent to avoid SPoFā€™s wherever possible.

1 Like
#12

Some cros-references that relate to this topic:

1 Like