Thank you @jeffz and @anon36056958 for the explanations.
But I didn’t post this feedback, because as a developer I couldn’t figure this out. I have some experience with most underlying standards and have been well-fed in the course of time with excellent content and announcements served by @RubenVerborgh (i.e. in the run-up to Solid’s launch).
I am rather looking with the eye of a Product Owner placing my perspective on the user persona’s of people that first encounter Solid and need to make informed decisions on what it is, what it does, and how I can benefit from it.
Landing on the MIT or Inrupt website they should, ideally, very quickly come to the conclusion that “Yes, this is something radically new, the missing parts of the web, and we must evaluate how to be an early adopter of this great work, incorporate in our products and services”. And then burst with enthusiasm, start collecting more info, bringing others on board, etc.
So this is about positioning, content strategy, onboarding (‘customer journey’) and marketing / promotion, rather than a real technical question I had. I’m sure that I could go right ahead to create an OSS side-project, with the information I find on the sites, if that were my intention.
As a developer or architect that does not know about Solid and is perusing the multitude of technologies and frameworks to find the interesting ones for a shortlist, a quickscan of the website might lead the developer to say “Nah, that other app framework had more features and better documentation” and the architect “Meh, it is an app framework. Too bad… thought we had something here”. And move on.
The heavy terminology use of “App” is IMHO problematic, because nowadays in IT everything is casually called an app. Smartphone app, web app, server app, cloud app. Etcetera.
All this, together with licensing and community positioning issue, makes it really easy to interpret Solid in the wrong way, and IMHO may hamper its quick evolution and adoption.
If I land on the website(s) I would want to see much more about the underlying concepts, the specifications and benefits / USP’s they will bring me. Using eye-catching, attention-grabbing diagrams that entice me to dive into the specification texts, and these presented to me in an easy-to-read, comprehensive format and typography. That should come first, and only afterwards I should be taken by the hand to a ‘Let’s us show you how to incorporate all of this in your own work and create some prototypes’ (the ‘Hello World’ tutorial, if you will).
A final note about specification layout and format: ActivityPub did not have a strong accompanying website presence (and still does not have that) with activitypub.rocks - which is quite minimal, doesn’t really ‘rock’. Yet it had a really nice W3C-style specification document, that - I think - pleasantly surprised many developers in the ‘informal’, friendly style it was written and its use of diagrams:
With texts like these:
“So, okay. Alyssa wants to talk to her friends, and her friends want to talk to her! Luckily these “inbox” and “outbox” things can help us out. They both behave differently for GET and POST. Let’s see how that works.”
(Not the typical, tough and dry W3C standards text)
And then after Mastodon was launched, people started ‘dogfooding’ that platform to continue the discussions around further ActivityPub discussions. Has become quite popular really quick in OSS circles, and best way to inform yourself on new initiatives is by participating in the Fediverse. I get always really excited reading the chatter about this tech.
What Solid has going for it and AP had not, is that - from the early start (now) - you have potentially strong web presence (and of course, with @timbl and others, you have great name recognition). Solid movement should capitalize on that, if you ask me, and it needs putting aside the expert technical mindset for a while 