I’ve split off some of the previous comments here into separate threads, there is a draft service level wiki page.
Where did the price points on https://wiki.meet.coop/wiki/Service_levels come from?
Are they based on costs? And do you know what margins they would deliver?
Atm the Individual price of £15/month (plus the setup of £30) makes Meet.coop more than Zoom (currently £14.39/month for the basic account - with no set up fee) - I think we should be aiming to undercut Zoom to provide an incentive for people to switch to meet.coop
I made them up, they are guess work, but I’m also now of the view that
meet.coop itself shouldn’t get into the business of managing individual accounts and that this should be delegated to the co-operative member organisations.
Yeah spot on, I’ve been showing friends and they are immediately confused as to how they can see what they would be signing up for and how much it costs. I suppose we’re gonna need to nail this down as part of the What services can we offer from 1st July 2020? by optimising the site for this. Adding a Pricing or Sign-up button or whatever, leaving that to the pros!
So meet.coop as a wholesaler?
It gives a way for member coops to add some value and earn some margin.
They are closer to market.
meet.coop is a good brand - does its own work for you
for this to work well needs cale
will member coops set different prices?
Reviewing the forum posts and wiki proposals and having had some discussions with a few of you, let me try to summarise the critical issues.
First, we have a tremendous opportunity right now, aiming to offer the best services we can by the end of next week. This means a) simplicity as much as we can, b) adopt what is already available in terms of technological development and also in terms of market knowledge and in terms of legal structures and economic and social organisation.
Second, we also collectively have thoughts and aspirations to grow this initiative into something bigger, better and friendlier, but that will take some more time. Let’s not forget the initial Roadmap and its stages. If we start next week with the best we can manage, than we may have a chance to grow our social base and make steps to become more mature in the coming stages.
In this sense, NOW is the focus on getting especially collectives i.e. organisations on board, and focus on those from the Commons Cooperative Economy - our immediate “political” friends and aligned relations. Together we build up the movement and go through the first stages of development, working with what we have. And towards constituting a more powerful organisation, with the funds and structure to cope with the larger vision. For me the larger vision is what Open.Coop has in mind and has tried to express over the last years, where our family, friends and foos can easily join and contribute attention, time, resources and money towards the greater good of building a p2p commons cooperative networked knowledge society.
Back to NOW, challenges:
user registration: we don’t have yet the infrastructure or capacity to have a Single Sign On user account management system that facilitates users to be managed by the involved collectives, nor do we have much time to manuallly manage that, so we need to downplay user management as much as we can. This is especially problematic for individual membership.
-> so far we have identified 2 ways for servicing individual members
a. they become members of any of the co-producing membership based organisations with individual members (Webarchitects, Collective.tools, femProcomuns/CommonsCloud.coop, OpenCoop) who give them access to a dedicated GL container of their cooperative
b. we have one shared Greenlight container for individual members where all coops of a. co-manage individual users (this means 1. user self registers and gets a free account and 2. the managers covert the free account into a host account 3. the managers make sure changes are applied to the account when the user stops or modifies paying)
consumer organisation members: with the current state of technology (and especially thanks to ColloCall’s work of the last months and sharing that with us), we can now set key variables to limit the usage in ways that have a meaningful relation with the resulting costs:
a. maximum concurrent users
b. maximum number of rooms
c. maximum duration
Real costs are in fact more unpredictable, mainly as this involves collective coordination, e.g. when all users would coordinate to spread out their workshops, general assemblies and conferences according to server capacity, then costs would be much less than without such coordination. Starting hypothesis is that there will only be so much coordination, and in particular for the larger events.
Chris made a proposal to keep The Online Meeting Cooperative at this point in time a cooperative of cooperatives. I think our ambition is more than that, but maybe it is a realistic proposal for the current stage in our roadmap. I’d suggest to amend the proposal at some points, for example there’s no need to restrict consumer members to mandatory be cooperatives, we can welcome anyone willing to contribute as a member, also associations, foundations and even mainstream companies. Think about this: On May 6th we got together 3 coops to share a BBB server, and right away decided to allow any commons en/or social solidarity economy actor to join as member of the collective initiative. That is what us got here. And while thinking of the bigger picture and making first sketches of a sustainability plan, this is what we have, to aim to be operational in 10 days time (time is ticking )
In some way we need to compensate the people (organisations) who do the work. Maybe Chris’ proposal is one that could be put to work quickest? We should however keep our minds open to also work for the next stages to come, where we maybe setting up a new legal entity with all the necessary infrastructures.
In any case, we need to agree on membership contributions for each service level. IMHO they should be the same for all, unless a customised service is offered really. Then a part of those contributions could be kept by the co-producing member cooperatives. Imagine OpenCoop, femProcomuns, Collective.tools, Autonomic, Remix, or Webarchitects would work with an organisation who needs a solution to organise their online meetings, workshops, general assemblies etc. This might involve an intense relation where one helps to raise awareness for the distinct aspects of the Meet.coop offering, conversations, handholding and sales offerings and efforts until contract, invoicing and collecting the funds. Say any one of our organisations spends 200 hours to get, say, 40 such consumer member organisations on board. Our respective organisations charge the agreed contributions for the different services and keep a fraction of the revenue to compensate the work done while contributing the largest part (which need to be agreed) to the collective fund of meetcoop. Consider these members to contribute 2000€ per month or 24000€ for the first year. Then what would be a decent contribution for each team to accompany and get on board this group of organisations? Remember that these numbers are completely fictitious, but you get the idea.
WRT the service levels, I have changed the wiki page, adjusting to ColloCall’s prices mostly and taking into account that we also want to offer a free account (with restrictions) and for individual members. How does it look now? Is it too cheap? I’m not sure whether we should be below zoom’s prices (as that could make us more precarious than we already are) or above their price levels (as that could price us out of the “market”). From a user perspective, one wants a good quality, so it shouldn’t be too cheap or it can’t be developed nor maintained… In any case, ColloCall’s prices are competitive enough mostly, isn’t it?
- the general idea of current service levels are fine
- we can add some line items that express our cooperative differentiation (e.g. how “users” can become “participants” as co-producers)
- this doesn’t need to be “in your face”, if people click into it they find scope of participation at different tiers
- the tiers can be “join our weekly meetings”, “expand our offerings together to suit your needs”, “plan an event with us”, “start your own offering with integration to our collective infra”
- it must be really easy for people to sign up, complexity around cooperative participation can be gradually scaled up as the user wants
- once we have a process from Governance on how to make decisions, we can move these things along much quicker but based on consensus
But we have no actual way to make it “really easy for people to sign up” and be automatically provided with an account and we have no prospect of being able to solve this technological issue in the near term.
As I explained on the governance thread, we could create a sign-up form linked to a payment system like Open Collective, PayPal, Stripe of whatever and:
This doesn’t scale and if we have a dozen admins from different organisations creating and managing accounts on two or more Greenlight containers and having to manually move accounts between containers when service levels change, having to manually delete accounts when the monthly payment doesn’t come though and so on and so forth we are creating a administrative nightmare for ourselves. I’m strongly of the view that we shouldn’t do this unless we can start automating things, however I do think it would be fine for Webarchitects and other co-ops to have one or more containers each and for them to manage it for their clients manually.
Thanks @wouter, I’m just trying to make sure we keep our feet on the ground and take one step at a time — at the moment we have a group of co-operatives who want to make this happen and we have a great advantage when working with other co-operatives that we can generally work on the assumption that we have common shared principals and ethics and we can be honest and open with each other and I think we really need this at the moment because we are putting a lot of resources into this project on trust.
@chris thanks for explaining the technical limitations to automated account creation. However, I don’t think that is a prerequisite to making it easy for people to sign up.
I think there are a couple options to allowing individuals to sign up, pay, and use Meet.coop infrastructure:
What @chris proposes, to distribute the manual account creation and maintenance to member orgs. People arriving to Meet.coop are greeted with a form like what @decentral1se referenced in Governance Model they make a subscription on OC or Stripe, and wait for an email with account details within some time frame we commit to.
We host an “official” Meet.coop instance, and allow people to subscribe via an “official” OC hosted at open-coop, and wait for an email with account details within some time frame we commit to.
I think both these are possible. I can see how some of us may favour 1 for scalability, and 2 for usability. This is where we need a way to make decisions together.
@osb do you think both the above options, with proper marketing copy on the website, can address your concerns here?
@chris on the technical side, I want to clarify the steps to account creation. My understanding is:
All the Greenlight containers share the same BBB backend server
Sysadmin manually verify payment
Sysadmin manually login into the correct Greenlight container
If it’s a admin account run
If it’s a user account run
Sysadmin send email to new customer with access information
Does that sound correct? Is the user account the same thing as when I sign up using https://demo.meet.coop/b/signup?
I understand that the commands for listing accounts, updating accounts and removing accounts are missing, but how do you see those relevant in signup/onboard flow?
Do you think 1-4 can be automated via a Stripe (not familiar with OC API) webhook triggered execution of these steps?
Yes and no, yes the user account is the same as the one created using the signup form but no I don’t think we can use the CLI for account management, we can only use the web interface.
This is because we don’t have a full set of commands available to fully automate it, contrast the Greenlight single command:
run rake user:create[name,email,password,role,provider]
With the Nextcloud
occ user commands or the WordPress
wp user commands — both of these do allow account management to be automated but we only have a create command and account creation is not enough to allow things to be automated properly and if we are not automating it properly then it would be better if only the web admin interface is used.
Is greenlight the ONLY way to manage accounts for BBB?
It seems odd to structure our co-op and our propositions because of the limitations of Greenlight.
Could we not use Nextcloud’s account management functionality - and include BBB within that?
As I understand from various inputs from all of you, we are now trying to get some decent service proposition up and running, for which we largely copy the technical adaptations to Greenlight developed by ColloCall, but offering a more participatory process, i.e. building a community with users and members with the horizon of constituting a real platform coop.
In that light, I’d say both options could work together, and my preference would be to do so under the common brand of The Online Meeting Cooperative with meet.coop subdomains. So we make sure we don’t split the community and signal the common effort that goes into this project. Of course organisations who want a dedicated GL container or even dedicated BBB server can wish whatever domain and customisation, as long as they pay for it. But even then, we should seek to channel part of the funds (paid by such customer to a partner) towards the collective as compensation for the investments done collectively.
That could mean, IMHO:
[quote=“benhylau, post:15, topic:134”]
What @chris proposes, to distribute the manual account creation and maintenance to member orgs. People arriving to Meet.coop are greeted with a form like what @decentral1se referenced in Governance Model they make a subscription on OC or Stripe, and wait for an email with account details within some time frame we commit to.[/quote]
Webarchitects could offer a GL container webarchitects1.meet.coop for the (to be) defined “Service Level 1” and welcome its members wishing such service level there. Likewise all producer members could do so. We need to agree which fraction of the paid contributions goes to the collective fund.
What if we’d do that, have like the “official” service sign up through OpenCollective, hosted by OpenCoop?
- A user would need to register at OC, choose the Meet.coop Service Level, make the payment (recurring? Or 6/12 month commitment?)
- Would we then send an invite link to such user to sign up at the selected GL container?
- a team should be reviewing periodically whether payments are made by each user or inform the user of possible cancellation if payment is not in by the due date
- The OC will take 5% plus credit card costs
- How about invoices, does OC generate them or would that need to be done at OpenCoop?
- Will all remaining funds go to the collective and compensate the various work from there, or maybe there’s some percentage that needs to stay in OpenCoop for admin work or so?
At the level of femProcomuns/CommonsCloud.coop we were thinking to have a third option:
- an existing user (account creation is free at gent.commonscloud.coop) goes to the CommonsCloud form to request activation of the desired service level (currently this form, but we need to make it better to choose the possible service levels).
- our team adds a line in the contract of that user in our Odoo ERP system so the next month this will be charged from his/her bank account through standard SEPA bank debit procedures (still contract changes are now still done manually but we hope to automate that through our WP site and the Odoo API after the summer)
- our team activates the access to the desired service inside the gent.commonscloud.coop website.
As this is a webinterface to our LDAP directory, we’ll need to configure the GL containers to authenticate against our LDAP service. This way the user can login to the various services with the same account.
As stated elsewhere, we did publish our software under a free license. Unfortunately we have no developer(s) to maintain or further develop this software at the moment. Possibly you know of other SSO user account management webinterfaces that could do the job? At some point we’ll need to compare what’s the current state of the art and see what software to choose, don’t you think? It’ll require funds to develop/improve, but necessary to provide a decent user experience IMHO.
Picking up on one aspect of this:
We will need to seek permission to provide
example.meet.coop sub-domains to organisations that are co-operatives themselves, we are not be allowed to provide sub-domains to organisations that are not co-operatives, for non-cooperative organisations we would need to use a sub-domain on their existing domain or perhaps buy another domain for this, see the .Coop Third-Level Domain Policy which contains:
Second level domain registrants may submit a proposal to dotCoop to allow the maintenance of third-level domains for the use of eligible cooperatives. The following restrictions will apply for the use of third-level domains by organizations other than the second-level registrant and must be included in the proposal for third-level domain usage:
- Users must be members of the second level registrant organization;
- Users must be independently eligible for .coop domains based on the .coop Charter;
- The second level registrant will be assessed a fee by dotCoop for verification of eligibility of each of these third level domain users;
- The second level registrant will be responsible for maintenance of DNS information for each third-level domain;
- Each third-level domain user must agree to the terms of the agreement of the registrar of the second-level domain which includes the terms of the current .coop Registration Agreement.
this seems really important to me … before we start building meet.coop around what greenlight can do… can any one tell us:
Greenlight can use external authentication, look at the example Docker environment file:
There are examples for authentication via Google Apps hosted domains, Microsoft Office 365 Login Provider and LDAP authentication — we can configure Greenlight containers to use any of these methods (but only one method per container) rather than using the Greenlight user management interface.
Regarding using Moodle, Nextcloud, WordPress, Drupal or any other plugin I posted the following on another thread:
Maybe for simplicity we could stick to cooperatives being in charge of production, and those actors who fall outside the social and solidarity economy can only be user members. Which producer member right now is not a cooperative, but still in the SSE? Maybe Remix and Autonomous? If they really want to manage GL containers, they either co-produce them with us or do it under another domain (but that’d require maybe some more time to agree how exactly).
If we focus now on getting our service out, what do we need to agree on and get up in the air?
- GL containers for those producer members who want to resell, like Webarchitects, possibly femProcomuns with CommonsCloud, who else wants that?
- we need a “reseller” agreement, to define how we handle responsibilities and which part of the contribution stays at the producer coop and which part goes to the collective.
- If we follow OSB’s proposal to have a Meet.coop account on OpenCollective, with OpenCoop as fiscal host, we could treat this as a collectively produced service (where some of us agree to share responsibility for account management), which is more centrally displayed at the meet.coop website. About the hassle of account management (I know from CommonsCloud), I think we could define routines between a few of us to handle the onboarding of the first say 100 members, until we get a decent onboarding and account management system.
- For 3) we’d need to agree more finegrained about responsibility and sharing the proceeds. Nothing impossible IMHO.
I think something like this is a good idea.
I have failed to write the Ansible to enable us to start running multiple Greenlight containers by 1st July, it is probably going to be a week late. Perhaps all we should aim to do for July is provide Greenlight containers for members? And once we know how that is working and what the usage looks like and perhaps we have some additional monitoring setup we then decide on our next steps?
We still need to agree on the Service Levels. Chris made a great start in the wiki, which I adjusted to make it somewhat more in line with the ColloCall prices. But I read doubts at your part, let me cite from the Systems architecture thread:
Now, I think people will want to know what they get before making any level of contribution. If we tell them “you need to pay between 20 and 200 a month, depending on to be defined and implemented usage statistics” they walk away. In fact, many are asking for such definition.
Also the ColloCall prices and service level definitions are rather ok, isn’t it?
In Open App Ecosystem Loomio I posted thoughts about the state of ‘rooms’ technology, referring to Greenlight and the configurability of BBB rooms.
A query came in
Glad to see this more detailed feedback about the Open2020 BBB experience. I had, unfortunately, recommended it to OSHWA based on the earlier report of a successful experience. And I also see that social.coop has decided to join meet.coop which hosts BBB sessions.
Should I rescind my recommendation?
Here are some clips from my response . . meet.coop is working hard on formulating its service offering . . A lot will rest at first on fair-use agreements . . The BBB tech itself works, no problem, the challenges are more about the large-scale administration of the front end . . In the next month, in meet.coop, things will firm up membership-wise and offering-wise.