Multi – Multiplayer Collaboration for macOS
multi.app
multi.app
Free plan : Because everybody does that and we don't give a crap if we are loosing money
Personal plan : More than 6x the monthly price of the personal plan of GitHub because our solution clearly worth that, trust us (also we need paying customers to sustain the free plan, that thing cost us like A LOt)
Enterprise plan : Yeah you know what that personal plan we totally get that it's too much so call us and we can arrange something. It's business after all it's not like you are a struggling indie dev or a startup hahaha.
When did it all go wrong?
Similar to local coffee shops charging more because they can’t afford bulk orders for 20mil cups.
Link expires in 6 days. Most of the discussion is in the comments.
For anyone who doesn't want to load a ton of JS, in short:
# Free
Mostly pairing features. Free because we think that collaborative pairing functionality should be available to everyone, whether or not you can pay. If you're an individual contributor, you should just be able to sign up. Our closest competitor charges $30 a month for just pairing functionality, and as a result many small teams can't afford to use it.
# Standard
Mostly features to help with async communication and documentation. We think that distributed work in it's ideal is "Pair often, write a lot, and minimize meetings."
We think it makes sense to draw the paywall here because a/ The async features cost us more to run, and b/ This problem is something that team leaders or managers care about. And those are the people with credit cards.
We support teams having a mix of Free and Standard seats. Just pay for the power users.
# Enterprise
There are some features that cannot be per-seat: They have to be the whole team or nothing. For example, SSO (yes #ssoTax), API access, bespoke security review etc. For these, we can talk to the team about what their usage will look like in deciding the price.
Hope that helps. We're very open to feedback on this. DM's open at @embirico on Twitter if you have thoughts privately.
I've been using Drovio (formerly UseTogether) for a few years, mostly on inertia, as they were the "best" I found when looking originally. It suits my needs, but feels a little kludgy at times.
One of the killer features, imo, is that Drovio can be run from the browser, at least for the clients. This lets you get a teammate pairing with you super fast, without having to make them download/install something.
As far as I can tell, so far, Multi doesn't have that ability
I used (and loved) screenhero back in the day too
Another tool that supports streaming to a browser is [Coduo](https://apps.apple.com/us/app/coduo-pair-coding-for-xcode/id...)... although I just noticed the single 1-star review :/
Multi is typically used for long-term teammates. That's when, the extra features we get from being native, as well as the command palette to reach someone, are more useful.
Wasn’t Zoom a privacy sheetshow?
I'll be responding to the comments. LMK if you have any questions.
I did a bunch of interviews with engineering teams for a similar product idea that said as much. We built an alpha of one even with both a windows and Mac client to meet that need but our big finding from early feedback was that dev teams really didn’t seem to want to do synchronous real time multiplayer collaboration very frequently. They liked the idea of async (which we leaned into) but time and time again realtime multiplayer was called out as a nice idea but not something they do in practice much. It’s like pair programming in general, good idea, infrequently done except for unique teams from what we’ve seen.
Yes indeed, I'm looking more into a solution for training and tutoring (students, interns, ...), currently doing it with Team Viewer which is good but not perfect, doesn't provide highlighting, doesn't show keyboard shortcuts, ...
For a more better experience on both macOS and Windows, check out CoScreen as mentioned, and Tuple too!
> Guide, annotate, or take control, in any app.
For some options that work with PC, check out my other comment mentioning "Windows"
It accounted for well over half of our company’s support tickets. The biggest problem is nobody on the customer end wants to champion getting it setup. When things go wrong, they just throw their hands up.
The core of SCIM/SAML is relatively simple, but there are tons of different ways companies can configure things.
* Younger companies tend to use a "modern" identity provider, Okta, Google Workplace, etc. However, the owner of SSO system doesn't tend to be an SSO expert. These setups normally work "out of the box", but require a bit more generic guidance since the person setting it up only deals with SSO occasionally.
* Older companies have the internal expertise, but often use legacy configurations. Many time, this is just a matter of figuring out what the two different system call various fields. However, the range of errors can be huge, so you have to explore a bunch of stuff.