I would suggest that it would be potentially weeks if not months of work by experienced developers, of which we have none — sorry but we do not have the resources for this, we don’t even have the resources to pay ourselves anything for the work we are doing at the moment.
1 Like
Fair enough, on both counts @chris yes . . especially, absolutely, regarding repayment for all the work that has been ploughed in to date. 
If that’s what it takes to get a proper front end that serves organisations’ needs, then there’s serious P2P code organising/lobbying to be done in the Greenlight community, and probably serious fundraising to be done (crowdfunding, maybe?). But developing users’ capacity to manage room bundles is a pivotal thing? For users, the rooms are the reality of the system. they live there.
In the long run, surely meet.coop is not just reselling server bandwidth under fair use? We’re eventually offering well-adapted means of organising for coops and movement organisations. What they need is digital rooms equipped for purposes of diverse kinds, with appropriate tools, so they can inhabit them, and do work in them? For them, the front end is everything?
This is a short-term strategy consideration for a room admin circle? To be formed soon - before Alpha launch of the service.
I note that there are major front-end issues regarding account admin and Greenlight containers in the Marketing thread Marketing Meet.coop.
Being constrained by what Greenlight will and won’t do is a critical issue, and it seems some working compromise is going to be needed, short-term. Finding the balance on this calls for a joint heads-down by the contribution accounting circle (eg @chris @wouter @osb ) and the operations circle (eg @chris @hng Koumbit etc) - which as-yet haven’t been constituted. This immediate compromise (and longer-term intentions) needs resolving asap? This will not resolve in the weekly all-in open video forum, without detailed prep, it’s too tech, and the Marketing thread is already too complex to easily follow.
Let’s kick in with executive action in circles asap? An ‘organise in circles’ decision is urgent business for Thursday? With preparatory/pre-emptive work in the above named circles before Thursday?
There isn’t anything to resolve @mikemh, all we have the are tools we have, we are not in a position to change them at the moment so all we can do is use them as they are or not use them.
Let’s make sure we distinguish clearly between what we can and fins desirable to do NOW and what constitutes our WISHLIST of how we’d like to be working and offering our services. For the NOW we can do a sprint with the limited resources in time and software that we have (which is already a lot really) and at the same time we go find the means to work towards fulfilling our wishes.
That may involve 1) early movement building with likeminded actors who have already certain awareness of privacy and the need for cooperative platforms and are willing to do a little extra effort compared to the big data exploiting oligarchs like google and zoom, 2) seek grants from funds around privacy and cooperative commons development, 3) develop plans for collective financing of the cooperative entity and server infrastructure that we need.
If we want to get somewhere collectively, we cannot forget the NOW, and here’s where I think the ideas of executive circles might be good to define further - I understand that it relates to responsibilities and also to economic compensations, and rules for inclusion / exclusion shall be defined, a little task in its own. @mikemh have you developed this idea somewhere or care to define it in a wiki page?
Of course we can also not forget the mid- and long-term vision to realise our shared wishlist, but we should at least keep these two levels separated to not confuse ourselves or new people reading up on this. How do we organise that best?
I understand @chris. What needs resolving, in my perception, is not sysadmin tools stuff (yes, we have the Greenlight that we have) but account-admin practical stuff . .
- how accounts will be set up
- how/who will perform (and be paid for) account admin/members registration/enquiries
- how initial contaners will be managed (will it be centralised or to some degree decentralised across coops - founder coops?)
- what the future implications are for recreating containers under more distributed management
- what kinds of account types can be offered to incoming members - one container fits all?
- what pricing to place on these?
. . within (short-term) admin limitations of existing tools? Currently this seems to me to be very unclear, in need of urgent resolving.
I don’t see a form of practice yet emerging, that will underpin a public launch of a service (and a development project) that looks coherent and interesting to a would-be member organisation already participating in Zoom.
If you believe there’s a current post in a thread that defines an adequate working method, for the Alpha phase of membership registrations, do please highlight the link Chris? It would be a relief to discover I’m mistaken.
As I have said before we need to delegate the admin of each Greenlight container to a member organisation, this is the only simple and straightforward solution I can think of for the short term.
@wouter I’ll post a slide deck in the next hour, containing maps/prompts on executive circles, membership classes, contribution accounting, voting rights.
Uh huh . . so, is this three member organisations (Webarchitects, femProComuns, collective.tools) with three locally administered Greenlight containers, offering just one kind of plain-vanilla room deal? Or with possible variation of room deals, across the three coops? One price fits all, or different levels of pricing for ‘the same’ plain-vanilla, fair-use deal, from any Greenlight admin? Centralised, one-stop-shop, member registration and account/Greenlight setup, or the original idea that intending members would be able get just one (equivalent?) room, from any of the three founder coops?
The original three-coop shopfront looks to me - and to @osb I think - like a complete maze as a registration approach, of no appeal to any but the most enthusiastic, early-adopter, principled supporters of platform cooperativism. Do we not have an alternative to that?
In that case it would call, I think, for a very low-key, small community launch of the Alpha phase, which basically would constitute a prototype to be replaced eventually by a model suited for large-scale membership. And with a whole bunch of fundraising and freecode hacker enlistment in parallel, to develop a more adequate account admin front end, before going large.
There are more than the three founding member organisations involved now and I’d simply leave it 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.
We have no way of automating the setting up or removal of Greenlight accounts so this isn’t something we can do in a way that can scale, all we can do is manually manage this process and to make management simple I’m suggesting that the organisation responsible for each Greenlight container should be the organisation responsible for the management of the accounts.
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.
1 Like
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.