Working together and gaining trust

[Alexandre Oliva]

On Feb 11, 2026, Claudio Bantaloukas <claudio.bantaloukas@arm.com> wrote:

> Indeed, it seems to me the friction comes from two different thought
> frameworks being applied. You start your argument from a
> non-conflicting freedom definition whereas my definition sees freedom
> as inevitably conflicting and thus requiring one or more between eye
> contact, discussion, negotiation, tradeoffs, policy, law, war, hugs,
> listening to be made to resolve the conflict.

*nod*

Even my proposed solution to what may be perceived as a conflict of
freedoms is conflictless: I'm not saying that all service suppliers must
abide by our values and principles and follow our alignments.  I'm just
saying that we shouldn't rely on suppliers that don't respect our
freedom.  They can keep on offering the services to those foolish enough
to accept them under the subjugation framework they wish to impose,
while we escape the subjugation by getting service elsewhere, or doing
it ourselves.

> If it helps, allow me to explain the way that a forgejo instance

Thanks for the data points, they're useful.

You surely understand them far more deeply than I do.

Given your understanding of SaaSS, would you say that a community
relying on a forĝejo instance ran by a third-party, with runner
definitions executed by, erhm, fourth-party givers, is in control of its
own computing, or that there's any aspect of SaaSS in there?  Consider
the key computing elements done by the forĝejo instance and by
forĝejo-runners, whose computing those are, and who controls them.

(the main reason I'm investing so much time and effort in this thread is
to spread awareness and intuitions about SaaSS, so that I don't have to
be the pest pointing out when there's a problem, but rather that we all
work together to avoid even getting to the point of having a problem :-)

> Hopefully this shows that a forgejo instance is inherently not SaaSSy.

These are no doubt interesting design elements.

I'm still worried about the computing that goes into patch
merging/rebasing.  (Incidentally, on a related concern that has nothing
whatsoever to do with SaaSS, I don't see how requiring originator-signed
commits could even possibly work with server-side rebases)

> When it comes to the service that Carlos is proposing that openssf
> provide, things are even clearer. gitolite is so barebones it squarely 
> fits the "Use of simple software repositories is not SaaSS" rule.

I don't know a lot about gitolite, but if all it does is publish the
code and selectively accept pushes from authorized git users, it's not
even doing anyone's computing.  Server-side commit checkers, however,
could be SaaSS depending on who controls them.

> When it comes to projects controlling who has access, both of these
> software programs have provisions for delegating user and group
> management.

And then we get to another important point: who controls the user and
group management infrastructure.  Is there any relevant computing there
to worry about?  Are there other issues (not necessarily relevant for
SaaSS) that would make it a poor idea to delegate such key piece of
self-control infrastructure to a third party?

> You seem to argue that shared infrastructure with independent
> authority is structurally incompatible with software freedom.

It depends a lot on what the infrastructure does.  If it's publishing or
mediation of communication, those are not much of a point of concern.
(and that's what Savannah does AFAIK, so there aren't any SaaSS concerns
there).

The moment you start doing computing for others, however, then SaaSS
becomes (or should become) a concern, and then you may find that what it
takes for your individual and organizational users to retain their
control over their own computing might require from small tweaks to your
infrastructure to opening things up so much to others' control that
you're no longer willing to offer the service in a way that respects
their freedom on your own machines.

> Does your argument mean that any project hosted in savannah.nongnu.org
> can ask for a separate instance of savannah that the project can
> change independently? I think that's not the case.

It is't, and that's fine because the services it offers aren't SaaSS
because they aren't the client projects' computing: publishing and
mediation of communication are not any single party's computing.  The
consequence is that the server-side computing that Savannah does is the
service provider's own computing, and control over that belongs with the
service provider.

A lot of what a Forge is expected to do falls in this category.

But a lot of recent-ish (proprietary/locking-in) Forges have taken over
(or rather offered suckers the opportunity to be SaaSSed) various other
kinds of computing that belongs with the users and with the projects, to
the point that today even Forges that aim to be freedom-respecting offer
such features, so those can only be used in freedom by projects that
self-host their Forges.

But you also show that there has been effort in free software Forges to
redesign some such proprietary traps into something that keeps at least
some significant amount of control in the hands of the projects where
control belongs.  Self-hosting of computing services remains the golden
standard, but this may open up valuable alternatives, depending on deep
understanding and careful analysis.  Not the sort of analysis that could
be done in a battlefield, for sure.

>>> I think whatever change proposal is made will have to be weighed in
>>> against such considerations, including technical feasibility, resource
>>> constraints, technical debt being introduced and maintenance burden
>>> generated.
>> And then, who decides?  If we can weight on our own terms and have
>> our
>> decision implemented, we have control.  If we make our decision and then
>> have to beg someone else to hopefully do it for us, fearing they might
>> refuse, we don't have control.  And if it's our computing we're talking
>> about, that's a software freedom problem.

> The question is not just who, but how, how long the decision making
> process takes, whether it is finite, whether a decision actually
> results in the desired action and how much it helps the projects.

Another important consideration, that I realized after posting my
earlier message to you, is what recourse the project has if a service
provider refuses.

If we speak of project's self-hosted infrastructure, the problem becomes
a matter of find other helpers to make the change.

If we speak of infrastructure hosted by the service provider, a "no can
do" by the provider can be a *lot* more disruptive to the project.

> In the case of sourceware:
[...]
> I would guess savannah has a similar structure.

For quite some time, AFAIK Sourceware and Savannah shared the property
of not doing computing for the hosted projects, only publishing and
mediation of communication.  Concerns about SaaSS were out of scope
then, because there wasn't any project's computing involved.

At some point Sourceware started offering services that involved
project's computing.  AFAICT at least some Sourceware operators have an
understanding of the SaaSS issues and strive to avoid entrapping hosted
projects, but at least one of the hosted projects seems to have been
dangerously unaware and/or uncaring about SaaSS avoidance.

> In the case of CTI

Your description matches my understanding, and it makes matters even
more complicated because there are two layers of indirection that could
each say "no can do" to our project's community governance on matters in
which we should have our autonomous control.

> None of these existing systems provide absolute and direct control of
> the infrastructure to the projects.

That would be too demanding.  Avoiding SaaSS is about having control
over your computing, not over everything around it, and not necessarily
direct (which doesn't even make sense to me when it comes to
collectives, whose actions are of necessity always carried out by
appointed agents)

> And given that the services offered can be replicated, projects have
> the ultimate power to walk out.

That's valuable, but it's no substitute to being able to make changes
autonomously, without having to walk away from our own infrastructure.

-- 
Alexandre Oliva, happy hacker            https://blog.lx.oliva.nom.br/
Free Software Activist     FSFLA co-founder     GNU Toolchain Engineer
Learn the truth about Richard Stallman at https://stallmansupport.org/