It's All about Perspective; 6 Things We Learned While Building Measure

A presentation at Open Source Summit Europe in October 2018 in Edinburgh, UK by Stuart Langridge

Slide 1

Slide 1

It's All about Perspective 6 Things We Learned While Building Measure

Slide 2

Slide 2

Slide 3

Slide 3

Jeremy ● ● ● ● Datadog Had the idea Interested in community Interested in measuring it ○ Not to compare or rate, but to improve

Slide 4

Slide 4

Stuart ● ● ● architect and coder interested in community interested in design

Slide 5

Slide 5

The Six Things

Slide 6

Slide 6

Slide 7

Slide 7

  1. Naming things is hard

Slide 8

Slide 8

Names, good and bad ● ● ● ● ● Word Pages Windows Facebook Telegram ● ● ● ● ● ● Excel Alexa Medium Gimp Chrome Firefox

Slide 9

Slide 9

Poll for the name “Measure” of people on this stage It’s a great name 50% As soon as someone suggests a better name we’re switching to that 50%

Slide 10

Slide 10

Slide 11

Slide 11

  1. Simple sounding things are sometimes complex (once you drill into them)

Slide 12

Slide 12

The quest for notifications ● ● ● ● An open source SaaS project has two sets of users: the people who use the project, and their users Use of external services is annoying to set up in this environment Everything is fractal: a simple-sounding thing has many ramifications It’s better to not do a thing and be honest about that than to do a half-assed job

Slide 13

Slide 13

Slide 14

Slide 14

  1. Work closely with your dependencies and they’ll be nice to you

Slide 15

Slide 15

(Some) Modern open source projects

Slide 16

Slide 16

(Some) Modern open source projects

Slide 17

Slide 17

(Some) Modern open source projects

Slide 18

Slide 18

We’re all in this together ● ● ● ● Measure uses GHCrawler from Microsoft Some issues with the way it worked Fix them and contribute back upstream When we had questions, they listened

Slide 19

Slide 19

Slide 20

Slide 20

  1. Your error paths are at least as important as the parts that work

Slide 21

Slide 21

The unideal world ● What should happen: ○ ○ ○ ● They download the project It works first time Hooray! Time for cakes! What doesn’t happen ○ That

Slide 22

Slide 22

Character is what you are in the dark ● ● ● ● ● ● Make your errors helpful to your user base, not your developer base Explain what happened Explain why it happened Give possible fixes If there’s only one possible fix, do it Have a switch somewhere to turn on the techie stuff but keep it off by default

Slide 23

Slide 23

Slide 24

Slide 24

  1. Publicising your thing is as much a skill as writing it

Slide 25

Slide 25

If you build a better mousetrap, the world will not beat a path to your door. Stop thinking it will.

Slide 26

Slide 26

Marketing ● ● ● ● ● ● Bit of a dirty word among OSS community people This is wrong It’s a skill Learn that skill Getting eyes on your project is just as important as building it right Publicising your project gets you feedback and grows your community of contributors

Slide 27

Slide 27

Slide 28

Slide 28

  1. Have a philosophy

Slide 29

Slide 29

What’s it all about, when you get down to it? Measure’s philosophy: ● ● ● ● ● Should be simple Should be visually appealing Should offer an opinionated default experience, but be extensible Should be able to completely separate inside and outside contributions Should treat the concept of contributors as first-class citizens

Slide 30

Slide 30

Why have a philosophy? ● ● ● Really helped us decide what’s important and what isn’t Can say “Measure doesn’t do that; another tool may be a better fit” Can close issues

Slide 31

Slide 31

The Six Things We Learned 1. 2. 3. 4. 5. 6. Naming things is hard Simple sounding things are hard once you drill into them Work closely with your dependencies and they’ll be nice to you Your error paths are at least as important as the parts that work Publicising your thing is as much a skill as writing it Have a philosophy

Slide 32

Slide 32

@linuxquestions @sil github.com/MeasureOSS/Measure