Please someone correct me, but my understanding is that Jitsi meet has a very different architecture compared to Zoom.
Jitsi Meet uses a "SFU" which means the A/V stream of each participant is sent to all the others. That basically does not scale in terms of network bandwidth.
Zoom seems to use a central server that kind of "mix" streams and send them to all participants. Or something hybrid.
Jitsi could be able to connect to an "MCU" like OpenMCU for this kind of architecture, but I have no clue if it is easy or not to deploy.
I am working in a full-remote company with ~15 people. Jitsi is ok for meetings with 2-4 people. With more people, it just does not work reliably. Zoom does.
Zoom also use the Selective Forwarding Unit (SFU) architecture. Or a central server that kind of "mix" streams and send them to all participants, if you will.
Jitsi Videobridge does this by receiving simulcast streams from each participant. This server individually picks out streams and qualities that will fit in each recipient's downstream pipe based on measured bandwidth and configured priorities (e.g. you could choose to give more bandwidth to those who are actively speaking, or shut down all but the last N speakers video streams).
Yes, the available network bandwith on a Jitsi Videobridge could be a bottleneck. Each meeting need to fit on a single bridge instance. However, using common servers connected at 1 Gbps or 10 Gbps, it shouldn't be any problem to have meetings with substantially more than 2-4 people. Say a HD stream from most webcameras outputs 3 Mbps at full blast, with 50% overhead due to the simulcasting. That's over 2000 participants on a single server connected at 10 Gbps, all receiving all video streams in full quality.
For meetings with 2 participants the streams run peer to peer, so here you get the best possible latency and quality.
We've set up Jitsi on a VPS instance at a nearby provider, and have not seen any problems with meetings of 10-15 people. Stability and performance also outperforms all the other solutions I've tried. There's currently a bug in Firefox's simulcast implementation, so if you have any participant using this browser, this feature gets disabled for everyone. Even with this issue, I haven't noticed anything but excellent performance with this few number of participants.
It seems to me this example has nothing to do with the parent's comment. He is talking about co-ops. Companies that are owned by workers. It implies the company cannot be sold without a majority of workers to agree.
But you're right the funding scheme would be more challenging. But if the service sold is of very good quality, it may work. And the "not for private investors" model may also be something good to promote for (some) consumers.
Juno was owned by the workers - They had equity in the company based on when they started.
> But the icing on the cake is Juno's equity offering: 1 billion of the company's founding shares reserved just for the drivers. [1]
It was all stripped away when the company was sold off to Gett because of liquidation preference because now.
> But drivers were soon informed by emails from Juno that the stock plan was void. They could instead receive cash payouts amounting to less than what they could make in a day of driving. [2]
We should be doing the opposite. Engineering and deploying ultra-light weight material that unfolds into massive solar sails that can be controlled carefully to cast a shadow and cool the earth slowly over the course of decades to counteract some of the effects of global warming.
