FSDL should support Commons-based peer production

aschrijver · August 23, 2024, 11:47am

Is the FOSS movement working on individual stand-alone projects in a highly fragmented landscape? Or is it practicing Commons-based peer production (CBPP), albeit very inefficiently, and with code forges as their primary tool? How can we improve collaboration and co-creation in support of CBPP, and what can be the role of the Social Web in doing so?

Code forges & Development process

Code forge software uses very particular abstractions to handle aspects of software development. The features they expose are very much tailored to:

Individual organizations to organize their development efforts.
Tech-savvy developers within those organizations.

Conceptually the core forge functionality looks more or less like this:

While the diagram is simple, leaving out many nuances, it highlights typical code forge functionality:

Individual people maintain lists of Issues, and PR’s that are merged into code via peer review.
Teams and Projects are ‘projected’ on top of that, but not deeply / tightly integrated.
Manual activity by people create (bi)directional navigation links, that may go cross-organization.
While software development follows intricate processes, these are only supported very meagerly.

A code forge offers functionalities from domains such as version control, issue management and peer review but offers hardly any means to integrate them into more elaborate processes. Doing so requires manual enforcement and discipline and/or custom automation of governance policies and development method.

In their offering the commercial forge platforms consider these typical “code forge” features to be expected functionality to build their product on top of (the “code forge” is a supportive domain), while the FOSS code forge projects treat these features as the product itself (the “code forge” is the core domain).

Typical FOSS forges do NOT support the FSDL. They merely provide building blocks of the FSDL.

The popular commercial platforms, i.e. Github and Gitlab, go a bit further in their support of the software development lifecycle (SLDC), and importantly, they offer sufficient extension points for the emergence of a rich ecosystem that addresses various missing aspects of the SLDC.

Code forges & Project management

In FOSS we talk about “FOSS projects” without considering how “projects” relate to the development lifecycle. Especially at the start of most FOSS projects this isn’t really relevant yet, but even as the popularity of project grows and a larger community forms there is usually but little reflection on the development method. The forge is used as-is and habits have been formed around that, whereby issue management is the central driver of a kind of de-facto “design-by-consensus” process.

In FOSS the code forge is main driver of project activity, not an optimised development process.

Let’s delve into some popular code forge softwares and consider how they deal specifically with projects (for brevity collapsed this elaboration).

Click to expand comparision of Project Management in popular code forges.

Github projects

Github calls their feature “Projects” and refers to it as “project management”. These are defined as folllows:

Projects is an adaptable, flexible tool for planning and tracking work on GitHub.

A project is an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively. You can create and customize multiple views by filtering, sorting, grouping your issues and pull requests, visualize work with configurable charts, and add custom fields to track metadata specific to your team. Rather than enforcing a specific methodology, a project provides flexible features you can customize to your team’s needs and processes.

Projects are either associated to an organization or a user account, and repositories are linked to them. Process automation of project workflows uses either the GH API, GH Actions or item-add filters.

Gitlab projects

Gitlab defines projects as part of the first “Plan” stage in a larger workflow (a lifecycle basically). The data model that Gitlab uses is way more intricate than that of Github.

The data related to a specific development effort goes in a project. The project serves as a central hub for collaboration, version control, and project management.

Projects provide the environment for managing and collaborating on software development projects, from planning and coding to testing and deployment. A project contains a repository. A repository contains all the files, directories, and data related to your work.

The repository is part of the project, in a 1-to-1 mapping. The project abstraction is more akin to how we intuitively consider projects. It is a container for many different artifacts related to the software development, including the codebase.

Gitlab uses Role-Based Access Control (RBAC) where accounts receive Permissions based on the membership Role(s) they have within a hierarchical structure of Groups. Groups can have (sub)Ggroups, and can have Projects assigned to them. Multiple Groups can have access to a Project, which then becomes a Shared Project. At the top level all of this is assigned to an Organization.

The perspective one has on the ongoing work depends on their navigation in the hierarchy of Groups and Projects. For example viewing the ActivityPub Epic at the top-level of the Gitlab organization shows an aggregation of all work planned for this product feature.

Note: The intricate data model and flexibility it allows to configure the UI once again stands out to me as not being intuitive. The UX confuses me, and I don’t know how to effeciently drill down from org level to individual codebases.

Note: A 2,000 page The Gitlab Handbook is available that explains the entire Gitlab organization and the software they use. An invaluable resource, yet also with a lot of complexity shining through. This resource though will be loved by enterprises that want to customize Gitlab for their own use.

Sourcehut projects

Sourcehut has as its main selling point its brutally minimalistic keep-it-simple design. The product has no documentation (assumably under the premise that the simplicity obviates that requirement). With this Sourcehut appeals to a very specific audience (more of the ‘linux terminal hacker’ types).

In Sourcehut accounts have projects. The project consists of one or more repositories. Each repository is a bare-bones git representation i.e. it provides version control.

Issue tracking is a separate service, where multiple trackers can be defined at project level, from where commits can be referenced and status of implementation is tracked. For discussions a separate Mailing list service is available.

There’s hardly any project management to the Sourcehut services that are provided. In functionality it comes closest to Gitlab’s abstraction.

Note: I did not create a sourcehut account, and there may be more capabilities once logged in. For the purpose of this topic it is not really relevant to deep-dive those.

Gitea / Forgejo projects

The Gitea and Forgejo are largely direct Github alternatives, mimicking the GH functionality. In terms of features they can be said to offer “project management lite” when comparing to Github. The Projects data model and UX is very similar, and the differences are in fine-grained UI functionality where Github is ahead.

Peer production & FSDL

When we look at the SDLC various stages of software development are defined. These aren’t sequential, but are like parallel tracks. No matter what kind of development methodology is applied, conceptually Rational Unified Process (RUP) depicts the overall process of software development quite well:

(Note: The diagram is only relevant to demonstrate that typically software development has parallel tracks, i.e. workfows/disciplines and transitions through different phases of maturity. And that activity in each track varies depending on the phase of the lifecycle.)

The Free software development lifecycle (FSDL) is a variation of the SDLC that is tailored to how Sustainable FOSS is created by the Free Software movement. Sustainable means: Healthy initiatives throughout the entire lifecycle, and where people involved are properly compensated for the work they do.

TODO

(Had this topic as unfinished draft for 2 months, now just submit it for the time being… )

aschrijver · September 12, 2024, 4:40am

An interesting HN discussion and submission Why Github Won. I started writing for FSDL should support Commons-based peer production where I think forge federation should be headed. There are a number of comments in the thread that allude to a similar direction.

Like this comment saying “I wish someone would make a Github competitor that’s fun and social”.

And this comment saying “GitHub is still super popular, evolving more and more into a social network. where the users work for free to increase the value of platform and promote it for the chance at more GitHub stars”.

In commons-based peer production we’d have a fediverse full of people creating together. The focus would be on “creator experience” CX rather than dev experience DX.

In chat @jfinkhaeuser pointed out that:

That article is full of bias, lies and omission. […] It really reads like the perspective of someone who doesn’t know about FLOSS before that time, so concludes everything started with what he knew.

Undoubtedly! Because that’s how it “works” in hypercapitalism to “win”. And yet here we are, where Github won and git is the predominant DVCS for aeons now (in IT time). The savvy fossbro SV-mindset ruthless enterpreneurial types on any crusade are more likely to “win”, and the winners get to write the history. To the deep frustration of the losers, who keep drawing the short straw in an unfair game. Pointing out the unfairness doesn’t help solve it though, as hypercapitalism speeds up faster than a minority of “aware people” are able to reign it in.

This is what a) frustates me no end, and I assume you do too, and also b) intrigues me a lot. Because we at the FLOSS side of things are free to be unencumbered and R&D the innovative humane tech solutions that are truly needed right now. And even better, to do so before they fall in the hands of those who would only use them for their own selfish purposes. Selfish people who often can’t innovate because it isn’t commercially viable to do so.

In other words: In our ability to out-innovate the commercial world we can create winning conditions for a better world. But we squander them, because we aren’t able to execute as efficiently as commercial entitities. We rather:

Work as individuals, absorbed in our passion, yet mostly alone and thus weak.
Do not consider the full FSDL to the detriment of our own success factors.

For a long time now I have this feeling that the combined social force of our grassroots movement with the technological innovations that enables us to unite from all corners of the world, should allow us to bring much needed technological paradigm shifts upon which alternative and much better socio-economical systems can thrive. If only we could set the flywheel of our collaborative collective in motion (… which is wicked hard).

And then we can only observe how our work is once more co-opted, fruits of our work harvested for hypercapitalist purposes.