Hey
@naruto11eth — while I strongly agree with the push for dogfooding, and strongly agree with replacing centralized apps/systems as quickly as possible, these are complex decisions with lots of variables.
I’ll say more here because it’s a good learning moment for a lot of people building decentralized web3 products. We’re finally getting to see good products emerge and many builders out there are dogfooding and face these decisions all the time.
For context, we definitely wanted to use Huddle initially, but had to play it safe this time. Reasoning below. With more time we would’ve done it, and we planned to shift over to Huddle next FIL Bangalore.
First though, Huddle is well on its way to matching and exceeding zoom UX on a lot of parts — it’s actually astonishing that a team so small has pulled off such a remarkable feat so quickly 🎉 — for ex, recently I’ve had to switch many calls away from Zoom and to Huddle because the p2p AV quality & delay is so much better in many countries’ networks than over zoom’s relays. I already default to Huddle over Zoom for many uses, though not yet all. Huddle is already used for lots of event streaming, and in my experience has worked very well. I’m frankly very impressed with the product success all things considered — true david v goliath story.
So, reasoning for this event:
- Dogfooding is hugely valuable in itself - and we should all try to do it
- Valuable for Huddle to claim the victory of using the product for this
- but: products take an enormous amount of work to perfect in all edge cases - we’re talking thousands of little features interacting in complex ways.
- Zoom has had the benefit of 10 more years, thousands of people (vs ~20) perfecting the product over those years, and many orders of magnitude more product stress testing over Huddle (trillions of meeting minutes, millions of events, etc.)
- Lots of people are way more familiar with zoom today, so AV team and others much more used to zoom today.
- Live event streaming — while already happens on huddle already — hasn’t been as high priority as other use cases, so there’s unknown product surface area where issues may appear. With millions more minutes and thousands of events, those issues will be ironed out.
- Live events have very little margin for error - even slight hiccups can cause a lot of problems and make the experience bad for attendees, speakers, event staff, etc.
- sometimes a problem unrelated to the software (eg in physical AV setup, user familiarity with the product, network issue) could be mistaken as a problem in the software.
- Last minute additions (like this one) have little or no chance for testing & training staff, so you have to reduce likelihoods of something going wrong (including user familiarity) - this was the big one here: had we had any time to test, we could’ve tried it.
- All of these issues would reflect poorly on Huddle regardless of whether it was a software issue on their end at all or something else.
So, while I very much agree with dogfooding, and replacing centralized things asap, we also have to do it responsibly.
I very much want to see any calls on next FIL Bangalore (and many other events) over Huddle, and am sure the team will deliver 🎥💙🎉