@ben_nuttall
How to market your open source project
This talk is (mostly) not about marketing!
@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
@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
@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
@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)
@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
@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
@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
@ben_nuttall
Rome wasn’t built in a day
xkcd.com/2231
@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?
@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”
@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”
@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?
@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?
@ben_nuttall
GitHub repository
@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)
@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)
@ben_nuttall
Noting contributors
@ben_nuttall
Noting contributors
@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
@ben_nuttall
FAQs
@ben_nuttall
Issue templates
@ben_nuttall
Issue templates
@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)
@ben_nuttall
Documentation - reference vs guidance
@ben_nuttall
The Documentation System
documentation.divio.com
@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
@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
@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
@ben_nuttall
Open discussions & roadmap
●
Be open about project goals
●
Public roadmap
●
Discuss decisions in public
●
Issue-driven development
@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
@ben_nuttall
Social media - Twitter
@ben_nuttall
Twitter bot
@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?
@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?
@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
@ben_nuttall
Blogging
●
Is there an existing blog you could
contribute to?
●
Tweet and promote the articles
@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!
@ben_nuttall
Logos
@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?
@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
@ben_nuttall
Make & share resources
●
Documentation
●
Books
●
Articles
●
Videos
●
Live streams
●
Structured courses
●
Q&A
●
Worked examples (PRIMM)
@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
@ben_nuttall
How to market your open source project
This talk is (mostly) not about marketing!

How to Market Your Open Source Project

  • 1.
    @ben_nuttall How to marketyour open source project This talk is (mostly) not about marketing!
  • 2.
    @ben_nuttall Ben Nuttall ● Software Engineerat 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 talkis 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 talkfocuses 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 marketingmean 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 changein 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 sourcecode ● 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 builtin 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 tohear 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 tohear 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 ● Whatis 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 - findingthe 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.
  • 16.
    @ben_nuttall Welcoming contributors ● Make iteasy 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 alist 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.
  • 19.
  • 20.
    @ben_nuttall Issues & questions ● Signpostto 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.
  • 22.
  • 23.
  • 24.
    @ben_nuttall Documentation ● Use appropriate toolse.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.
  • 26.
  • 27.
    @ben_nuttall Documentation contents ● Landing page ● Howto install / upgrade ● Getting started / examples ● Concepts explained ● API / CLI reference ● Development ● Changelog ● Migration guide ● Deprecations / breaking changes
  • 28.
    @ben_nuttall Migration guide ● Help peoplemigrate 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 vsEjector 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.
  • 33.
  • 34.
    @ben_nuttall Having a website ● Couldyour 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 ● Isthere 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 writesemi-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 anexisting blog you could contribute to? ● Tweet and promote the articles
  • 38.
    @ben_nuttall Conference talks ● Could yougive 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.
  • 40.
    @ben_nuttall Logo ● Can you designsomething 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 ● Isthere 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 & shareresources ● Documentation ● Books ● Articles ● Videos ● Live streams ● Structured courses ● Q&A ● Worked examples (PRIMM)
  • 43.
    @ben_nuttall Write for opensource.com! ● Contributionswelcome ● 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 marketyour open source project This talk is (mostly) not about marketing!