Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

@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

Slide 3

Slide 3 text

@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

Slide 4

Slide 4 text

@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

Slide 5

Slide 5 text

@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)

Slide 6

Slide 6 text

@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

Slide 7

Slide 7 text

@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

Slide 8

Slide 8 text

@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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

@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?

Slide 11

Slide 11 text

@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”

Slide 12

Slide 12 text

@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”

Slide 13

Slide 13 text

@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?

Slide 14

Slide 14 text

@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?

Slide 15

Slide 15 text

@ben_nuttall GitHub repository

Slide 16

Slide 16 text

@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)

Slide 17

Slide 17 text

@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)

Slide 18

Slide 18 text

@ben_nuttall Noting contributors

Slide 19

Slide 19 text

@ben_nuttall Noting contributors

Slide 20

Slide 20 text

@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

Slide 21

Slide 21 text

@ben_nuttall FAQs

Slide 22

Slide 22 text

@ben_nuttall Issue templates

Slide 23

Slide 23 text

@ben_nuttall Issue templates

Slide 24

Slide 24 text

@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)

Slide 25

Slide 25 text

@ben_nuttall Documentation - reference vs guidance

Slide 26

Slide 26 text

@ben_nuttall The Documentation System documentation.divio.com

Slide 27

Slide 27 text

@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

Slide 28

Slide 28 text

@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

Slide 29

Slide 29 text

@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

Slide 30

Slide 30 text

@ben_nuttall Open discussions & roadmap ● Be open about project goals ● Public roadmap ● Discuss decisions in public ● Issue-driven development

Slide 31

Slide 31 text

@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

Slide 32

Slide 32 text

@ben_nuttall Social media - Twitter

Slide 33

Slide 33 text

@ben_nuttall Twitter bot

Slide 34

Slide 34 text

@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?

Slide 35

Slide 35 text

@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?

Slide 36

Slide 36 text

@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

Slide 37

Slide 37 text

@ben_nuttall Blogging ● Is there an existing blog you could contribute to? ● Tweet and promote the articles

Slide 38

Slide 38 text

@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!

Slide 39

Slide 39 text

@ben_nuttall Logos

Slide 40

Slide 40 text

@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?

Slide 41

Slide 41 text

@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

Slide 42

Slide 42 text

@ben_nuttall Make & share resources ● Documentation ● Books ● Articles ● Videos ● Live streams ● Structured courses ● Q&A ● Worked examples (PRIMM)

Slide 43

Slide 43 text

@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

Slide 44

Slide 44 text

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