This document outlines strategies for marketing open source projects as a developer. It recommends focusing on fundamentals like easy installation, good documentation, and welcoming contributors. Specific suggestions include choosing a clear name, hosting the code on GitHub, maintaining issue templates and FAQs, writing documentation on ReadTheDocs, having a public roadmap, using Twitter to promote the project, and writing blog posts or articles about the project. The overall message is that marketing an open source project is primarily about making it easy for others to find, use, and contribute to the project.

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!