investment) • Fully distributed since inception (i.e. we were remote before it was cool) • Over a decade of remote • Turns out to be helpful for open source projects too
first exposure to digital signage • Small deployment (~10 screens) • Horrible existing software • Flash, Windows, RDP • 30 days from acquisition to go-live and no software
from standard input or a specified file which are to be executed at a later time." $ at 11:00 AM next fri warning: commands will be executed using /bin/sh at> /usr/local/bin/myscript.sh at> <EOT> job 1 at Fri Apr 3 11:00:00 2020 $ atq 1 Fri Apr 3 11:00:00 2020 a root
are unreliable • Required multiple levels of "fallback" • Sometimes required physical power cycle to recover (i.e. unplug/plug back in) • Avoid consuming USB modems directly at any cost. • Use a router. • Positive note: Required me to refresh my Hayes commands (and minicom)
got a ton of interest • Drove a lot of traffic • One of the most popular forum threads on the Raspberry Pi Forum • Screenly OSE is today the most popular digital signage project on Github • Within weeks we had our first commercial request
was great for one screen, but... • Users wanted to manage multiple screens from one interface • Did not want to rely on community support channels • Wanted a turn-key solution (e.g. automatic updates) • Were happy to pay for it • ...Allows us to spend money on OSE
management interface • Device management was very rough • Scaling was hard • The technical debt from the early days became increasingly challenging to deal with • Yet we managed to scale the system to support thousands of screens and build out a team
Screenly OSE or Screenly Pro v1 • Incorporate lessons learned from v1 • Don't re-invent the wheel - find partners • Transactional (and automatic) updates • Goals • Commercially managed operating system • "Unified" player with seamless playback • Transitions between assets • Locked down and secure • Full hardware acceleration • Full compositing / future proof
can be amazing • Documentation is very important • Try to lower the barrier for new developers • Have good test coverage and automated tests • KISS • Successful open source projects require financial resources (or lots of your time) • Take good care of your contributors
languages and frameworks • Content marketing is important • Partners and integrations are important to drive engagement/users • Don't assume new contributors are familiar with "modern" dev flows
Viktor Petersson
vpetersson
takanariko
rtechkouhou
takashi_toyosaki
miyamoto_hiroki
ozaki25
tzkoba
yamamuteki
kyonmm
kyokonishito
nk35jk
tacck
fruitriin
trishagee
rocio
paulrobertlloyd
brad_frost
jacobian
matthewcrist
davidbonilla
caitiem20
dougneiner
iamctodd
gr2m
lynnandtonic
