I was the co-founder and CEO of Screenhero, and after its acquisition
by Slack in 2015, I led the team that built Slack Calls (voice, video
and screen sharing in Slack), and left Slack in 2018.
Today, we (myself and another engineer) are launching Screen, which is in
many ways a successor to Screenhero. Our goal is to help you work with
others like you’re in the same room.
Like Screenhero, it supports low-latency screen sharing with
multi-mouse control. How low? It has the lowest screen sharing latency
of any product we’ve tested: 30-50ms best-case end-to-end latency
between screen capture and render, vs. 100ms-150ms in regular WebRTC.
This means it’s great for remote pair programming, which was
Screenhero’s biggest use case.
We have voice, video, multiplayer drawing and control, and ephemeral
messaging, and we integrate with GCal and Slack.
We have native apps for Mac, Windows, and Linux (Screenhero’s
top-requested feature was Linux support). We use custom native code to
make multiplayer control work, and a heavily-modified custom fork of
Electron to minimize latency. It's WebRTC-compliant, so you can share
meeting links that anyone can join with a WebRTC-compliant desktop or
mobile browser — no download required. Daily.co is our primary
WebRTC-infrastructure provider (they’ve been amazing to work with!).
We're hoping Screen will be useful for engineers (pair programming,
live debugging), designers (review with stakeholders - they can draw
on your screen to give feedback), students and teachers, and anyone
You can view a 1-minute demo video by clicking the
play button at https://screen.so, and there's a longer article
at https://screen.so/about, if anyone's interested.
I’ll be around to answer questions and welcome any feedback.
I hope you'll find Screen useful, especially during these times!
This resonates with me, and is definitely why I loved Screenhero so much, it felt VERY fast, and visually looked crisp. Even the initial connection speed was fast, while Slack takes about 3–8 seconds to connect. And also why I was so disappointed with Slack's product, now it's back to the same level as Google Hangouts.
It's surprising that having the same lead, and access to the same source code, that the product was unable to achieve the same level of quality & performance. What would you say the culprit is? And if I may lead the question... Bureaucracy inside Slack? Managing a new team? Having to rewrite on presumably a new language & software stack? Rushing to meet deadlines?
Anyways, awesome to see your back at it again, and that you have such care about latency, people do notice & care!
Screen’s goal is to support remote work of any kind — including engineering & pair programming, for sure, but extending to many other uses cases, such as creative review, education, and beyond. And yes, I agree competition is good! :)
Curious: I assume you can't just sell your company and rebuild it in most cases. Was there an embargo on the amount of time before you could build this?
I would absolutely pay for any open source competitor to this type of product, preferably one that integrated with Jitsi (which itself is open source). Fool me once.
But to echo other comments, you really need to change the name.
Question for clarity sake, have I read this properly that you all still are with Slack, does this mean Screen.so is "A Slack Company" or just leveraging that relationship for tightly coupled/efficient integration as a wholly separate company?
Love that it is still blazing fast. Love that awesome features like multi cursor are still very much a thing.
Congrats on the re-launch!
Are you able to share further technical details on what you've had to do to get the speed gains you're describing?
I’m open to finding a new name — in fact, a few days ago, I had reached out to Slack to see if they’d be open to letting us use the Screenhero name since they’re not using it. If that doesn’t work out, and and there’s still significant distaste for the name, we’ll change it. 99.9% of the time we’ve spent to get here has been on the product, getting it to work on all the platforms it supports, and making sure it’s performant and fast. The 0.01% of time we’ve spent on getting our name and domain is something I’m happy to revisit before our GA release.
Do you really think nobody is going to be confused when you tell them to use "Screen"?
"I'm staring at my screen right now, what do you mean?"
"It's the name of an app".
If people have to introduce your app as "use the app called Screen", then it's a bad name. Think Viber, Skype, Whatsapp, Colgate, Facebook.
What was that product name? Screenmaster screenlord turboscreen are all more likely to get potential customers to remember and find you.
It’s a terrible name as is.
All your other suggestions are even more horrific, you might as well call it TurboScreenMaster 3000.
'Screen' and 'Screen Inc' is fine as it is.
This project don't even have the GNU keyword to help.
I guess this is an aspect where search engines are much better today, to get the context. But still, the issue remains.
Regarding the name / domain name i wanted to let you know that www.BrowserMeeting.com is available.
I was holding on to this domain for a future screen sharing & web browser based virtual meeting project.
If you or any HN readers are looking for a category killer keyword rich premium .com that is PERFECT for a "Browser Meeting" project please send an email to:
sales AT browsermeeting.com
You cannot get a trademark on it, or at least shouldn’t be able to if the USPTO observed its rules.
You really need to change the name.
PS edit: this isn’t glib. I’m genuinely curious why, who and how this choice was made.
If you're intelligent enough to use screen, surely you're intelligent enough to understand the difference between a terminal app and an app that shares your screen.
Again, the number of people who this impacts is so small that it's hardly significant. Sure, here on HN I'm sure it seems that everyone is confused, but we're hardly a representative sample here.
> has trademark problems
Honestly I don't buy this. When you trademark something, you do so in a very specific manner, and I think Screen's market is specific enough as to defend a trademark in the screen sharing/collaboration segment _should they even choose to trademark the name_, which they can easily choose not to do.
Also, no one in our private beta ever raised this concern.
Screen just switched to public beta today, and the idea is for us to get feedback on issues we may not have seen before. This is a great example of such an issue! And as I’ve said elsewhere, if this continues to be an issue, we will change it. It’s not in our interest to have customer confusion either.
Just today I was recommending (GNU) screen to a coworker to address transient outages with a remote connection. It would get pretty annoying to constantly clarify which screen I mean, as they are both used in the same circumstances.
Don't get me wrong, I've got lots of colleagues who use various other editors, like vs code - but... This isn't just a case of pre-existing software with a similar name - combined with ssh, gnu screen is arguably superior for pair bugfixing in production, for example (multiple ppl can ssh into the same server).
I get that this is "like gnu screen, but for xorg/Wayland - and without any support for resuming remote sessions" - just sounds like an odd pitch - as you say you especially want to target Linux support...
You support Linux (well!), I’m surprised your beta testers didn’t say anything. That’s an interesting problem —I wonder what other blind spots like this can be avoided.
Admittedly, we only had a handful of Linux users in our private beta, but still, none of them mentioned the GNU tool.
The name you have chosen requires an explanation just to discuss this with my coworkers. Perhaps it is a generational thing, but in a quick survey asking around "Have you heard of the new tool screen?" the response was 100% "screen isn't new and yes I've heard of it... have you heard of tmux?"
For the majority of businesses looking at 'Screen' now, they won't bat an eyelid and will use it along as it 'just works' no matter the name conflict. If they saw GNU Screen they'll just say 'What's that' and forget about it.
Also, nobody in our private beta mentioned GNU Screen.
A public beta helps us get feedback on issues that we have missed before, and this is one of them!
> 1M Developers: GNU Screen exists you know.
> 90M+ Customers and Businesses: Take my money now! Let's use 'Screen' to screen share!, Yay!
I'm pretty sure that 'Screen' would appeal to businesses and customers who really just want to get on and instantly collaborate with who ever rather than to know that something called GNU Screen exists and would be less likely to be confused by the conflict anyway.
I think what you've got looks great. And it's a great opportunity to claim a name of it's own!
I mean either they think you are significantly less informed than them and you actually think GNU screen is new, or they are using the chance to make a quick joke of not particularly startling originality.
Because if they do think you know what GNU screen is then they must think this new tools you're referring to isn't it.
I just posted a top-level comment on the naming issue, where we were coming from, and that I’m open to changing the name.
Unless Screen hopes to build a business targeting clients that are unique.
I don't think we are unique but I like to think we are the kind of place where most people would prefer to work. Uncommon but hardly unique and definitely in the target market for this tool.
Now I've been doing it as well... What I really wanted to say is thank you for launching this product in a time where it's desperately needed by many people and making it free. You said elsewhere that you're bootstrapped and I really don't want to think of the server costs coming your way, so I seriously do commend you.
If you have suggestions of what we can say and do to make this better, please let me know. I will be looking into improving the language before we do our GA launch.
While I do take a lot of interest in law, I am by no means a lawyer. Personally, I would feel good about: "Neither Screen nor these third parties store or record media data as part of the Service, nor process it other than necessary to provide the Service to you."
I'm sure corporate will have opinions on this when I propose it, and I'll be sure to pass those on. As an additional point of feedback, it would be wonderful if you listed payment options somewhere. Although maybe it's an artefact of your early launch or by design that you don't.
EDIT: changed "our Service" to "the Service" above for consistency
>Neither Screen nor these third parties store or record media data as part of the Service, nor process it other than for the purpose of providing the Service to you.
Here's our experience in case it's helpful:
- There's no concept of user provisioning or inviting users, so when I first signed up and started a session in slack everyone was a little confused about if they needed to individually sign up or if they should be expecting an invite to their corp email.
- I'd also like some degree of user management at a corp level if for no other reaosn consolidated billing and basic auditing.
- One of our cofounders is on linux and tried to do a screenshare. He has 3 monitors hooked up and even though screen asked him which monitor to share, it still shared all 3 at once.
- On my side from a macbook as a viewer the app wedged all 3 of his monitors into view on my tiny 13" monitor and this completely destroyed the aspect ratio of each of his monitors (ha, it's really hard to write this without using the word screen), also the resolution was super low, likely because one of his monitors was showing a twitch video and the screen app was trying to keep up.
- I tried zooming in on the one monitor where he had code open and it was super pixelated.
- I tried drawing and there was a very noticeable delay for both of us even though we're both on high speed connections.
- I tried to take screenshots of all this but every screenshot I took just resulted in a grey image (not sure if screen intentionally blocks screenshots but they're pretty important for us).
...sadly there was no way for us to do anything like remote debugging under these conditions. Will keep an eye out for updates since this is something we really want!
Systems: Mac OS 10.15.2, Arch (Manjaro)
Looks like a bug in our Linux multi-monitor code. I'm going to look into this right now! It’s been a while since we touched that code, and it’s likely that bugs may have crept in since then.
Also, corp level user management is something we’ve got in the works, but we wanted to get the product out so that people could start using it, and then add admin tools on top of that. For instance, if you’re on G Suite, everyone should be able to OAuth in. But I hear you on the need for better tooling around users.
Were you able to try screen sharing from your Mac to his Linux computer?
Thanks for looking into this, the performance was amazing and I really want to use this!
That's how I see it, at least.
Having said that, I’ve heard this request a few times now, and we will likely get to this soon. But I am curious whether the workaround would work for you for the time being.
Suggesting the "whole purpose" of an app that does video, audio and screen sharing is to let someone else control your computer seems strange though - it's one of many features, not a purpose in and of itself.
Has there been no real research that your chosen name is already taken?
But yes, we didn’t hear from anyone in our private beta that there was any confusion regarding our name, and we ourselves completely missed the fact that GNU Screen exists with this name. I’m sorry for the confusion, and we will revisit our naming decision.
I think it's perfect for businesses, and large companies, but might not be something suited towards somebody like me.
TeamViewer is the current tool of choice as I do volunteer work remote-teaching art to students and I'd just be a little worried about migrating everything over while it's free, only to suddenly not be able to afford it.
This is of course no fault on your end, and I just think while this is aimed at a certain demographic, others might be more suited to working elsewhere as 'Free' and 'Free for a period of time until we decide to start charging' is a little intimidating.
Brilliant program, brilliant work, and I wish you the absolute best of luck <3
I suppose people that use it a lot will benefit and those who have big budgets won't think about the price.
I loved screenhero and bemoaned it's disappearance into the slack neververse. Glad to see you are able to bring something back that was good before an aquihire gone blank.
If there's ever a version where I could pay a hundred bucks to use the code on my own servers for as much as the servers can handle, I would jump on it.
No big deal when screen sharing with friends, creates an issue for some people who don't know about these things and they get stalked by someone who suddenly knows what city and internet provider you are using, for some people.
Could you post this as a feature request on https://support.screen.so, along with some context to your use? That way we can follow up with more questions, others can vote for it, and we can update you on our progress. Thanks!
Can you shed any light on what WebRTC server you use? ie. Jitsi, Janus, etc.
This is HN after all - be great to get a nutshell description of the tech stack and after all your experience at iTeleport, Screenhero, Slack, etc. the things you've learned from a technology and even bootstrapping/product market fit standpoint?
WebRTC server: Daily (primary), and Twilio (secondary)
There’s no shortcut to the performance side of things, so we had to do a lot of custom work on Mac, Windows and Linux to get screen sharing to be super fast. The high level bit there is the boring-but-correct advice: measure everything, start with the biggest bottleneck, optimize, repeat.
The desktop apps follow a Slack approach (with a slight twist). Like Slack, we use Electron, but in our case, we’ve heavily modified it to make screen sharing super fast. We then use the standard Electron model to have main & renderer processes. The renderer process fetches the UI from our website (hosted on Firebase).
Almost everything (other than our custom node module) is in a monorepo. Even our modifications to Electron are stored as patch files, which just makes it easy to keep things aligned between our app and our modifications to Electron.
Our website/webapp (they are one and the same) are built on Ionic/Angular (we started before Ionic supported React). We used Ionic because I didn’t want to have to create new different UIs for each platform — I think the user is served by having a low cost product where the effort is spent mainly on performance and quality, rather than a slightly different UI for each different platform (which has significant cost). We’ve tried to maximize code re-use wherever possible, which is how a 2 person engineering team was able to build this product (granted, it took almost an entire year, or more if you count the project we pivoted from).
Happy to dive into details if you’d like!
Were there any issues from slack corporate with you launching this? Seems like it competes pretty directly with the features they already bought from yall...
I can’t speak for the company, but I imagine they’d be happy that another collaboration tool has launched that integrates with their platform to give their customers even more choice in how they work.
I waited with bated breath for the features to show up in Slack, and when they did I was basically satisfied until they shut it down, where I was crushed again.
Here's hoping the lawyers don't beat you up!
Guess what color I'd paint a bike shed? Any color at all if it worked!
Your bike shedding comment made me laugh out loud :D
Suggestion: (rather than complaint about the name), it'd be nice to have a little faster/easier method of changing the audio/video devices. Like the device arrows in zoom. I happen to have multiple of both devices (on my desktop) and sometimes apps get confused on which to use - so a quick way to change it back is always preferred.
Suggestion #2: Everyone seems to be killing for their whiteboards back right now. So a mode to have more strictly a digital multiplayer whiteboard would be cool.
Bug (Windows 10 x64): When I left my first meeting, the app didn't release the camera (light stayed on) & microphone (windows said it was in use) until I exited the application (from the tray). Relaunched the app and created a new meeting and it didn't happen again, so I'm not sure why. Just fyi.
Digital multiplayer whiteboard: we sort of do. You can draw even outside of a screen share — just draw during a video call (or even voice (or even no media at all!)). But I’m curious if you meant something else? There are a number of websites that do digital whiteboards, and we didn’t want to reinvent the wheel.
Bug: this is an intermittent bug we’ve heard about from some users but have had a hard time reproducing. Thank you for letting me know — we’ll try to figure out a better way to log the error to help us reproduce and solve it.
1) GNU Screen exists and people use it everyday to do something similar.
2) Why do you mention that started Screenhero and that Slack acquired that company in the banner? That’s great for you, it just comes off a little haughty, because it’s pretty irrelevant to a new user reading about this product imo
The point of the intro is to convey that I’ve built a similar product before, and have experience in the videoconferencing space, and that this product builds upon the ideas of the previous products I‘ve worked on. Sorry if it came across as haughty, I didn’t mean it that way.
But if the guest needs to see something else on the host’s computer (if you’re working together on a webpage, or a desktop app), then whole-desktop screen sharing is the best approach.
Screen definitely isn’t the best tool for every job. But it’s great for when you want everyone on the same page, seeing the same thing, and able to talk about the content of your screen and even control it together.
Ctrl + Opt + Command, commonly known as "mash" are three keys commonly set by devs. In my case used for moving my displays around using SizeUp. Mash + left arrow (move window to left) etc.
Command + Options + some letter would be fine.
It's making the app unusable for pairing right when I want to be able to use it without issue, as you're not affecting just one keyboard shortcut BUT ALL shortcuts that use Mash as a base.
Better yet, option to set keyboard shortcuts, but Im sure that's low on your priorities right now. Or maybe just add.. turn on/off keyboard shortcuts, this would also solve it.
I'm surprised by how much attention the name is getting. I don't think I personally know anyone who would use GNU Screen over tmux. And disambiguation doesn't seem hard in this case anyway.
One thing that does mildly concern me is the prospect of Screen just turning out to be another Screenhero in terms of being acquired and then neglected or discontinued. But hopefully that won't happen based on the lessons learned in the founder's post.
Having experienced an acquisition, there’s not much value in going through the same experience again.
What’s personally interesting to me is: can we make something that helps all knowledge workers work together remotely in a way that they couldn’t before? We were onto something with Screenhero, and I’m excited at the chance of following that thread again, and seeing where it takes us!
Having said that, I know trust takes time to build, and I hope to prove this to you with actions rather than words.
Gave it a quick spin immediately and looking forward to using it more in future. Pricing looks about right for us too.
My feature request would be to make it easier to have it always on. For us friction to initiate is one of our biggest annoyances, if the whole team can have it on then knock (like sneek) to get the attention of the other(s) that would be great.
Can you go into some detail on the tech stack you used to make this?
The UI seems non-native, but there must be native layers for each platform in order to link into the accessibility features of each.
It’s built on a private fork of Electron, but the UI is all web-based. Electron handles most of our native needs, and where it doesn’t, we have a node module to connect into the OS. A lot of our secret sauce is on the native side, but honestly, there’s a lot of complexity across the product.
If you have any specific questions, ask away!
Over the past few days we've been transitioning our higher ed staff to working remotely and are able to use Microsoft Teams or Zoom already to see another staff member's screen and walk them through basic things, but if the user needs to install a program, which would normally require admin rights on the machine, it appears that neither of those two solutions allow for that type of assistance from our IT staff.
Does Screen provide a solution for that situation? If so, we can give it a shot with our IT staff ;-).
As a former and early Screenhero adopter, I'm not sure why they had sold to Slack and have now come back with the same, if not a worse reincarnation of Screenhero.
At least they have Linux support this time since Screenhero and Slack repeatedly refused to port Screenhero to Linux. But again, having no web support would reduce the friction for new users having to install something rather than downloading a specific electron app.
Also, there is no way to make a web app that does what Screen does. If there were, we’d have built a purely web-based app.
With Screen’s desktop app, you can share your screen TO someone on the web, but they need the app to share their screen, since multiplayer drawing and control can’t be done otherwise.
I'd love to try something better but running a closed-source app with complete access to my screen, mouse and keyboard connected to the Internet is really not an option. And it's really difficult for me to understand how so many people have no problem trusting it. What am I missing?
For the moment maybe the best we can do is trying to use apps with screen sharing support included, e.g. Visual Studio Code's sharing.
Your mention of VNC reminded me of some work I did in 2008 :) https://blog.printf.net/articles/2009/01/26/multi-pointer-re...
Question: I am looking to build a remote development environment and would love to license this to see if possible to develop on a cloud machine to avoid issues with rdp/nomachine etc. Any interest in that idea? Congrats again and looking forward to trying it out!
I feel it’s like 1 step forward and 2 steps back kind of thing.
Also, regarding acquisitions, I’ve been there, done that, and I wouldn’t be building this company just to do the same thing again (life’s too short for that).
I love Slack as a company and as a product (I spend many hours in it daily). However, in hindsight, it’s not possible to integrate one complex piece of software into another complex piece of software. We ended up with a union of two separate sets of constraints (from each product) which made it impossible to make it all work. We didn’t know this when we started. I really value my experience at Slack, and it was through that experience that I learnt this lesson, along with many others, that have helped us make Screen what it is today.
For Screenhero users, I feel that with Screen being publicly available today, the Screenhero -> Slack -> Screen transition has been one step forward, two steps back, and three steps forward again. I’m committed to continuing the forward steps from here on in.
Why not making a Slack-like chat system as well? It seems a natural expansion. (I am the CEO of SerpApi. Feel free to email me at julien at serpapi.com)
For the share owners and everyone involved in the acquisition it's loads of dollars in the bank. So who cares about the users?
A while back I also tried to build a replacement called Tandem (https://tandem.stream), so I really respect the effort it takes!
We built a crappy version of this for our team about a year ago. This is the first tool that solves all of our remote / distributed team pain-points in a really elegant way.
Summary: we were sustainable ($1MM ARR), but chose to join Slack since we felt we could get to our goal (have everyone use our product) faster. We didn’t foresee our product getting dropped.
This time around, the company is 100% bootstrapped, and I have no intention of taking any investment. We just want to be able to keep our burn rate low, build a product people love, and stay independent forever. I believe we can do that as long as we continue to make something people want.
USE Together CEO here - we’d be happy to help and get that fixed quickly, don’t hesitate to drop us an email at email@example.com :)
Could you please post this as a feature request on https://support.screen.so so we can follow up with you and update you on our progress?
"Lets debug this over screen" - obviously the pairing screen.
"If your ssh connection keeps dropping out you should use screen" obviously gnu screen.
It will also be very hard for you to trademark your name.
I do agree with those saying that in the wider audience, GNU screen does not mean anything, including (probably) the large armies of Windows developers. Besides that you should use tmux anyway ;).
Trademarks don't need to be officially filed to be real in common law -- you just have to use a distinguishing mark for a certain period of time. so the GNU/FSF screen would have rights to Screen in the computer program industry even if they haven't officially filed. Filing just helps you defend a trademark, it's not strictly necessary.
For it not to "continue to be" a source of confusion, then it has to "stop" being a source of confusion. What makes you think it'll stop?
GNU screen won't stop being on millions of machines, nor will it suddenly stop being a popular tool.
I suggest a cute acronym, instead. How about "SSH", for "Screen SHaring"?
This is basically slashdot with a different color scheme..