We’re already scoping out client needs for re-selling meet.coop services through Autonomic Co-op and would easily be ready to start marketing this, managing accounts and rolling our own greenlight container all from Autonomic side! This seems like the only logical move we can make right now and I think it would be fine. It would really be great if we could prioritise and close off what is blocking us from getting this step done this week.
I agree and I’m afraid that I haven’t been able to make the progress I hoped to be able to make in the last 10 or so days, in terms of the updates to the Ansible role to enable multiple Greelight containers to be run, this is in part because I have spent a fair amount of time discussing governance and what we can and cannot do with the software we have at hand, however I’m getting there…
One thing we will need to make a decison on is the existing accounts, I suggest I should try to retain them on demo.meet.coop and start again with all new Greenlight containers on ca.meet.coop, as I don’t think anyone is in control of accounts on this server? Or have I got that wrong?
[@chris ] up to the organisations in question regarding how many Greenlight containers they need for their own organisation and their clients and how they are configured and how they raise money to pay for them
Goodness, this is pragmatic and no mistake! Not so much a coop of coops, or a federation, but an un-federation, under a minimal server-sharing protocol. It’s not that I have a problem with a sysadmin-led way forward (well, i fact I do) but that if meet.coop is ever to become a coop under multi-stakeholder governance, or even a commons of digital means, driven by use-situations in the commons-coop economy, such a fragmentary financial and operational start is likely to be an obstacle.
I think that then, the launch could only be seen as a prototype of an organisation (Plan A), which might lead to a proper, user-oriented version (of system, and of organisation) only after achieving some serious development of front-end capability for managing containers. There is a real bootstrapping problem here. Yes, some revenue does have to be brought in thro selling something soon. But I think we need to start also thinking crowdfunding for front-end development, and a properly specified, use-oriented Greenlight, as an urgent Plan B.
[@decentral1se ] prioritise and close off what is blocking us from getting this step done this week [launching marketing from Autonomic Coop]
I get that, and wouldn’t want to stand in the way of that practical step. I recognise that something has to be sold, soon, to pay back sysadmin labour. And that Webarchitects and Autonomic (Koumbit and Hypha too?) have no problem with that plan, which seems ‘the only logical move’. But I don’t think this amounts to “re-selling meet.coop services”. Rather it looks like a way of not constituting any meet.coop service at all, other than the reselling of bandwidth on the server that meet.coop, the multi-stakeholder, user-oriented organisation, might have been be developed on.
If that is meet.coop, July2020, then governance is simple enough, I think: an informal federation or a coop, of sysadmin producer coops, re-selling bandwidth in room-sized pieces to passive customers.
(Genuinely) good luck to Plan A. Time to start parallel Plan B.
I’d rather you didn’t dichotmise the ideas being proposed here based on the role of the one proposing it. Also, positing the ideas proposed here as an obstacle seems upside down since we’re responding to the actual obstacle of next to nothing resources and a set of tools which don’t quite fit.
I realise that this curt comment might make it seem like I don’t appreciate the work and planning that is happening on governance. I apologise for that. To re-phrase, this seems like the most viable plan for bringing in money quickly based on the technical limitations we now understand. I don’t see this plan of action in opposition to the wider goals of being multi-stakeholder.
This isn’t just about sharing bandwidth, although a lot of bandwidth is essential for the service to work, the reason that the three founding co-ops came together to create this project was because we didn’t have the resources to provide a co-operative video conferencing system on our own, we were then joined by other who also contributed resources such as time and money — without this co-operation we couldn’t have got to where we are now.
This is spot on and it is also exactly what Webarchitects and no doubt lots of other small co-ops and other small organisations providing services using Free software tools have to work with all the time (if they are not working for rich organisations) — we have no capital, we earn just enough to stay afloat by working very long hours and we wish we could could produce software with all the features you would like to see but these things take a lot of skills and time and if we are not in a position to do it ourselves then money is needed to pay others to do the work and as I have said before we have no money… So we are just doing what we can with the small amount of resources we have, what else can we do?
2 Likes
I didn’t see it as curt @decentral1se , thanks for your comment. I can see how things look from the server resources standpoint, and as @chris has just pointed out, there is server/bandwidth resource available now that wasn’t, before the federated strategy was adopted. So a real step forward.
Also can see that from the pragmatic standpoint of now running something on that resource that is revenue earning, there may only seem to be “one logical way forward” given the inadequacy of the front end for any more complex social and economic plan. So I didn’t mean to be snarky or polarising when I wrote of a sysadmin view. I think its a very straightforward description of what’s leading the development at this time.
It does seem clear at least to me, that to achieve anything more complex in economic terms, or room-creation and -usage terms, or governance and collaboration terms, is going to require investment in major tools development (Greenlight). Thus . . Plan B in parallel. I don’t imagine it could be booted from the revenue base of piecemeal selling by individual coops - that’s barely enough to cover the bread and butter ops and repay the up-front labour? So it needs something like crowdfunding, and a re-spec of what a proper Greenlight would need to do? That approach would take some time to spin up.
1 Like
I get it @chris It’s a rock and a hard place, with very litle slack.
Not being someone who has to make ends meet in the hard place, I find myself looking for some other approach, that might enable some other broader outcome, thro making some broader kind of alliance maybe. It’s taking some time to understand the pragmatic constraints that currently prevail in this venture, and I do sympathise with the position I now understand you and other small coops are living with, and are stating here in the thread.
I do genuinely supprt Plan A. I do absolutely need to discover the possibilities for a Plan B, involving some other/expanded grouping of allies and resources. I understand Plan A will make some small contribution to immediate difficulties in a tight situation. But it’s a Plan B that will make a difference to the agendas that my work is derived from, as a commons economy activist rather than a server-services cooperator. It’s my grand-daughter’s ‘hard place’ in 20 years time, that I have my eyes on.
I haven’t had time to workout the nature of the development community around BigBlueButton yet however your assumptions @mikemh did remind me of this cartoon.
1 Like
My worst fears! 
Seriously though . . this is a politics, and is as hard to handle in its own way as all the other kinds. I wouldn’t lightly take on a project commitment that requires a major fork in a FLOSS repo. But if duty calls . . ? This is where being an anthropologist comes into its own. “I’m from Mars - Tell me, what is it you folks do around here?” 
Philosophy alert . . Browsing the Open Apps Ecosystem Loomio today - important for our venture here? - I found a link to this . .
programming communities are founded on us-and-them interactions with self-important leaders where something is good if it’s part of your tribe’s way of doing things, and bad if it’s part of somebody else’s. In such environments, cross-pollination and common goals rarely exist between framework communities
and this
frameworks are designed by people who are reinventing things and discovering things on their own . . like two electrical engineers arguing about what a “volt” is
O dear. The source is here in Medium
The author’s response is to prescribe professionalised engineering discipline. Medicine as bad the the sickness, I might say. But there is a critique here, of the hacker mode that has been established in the past 35 years or so, in the name of ‘agile’ and ‘free code’. Doing agile and cross-culture, and at the same time mobilising tradition and architectural skill, is a game we need to get good at, pretty fast.
With Greenlight, the code repo, we find ourselves somewhere in the crossfire? With meet.coop the coop, too, as a form of activist organisation: needs agile and architecture? That’s a class act.