What services can we offer from 1st July 2020?

I updated the tasks on the wiki page and also changed the draft service levels and prices somewhat, see the screenshot below.

We need to start bringing in some income for this project to pay for the time and server resources is it using, if a few people can volunteer to take on that tasks that don’t have names against them then I think we can have a viable service up and running by 1st July, but this is a very tight timescale and it will need quite a lot of work to pull it off…

Screenshot_2020-06-19 Service levels - Online Meeting Coop Wiki(1)

1 Like

Screen Shot 2020-06-30 at 6.08.38 PM

I have the following use case for some potential clients + imaginary scenarios, and wonder where we see them fit into these service tiers.

  1. Event of 100 people, single room like OPEN 2020. They would pay €200 to set up a Medium account + €100 for the month, then tear down the account? Can they load a list of email addresses to Greenlight to give registration links for access control?

  2. Weekly 6 people meetings, with annual 200 people conference. Medium throughout the year would cost €1,400. They’d rather set up a free account, and pay €300 once.

  3. Language tutor with 20 students, need to set up a room per student (so they don’t go into each other’s rooms accidentally during a class). They would pay for the Large account in order to get > 12 rooms even though all the sessions are 2 people? They are better off creating 20 Free accounts.

  4. I want a custom domain like bbb.deprecated.systems. Both Medium and Large will support this right, since I am an admin of a custom Greenlight instance. I know there is mention of dedicated domain / sub-domain, but it’s unclear whether this mean my domain.

In general, I feel there are too many tiers. Individual and Micro are sort of the same. I can’t see someone needing 3 rooms to not need 6 rooms, or 3 h vs. 6 h. Instead I think it’s useful to make plans with a type of user in mind. For example:

A. The tutor who needs to make as many rooms as they want, but each one limited to 6 participants.

B. For small conferences who cannot afford €300, and want to make a room URL per session before the conference (e.g. Open Publishing Festival), there should be a way where they can make many rooms each with 20 participants and each one only 3 h in duration.

I think the way that the service levels are structured now are reflective of the infrastructure, but don’t reflect real world use cases very well.

It does, you can have meet.hypha.coop and also the email notifications can be set to use a meet@hypha.coop SMTP account, however we haven’t yet got multiple Greenlight containers working… I’m sorry to say that I have got less done in the last 10 or so days than I hoped I would…

I think for most organisations Greenlight containers without limits on numbers of people in meeting room or the length of meetings will make sense, restrictive limits like this only make sense when selling individual accounts rather than containers.

I think I’m with @benhylau here - though I admit that I now have become unclear on what level of management is conducted in a Greenlight container - does it give container admins rights to create room admins, or is it a lower level, where specific rooms can be created, with specific resident hosts? I can no longer remember what kind of rights we conference organisers were given for Open2020, and never was aware at that time how that ‘admin space’ was related to Greenlight ‘container space’. Some kind of Venn diagram of the admin privileges hierarchy would really help, mapped into Greenlight/BBB system architecture, so that we all can see what kinds of constraint there are on how accounts can be administered (as distinct from server/software admin). @osb d’you get this? The ad-hoc administration of user-organisations’ room bundles, by them, is where things should all be focused? Server admin issues should be well in the background, as regards account administration.

Right now, alpha phase, we’re much constrained by what Greenlight capability (and sysadmin familiarity) allows us to administer at the sysadmin level. But the aim should be to move as quickly as is realistic to a use-case based offering of fair-use service bundles (accounts) in the beta phase of meet.coop. And to promise early adopters that this is what we mean to do, in consulation and co-design with them (in collaborative ‘circles’) about room use-cases and organisations’ room-bundle needs, so they stay with us through the painful journey.

I see use cases thus

  • individual person’s ad hoc meeting room - up to seven ppl cameras on for 2 hours - but typically two ppl cameras on for 1 hour, twice a day
  • ’atelier’ workroom for a circle - seven participants coming and going in varying combinations all day - average four ppl cameras on for five hours
  • conference/confluence - 50 participants 6 cameras on over two days plus eight breakouts 50 cameras on total 6 hours
  • town square - 100 ppl coming and going continually every day cameras on average 5ppl staying 20min
  • custom - to be individually negotiated

The nature of this use case typology differs from ben’s, I think. Maybe Ben is seeing owner-entrepreneur/freelance/gig-economy small businesses. I certainly am seeing commons-economy/solidarity-economy/civil-society movement organisations and coops trading under coop principles. No individual or free accounts (maybe when we have a large and reliable surplus!). @wouter what would your use-cases look like?

Account offerings is another matter. I see accounts as offering bundles of these room types in maybe three tiers, under fair-use expectations policed as firmly as is possible, priced accordingly, selling only to organisations:

  • single-circle organisation = ‘simple organisation’ rate - single-person accounts/rates not to be offered. Free accounts not to be routinely offered (but cases of hardship considered)
  • multi-circle organisation = “complex organisation” rate
  • federated network (eg a Hispanic or Japanese language-based network, a bioregional trade and civil society network, a university - an example might be Coop University in the UK) dedicated service rate . ‘Own-server’ badged reselling of bandwidth (as in Collocall?) is not a service to be offered. Only networks under meet.coop governance to be eligible for accounts

I can possibly help with tech support via BBB room…

In Upcoming Conference and Events we are discussing a way to support Event use, which is characterized by:

  • high touch (lots of planning work, trial runs, management of accounts and recordings)
  • high resource (up to 200 participants)
  • durational (usually 1-5 days)

However, most events also have regular meetings throughout the year that fits into one of our existing levels. Perhaps we can add a row, where each paid tier gets durational access to our “event server” for a fee.

For example, Individual accounts can hold 1 event per year. Micro 2 and Small 4 events. Medium unlimited. Every event involves extra fees, but something pretty affordable and depends on the amount of labour needed to set up.

1 Like

@wouter @mikemh and I had a meeting to discuss this, notes here.

Here is my proposal based on our discussion and some other things I added.

Free Small Medium Large Organization Custom
User accounts 1 1 1 1 Unlimited Unlimited
Max rooms per account 1 3 6 9 12 Unlimited
Max meeting participants 6 20 20 50 250 Unlimited
Max meeting duration 1h 3h 6h 6h 12h Unlimited
Event server access*
Customization
Recording

Notes

  • The Free tier is a single Greenlight container centrally managed by Meet.coop where anyone may self-register, these users are not considered Members
  • A Reseller gets three Greenlight containers: Small, Medium, Large, which they resell and revenue share with Meet.coop
  • The Organization and Custom tiers are centrally sold and managed by Meet.coop
  • The Event server is managed by Meet.coop and available to Members for a time duration for a fee (the fee is based on duration if requirements fall within what is offered in our “intake checklist”, custom work will be quoted custom)

@wouter @mikemh @hng @chris @osb and others. Thoughts?

2 Likes

Nice work all.

I don’t think we can limit this without investing in some development time. I could be wrong. My understanding is that the BBB web API allows us to know how long a meeting is going on, and we could keep polling that to know, but we wouldn’t have a way of gracefully kicking out the meeting if it runs out. We might be able to poll and then understand that some users are running over on their meetings and should upgrade? Again though, that will need some work and I am not sure we have resources for it?

Also, although it is probably quite clear, I’d like to flag that I am concerned that we ran over the 1rst of July mega super fast get some money in launch ASAP running as fast as possible momentum and now I don’t see a new target whereby we hold ourselves to account for making it clear how services can be offered and money can come in.

I know there is good organisational work going on and it takes time.

My humble request is for a new target for service offering to form up.

1 Like

My hope as well, that we can have some rough consensus on this here, and we can approve it formally at week’s meeting and start offering the service as soon as multi-Greenlight is ready.

The max duration was on the original table. To be honest I don’t feel it’s so important, or that the numbers here are consequential. Zoom has limit just short of an hour for free tier, most meetings last an hour, that pushes ppl to upgrade. In our case, if 3h meeting isn’t long enough for you and you need 6h, you should probably spend less time in meetings :slight_smile:

Also, even if things are here, doesn’t mean we have to actively police it. At least not a block to launch. Think of server bandwidth and how many providers are actually “unmetered” essentially but don’t advertise that.

With our Greenlight fork it is possible to set the maximum duration of every meeting for a Greenlight instance, although we haven’t tested this a lot.

Personally I would add a duration limit only to the free tier. Also note that Greenlight by default only allows the room limit per User to be set to 1, 5, 10 or unlimited, anything deviating from that would mean additional development work.

2 Likes

Thanks @hng! In fact, I did even integrate those changes from your fork myself and forgot about it :smile: So, we have a configuration knob to control duration, see this commit. Comments on this functionality above are important to reflect on though.

Honestly, I think we should just merge the Small and Medium tiers and offer 5 rooms/20 participants/24h calls, to also simplified this whole table.

The meeting duration can prevent use cases where people literally keep a video on 24h. My old company used to continuously stream rooms between different offices.

Proposal v2

Free Small Large Organization Custom
User accounts 1 1 1 Unlimited Unlimited
Max rooms per account 1 5 10 10 Unlimited
Max meeting participants 5 20 50 250 Unlimited
Max meeting duration 1h 24h 24h 24h Unlimited
Event server access*
Recording
Customization

Probably can allow Large and Organizations to have recorded rooms now too. See Zoom offerings for comparisons (they cap at 24h for first paid tier).

2 Likes

Merging small and medium is a good idea.

One question concerning the max meeting participants: Is this number per meeting/room or overall? BBB does not support meetings with more than 100 users. Also does that mean an Organization gets a dedicated server? 250 participants is quite large and would need a dedicated server in my opinion, most BBB servers can handle 200-300 users at the same time (but not in the same room).

2 Likes

Reading this table, I would assume it means per room. I don’t think there is a way to limit # of participants per Greenlight instance since BBB doesn’t actually know.

This will prevent a lot of our events. Even if cameras are mostly off? Is this part of the spec or general ballpark?

I also agree. 250 is from the original table, it didn’t make much sense to me to be colocated on same BBB. Maybe @chris can comment on the origin of that? That tier does not have a dedi.

1 Like

This is an official recommendation by BBB.

“We recommend no single sessions exceed one hundred (100) users.” https://docs.bigbluebutton.org/support/faq.html#how-many-simultaneous-users-can-bigbluebutton-support

We have always said to our customers that this recommendation exist and we can not support sessions with more than 100 participants, if they may work they may work.

In general it is very hard to get concrete numbers as there are so many factors. BBB also has no real limits, performance just goes done or the server even crashes if usage exceeds the server resources.

Performance wise it’s like this: only listening < audio enabled < webcam enabled.

1 Like

Seems to me, to run a service like this, without means of monitoring usage, is daft. It means dimensions of service bundles and account pricing can’t be based on any operational information. This can’t make sense?

Maybe our use case - as a service-reselling organisation - is different from the original use case of BBB (provision of rooms under the administration of a single educational organisation?). But a business reselling server capacity needs to be able to monitor usage? Basic! Resources need to be found, to scope out the work required to patch this?

Could be that BBB API needs hacking? So, deep-ish work.

When is your ETA @chris ? Is this proving problematic in a way you hadn’t anticipated?

This is realistic imo. My view of the most important use case is to support collaboartive work in teams (‘circles’ even!) with persistent shared workspace and persistent shared documents.

I don’t see ad hoc meetings, each starting from scratch, with presenters bringing their own package of materials in their briefcase, as basically the most significant use case.

These are zoom rooms and we are about one year and perhaps $200k away from technically and operationally able to support that as a service. Ballparking.