1
00:00:00,000 --> 00:00:04,750
Okay, let's unpack this. So if you're a developer, an engineer, or even just

2
00:00:04,750 --> 00:00:05,100
someone who has

3
00:00:05,100 --> 00:00:11,120
to share really detailed stuff for work, you know the feeling. That moment of dread.

4
00:00:11,120 --> 00:00:14,160
Oh, absolutely. The universal agony of remote work.

5
00:00:14,160 --> 00:00:17,610
You're deep into a debugging session, you're right there, the fix is in sight, and

6
00:00:17,610 --> 00:00:17,860
you

7
00:00:17,860 --> 00:00:22,780
hit share screen and, you know, whatever corporate chat app you have to use, and

8
00:00:22,780 --> 00:00:23,300
then it all

9
00:00:23,300 --> 00:00:24,300
just-

10
00:00:24,300 --> 00:00:25,300
Brines to a halt.

11
00:00:25,300 --> 00:00:26,300
Yeah.

12
00:00:26,300 --> 00:00:27,300
Time slows down.

13
00:00:27,300 --> 00:00:28,300
Yeah.

14
00:00:28,300 --> 00:00:32,150
The moment of the meeting, it just turns into this blocky, low-res smear that's

15
00:00:32,150 --> 00:00:32,820
like five

16
00:00:32,820 --> 00:00:36,200
seconds behind your cursor. It's a total productivity killer.

17
00:00:36,200 --> 00:00:40,020
It really is. And that's because these generalist tools, the ones built for, you

18
00:00:40,020 --> 00:00:40,540
know, video

19
00:00:40,540 --> 00:00:45,140
calls and emoji reactions, they often fail completely when they have to handle high

20
00:00:45,140 --> 00:00:45,660
density

21
00:00:45,660 --> 00:00:47,200
information like source code.

22
00:00:47,200 --> 00:00:48,760
They just can't handle it.

23
00:00:48,760 --> 00:00:53,070
No. They prioritize massive scale over performance in these niche cases. And that's

24
00:00:53,070 --> 00:00:53,400
exactly why

25
00:00:53,400 --> 00:00:58,040
we're doing a deep dive today into a specialized, almost surgical solution. It's

26
00:00:58,040 --> 00:00:58,560
called Scrigo

27
00:00:58,560 --> 00:01:02,530
Server. And it's an open-source project created for one reason, right? To get rid

28
00:01:02,530 --> 00:01:02,780
of that

29
00:01:02,780 --> 00:01:07,380
exact frustration, that low-quality, high-latency screen share.

30
00:01:07,380 --> 00:01:08,380
Precisely.

31
00:01:08,380 --> 00:01:12,000
So our mission today is to cut through some of the jargon you see with tools like

32
00:01:12,000 --> 00:01:12,380
this.

33
00:01:12,380 --> 00:01:17,830
We want you, the listener, to get a quick, solid understanding of what Scrigo is,

34
00:01:17,830 --> 00:01:17,940
why

35
00:01:17,940 --> 00:01:22,900
it works better than what you might be using now, and how the tech behind it

36
00:01:22,900 --> 00:01:24,020
actually helps

37
00:01:24,020 --> 00:01:25,340
it do its job.

38
00:01:25,340 --> 00:01:28,180
All without needing a PhD in computer science to follow along.

39
00:01:28,180 --> 00:01:32,330
Exactly. We're keeping it accessible, keeping it practical. We're looking at how a

40
00:01:32,330 --> 00:01:32,580
really

41
00:01:32,580 --> 00:01:37,130
focused open-source tool can, frankly, run circles around bloated corporate

42
00:01:37,130 --> 00:01:37,740
software

43
00:01:37,740 --> 00:01:39,080
for these critical tasks.

44
00:01:39,080 --> 00:01:40,080
A great case study.

45
00:01:40,080 --> 00:01:42,890
Now, before we get into the nuts and bolts, we really have to thank the supporter

46
00:01:42,890 --> 00:01:43,260
of this

47
00:01:43,260 --> 00:01:47,590
deep dive. This is all brought to you by Safe Server. They handle software hosting,

48
00:01:47,590 --> 00:01:48,100
and that

49
00:01:48,100 --> 00:01:52,270
includes complex open-source infrastructure just like this, and they support your

50
00:01:52,270 --> 00:01:52,780
digital

51
00:01:52,780 --> 00:01:56,580
transformation. So if you're looking for reliable hosting that really keeps up with

52
00:01:56,580 --> 00:02:02,260
innovation, you can find more information at www.safeserver.de.

53
00:02:02,260 --> 00:02:04,060
Thank you, Safe Server.

54
00:02:04,060 --> 00:02:09,590
Okay, so let's get back to that core frustration. The source material, the creator's

55
00:02:09,590 --> 00:02:11,060
own words,

56
00:02:11,060 --> 00:02:13,500
they were very clear about what struck this.

57
00:02:13,500 --> 00:02:18,540
Right. It was the failure of standard corporate tools. They even named names, like

58
00:02:18,540 --> 00:02:19,180
Microsoft

59
00:02:19,180 --> 00:02:22,420
Teams, where a stream would lag by several seconds.

60
00:02:22,420 --> 00:02:25,910
Or the quality was just so poor you couldn't actually read the text. You couldn't

61
00:02:25,910 --> 00:02:26,220
read

62
00:02:26,220 --> 00:02:30,020
the code, which defeats the entire purpose of the call.

63
00:02:30,020 --> 00:02:33,360
That distinction is so important. This wasn't built because the chat function was

64
00:02:33,360 --> 00:02:33,660
bad or

65
00:02:33,660 --> 00:02:37,380
something. It was built because the most fundamental collaboration feature sharing

66
00:02:37,380 --> 00:02:38,100
information

67
00:02:38,100 --> 00:02:39,300
clearly was broken.

68
00:02:39,300 --> 00:02:44,740
It was broken for that use case. So Scrigo's goal is surgical. It's hyper-focused.

69
00:02:44,740 --> 00:02:44,740
Share

70
00:02:44,740 --> 00:02:49,300
the screen, make it high quality, and make the latency reliably low. That's it.

71
00:02:49,300 --> 00:02:53,500
And the sources really stress that. This is an addition to your existing toolkit.

72
00:02:53,500 --> 00:02:53,740
It only

73
00:02:53,740 --> 00:02:57,700
handles screen sharing. It doesn't try to be your calendar or your chat client.

74
00:02:57,700 --> 00:02:59,740
It does one thing, and it does it well.

75
00:02:59,740 --> 00:03:03,810
And that focus is exactly where the performance comes from. I mean, think about it

76
00:03:03,810 --> 00:03:04,000
from a

77
00:03:04,000 --> 00:03:10,740
developer's point of view. You're pairing. You're debugging some tricky memory leak.

78
00:03:10,740 --> 00:03:16,460
You're in a state of flow. Even a quarter second of lag can just shatter that. You

79
00:03:16,460 --> 00:03:17,000
click,

80
00:03:17,000 --> 00:03:20,500
you wait, you click again, and suddenly you don't even know where you are anymore.

81
00:03:20,500 --> 00:03:24,560
I think we should also stress why this is so different from, say, streaming a movie

82
00:03:24,560 --> 00:03:25,560
on Netflix.

83
00:03:25,560 --> 00:03:26,560
Oh, that's a great point.

84
00:03:26,560 --> 00:03:30,860
With a movie, a little bit of buffering is okay, and some compression, some blurriness

85
00:03:30,860 --> 00:03:34,960
in the motion, your eye kind of forgives it. But code is different. It's high

86
00:03:34,960 --> 00:03:35,480
contrast

87
00:03:35,480 --> 00:03:37,820
text. Every single pixel matters.

88
00:03:37,820 --> 00:03:39,640
Every character has to be perfectly clear.

89
00:03:39,640 --> 00:03:44,300
What's fascinating here is that it needs both things at once. It needs low latency

90
00:03:44,300 --> 00:03:44,720
and high

91
00:03:44,720 --> 00:03:47,480
resolution. A lot of those other tools, they'll just pick one.

92
00:03:47,480 --> 00:03:52,680
Right. They sacrifice resolution to save bandwidth, and suddenly your text is illegible.

93
00:03:52,680 --> 00:03:52,940
Or they

94
00:03:52,940 --> 00:03:57,840
go for quality, but introduce so much lag that you can't interact at all.

95
00:03:57,840 --> 00:04:02,680
And Scrigo's promise is, you can have both. It uses tech designed to get around all

96
00:04:02,680 --> 00:04:02,880
those

97
00:04:02,880 --> 00:04:04,080
old bottlenecks.

98
00:04:04,080 --> 00:04:08,940
So if the corporate tools are the problem, the solution has to be a more direct

99
00:04:08,940 --> 00:04:09,520
path,

100
00:04:09,520 --> 00:04:11,080
and more control for the user.

101
00:04:11,080 --> 00:04:13,960
Okay, so let's get into the features that deliver that.

102
00:04:13,960 --> 00:04:18,320
On the surface, it seems really simple. We see things like multi-user screen share,

103
00:04:18,320 --> 00:04:18,320
which

104
00:04:18,320 --> 00:04:19,840
you obviously need for a team.

105
00:04:19,840 --> 00:04:20,900
That's not negotiable, eh?

106
00:04:20,900 --> 00:04:27,000
And a super simple install. It mentions using Docker or just a single binary file.

107
00:04:27,000 --> 00:04:33,320
And that simple install is a huge deal for developers. Docker, single binaries.

108
00:04:33,320 --> 00:04:33,320
That's

109
00:04:33,320 --> 00:04:36,590
the gold standard for getting something up and running fast. It means you don't

110
00:04:36,590 --> 00:04:36,720
have

111
00:04:36,720 --> 00:04:40,480
to fight with a million dependencies. You just run it, and it works.

112
00:04:40,480 --> 00:04:43,540
But the real magic, especially for performance, is what's happening underneath,

113
00:04:43,540 --> 00:04:44,000
right? In

114
00:04:44,000 --> 00:04:45,000
the tech stack.

115
00:04:45,000 --> 00:04:46,000
Exactly.

116
00:04:46,000 --> 00:04:50,350
Okay, so once you get past the easy install, you see some terms that can feel a bit

117
00:04:50,350 --> 00:04:50,840
intimidating

118
00:04:50,840 --> 00:04:55,600
for a beginner. Things like WebRTC, turn server, NAT traversal.

119
00:04:55,600 --> 00:04:58,760
Yeah, that's where people's eyes can glaze over. Let's break it down.

120
00:04:58,760 --> 00:05:04,320
Let's start with WebRTC. The documentation calls it the basis for secure transfer.

121
00:05:04,320 --> 00:05:04,320
What

122
00:05:04,320 --> 00:05:05,320
does that actually mean?

123
00:05:05,320 --> 00:05:10,090
Okay, let's simplify. WebRTC, it stands for Web Real-Time Communication, is

124
00:05:10,090 --> 00:05:10,520
basically

125
00:05:10,520 --> 00:05:15,520
a set of rules that lets two web browsers talk directly to each other, securely.

126
00:05:15,520 --> 00:05:16,520
Directly.

127
00:05:16,520 --> 00:05:20,630
Directly. Think of your normal corporate tool, like try and make a call through a

128
00:05:20,630 --> 00:05:21,680
giant overloaded

129
00:05:21,680 --> 00:05:27,020
switchboard operator. Every piece of data, your video, your audio, your screen, it

130
00:05:27,020 --> 00:05:27,240
goes

131
00:05:27,240 --> 00:05:31,320
from your computer up to the company's central server, and then all the way back

132
00:05:31,320 --> 00:05:31,720
down to

133
00:05:31,720 --> 00:05:32,800
your colleague.

134
00:05:32,800 --> 00:05:36,400
That sounds incredibly inefficient. A huge detour.

135
00:05:36,400 --> 00:05:41,560
It is. WebRTC tries to cut out that middleman. It attempts to create a direct peer-to-peer

136
00:05:41,560 --> 00:05:45,520
connection right between your browser and your colleague's browser.

137
00:05:45,520 --> 00:05:49,500
So it's like switching from sending a memo up three levels of management to just

138
00:05:49,500 --> 00:05:50,000
talking

139
00:05:50,000 --> 00:05:51,480
to the person at the next desk.

140
00:05:51,480 --> 00:05:55,040
That's the perfect analogy. And that direct connection is just inherently faster.

141
00:05:55,040 --> 00:05:55,200
It cuts

142
00:05:55,200 --> 00:05:56,320
latency down immediately.

143
00:05:56,320 --> 00:05:59,760
Okay. That makes a lot of sense for speed. But hang on. If it's going direct, what

144
00:05:59,760 --> 00:06:00,040
about

145
00:06:00,040 --> 00:06:05,400
security? That's listed as a key topic. If I'm sharing sensitive code from my

146
00:06:05,400 --> 00:06:06,000
machine

147
00:06:06,000 --> 00:06:09,840
to my colleagues, how do I know no one is listening in?

148
00:06:09,840 --> 00:06:14,210
That's a crucial question. And Scrego addresses it. Because WebRTC connections are

149
00:06:14,210 --> 00:06:14,480
always

150
00:06:14,480 --> 00:06:19,000
encrypted end-to-end. They use secure protocols. So even though the path is direct,

151
00:06:19,000 --> 00:06:19,480
the data

152
00:06:19,480 --> 00:06:22,360
stream itself is completely scrambled and protected.

153
00:06:22,360 --> 00:06:26,360
Okay, so the encryption handles the security part. What about bandwidth? If I'm on

154
00:06:26,360 --> 00:06:26,840
my,

155
00:06:26,840 --> 00:06:30,940
you know, sometimes flaky home internet, isn't a direct connection going to crush

156
00:06:30,940 --> 00:06:32,320
my network?

157
00:06:32,320 --> 00:06:36,860
Another great point. WebRTC is designed to be highly adaptive. It's constantly

158
00:06:36,860 --> 00:06:37,280
checking

159
00:06:37,280 --> 00:06:41,620
the available bandwidth and adjusting the stream on the fly. It might lower the

160
00:06:41,620 --> 00:06:42,200
resolution

161
00:06:42,200 --> 00:06:47,010
or the frame rate for a split second to maintain that low latency. It prioritizes

162
00:06:47,010 --> 00:06:48,240
responsiveness,

163
00:06:48,240 --> 00:06:52,000
which is the exact opposite of those heavy static corporate solutions.

164
00:06:52,000 --> 00:06:55,240
So it's smart about it. And this all ties into those other keywords we saw, right?

165
00:06:55,240 --> 00:06:55,960
Privacy

166
00:06:55,960 --> 00:06:57,360
and self-hosted.

167
00:06:57,360 --> 00:07:00,980
It absolutely does. Because you install Screeco yourself, using that Docker

168
00:07:00,980 --> 00:07:02,000
container or single

169
00:07:02,000 --> 00:07:06,040
file, you are running and controlling the server. You are the host.

170
00:07:06,040 --> 00:07:09,640
So the data isn't flowing through some third party cloud service.

171
00:07:09,640 --> 00:07:13,960
Exactly. You retain control. You're not subject to whatever monitoring policies

172
00:07:13,960 --> 00:07:14,760
your corporate

173
00:07:14,760 --> 00:07:19,920
IT department has on their own tools. For any developer handling sensitive IP, that

174
00:07:19,920 --> 00:07:22,640
control is a massive, massive appeal.

175
00:07:22,640 --> 00:07:26,920
It's selling independence just as much as speed. OK, let's tackle the one that

176
00:07:26,920 --> 00:07:27,160
always

177
00:07:27,160 --> 00:07:33,470
sounds the most complex. The integrated turn server and NAT traversal. If WebRTC is

178
00:07:33,470 --> 00:07:33,880
trying

179
00:07:33,880 --> 00:07:38,950
to go direct, point to point, what happens when the network basically says, nope,

180
00:07:38,950 --> 00:07:39,240
not

181
00:07:39,240 --> 00:07:40,240
allowed?

182
00:07:40,240 --> 00:07:43,980
And that's the reality of most networks today, especially behind a corporate

183
00:07:43,980 --> 00:07:44,680
firewall or

184
00:07:44,680 --> 00:07:49,320
even just a complex home router. These networks use something called NAT network

185
00:07:49,320 --> 00:07:51,360
address translation.

186
00:07:51,360 --> 00:07:54,910
And these systems are often like big brick walls. They're designed to block the

187
00:07:54,910 --> 00:07:55,160
exact

188
00:07:55,160 --> 00:07:59,040
kind of spontaneous direct connections that WebRTC wants to make.

189
00:07:59,040 --> 00:08:01,400
So the fastest route, the direct one, gets blocked.

190
00:08:01,400 --> 00:08:05,480
A lot of the time, yeah. And that's where the turn server comes in. Sensor traversal.

191
00:08:05,480 --> 00:08:07,240
Using relays around NAT.

192
00:08:07,240 --> 00:08:12,320
Exactly. Think of it as a helpful, reliable third party. If you and your colleague

193
00:08:12,320 --> 00:08:12,440
can't

194
00:08:12,440 --> 00:08:17,080
make that direct WebRTC connection, because a firewall is in the way, the turn

195
00:08:17,080 --> 00:08:17,320
server

196
00:08:17,320 --> 00:08:21,660
acts as an intelligent relay. Your data goes through the turn server instead, which

197
00:08:21,660 --> 00:08:21,800
is

198
00:08:21,800 --> 00:08:24,640
positioned out in the open where both of you can reach it.

199
00:08:24,640 --> 00:08:28,810
So the turn server is like a guide that says, okay, the direct bridge is out, but I

200
00:08:28,810 --> 00:08:29,060
know

201
00:08:29,060 --> 00:08:32,560
a tunnel we can use instead. It's the fallback plan.

202
00:08:32,560 --> 00:08:36,590
It's the failsafe that makes the connection reliable. And the fact that Scrigo has

203
00:08:36,590 --> 00:08:36,720
an

204
00:08:36,720 --> 00:08:40,720
integrated turn server is key. It means that the developer doesn't have to go set

205
00:08:40,720 --> 00:08:41,000
up some

206
00:08:41,000 --> 00:08:45,400
other complicated service or file a ticket with IT just to get it working.

207
00:08:45,400 --> 00:08:49,000
It just works out of the box. It just works. That reliability is what lets

208
00:08:49,000 --> 00:08:53,590
you build this into your actual workflow without worrying if it's going to connect

209
00:08:53,590 --> 00:08:54,360
this time.

210
00:08:54,360 --> 00:08:58,670
That makes so much sense. All those pieces, WebRTC, self-hosting, the turn server,

211
00:08:58,670 --> 00:08:58,820
they

212
00:08:58,820 --> 00:09:02,350
all fit together to solve that one problem. Okay, now here's where it gets really

213
00:09:02,350 --> 00:09:02,840
interesting

214
00:09:02,840 --> 00:09:08,820
for me. The open source side of things. Scrigo isn't some proprietary black box. It's

215
00:09:08,820 --> 00:09:09,280
licensed

216
00:09:09,280 --> 00:09:15,160
under GPL 3.0. That open source nature is absolutely vital

217
00:09:15,160 --> 00:09:19,690
to its trustworthiness, especially for a tool that's handling potentially sensitive

218
00:09:19,690 --> 00:09:20,100
code.

219
00:09:20,100 --> 00:09:26,480
Why is that? Because a GPL 3.0 license means transparency.

220
00:09:26,480 --> 00:09:30,270
The code is public. Any developer in the world can go and audit it for security

221
00:09:30,270 --> 00:09:30,840
holes or

222
00:09:30,840 --> 00:09:35,420
back doors. You get a level of trust there that you simply cannot get with a closed

223
00:09:35,420 --> 00:09:35,920
source

224
00:09:35,920 --> 00:09:39,120
enterprise product. And we can actually see that trust reflected

225
00:09:39,120 --> 00:09:42,780
in the community metrics, right? If you look at the GitHub repository, this is not

226
00:09:42,780 --> 00:09:42,880
some

227
00:09:42,880 --> 00:09:45,600
hobby project that got thrown out there and forgotten.

228
00:09:45,600 --> 00:09:49,680
Far from it. The stats really validate its maturity. I mean, it has 10,000 stars.

229
00:09:49,680 --> 00:09:53,040
10,000. That's a huge number in the developer world.

230
00:09:53,040 --> 00:09:57,470
It's a massive endorsement. It signals that this thing is genuinely useful to a lot

231
00:09:57,470 --> 00:09:57,600
of

232
00:09:57,600 --> 00:10:02,080
people. And it has nearly 700 forks, which shows that other developers are actively

233
00:10:02,080 --> 00:10:02,400
using

234
00:10:02,400 --> 00:10:05,680
and adapting it. I also noticed it uses semver for versioning,

235
00:10:05,680 --> 00:10:08,680
which is a small detail, but it shows a level of professionalism.

236
00:10:08,680 --> 00:10:14,470
The latest info we have points to version v1.1.0 from May of 2025. You see these

237
00:10:14,470 --> 00:10:14,720
stable

238
00:10:14,720 --> 00:10:18,960
numbered releases and it tells you this is a dependable, maintained tool.

239
00:10:18,960 --> 00:10:23,160
Absolutely. And if we peek under the hood at the languages, it's built primarily

240
00:10:23,160 --> 00:10:23,360
with

241
00:10:23,360 --> 00:10:26,080
Go and TypeScript. A very modern stack.

242
00:10:26,080 --> 00:10:31,720
Very. Go is at about 52.7%. And it's perfect for this kind of thing. It's fantastic

243
00:10:31,720 --> 00:10:31,800
at

244
00:10:31,800 --> 00:10:35,620
handling networking and lots of simultaneous connections without eating up all your

245
00:10:35,620 --> 00:10:36,200
server's

246
00:10:36,200 --> 00:10:37,200
resources.

247
00:10:37,200 --> 00:10:43,480
And TypeScript on the front end at 46.5% gives you that robust, reliable web client.

248
00:10:43,480 --> 00:10:47,680
Precisely. It's a solid, modern foundation. Now, one interesting thing is the

249
00:10:47,680 --> 00:10:48,160
contributor

250
00:10:48,160 --> 00:10:49,160
count is 18.

251
00:10:49,160 --> 00:10:50,480
Which is a good number, but...

252
00:10:50,480 --> 00:10:54,340
But when you put it next to 10,000 stars, it tells you something. This is likely

253
00:10:54,340 --> 00:10:54,820
maintained

254
00:10:54,820 --> 00:10:59,660
by a very small, very dedicated, and probably very high caliber core team. The

255
00:10:59,660 --> 00:11:00,080
architecture

256
00:11:00,080 --> 00:11:04,920
is likely clean, but it's a specialized tool driven by a handful of experts.

257
00:11:04,920 --> 00:11:08,410
That's a great insight. Okay, so to recap the key takeaways for you, the listener.

258
00:11:08,410 --> 00:11:08,720
Scrigos

259
00:11:08,720 --> 00:11:13,370
is targeted, a high-performance tool born from a very real, very acute frustration

260
00:11:13,370 --> 00:11:14,280
with corporate

261
00:11:14,280 --> 00:11:15,520
screen sharing.

262
00:11:15,520 --> 00:11:19,260
It's built on modern, secure tech like WebRTC. It gives you that crucial advantage

263
00:11:19,260 --> 00:11:20,000
of self-hosting

264
00:11:20,000 --> 00:11:21,660
for privacy and control.

265
00:11:21,660 --> 00:11:27,460
And its value is proven by the community. Those 10,000 stars really do speak

266
00:11:27,460 --> 00:11:28,320
volumes.

267
00:11:28,320 --> 00:11:30,720
Which I think raises an important question for anyone listening who's a

268
00:11:30,720 --> 00:11:31,240
professional

269
00:11:31,240 --> 00:11:37,680
developer or an engineer. How much is your collaboration time actually worth?

270
00:11:37,680 --> 00:11:41,700
Scrigo offers much better quality and control than the generic software you're

271
00:11:41,700 --> 00:11:42,200
probably

272
00:11:42,200 --> 00:11:43,200
using.

273
00:11:43,200 --> 00:11:47,650
For anyone whose job relies on sharing high fidelity detail like source code, the

274
00:11:47,650 --> 00:11:47,840
time

275
00:11:47,840 --> 00:11:52,970
saved by avoiding just one of those frustrating, laggy debug sessions probably pays

276
00:11:52,970 --> 00:11:53,480
for the

277
00:11:53,480 --> 00:11:55,360
entire effort of setting it up.

278
00:11:55,360 --> 00:11:58,360
So what does this all mean? I guess the next time you're stuck in a meeting and the

279
00:11:58,360 --> 00:11:58,600
shared

280
00:11:58,600 --> 00:12:03,000
code is a blurry mess and scrolling feels like you're watching a slideshow from

281
00:12:03,000 --> 00:12:03,880
2002?

282
00:12:03,880 --> 00:12:07,280
Just remember that specialized tools like this exist.

283
00:12:07,280 --> 00:12:10,240
Tools built to solve that specific pain point.

284
00:12:10,240 --> 00:12:14,630
Exactly. And the success of a tool like Scrigo, driven by fellow developers just

285
00:12:14,630 --> 00:12:15,160
trying to

286
00:12:15,160 --> 00:12:19,160
fix their own frustrations, should make you think about something deeper.

287
00:12:19,160 --> 00:12:23,350
If a core productivity task like screen sharing has to be fixed by the open source

288
00:12:23,350 --> 00:12:24,200
community,

289
00:12:24,200 --> 00:12:28,480
does that signal a fundamental failure of those massive proprietary enterprise

290
00:12:28,480 --> 00:12:28,860
tools

291
00:12:28,860 --> 00:12:31,600
to actually serve their most demanding users?

292
00:12:31,600 --> 00:12:33,720
A provocative thought to end on.

293
00:12:33,720 --> 00:12:37,090
And as you explore these kinds of innovative solutions, remember that this deep

294
00:12:37,090 --> 00:12:37,480
dive was

295
00:12:37,480 --> 00:12:39,040
supported by SafeServer.

296
00:12:39,040 --> 00:12:42,880
If you need support with software hosting or accelerating your own digital

297
00:12:42,880 --> 00:12:43,960
transformation,

298
00:12:43,960 --> 00:12:48,120
SafeServer is there to help make sure your infrastructure can meet your needs.

299
00:12:48,120 --> 00:12:51,960
You can find out more at www.safeserver.de.

300
00:12:51,960 --> 00:12:54,140
Thank you so much for joining us for this deep dive.

301
00:12:54,140 --> 00:12:55,640
We'll catch you on the next one.