zlacker

>>isodev+(OP)
Thankfully nothing like this is in Jitsi Meet’s TOS: https://jitsi.org/meet-jit-si-terms-of-service/

It never ceases to amaze me how companies choose the worst software!

>>_ddzr+6c
How does Jitsi handle 500-person+ conference calls these days? This is the killer zoom feature - it looks like Jitsi can handle up to 500 now. https://jaas.8x8.vc/#/comparison .

That's personally not enough for many remote companies. So if we're going to have to have Zoom on our machines anyway (to handle an all-company meeting), why not just use it for the rest?

>>ebiest+hh
Are 500-person conference calls actually productive? Surely the number of speakers in any such meeting will be a small percentage of listeners?

>>donalh+pj
It's useful.

It's more of a large-scale broadcast situation. Think of large corporate town halls, town council meetings, etc.

>>CorpOv+Uj
You can just have a conference call with the 5-10 speakers and use broadcasting software to stream it to the audience, why do they need to be in the conference?

>>Gasp0d+ol
Why setup a separate broadcast when listeners can just join the meeting room?

>>dcow+1n
Yes, I know it's more comfortable that way, but if you have to decide between giving all your data from all your meetings to a random US company and a slight annoyance whenever you do conferences with more than 500(!) participants, the choice is pretty simple to me.

Giving all the data to zoom probably means also giving it to most US law enforcement agencies (should they request it), that would be a big no no for me.

>>Gasp0d+4o
You say "just more comfortable" but if you have two streams and one of them is on a channel you know to be unreliable (Jitsi) it's pretty guaranteed the unreliable stream is going to be down a significant percentage of the time. If you're a company with 500 people this isn't a comfort question, you're wasting probably hundreds of hours of your employees' time.