Re: What a CG to do?

čt 10. 4. 2025 v 12:19 odesílatel Sarven Capadisli <info@csarven.ca> napsal:

> I initially wrote this as a response to a [discussion in the 2025-04-09
> Solid CG
> meeting](
> https://github.com/solid/specification/blob/main/meetings/2025-04-09.md#peaceful-progress),
>
> but I thought since this is somewhat of an ongoing topic, I should share
> here.
>
> Background on what a CG supposed to be / do is always handy:
>
> * W3C [Comparison of Group
> Types](https://www.w3.org/community/about/process/compare/)
> * [FAQ | Community and Business
> Groups](https://www.w3.org/community/about/faq/)
> * [W3C Community and Business Groups -
> Introduction](https://www.w3.org/2011/Talks/community-201109/)
>
> ---
>
> Personal understanding and experience:
>
> In the most general and common sense, a CG is a space where people with
> different abilities and aspirations but with shared interested can meet
> to [incubate
> stuff](https://csarven.ca/presentations/socially-aware-web#incubation)
> together. There's no strict notion of formal or informal - see also the
> fine print on agreements, rights, and process. At the end of the day,
> there are just different kinds of stamps of approval from different
> stakeholders.
>
> A lot of the interesting and important stuff happens in CGs and IGs, not
> WGs. You can't really have a WG or a successful one at that without
> [demonstrating that proposals have
> matured](
> https://www.w3.org/guide/standards-track/#has-the-proposed-spec-been-incubated-to-reasonable-maturity)
>
> to some degree. Strangely, some think they can just dump their
> proprietary solution out of thin air without properly going through an
> open incubation process. That does not follow the principles of [open
> standards development](https://open-stand.org/about-us/principles/).
> That's called pushing buttons for vendor lock-in or shooting for
> monopoly. Generally speaking, WG reports can show more reliable and
> interoperable solutions than CGs, but that's just part of their process
> and purpose. CGs are just one piece of the bigger picture, and it's
> important to understand their role without getting caught up on all or
> nothing mindset or trying boiling the ocean.
>
> I hate to break it to some, but the LWS WG alone isn't going to fix the
> web. The LWS WG is not superior to the Solid CG. In fact, the Solid CG
> should be thinking more broadly than LWS, because the LWS WG is
> extremely limited in what it can accomplish.
>
> If Solid is generally framed as being about "fixing the web" and society
> at large (tm), then it's obvious the problem space is super complex. It
> can't be tackled in a vacuum. It needs coordination with all sorts of
> groups addressing the challenges from both technical and social angles.
> The Solid CG contributes to that with what it can. It's not just about
> connecting technical specifications, whether internally or across groups
> and standards developing organisations, but also ensuring the work is
> well thought-out, [ethically
> grounded](https://www.w3.org/TR/ethical-web-principles/), and that
> contributors [consider the social
> ramifications](https://w3ctag.github.io/societal-impact-questionnaire/)
> of what they're doing.
>
> Solid CG having work items that overlap (to some extent) with another
> group isn't a bad thing, as I see it. It just means there are multiple
> approaches to solving shared problems (use cases). That's totally normal
> and even healthy. I'd be more worried if there was only one proposed
> solution to a wide range of big problems. Even WGs have delivered
> multiple specs offering different solutions to the exact same use cases.
>
> It's 100% okay for CGs to incubate ideas as far as they're able to. For
> the Solid CG, I'd suggest more focus on cultivating a healthy community,
> welcoming diverse voices, striving for equity, being inclusive, while
> working to eliminate antipatterns (see slides: "uninformed/casual
> comments, non-commitment, withholding knowledge, architecture astronomy,
> behaviour without Group consensus, commonswashing"), and respecting
> processes and guidelines. The technical stuff will sort itself out (tm).
>
> I find there's not enough noise about that in the Solid CG, but a
> disproportionate amount of noise about what a WG thinks or will do with
> flavour x of feature y in specification z, and whether the CG should
> just sit on the sidelines and see how things go. Those that want to do
> that, can step aside so that those that want to continue can without
> friction. As if the kind and amount of things in the [CG's
> scope](https://www.w3.org/community/solid/charter/#scope) is not as wide
> as open as the sky - which is a luxury with plenty of opportunity to
> make all sorts of advancements. Even publishing a W3C WG specification
> is just one step. It ticks the "[adequate implementation
> experience](https://www.w3.org/policies/process/#adequate-implementation)"
>
> box, and Members/Team/etc. approve it at some point for Rec. But many
> Recs just collect dust because they don't get adopted further or the
> ecosystem shifts and what once seemed promising becomes irrelevant.
> That's life. Sometimes specs just sit for ages until an external factor
> makes them critical infrastructure. History is full of examples and not
> just for specs.
>

As the original founder of the Solid Community Group, I set it up to
support open collaboration, enable threaded discussion, and provide a space
to develop specifications. Those early goals were met, and the group
naturally began to evolve.

However, it’s fair to say that for a long stretch, the CG developed a
reputation — both inside and outside the community — for aspects of it
being “ridiculously bureaucratic,” as Tim Berners-Lee once described. That
wasn’t incidental. For several years, leadership was highly centralized
under a single chair, and the group’s dynamics reflected that.

Much of the energy from the open source community fell away during that
period. Contributions slowed. Participation became difficult. Engagement
narrowed.

Just this morning, a developer said to me:

> “If I have any thoughts, it's that I'm sick of all the bureaucracy and
theorizing and I'd like to see more people actually doing things with
Solid.”

In parallel, after version 0.7, the Solid specification process drifted
heavily toward academic formalism and monolithic architecture. Instead of
focusing on broad adoption, practical improvements, or fixing the existing
foundation, the emphasis shifted toward theoretical structures — often more
about individuals building personal reputations than building interoperable
systems. This came at the cost of implementers and the open source
ecosystem.

Recently, though, things have started to shift. Chairs like Michiel have
been consistently welcoming and generous with their time — he went out of
his way to assist me just this morning. Similarly, Jesse regularly advises
and supports contributors, even with his limited time. Together, they are
helping to create a more open and constructive environment. I’ve seen them
provide direct support to grassroots efforts, and I think this has already
moved the needle in a positive direction. I am optimistic that the ODI
leadership will improve Solid (and the CG) for the better.

I'm also optimistic about the direction of Linked Web Storage (LWS) — a
cleaner, more flexible superset of Solid, with broader appeal and fewer
legacy constraints. If approached well, it could help unify the vision
while expanding its relevance.

There’s still work to do, but the direction now seems far more promising.


>
> -Sarven
> https://csarven.ca/#i
>