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

Ben Nuttall

March 30, 2021
Tweet

More Decks by Ben Nuttall

Other Decks in Technology

Transcript

  1. @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
  2. @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
  3. @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
  4. @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)
  5. @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
  6. @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
  7. @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
  8. @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?
  9. @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”
  10. @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”
  11. @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?
  12. @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?
  13. @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)
  14. @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)
  15. @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
  16. @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)
  17. @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
  18. @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
  19. @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
  20. @ben_nuttall Open discussions & roadmap • Be open about project

    goals • Public roadmap • Discuss decisions in public • Issue-driven development
  21. @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
  22. @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?
  23. @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?
  24. @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
  25. @ben_nuttall Blogging • Is there an existing blog you could

    contribute to? • Tweet and promote the articles
  26. @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!
  27. @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?
  28. @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
  29. @ben_nuttall Make & share resources • Documentation • Books •

    Articles • Videos • Live streams • Structured courses • Q&A • Worked examples (PRIMM)
  30. @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