A presentation at Open Source Summit Europe in in Edinburgh, UK by Stuart Langridge
It's All about Perspective 6 Things We Learned While Building Measure
Jeremy ● ● ● ● Datadog Had the idea Interested in community Interested in measuring it ○ Not to compare or rate, but to improve
Stuart ● ● ● architect and coder interested in community interested in design
The Six Things
Names, good and bad ● ● ● ● ● Word Pages Windows Facebook Telegram ● ● ● ● ● ● Excel Alexa Medium Gimp Chrome Firefox
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%
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
(Some) Modern open source projects
(Some) Modern open source projects
(Some) Modern open source projects
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
The unideal world ● What should happen: ○ ○ ○ ● They download the project It works first time Hooray! Time for cakes! What doesn’t happen ○ That
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
If you build a better mousetrap, the world will not beat a path to your door. Stop thinking it will.
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
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
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
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
@linuxquestions @sil github.com/MeasureOSS/Measure
When we started our journey building Measure, a contributor relationship management system, we thought we knew the path we'd take. While the concept was new, the two people involved had expertise building both communities and software. The path, it turns out, wasn't as clear as we expected. We knew Measuring communities effectively would be difficult, and would involve both code and people... but there was a lot we didn't anticipate. Travel with us on our journey as we explore how we approached this problem from the different perspectives of coder and consumer, and how this resulted in a smooth release but also some bumps along the way; how some questions went unanswered and some seemingly easy tasks turned out to be deceptively difficult. In this talk Stuart and Jeremy will share 6 lessons learned, and you'll leave with both a better understanding of how to evaluate your community and collaborate on building software.
for free. You
can too.