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
    How to market your open source project
    This talk is (mostly) not about marketing!

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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)

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  9. @ben_nuttall
    Rome wasn’t built in a day
    xkcd.com/2231

    View Slide

  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?

    View Slide

  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”

    View Slide

  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”

    View Slide

  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?

    View Slide

  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?

    View Slide

  15. @ben_nuttall
    GitHub repository

    View Slide

  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)

    View Slide

  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)

    View Slide

  18. @ben_nuttall
    Noting contributors

    View Slide

  19. @ben_nuttall
    Noting contributors

    View Slide

  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

    View Slide

  21. @ben_nuttall
    FAQs

    View Slide

  22. @ben_nuttall
    Issue templates

    View Slide

  23. @ben_nuttall
    Issue templates

    View Slide

  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)

    View Slide

  25. @ben_nuttall
    Documentation - reference vs guidance

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  30. @ben_nuttall
    Open discussions & roadmap

    Be open about project goals

    Public roadmap

    Discuss decisions in public

    Issue-driven development

    View Slide

  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

    View Slide

  32. @ben_nuttall
    Social media - Twitter

    View Slide

  33. @ben_nuttall
    Twitter bot

    View Slide

  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?

    View Slide

  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?

    View Slide

  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

    View Slide

  37. @ben_nuttall
    Blogging

    Is there an existing blog you could
    contribute to?

    Tweet and promote the articles

    View Slide

  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!

    View Slide

  39. @ben_nuttall
    Logos

    View Slide

  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?

    View Slide

  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

    View Slide

  42. @ben_nuttall
    Make & share resources

    Documentation

    Books

    Articles

    Videos

    Live streams

    Structured courses

    Q&A

    Worked examples (PRIMM)

    View Slide

  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

    View Slide

  44. @ben_nuttall
    How to market your open source project
    This talk is (mostly) not about marketing!

    View Slide