Slide 1

Slide 1 text

WHAT I LEARNED FROM WEBTORRENT: LESSONS LEARNED FROM STARTING AND RUNNING A P2P OPEN SOURCE PROJECT

Slide 2

Slide 2 text

WHAT WE DID RIGHT WHAT WE DID WRONG

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

LESSON 1 SHARE YOUR WORK EARLY AND OFTEN

Slide 10

Slide 10 text

> Late 2013: Announced WebTorrent > Early 2014: PeerCDN acquired, got job at Yahoo > Mid 2014: Released BitTorrent CLI > Late 2014: Works in the browser, end-to-end > Early 2015: Quit job > Mid 2015: WebTorrent is stable and useful

Slide 11

Slide 11 text

LESSON 2 FIND A JOB THAT ALLOWS SIDE PROJECTS

Slide 12

Slide 12 text

> 2016: Released WebTorrent Desktop > 2017: Brave Browser bundles WebTorrent > Late 2017: Burnout > Early 2018: WebTorrent Desktop hits 1 million downloads

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

WEBTORRENT IN 2019 > Website: 150,000 page views and 65,000 users per month > JS Library: Loaded 5 million times per month > Desktop App: 2 million installs, 100,000 monthly users

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

MIT/STANFORD PHILOSOPHY > Simplicity: the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation. > Correctness: the design must be correct in all observable aspects. Incorrectness is simply not allowed. > Consistency: the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness. > Completeness: the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

Slide 17

Slide 17 text

WORSE-IS-BETTER PHILOSOPHY > Simplicity: the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design. > Correctness: the design must be correct in all observable aspects. It is slightly better to be simple than correct. > Consistency: the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency. > Completeness: the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

Slide 18

Slide 18 text

WORSE-IS-BETTER PHILOSOPHY > Simplicity: the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design. > Correctness: the design must be correct in all observable aspects. It is slightly better to be simple than correct. > Consistency: the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency. > Completeness: the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

Slide 19

Slide 19 text

int fd = open("file.txt", O_WRONLY | O_APPEND); write(fd, "hello, world\n", 13);

Slide 20

Slide 20 text

char buf[] = "hello, world\n"; int buf_size = sizeof(buf); int fd = open("file.txt", O_WRONLY | O_APPEND); int bytes_written = 0; while (bytes_written < buf_size) { bytes_written += write(fd, buf + bytes_written, buf_size - bytes_written); }

Slide 21

Slide 21 text

WEBRTC IS WORSE-IS-BETTER > Has performance issues > Terrible API > Yet, it enabled P2P on today's web > proved that the dweb is a valid web use case > Makes it easier to argue for better P2P web APIs

Slide 22

Slide 22 text

LESSON 3 WORSE IS BETTER

Slide 23

Slide 23 text

"The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing."

Slide 24

Slide 24 text

$ webtorrent --help Usage: webtorrent [command] Example: webtorrent download "magnet:..." --vlc Commands: download Download a torrent seed Seed a file or folder create Create a .torrent file info Show info for a .torrent file or magnet uri Specify as one of: * magnet uri * http url to .torrent file * filesystem path to .torrent file * info hash (hex string) Options: --airplay Apple TV --chromecast Chromecast

Slide 25

Slide 25 text

LESSON 4 PROVIDE VALUE ALONG THE WAY

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

WHO IS YOUR IDEAL USER?

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

const client = new WebTorrent() client.add('magnet:...', torrent => { // Torrents can contain many files. Let's use the .mp4 file const file = torrent.files.find(file => file.name.endsWith('.mp4')) // Display the file by adding it to the DOM file.appendTo(document.body) })

Slide 30

Slide 30 text

npm install render-media

Slide 31

Slide 31 text

LESSON 5 SOLVE ONE USE CASE PERFECTLY

Slide 32

Slide 32 text

webtorrent_success = js_bet * electron_bet * webrtc_bet

Slide 33

Slide 33 text

js_bet = .95 electron_bet = .80 webrtc_bet = .50 webtorrent_success = nodejs_bet * electron_bet * webrtc_bet console.log(webtorrent_success) // 0.38

Slide 34

Slide 34 text

LESSON 6 TECHNICAL BETS ARE MULTIPLICATIVE

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

LESSON 7 HAVE A SIMPLE PITCH

Slide 37

Slide 37 text

HTML – THE ORIGINAL WEB API

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

LESSON 8 DESIGN FOR THE LEAST TECHNICAL USERS

Slide 40

Slide 40 text

Thanks for the feature request! WebTorrent Desktop values simplicity more than most torrent apps. This sometimes means saying 'No' to good ideas. We try to implement only the most important features that a torrent app needs and make those features as good as possible. We don't want the app to get overloaded with knobs and dials that may only benefit a small percentage of users. That's not to say we won't ever add large new features. We support powerful features like instant streaming, dynamic piece prioritization, web peers (WebRTC), etc. but only when they have a clear benefit to a vast majority of users. See the 80-20 rule. I don't think it makes sense to implement this feature right now. I hope this makes sense!

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

LESSON 9 IGNORE THE NERDS

Slide 46

Slide 46 text

// App version telemetry.version = config.APP_VERSION // Screen resolution telemetry.screens = getScreenInfo() // OS version and amount of RAM telemetry.system = getSystemInfo() // # of torrents currently active, # in list, total size telemetry.torrentStats = getTorrentStats(state)

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

LESSON 10 GROWTH MATTERS

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

LESSON 11 BE PROACTIVE, NOT REACTIVE

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

LESSON 12 BUILDING DECENTRALIZED SOFTWARE WITH CENTRAL COORDINATION IS OKAY

Slide 54

Slide 54 text

"MECHANICAL SYMPATHY"

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

LESSON 13 DWEB APPS ARE NOT ROBUST ( YET )

Slide 57

Slide 57 text

!

Slide 58

Slide 58 text

LESSON 14 THE OPPORTUNITY IS HUGE

Slide 59

Slide 59 text

HAPPY HACKING! @FEROSS • FEROSS.ORG