Choosing community-owned code to run on our community server.

Hi fellow Solid community members,

Since many years, we have a community pod server at
https://solidcommunity.net.
It is now time to switch the software it runs from NSS (Node.JS +
JavaScript) to CSS (Node.JS + TypeScript).

As you may know, the main repository
<https://github.com/CommunitySolidServer/CommunitySolidServer> of the CSS
code base and its issue tracker are under the full control of the CSS team
at UGhent/imec, which is one of many institutions and stakeholders that
come together in the Solid project (they will also be one of several W3C
members coming together in the proposed Working Group; my employer Ponder
Source being one of the others).

Unfortunately, it has come to light a few years ago and again yesterday,
that this particular code repository is not run in an inclusive way (see my
forum post
<https://forum.solidproject.org/t/migrating-from-nss-to-css/6856/5?u=michielbdejong>
for the saddening details).

Luckily, this is open source software and there are also other forks of the
code, like the PDS Interop one
<https://github.com/pdsinterop/community-server>. These generally have
their own issue trackers, and their own decision mechanism for which
contributions are accepted and which ones are not.

So we have a choice. I think we should create a "community fork" (or use
the existing PDS Interop one) of the Community Solid Server that *does*
allow *all of us *to for instance propose experimental features we want to
switch on on solidcommunity.net, which legacy features we do not want to be
switched off, etcetera.

As an example, I remember when I was working on Solid Web Monetization, it
was easy to add an experimental endpoint
<https://github.com/nodeSolidServer/node-solid-server/pull/1546> to the
code running on solidcommunity.net, which I could then use for my demo, and
discuss with other Solid community members, even though this feature
eventually never made it into the spec.

It's fun and useful if our community server can be used as a playground for
features that are not in the spec. As a community, we should be empowered
to do things like that on solidcommunity.net if and when we want to.

So for solidcommunity.net, I think it is important that the code that runs
there is maintained in a collaborative way, acknowledging all members of
our community, their different reasons for being part of this project,
their different skill sets and interests, and their different ways of
contributing to the project.

And of course not all PRs can always be merged, and not all feature
requests can always be attended to. But even when a community member
proposes a code change that the maintainers decide to reject, this
contributor still has a right to be talked to in a welcoming and friendly
way, and not see their contributions simply disappear from the issue
tracker without explanation. So apart from the point about us as a
community having control over the behaviour of the server, this is also
sending a signal to ourselves, to the larger web standards community, and
to the rest of the world, that (despite sometimes misconceptions to the
contrary) the Solid project is run by a diverse and inclusive community,
and all voices have a right to be heard here.

We want our community to be a nice place for everybody! Only then can we
make Solid a success.

I therefore propose that when we switch solidcommunity.net from NSS to CSS,
we use code from a repository that welcomes contributions from all members
of the Solid community. This is a decision we can take as a community,
which is why I'm posting this to the CG mailing list. The practical details
of it can then be carried out by the Solid Team.

Thanks for reading this far; I'm curious how other people feel about this
matter!


Kind regards,
Michiel de Jong
https://www.w3.org/users/143305/