Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How to market your open source project

How to market your open source project

Talk given at Open Source 101

A1995c9abe48450ce2f82d93ca0b863f?s=128

Ben Nuttall

March 30, 2021
Tweet

Transcript

  1. @ben_nuttall How to market your open source project This talk

    is (mostly) not about marketing!
  2. @ben_nuttall Ben Nuttall • Software Engineer at BBC News Labs

    • Former Community Manager at Raspberry Pi • Based in Cambridge, UK • Creator of gpiozero & piwheels • Contributor to opensource.com • twitter.com/ben_nuttall • github.com/bennuttall
  3. @ben_nuttall What this talk is not • How to buy

    a billboard to advertise your project • How to design a Google Adwords strategy • How to be a social media pro • How to go viral • How to run a great Mailchimp email campaign • How to optimise Google Analytics • How to get a celebrity endorsement for your project
  4. @ben_nuttall What this talk focuses on • Things you can

    do as a developer to make it easy for you and others to promote your project • Things you can do to promote your project • How you can leverage any potential company support you might have
  5. @ben_nuttall What does marketing mean in open source? • Reaching

    new users • Advocating for its use • Showing how it can help • Sharing case studies • Building a community • Promoting a bigger project (e.g. this project makes the Raspberry Pi look more appealing)
  6. @ben_nuttall Examples gpiozero • Python library - “zero- boilerplate” alternative

    to low- level RPi.GPIO • Easier for beginners, nicer experience for advanced users • Intended to replace the need for RPi.GPIO in all cases piwheels • Python Package repository • Provides pre-compiled packages for Raspberry Pi • Makes “pip install” fast on Raspberry Pi • Easy to go back to the old way if needed
  7. @ben_nuttall Examples gpiozero • Requires a change in behaviour •

    Requires learning something thing new • Lots of tutorials showing how to do things the old way • Hard to measure success piwheels • No change in behaviour required • Users get the new way by default • Works the same as before • Automatic collection of detailed usage statistics
  8. @ben_nuttall Fundamentals • Access to source code • Ease of

    installation • Documentation • Choosing a sensible name • Choosing an appropriate licence • Sensible versioning, backwards- compatibility & deprecation policy • Meeting expectations
  9. @ben_nuttall Rome wasn’t built in a day xkcd.com/2231

  10. @ben_nuttall Choosing a name • Short, precise and descriptive -

    ideally obvious • Well scoped (don’t overpromise) • What’s available? Check PyPI/npm/etc • Pronounceable (i.e. not kubectl) • Easy to spell / not confused with something else • Is there a convention? e.g. flask-X • Capitalisation: lowercase, hyphenated, full English?
  11. @ben_nuttall Bad things to hear about a project • “You

    can’t install it the normal way - you have to download the tarball and build it from source” • “Don’t bother asking for help - they’ll laugh at you and call you stupid” • “Documentation? Just read the source code” • “It’s on SourceForge” (sorry) • “They only support Arch Linux” • “It’s a more complicated way of doing X” • “It’s not worth the pain”
  12. @ben_nuttall Good things to hear about a project • “There’s

    a great community” • “It has great documentation” • “It’s so much easier than X” • “It’s much faster than before” • “It has a really nice API” • “It’s easy to get started” • “They accepted my pull request” • “It’s easy to extend”
  13. @ben_nuttall Defining your project • What is your project? –

    Snappy one-liner: it’s X for Y; a simple way to do X; a Python wrapper for X • Who is it for? – Beginners? Advanced users? Both? People using X with Y? People using X on platform Y? • What problem does it solve? – Easier? Faster? Cheaper? Automates X? • What’s the alternative? What’s the route to change? – How is it better than X? How to migrate from X?
  14. @ben_nuttall Expectations - finding the project • For Debian/Ubuntu? Can

    I apt install? • Python package? Can I pip install? • NodeJS package? Can I npm install? • On GitHub? github.com/org/project • Where are the docs? readthedocs? • Is there a website?
  15. @ben_nuttall GitHub repository

  16. @ben_nuttall Welcoming contributors • Make it easy for someone to

    set up your project for development • Provide developer documentation • Tests! • Lay out your contribution expectations • Respond to issues & PRs • Thank people! (even for small contributions)
  17. @ben_nuttall Noting contributors • Maintain a list of contributors •

    Include small & non-code contributions (ideas, suggestions, finding bugs, other help) • Name & thank contributors in the changelog • Mention contributors in comms (social, blog posts, etc)
  18. @ben_nuttall Noting contributors

  19. @ben_nuttall Noting contributors

  20. @ben_nuttall Issues & questions • Signpost to where you want

    people to go, e.g: – Check the FAQs first – Issues & bugs: GitHub issues (use templates!) – Q&A: GitHub discussions / Stack Exchange / community forum
  21. @ben_nuttall FAQs

  22. @ben_nuttall Issue templates

  23. @ben_nuttall Issue templates

  24. @ben_nuttall Documentation • Use appropriate tools e.g. sphinx • Host

    the docs e.g. readthedocs or custom domain • Host multiple versions (sphinx/readthedocs does this) • Mix of automated docs (from docstrings) and written docs • Include diagrams & pictures (e.g. graphviz & fritzing)
  25. @ben_nuttall Documentation - reference vs guidance

  26. @ben_nuttall The Documentation System documentation.divio.com

  27. @ben_nuttall Documentation contents • Landing page • How to install

    / upgrade • Getting started / examples • Concepts explained • API / CLI reference • Development • Changelog • Migration guide • Deprecations / breaking changes
  28. @ben_nuttall Migration guide • Help people migrate their code and

    introduce new concepts • Compare and contrast • Cover all areas included and highlight any gaps • Explain benefits • Cover migration FAQs • Cover migration back if necessary
  29. @ben_nuttall Escape hatch vs Ejector seat What happens when users

    hit the limits of your abstraction? • Option 1: go down with the ship • Option 2: the ejector seat • Option 3: the escape hatch https://anvil.works/blog/escape-hatches-and-ejector-seats
  30. @ben_nuttall Open discussions & roadmap • Be open about project

    goals • Public roadmap • Discuss decisions in public • Issue-driven development
  31. @ben_nuttall Social media - Twitter • Personal – Use your

    own account to tweet / RT about the project – Follow search terms (e.g. TweetDeck column) • Company – Tweets & RTs about your project from a company account could have more reach • Project brand – Consider setting up an account for the project – Twitter bot – Use third-party services like Buffer to help
  32. @ben_nuttall Social media - Twitter

  33. @ben_nuttall Twitter bot

  34. @ben_nuttall Having a website • Could your project warrant a

    “home” on the web beyond its GitHub repo, documentation site, package page, etc? • Does your project naturally have a website as part of its purpose? • Does it make sense to have a landing page pointing to downloads, docs, source, issues, social media, community, etc?
  35. @ben_nuttall Having a website • Is there a collection of

    similar projects like SciPy or Pallets Projects? • Does your company have an open source projects page?
  36. @ben_nuttall Blogging • Could you write semi-regular updates about your

    project? • Could you collate/accept community contributions? • Start simple - use something like hosted WordPress • Integrate into your website if/when you get one
  37. @ben_nuttall Blogging • Is there an existing blog you could

    contribute to? • Tweet and promote the articles
  38. @ben_nuttall Conference talks • Could you give a conference talk

    about your project? • Even if the talk is not about your project, but about another concept using your project • Consider lightning talks and local user groups too • Promote community members speaking about your project • All Things Open CFP!
  39. @ben_nuttall Logos

  40. @ben_nuttall Logo • Can you design something simple? – Word

    logo with simple shapes? • Can you do a call for a design contribution? – Create a GitHub issue • Can you ask a designer for a quote, and raise the funds to pay it?
  41. @ben_nuttall Hitch a lift • Is there a relevant email

    newsletter you can submit to? • Build a demo using another project, see if you can blag a RT out of it
  42. @ben_nuttall Make & share resources • Documentation • Books •

    Articles • Videos • Live streams • Structured courses • Q&A • Worked examples (PRIMM)
  43. @ben_nuttall Write for opensource.com! • Contributions welcome • Any topic

    related to open source • 2 million readers per month • Your article will get more hits here than your own blog • Twitter: – @opensourceway – @JenWike • opensource.com/how-submit-article
  44. @ben_nuttall How to market your open source project This talk

    is (mostly) not about marketing!