Infrastructuring & federating around the FLOSS toolstack

Call to a gathering in commons.hour. Building an agenda, selecting a timeslot

Federation across public-facing toolstack platforms seems to be emerging as a topic of wider discussion currently. Maybe the same is true for sysadmin-facing toolstack platforms too?

Here’s a small slide deck with an offered agenda. And here is a date poll

Please respond in the date poll, so we have an idea how big the gathering might be? Cheers.

Offered agenda includes three topics:

  • Challenges we’re finding, provisioning FLOSS tools @ platforms
  • Provisioning a toolstack for admins and platform coops differs from provisioning the gneral public?
  • Federating across cultures /languages /regions - Our rationale(s)?

Basic question across all three topics:

  • Is there an ongoing discussion to have here?
  • Is it one discussion, or several?
  • Who will convene it/them?
  • What (async) media & (live) venues will be adopted?
2 Likes

There’s a related thread here Maintainance and volunteer labour. It focuses more on livelihood and contribution within an organisation, as distinct from strategies of federating across organisations.

@Graham and @decentral1se have tagged this thread. Only 2 people (includes me) have voted so far in the date poll. Without more attendees, we don’t have the makings of a discussion. Maybe the issue isn’t made clear enough above . . or is null??

How about @Yurko @dvdjaco @3wc @hng from Tech circle?@benhylau from Org? @osb from Product? @chris @petter from federating coop founders? @freescholar @jamie @jdaviescoates as sysadmin members? @asimong as a platform-building member? If the issue is unclear, ping me? Cheers.

I’ll close the poll Tues 27 July, 20:00 BST

I don’t have capacity to participate. I am currently working about 14 hours a day :slight_smile:

1 Like

I threw my name (and signal of interest) in the poll less due to my involvement in this particular group but due to my involvement in IEEE SA-Open. There seemed to be some overlap given what was in the slides @mikemh made and would like to attend if only just to listen and learn more about what is going on here :slight_smile:

1 Like

I find the topic interesting and relevant, I’ll try to attend but I’m quite stretched in the coming weeks.

1 Like

Small showing in the poll: four plus another possible. @Graham @nolski @bhaugen @mikemh @dvdjaco :heart: On that basis

Others: if you can join please add your name in the poll under that date:
@3wc @petter @freescholar @jamie @asimong

Offered agenda is here. Open for thoughts below, on the proposed agenda topics:

  1. Too much redundancy in public provision of FLOSS tools, too little revenue to support admin of the public platforms? So, federate?
  2. Provisioning the admins vs provisioning the public: federating in the back office, federating in the front office?
  3. Should rationales for federating include escaping regional/cultural/language silos?
1 Like

Thanks Mike. I’ll aim to be on the call. I’m less enthusiastic about your outline agenda, which to my eye looks like it might be diving in too deeply too quickly? Don’t know.

From my perspective I’d like to be part of a conversation that involves some of the people running/offering services that are broadly aligned in terms of values (commons/co-op oriented, FLOSS stack, etc), to understand a bit about whether they are wildly successful or struggling for customers/revenue.

If it’s more the latter, I’m interested to explore the potential for some level of federation/network, which might begin with something very simple like adopting a common statement around values/principles and displaying a shared social brand identity, as a basis on which to build.

I’m interested in any market research and/or customer insight that might exist. If providers are really successful, what is driving that? If struggling, what are the reasons behind that? From my perspective I see what I think is strong latent demand for privacy-respecting non-GAFAM service offerings, so if that’s not translating into customers and revenue it feels really important to try to understand what that’s about.

I think you may be right :wink: I do feel there’s some practical difference between federation that supports admins in the background (I’m thinking Coop Cloud for example), and rationalisation-through-federation across public-facing platforms (many many toolkits around the world, with not very good UI, generally speaking). I also wonder whether cross-regional federation has its own rationale, but I’m not sure what that is: UK/Europe or global North-South for example.

@mikemh, I can make 2021-08-10T14:00:00Z, speak to you then!

EDIT: also added it to the calendar on https://nextcloud.meet.coop

1 Like

Not that it’s any more important than the other aspects, but one thing I can focus around is the underlying ontology that can support a federated ecosystem. I’d be delighted to talk with others who share the interest.

1 Like

The chat today was @asimong @nolski @mikemh and Mary Fee. Shared chat is here:

1 Like

My hunch is that the way this challenge is to be addressed in the upcoming commons.hour project will be through specifying protocols, in a number of areas of practice within meet.coop:

  • Protocols of the platform - as a ‘commons of running code’
  • Protocols of the (async, text) media that we host (for example deliberations in this forum, a handbook, the public-facing website, etc)
  • Protocols of the live P2P ‘venues’ that we create and convene - notably the governance forums that we need to establish, in order to operate as a multistakeholder coop (General Assembly, Community Circle, etc).
  • Protocols of the contributions made by different kinds of members: ops members, user members (and the ways in which contributions are recognised - including getting paid for work hours)

Obviously a well founded set of protocols implies a solid ontology. Is the work of ‘ontologising’ different in principle, in any way, from the work of ‘protocolling’? Or do they reach the same outcomes by different routes?

Protocols (in the sense used here, as principles-for-people, not engineering descriptions) are specifications of little elements of practice? While ontologies are specifications of entities? Not exactly the same route? Not just philosophy I think! Has some practical implications?

I agree @mikemh that it may well be in conjuction with specifying protocols, but saying “through specifying protocols” runs the risk of people either thinking that all they need to do is to specify a protocol that they can get to work, and that will somehow ‘solve’ the ontology (it won’t); or that approaching with a protocol mind-set is a good approach to developing ontologies (I doubt it).

The most important thing to me, in specifying an ontology, is that it relates to people’s understanding of the domain. “Relates to”, mark you, not simply “reflects”, because different people have different understandings of a domain, and the challenge can be seen as getting them into dialogue to broaden their understanding to encompass (somehow) the ideas of others.

I’d say, rather, that good protocols require a sound ontology. Ontologies aren’t just about types of object (and particularly not as I know you favour processes over objects) but can be about all types of entity and their relationships, including processes. I wish I had a good example to hand, but I don’t…

I don’t have much capacity to contribute at present, but briefly …

I’m less enthusiastic about your outline agenda, which to my eye looks like it might be diving in too deeply too quickly?

I wonder if the problem is actually the opposite. Think back to the open space session we had for the Open App Ecosystem at the Open conference in London (2018?). I left the agenda intentionally vague, to allow those who gathered on the day to use the time as we saw fit, rather than being tied to a preconceived agenda defined by me. But although a lot of interesting perspectives were shared, the lack of a clear goal for getting everyone in a room resulted in a fairly wooly and somewhat directionless discussion.

I’ve been thinking today about the concept of “slow technology” (a la Slow Food). Which could look like accepting that sustainable change takes time and that although it’s easy to feel like replacing predatory platforms needs to be done yesterday, we might actually make more progress if we plan out our work over a longer timeframe.

To use this as an example, what if instead of calling for a video conference session ASAP, @mikemh proposed a series of sessions, starting in 6 months time? The intervening time could then be used to gather those who might want to attend in an asynchronous discussion, decide together how many sessions to have and how long to make them (eg 3 sessions or 2 hours, or 6 sessions of 1 hour), and collaboratively crafting a detailed agenda for each one. That way, by the time everyone is gathered in realtime, a lot of the groundwork has already been done to establish some shared context, and the sessions can be used in a more focussed way to make decisions, set specific organizational plans in motion, divvy up tasks etc.

Just a thought…

Thanks for this thoughtful stuff. I’ll look at it in the context of commons.hour I think maybe what we’re doing there is some kind of hybrid. Anyway, I’ll think later. Cheers