I think this discussion is outgrowing it’s frame. (Something we need to strictly avoid in a federated Idea, Community and Project Hub.)

I propose moving this into a Repository or Organization on a forge.

Those are great ideas. I’ll try to minimize these into minimum viable product requirements based on the three domain split:

MVP

Ideation

A service which allows the sharing, discussion and concretize ideas.

It should achieve these minimum features:

• To create ideas as ActivityPub Objects containing text, tags, and a reference to an Idea it’s based on (if any).
• To discuss Idea Objects in the Fediverse.
• To gather the discussion in an easy to view UI.
• The change of Idea Objects should be possible for the author of the Idea.
• Any user should be able to create a new Idea based on an existing Idea Object.
• To generate a feed for users to find new Idea Objects.

Community Governance

A service closely working together with the Ideation and project management service.

It should achieve these minimum features:

• The creation of a developer community Object (group) based on an Idea.
• Users to join and leave a community.
• Users to assign themselves roles, describing their abilities and resources they can provide to the project.
• Users to vote for a maintainer of the project and communicate this with the project management service.
• Users to discuss the project on the Fediverse.

Project Managment

A forge that hosts the repositories of a project and allows for the Community to change the access levels of developers (Maintainers, Contributors, etc.).

It should achieve these minimum features:

• To create repositories for a community.
• The features of forge (issue trackers, contributions, etc.)
• To change access levels based on the Community Governance.

I decided for this three division, because Project Management can be seen as a Forge with some additional features (maybe implemented with just a plugin or bot) and the focus of development should lie on Community Governance and Ideation, the new and unique services.

I only include those requirements here, which I think can be reasonably implemented in a first release and nothing more.

Maybe a little mental prototyping is in order:

A project based on the fediverse may be created, that:

1. Allows any user to publish an “Idea” Object containing anything from a small word impulse to an entire whitepaper.
2. That “Idea” Object can be extended to become a “Concrete” Object, containing more technical details.
3. The “Concrete” Object is proposed to developers.
4. Developers join a project. Meaning they want to work on the project. Creating a “Group” Object.
5. Developers are given a public discussion room for internal discussion.
6. Developers create a repository on a forge and select a maintainer from amongst their members. (Maybe by voting?)
7. Development begins.

(Whenever I say Object, I mean an ActivityPub object)

Developers should be able to join and leave a project at any time. And if they are a maintainer, the group should just be able to chose another developer from amongst their members.

(This can be risky, if a project is entirely abandoned and a malicious entity gains control of the project, at which point a “fork” of the project should be created - nobody with a link to the abandoned project should receive releases from that anymore.)

My post is incomplete though: I’ve defined problem that the united software development paradigm should set out to solve, but I didn’t provide much information as to how that problem might be solved.

For that I suggest a new definition of the free software development process:

1. An idea is had and published.
2. The idea is made concrete.
3. A group of developers finds themselves to work on the idea.
4. The group writes the code.
5. The group makes a release.
6. The group’s software gains adoption
7. The community of users and the developer group grows.

At no point during this new process does the success of the project depend on an individual. Indeed each step of this process could theoretically be done by a different person or persons. Thus requiring a whole new definition of what a maintainer is, how they become one and forge software has to change accordingly.

And there should be software to support the first three steps of this process especially, software where you could publish ideas (1), make them concrete (2) and find developers to work on a project together (3). Federating this software and embedding it in Gitea or another federated forge would probably be the best approach.

Since Big tech cannot use this process really, since it includes giving away your ideas and not just your code to the commons.

Why not look at how free software is currently developed, to define what a United Software Development paradigm might look like?

The traditional free software development process can be divided into three parts:

1. Somebody creates a project. They set the rules, goals, roadmap, development pace, forge, organization, etc.
2. With luck the project gets to a release. Then some users might adopt the project and maybe somebody decides to collaborate on the project.
3. If the project is successful, it’s adopted by many more users and gains a developer community.

This process has several problems first amongst which is the reliance on the individual, that started this whole project. In order to reach step 3, at which point the project could maybe survive without them, this individual has to be able to develop the project, document the project, provide Q&A, collaborate with other developers, provide potential up front costs (server costs, etc.). And all that without earning a penny for their work in most cases.

And after step 3, this individual might not be quite as relevant to the project as it used to be, but it is often still vested with an enormous burden and authority over a project (the title “Benevolent Dictator for Life” describes this situation quite well).

Thereby it is no wonder, that free software is struggling: It’s development has to overcome extreme burdens, that have nothing to do with the quality of the project and it’s idea, before reaching adoption and a developer community.

This makes starting a new free software project extremely unattractive for developers committed to free software. And those that do decide to start a new project often waste their energy, time and other resources developing projects, that fail at one of the hurdles described above. Making their efforts futile.

Thus I understand the United Software Development paradigm as an answer to this current situation, creating a path for developers to create new free software that is successful based on the merits of the project and not the ability of it’s founder.

But in order for this to be achieved, the United Software Development paradigm has to include not just the actual development of the software, beginning with the creation of a repository, code and corresponding to step one in the traditional free software development paradigm.

It has to begin before that and give people the ability to find a group, an idea, and a basic organization together and to create a software from the beginning as a team effort and gain team members along the way.

The modern forges have become centers for open source software, but they do not provide developers with a way to connect, find like minded people, ideas and develop projects from these ideas as a team, because forges today (especially GitHub) are suited to the needs of big tech companies benefiting from the voluntary work done by open source developers.

Free software can only survive if free software developers can develop their own projects in a cost efficient manner and without being a Swiss army knife of a developer / designer / Q&A / security researcher / devops.