i re-phrased the introductory paragraphs - i will explain the significant changes
Millions of Free Software developers forgot why it matters to own their tools.
i understand what this is trying to suggest; but clearly, it is a generalization of no individual persons, but an amorphous ācollective consciousnessā - the people who wrote software before forges existed, did not forget the value of the unconstrained decentralized workflow - most of them still prefer it today - people who started programming in the era of forge popularity, never knew of it, so they had no such conceptions to forget - programmers especially, are predominantly ālonersā, or have at least a strong sense of individualism, and generally demand autonomy, unless there is a large paycheck involved - āas a collective (on average), we forgotā is just too wishy-washy - it does not actually describe anyone that i know of
They know, better than anyone, how to fix and improve them.
this unfortunately is also not accurate - it probably is a fair estimate of people who wrote software before forges existed; but in recent years, the majority of people who use forges are web developers - they do not know the tools ābetterā - they know absolutely nothing about how the build tools, run-times, and systems work, and do not want to know; because (the real problem) they do not need to know, as their predecessors did - they use only the tools which they are bestowed upon them from on high by their tech over-lords, they use them glibly as prescribed, and if the tools break, āsome guruā (in the cloud) will fix it for them, someone who they do not know, and probably will not communicate with them directly
again, i understand the intention of that sentence; but i dont know how to word it sincerely - maybe they should know how (or at least want to), and maybe the people who came before them knew how, but this is probably not worth mentioning - some people do know how, but those people do not need convincing - the ones who dont know how, probably dont want to know, and never will - the majority of programmers will never be swayed by any arguments from ethics or practicality - a web developer is not going to be persuaded by arguments that suggest configuring apache, jenkins, or firewalls is a path to freedom, much less to suggest patching them and re-compiling - to many people, the convenience and laziness offered by freebie web services is the most beneficial form of freedom (ironically) - it frees people from the time, work, and expertise which self-sufficiency demands
NOTE: you can see? how difficult it is to express these ideas formally and concisely - it took me two paragraphs to unpack the subtleties lurking in that one sentence
Some Free Software developers chose to use different tools, such as email and DVCS without a web interface. Many others decided to run their own Free Software forge and work in a decentralized way, improving their own tools and independently deciding who they work with. But even then, they are isolated instead of being federated with each other.
as a whole, that is not true - email is federated and DVCS does not need to be federated, because it is fully-distributed, which is federationās stronger, more robust cousin - email is the most popular and useful federated system in history, and it is still the most used federated system today - since the earliest days of the internet, no one was isolated from anyone else on the internet; because the internet itself is a federated system
after re-reading it though, i dont think that was the intention - it is those who ādecided to run their own Free Software forgeā who were āisolated instead of being federatedā - probably the wording is ambiguous, which gave me the first impression - if that was the intention, it would have been more clear like " But that latter group traded away federation and got isolation instead"
that paragraph is trying to make a point, that web forges have an indisputable natural advantage over patches via email; but they offer nothing new or unique - forges are only a collection of tools, which people had already been using in other forms, presented as a convenient unified web interface - some people consider that presentation to be more convenient; but convenience is subjective - it is only a different workflow - that workflow is perhaps unfamiliar to young people; but many major software projects today still prefer it - git itself is developed in that way, as well as GNU and linux, as examples - none of those are suffering from impedance or lack of contributors, due to that workflow preference
overall, that paragraph is really self-contradictory, for demonstrating the motivation of the forge-fed - the motivation is some (any) form of decentralization - if a system is decentralized, it does not need to be federated - a decentralized system is a more complete and robust extension of the weaker federation - the advantage of federation over full decentralization, is that each node may choose which portions to replicate, where fully-decentralized nodes must replicate everything - im pretty sure thats how git-ssb works - if someone wants to add a comment to a post, for example, one must first download the entire project (all tickets and historical edits, the forge itself, everything) - likewise with pagure - it is actually decentralized - to add a comment in that way, one must first clone the entire āticketsā VCS
federation is one form of decentralization; but self-hosting a typical forge such as git-tea, is not decentralization - it is definitely centralized - the only difference is where the ācenterā is, and who controls the central machine - think of the āhubā topology in networking terms - git-tea is literally a git āhubā - that is the essence of centralization
FWIW, there also was not much of a choice to make - there were no other tools available; but it was not a problem, because those tools are perfectly adequate for unfettered global collaboration - no one who used them wanted to supplement them with a webby interface - corporations such as source-forge, google, and github wanted to displace them, but not to fill any demand for improvement - profit, was the only motivation for the invention of forges
the convenience of forges was so alluring to noobs, that now many people consider them to be so essential, that they too, would not āchooseā any alternative to web forges - there are many of forges to choose from, but none are significantly different - the difference is that now, people can āchooseā between the web and email workflows; but unfortunately they are not compatible - that is a key area where forge-fed comes to the rescue
to illustrate that point, forge-fed should allow people who prefer to use a forge (any forge) to collaborate/contribute to projects which only communicate and accept patches via email - and people who prefer to use only email should be able to collaborate/contribute to projects which only communicate and accept patches via a web forge - i do not yet know enough about the motivation or goals of the forge-friends group to presume anything; but if this is the first time that you have imagined that use-case, you are thinking of forge-fed in a severely impoverished way - it is not only about uniting web forges - it is about uniting people, regardless of their preferences of tools, workflows, service providers, or whatever
in short, if you write software, and your tools understand the concept of a patch, and you have some networking capability, whether that is a web browser or netcat, you should be able to collaborate with any one else, via the forge-fed protocol
likewise:
It must be possible for developers to work together on the same software project regardless of the user interface they use.
that is, regardless of all tools, workflows, machines, hosts, geographical locations, and so on - regardless of anything imaginable, related to networked computers - āthe user interfaceā in that sentence is presumably: āthe webby forge interfaceā - that is very much not regardless of oneās choices - most forges do not function completely without javascript, for example - the differences between git-tea, gitlab, and pagure for example, are negligible - they are nearly identical āinterfacesā, all are essentially clones of the github model
that stated goal is too narrow - āregardless of the user interface (which is a web forge)ā effectively implies: āyou must use firefox or chromeā to communicate with this project in any way - i reject that notion whole-heartedly
This will help developers to move away from software forges they are forbidden to change and regain control of their tools.
this should also help developers to regain control of their tools, by moving away from web forges entirely; and instead using tools which are simpler, more efficient (native clients), and more robust than web forges, and can function completely and reliably, even when the entire team and/or the infrastructure is offline for 6 days each week
that is not a wild or fringe suggestion - git-ssb has that āreliable offlineā feature baked in at the protocol level - it is actually impossible to remove that behavior - forge-fed could also work perfectly, even if a projectās primary forge is running on a laptop, which is only online for one hour per week - but the protocol can not guarantee that level of robustness - forge developers would need to implement that robustness, per a strong recommendation - so, forge-fed must be sure to recommend it - i wanted to underline that - it is a highly desirable feature, and is one of the main benefits of federation and decentralizatoin; but fediverse fans seem to devalue or forget about it
just gave some feedback 
