DevRel Scribbles
  • What are Scribbles?
  • Index
  • Developer Advocacy
  • Developer Advocates
  • Life as a developer advocate
  • Modernising Red Hat’s enterprise developer program
  • Engaging 9-year-old software developers
  • Making 22-year-olds love 26-year-old software
  • Dogfooding developer products: gathering insights from internal hackathons
  • How far does your ethical responsibility stretch for the tech your devs create?
  • Outside the lecture theatre
  • How do you design programs for diversity?
  • Build the Platform Your Developers Actually Want
  • Measuring dev rel programs far beyond marketing activities
  • Developer Evangelism
    • Developer Evangelists
    • How to rock a technical keynote
    • The Art of Slide Design
    • The Art of Talk Design
    • The Art of Story Design
    • Dev events beyond 2021
  • Developer Experience
    • The Power of Content
    • Building a Developer Community in an Enterprise World
    • How to lose a dev in three ways
    • Developer relations, why is it needed?
    • The hierarchy of developer needs
    • GitHub is your documentation landing page
    • Docs as engineering
    • Commit messages vs. release notes
    • A11y pal(ly)- crafting universally good docs
    • Inspiring and empowering users to become great writers, and why that’s important
    • Solving internal technical documentation at Spotify
  • Community Management
    • Building community flywheels
    • DevRel = Community Management?
    • Creating high-quality communities
    • How to grow a healthy Open-Source community?
    • Managing communities at scale
    • Using community to drive growth
    • Useful community success metrics
    • Communities aren't funnels
    • How to mobilise your community during a pandemic
  • Managing a DevRel Team
    • Developer Relations + Product
    • Distributed developer relations
    • Understanding company goals
    • DevRel Qualified Leads (DQL)
    • Path to success for DevRel
    • How to move up in your organization
    • Four pillars of DevRel
    • Building your DevRel dream team
    • Managing the burnout burn-down
    • I messed up and I’m going to get fired
    • How to report on community relationships without being creepy about it
    • How to scale a developer relations team
  • Misc
    • Is developer relations right for you?
    • Tooling your way to a great DevRel Team
    • Planning your DevRel career
    • Success metrics as narratives
    • Get executive buy-in or else
    • Introduction to the AAARRRP devrel strategy framework
    • Strategy for developer outreach
    • Connecting dev rel and product
    • Performance DevRel
    • Ultimate cheat codes for healthier travel
Powered by GitBook
On this page
  • Summary:
  • Scribbles:
  • Characteristics of a good open-source community...
  • Ladder Model for Open Source
  • Tackling imposter syndrome...?

Was this helpful?

Export as PDF
  1. Community Management

How to grow a healthy Open-Source community?

Twitter Spaces fireside chat as we discuss growing healthy open-source communities with Brian Douglas, Developer Advocate at GitHub.

PreviousCreating high-quality communitiesNextManaging communities at scale

Last updated 3 years ago

Was this helpful?

Summary:

  • Structuring the project with promotion paths

  • Hierarchy of advancement in open source projects

  • Holding yourself accountable for the communities and making sure you start initiatives to stay interested.

  • Setting clear paths for learning and advancement.

  • Establishing your intentions, boundaries, and interests — and communicating that (or being open to hearing this is so important!

Scribbles:

Characteristics of a good open-source community...

  • structure

  • knowing who to talk to

  • documentation

  • steps how to contribute

  • the architecture

  • structuring the project with promotion paths

Ladder Model for Open Source

  • hierarchy of advancement in open source projects

  • allows for buying and learning

  • setting clear paths for learning and advancement

Share your work with the community, do not hide behind your code and work.

  • Have your readme at the bare minimum. Make it easier for the newbies!

  • Holding yourself accountable for the communities and making sure you start initiatives to stay interested.

  • Make sure your community shares the same goal as you.

  • Not accepting contributions in open-source == respectfully drawing a line about how much and what kind of engagement you want from the community,

  • Documentation (blog posts, guides, etc) and paying attention to the little details including down to social cards is super helpful especially in telling stories and intention.

Tackling imposter syndrome...?

Here's how Brian approaches impostor syndrome and making open source accessible -

  • Intentionally you're going to have a solution written in the issue, provide an easy win.

  • Providing mentorship and help.

  • Giving credit where you can.

Video