Great post! I am not sure about DevRel wrt Solid, but that is just because the strategy of Solid vs. Inrupt regarding positioning and finding adoption in ‘the market’ is not clear to me. That’s okay, they don’t need to share that with me, and there may be commercial interests that make other audiences more interesting to pitch to. But I can’t help but wonder if Solid couldn’t have a way bigger, way more active developer community by now. That folllowed by the thought that maybe Solid is still in too early stage of development to spend much time on ‘DevRel’, or that I am just not in the audience that’s interesting for Inrupt and other companies / institutions involved. Maybe the intention is to find uptake through corporate, governmental and academic channels mostly. I don’t know.
Yes, @jeffz is among the group of very helpful community members. Such help is so important to get people started. Thank you, Jeff!
Yes! I’ve had several similar discussions on ‘product’ positioning in the path. The Solid website has been significantly improved and now states more clearly what Solid is about. The things you mention provide a simple, comprehensive and compelling offering that could be one of those ‘stable stepping stones’ I mentioned, that can entice technologists to become passionate for Solid and stay on as long-term technology advocates building all kinds of ecosystem tools in different languages.
Compared to not so long ago the various specification documents have been much improved, so I am hopeful that such a stable staring point is indeed forged. Due attention then also needs to be given to some of the DevRel-related activities you mention.
Thanks @NoelDeMartin for reminding us about your great article on Interoperable serendipity. In the discussion at the time I mentioned the challenges that I experience promoting this kind of interoperability for the Fediverse. A big issue here is that developers tend to focus most on their own apps and take what is available to them, expand a bit on that, but then do not spend the time to make their extension easily accessible to others. The result is what I call Ad-hoc Interoperability. Over time this creates a patchwork of slightly incompatible apps that make interoperability harder and harder.
This is what I described above. But now we’ve only created the potential for reuse. As your article states this is not enough, and will not work if something extra isn’t added. Those imho are social aspects, collaboration, etc. that are missing. And this is something I feel as an issue for Solid Project to tackle too, as there’s imho too much of “If we just have all these specs then Interoperability is a solved problem”.
Btw, I came upon a much better, more universal, term for Lens-based interoperability, namely interconnectivity. I was introduced to it by @steffen who started Iconet Foundation that is dedicated to the concept.
On the whole I think that social aspects are crucial, not just within the software development lifecycle of one project, but across an entire ecosystem. And that focusing on formation of a healthy “social fabric” is key to interoperable serendipity. I am involved in an initiative that is not yet launched called Social Coding that intends to explore these social aspects for the Free Software Development Lifecycle (FSDL) and leverages the Fediverse (a Peopleverse!) as the social fabric to do so. This will be a crowdsourced initiative.