1. freeCodeCamp's Python certification

2. freeCodeCamp's JavaScript certification (Version 10)

3. freeCodeCamp's Responsive Web Design Certification (Version 10)

4. freeCodeCamp's Relational Database + SQL Certification

5. Our A2 level English for Developers Certification

6. Our B1 level English for Developers Certification

7. Our beta A1 level Spanish curriculum

8. Our beta A1 level Mandarin Chinese curriculum

Those are a lot of gifts to unwrap, so let's start unwrapping!

Programming Certifications and Version 10 of the Full Stack Development Curriculum

Over the past 11 years, the freeCodeCamp community has built and rebuilt our core programming curriculum several times.

We are finally approaching our vision of how comprehensive and interactive a programming curriculum can be.

Version 10 of our curriculum is a series of 6 certifications – each with more than a dozen projects that you'll build to solidify your fundamental skills.

At the end of each certification, you'll take a final exam. And if you can manage to pass this exam, you'll be awarded a free, verified certification. You can then embed that on LinkedIn, or add it to your résumé, CV, or portfolio website.

So far, 4 of these certifications are now live:

• Responsive Web Design certification announcement

• JavaScript certification announcement

• Python certification announcement

• Relational Databases certification announcement

And we will release the Front End Libraries and Back End Development certifications in 2026.

After earning all 6 certifications, you can build a final capstone project – which will be code-reviewed by an experienced developer. Then you’ll sit for a comprehensive final exam. And upon completion of that, you'll earn our final Full Stack Developer Certification.

If you start progressing through these first four certifications today, the last two certifications should go live well before you reach them. After all, each of them represents hundreds of hours of conceptual computer science knowledge and hand-on programming practice.

Language Coursework

First, you may be asking: when did freeCodeCamp start teaching world languages?

Well, we started designing our English for Developers curriculum back in 2022. And over the past few years, we've expanded it considerably.

The curriculum involves interacting with hand-drawn animated characters. Along the way, you get tons of practice with reading, writing, listening, and (coming in 2026) speaking.

It's a story-driven curriculum. You step into the shoes of a developer who's just arrived in California to work at a tech startup. You learn grammar, vocab, tech jargon, and slang through day-to-day interactions while living your new life.

So far, two of these certifications are fully live:

• A2 Level English certification announcement

• B1 Level English certification announcement

We're also developing levels A1, B2, C1, and C2 for release over the coming years. (Yes, years. Each of these is a huge undertaking to develop.)

Not only has the freeCodeCamp community designed thousands of English lessons - we also built tons of custom software tools to make all this coursework possible. So in 2024, we asked: could we use the same tools to teach people Spanish and Mandarin Chinese?

And today, the results of this effort are now in public beta. We're starting out with A1 Level for both of these languages, and will ship the remaining levels over the coming years.

• A1 Level Spanish curriculum announcement

• A1 Level Mandarin Chinese curriculum announcement

Why Teach Spanish and Mandarin?

Aside from English, Spanish and Mandarin are two of the most widely-spoken languages in the world. You can use these languages to participate in tons of online communities, visit major cities, and even find new job opportunities.

Learning foreign languages is also excellent for your neuroplasticity, and can be done alongside learning other new skills like programming.

And now you can learn these languages for free, using our comprehensive end-to-end curriculum that was designed by teachers, translators, and native speakers.

Update on Translating freeCodeCamp’s coursework into major world languages

As you may know, freeCodeCamp has been available in many major world languages going back to 2020. But whenever we launch new coursework, it takes several months to translate everything.

Thankfully, machine translation has been steadily improving over the past few years.

The community is still translating tutorials and books by hand, but for something that changes as quickly as freeCodeCamp’s programming curriculum, we want to speed up the process.

We’ve conducted pilots of translating all the new coursework into both Spanish and Portuguese.

• First, we used frontier Large Language Models and extensive glossaries and style guides to process the hundreds of thousands of words in our programming curriculum.

• Then we had native speakers randomly sample these translations to ensure their quality.

• Once we felt the translations were strong enough, we started creating data pipelines to automatically update translations as the original English text changed through open source code contributions.

The monetary cost of doing all this is not significant. So we should be able to offer freeCodeCamp’s programming curriculum in additional languages we weren’t previously able to support, such as Arabic and French.

If you are one of the hundreds of people who’ve contributed translations to freeCodeCamp over the years, we’d still welcome your help translating books and tutorials, which don’t change much after initial publication.

After all, the gold standard for localizing a document is having a single human translator holistically read and understand that document before creating the translation.

This community is just getting started.

This year the freeCodeCamp community also published:

• 129 free video courses on the freeCodeCamp community YouTube channel

• 45 free full length books and handbooks on the freeCodeCamp community publication

• 452 programming tutorials and articles on math, programming, and computer science

• 50 episodes of the freeCodeCamp podcast where I interview developers, many of whom are contributors to open source freeCodeCamp projects

We also merged 4,279 commits to freeCodeCamp’s open source learning platform, representing tons of improvements to user experience and accessibility. And we published our secure exam environment so that campers can take certification exams.

You can view our 2025 list of Top Open Source Contributors.

As a community, we are just getting started. Free open source education has never been more relevant than it is today.

We invite you to get more involved in the community, too.

I want to thank the 10,221 kind folks who donate to support our charity and our mission each month. Please consider joining them: Donate to freeCodeCamp.org.

And here are some other ways you can make a year-end donation that you can deduct from your US taxes.

freeCodeCamp has a vibrant global community of ambitious people who are learning new skills and preparing for the next stage of their career. I encourage you to join the freeCodeCamp Discord and hang out with us there.

And take Naomi’s freeCodeCamp Community Survey to help us understand what you like about freeCodeCamp and what our community can do even better.

On behalf of the global freeCodeCamp community, here’s wishing you and your family a fantastic finale to your 2025. Cheers to a fun, ambition-filled 2026.

This year we made substantial improvements to the new Full Stack Developer curriculum. This is the 10th version of the freeCodeCamp curriculum, and includes 7 certifications. Along the way, learners build more than 100 hand-on projects and pass exams on computer science theory.

Also, over the past year, the freeCodeCamp community published:

• 129 free video courses on the freeCodeCamp community YouTube channel

• 45 free full length books and handbooks on the freeCodeCamp community publication

• 452 programming tutorials and articles on math, programming, and computer science

• 50 episodes of the freeCodeCamp podcast where I interview developers, many of whom are contributors to open source freeCodeCamp projects

We also merged 4,279 commits to freeCodeCamp’s open source learning platform, representing tons of improvements to user experience and accessibility. And we published our secure exam environment so that campers can take certification exams.

Finally, we made considerable progress on our English for Developers curriculum, and started work on our upcoming Spanish and Chinese curricula.

We are just getting started. We’re already mapping out additional coursework on math, data science, machine learning, and other deep, skill-intensive subjects.

All of this is possible thanks to the 10,342 kind folks who donate to support our charity and our mission, and the thoughtful folks who their time and talents to the community.

Below is a list of our 611 most prolific open source contributors in 2025:

GitHub Top Contributors

• Clarence Bakosi

• Supravisor

• Giftea ☕

• Diem-Trang Pham

• Anna

• c0d1ng_ma5ter

• JungLee-Dev

• hbar1st

• dev-kamil

• Ariz Faiyaz

• agilan11

• Vinson Pham

• Stuart Mosquera

• Stephen Mutheu Muya

• Mohamad Salman

• Alex Goldsmith

• Vishnu D

• Kannan

• Tanmay Gautam

• l3onhard

• Prabhakar Yadav

• Ezoh Zhang

• Ajay A

• Vivaan Teotia

• Hassan Waqar

• Krzysztof G.

• Roberto Iacono

• Melvin Kosisochukwu

• Lasse Jørgensen

• dennmar

• Arif Khalid

• Sorya Ek

• Raymond Liu

• Ayush Sharma

• Yusuf Can Aşur

• Karthik Bagavathy

• Naman Khandelwal

• Varshith Kalakota

• Omar Rafiq

• Prashant Rathore

• Agung Saputra

• Sanchit Kathpalia

• Shashank Dangi

• Gary Yeung

• Amit Upadhyay

• pkdvalis

• sinha21Soumya

• Telukula Vishal

• sskiragu

• Aishwarya

• Trevor Browning

• AilaLu

• zxc-w

• Anish Lukkireddy

• Josue Igiraneza

• Aditya Ravichandran

• Skye Mickens

• Gagan Bhullar

• Aditya

Forum Top Contributors

• Teller

• pkdvalis

• Hassan Zaib

• A1legalfreelance

• Doug Badger

• Jeremy

• fcc4b6d10c4-b540-4e2

• Arakhsh Q

• Raymond

• Hanaa B.

• Lasse

• sanity or not

• MostafaElbadry

• Anna

• Muhammad Subhan

• Stephen Mutheu

• Zeynep Serra Akkaya

• A.Bappy

• Paulo

• StaySilent

• Klexvier

• Robert H.

• Marvin Hunkin

• Tracy Chacon

• bochard

• CODY BIGGS

• Infinity

• Shady H. Bedda

• Boolean Method

• Ariel Leslie

• Head in Cloud

• Dovb1ek

• c0d1ng_ma5ter

• evaristoc

• ahr aitch

• Jay

• AlexanderTheDev

• Malcolm Harrison

• Ethan1

• Vikram Ingleshwar

• Amine (Mike)

• Nicolas Greenwood

• Amunyelet-Ojala

• anon75571083

• Brenden Howlett

Translation Top Contributors

• Afonso Branco (AfonsoBranco)

• Michael Qu (qubycn)

• Alan Luo (iLtc)

• Nadja Sellinat (biebricherin)

• David Almeida (david.miguel.almeida)

• jeigux

• Nairobi (fanqie)

• Ivan Forcati (IvanF)

• Quang Nguyen (nguyendangquang126)

• Ganebas

• Kentaro Nareswara (K3N7)

• Alana Maia (nicegrrrl)

• Gustavo Birman (Gustavuspqr)

• Nataliia Hrytsyk (nataliia.hrytsyk)

• Filipe Oliveira (FilipeOliveira)

• Діана Маркута (dianamarkuta)

• Kostiantyn Krysenko (barkode)

• v4n31aa

• janni1288

• Nastasia Milosev (nastasia.milosev)

• Juan Diaz (JuanPabloDiaz)

• Stas Kinash (stasKinash)

• ToteM

• Tihomir Manushev (haraGADygyl)

• Maximo Sanchez (maxysanchez.06)

• Сервило Галина (servilogalina)

• Laureline Paris (LaurelineP)

• mubinabegimxayrullayeva

• mitegab

• Berke Volkan (kzlpndx)

• Dana Volovelsky (danavolovelsky)

• Isauro Rodriguez (icaro5)

• Yuliia Lishchuk (yuli)

• Palak (palakkhan2002)

• bahtiyorjonq777

• Olha Boretska (olha.boretskaa)

• yidev27

• Ilona Sheremeta (lonasheremeta78)

• Anna Shram (annashram53)

• Anastasiia Perchyshyn (anastasijp2004)

• Mariia Soloshenko (Mariia_S)

• erickk (lucerile435)

• Fran Sanabria (fransanabria)

• Богдана Онищук (bohdanaon9001)

• Shogo SENSUI (1000ch)

• maysa42snow

• Halia Senkiv (haliasenkiv)

• Jiyoung Suh (JiyoungSuh)

• Anairis Carballea (acarballea)

• Johan Javier Gonzalez Perez (javiergonzalez045)

• yosrmaalej47

• Akram Dhib (akramdhib999)

• Bảo Nam Trần Hoàng (kipi91212)

• Eduarda Groehs (egroehs)

• FlameC (anonymHe)

• sohyun

• Xiaoyan Zhang (Drwhooooo)

• Gabriela Silva (gabrielaquintilho.s)

• Fausto Chiacchietta (faustooch)

• Seif-03

• オメロ (homero304)

• Msam

• Eya (eyaaba)

• mohamed ben haj salah (mohamedbhs7)

• abdallah djarraya (abdallahswimmer)

• Aylin Gümüş (aylingumus)

• aminezribi03

• Eloy Gutiérrez (eloy.alumnes)

• Ameeri22

• youssef1607

• Pablo J Lebed (pjl1978)

• Mergen N (mn)

• Yuki Shibata (kyubashi)

• ggfly666

• Amine (ersu.amine)

• WaifuXv

• Jawnex

• mamaruo

• Eric Gigondan (Itsatsu)

• Hamzalakoud

• c.marget

• Saki Basken (sbasken)

• hashim rashid (hhashbrown)

• yuan-minglongze

• OKmimech

• J.G. P.C. (kaiserpc)

• Fatma Ajroud (faty_aj)

• Yuna_707

• Franklin Solar Navarrete (fsolarnavarrete)

• zeinebBenRayana

• Mark P. (Futuraura)

• Ahmad Hassan (sUfi)

• Ivrin Ivrin (Ivrin)

• parapara0919

• Panah (panah)

• Mario Turtoi (MarioDev)

• Edenilson Ulises Aguilar Diaz (UlisesDiaz0)

• rustamdocstranslator

• Cristian Salazar (Cristian-27)

• IsabelaMB

• Khalil Sassi (khalilsassi67)

• Sorayadc

• Franco Casafus (francocasafus22)

• miwamiwamiwa (miwalaa)

• franciscomelov

• Juan Taroni (juanribeiro.taroni)

• Alexander Liu Gao (aleliu)

• YC liou (iop52896)

• David Oliveira (EngDavidOlivr)

• Campoz _ (campozzz)

• Roberta Meyrelles (rmftelier)

• Polina (minlaux)

• Matheus G. Oliveira (PomboObeso)

• Hou Bowei (houbowei)

• Paul (ptijero)

• Danilo Parada Garcés (dparada.sistemas)

• Ana_Writer

• Nathalia Oliveira (royalpython)

• Amir (Amir_lvx)

• Eltaj Mammadzada (eltajmammadzada)

• Oliver Loza (THE_G3NES1S)

• Jakhongir Murtazaev (jakhongir.murtazayev)

• Siyana Zdravkova (BlueButterflies)

• Vindishel (vindishel)

• Daniel Jimenez (danjim82)

• hk7math

• KAWPHUNMAN

• wdthor

• Snow sita2 (EnmanuelTorres)

• Aldo Vanegas (AldoLara)

• nmo-genio

• Pedro Daniel (pedrodanielgomes)

• sadnessasha

• Aby Prastya Palgunadi (arcanaxvi)

• Halifolium

• juan jose (Juanx64)

• Henry Richard Flores Bazurto (hflores10)

• Leah

• Emma (emmaa5)

• ANVAR ZIYODOV (ziyodovanvar1999)

• dharris296

• Juan Esteban Montoya Marín (montoyajuanes11)

• Yiming Sun (sunyiming008)

• Fauzi Kurniawan (kurniawan26)

• Royyan Ahmad Zaydan (Kasehito)

• Mikadifo

• thelooter

• Berkcan Gümüşışık (berkcangumusisik)

• Stephen Mutheu (stephenmutheu)

• athen

• Wajahat (syedmuhammadwajahathusain)

• Tanish Chauhan (tanishc4444)

• Satya900

• Luis V. (lvalderramavergara)

• Sharvio

• HibouDev

• dTM99

• wuzzjohn

• Gavin Xu (gavinxu2)

• ProjektMing

• Saidkamol Saidjamolov (saidkamolxon)

• beta filip (betafilip)

• Deborah Porchia (deborah98)

• teddy_ye

• Rommel Hindap (rommel.b.hindap)

• Jesús Lautaro Careglio Albornoz (JLCareglio)

• SergioBlancoFtns

• Nathalie Bour (nathalie.bour)

• Qingfeng Huang (darrenhqf)

• Omar (omar.fanzeres)

• Atsushi Hatakeyama (atsushi729)

• Diego Fierro (diegoefierro)

• IsaRO (IsaR0d)

• Abdulbosit Tuychiev (abdulbosit19980204)

• NG KA YEE (hkscsheph)

• Floman Dizwit (Hockman)

• Karel Vanhelden (karelvanhelden)

• khay56

• Dostonbek Matyakubov (doston12)

• MarcoGeldenhuis

• immeteor2

• Freedom Fighter (1543431a)

• Ibn Hosain (ibnhosain014)

• Vairus (e-oannis)

• Elio Fang

• YiWei

• Tsukistar

• luojiyin

• Qingfeng Huang

• wendy chen

• zhizhan

• HeZean

• Ivan Forcati

• Andrea Sisti

• 彭雪梅

YouTube Top Contributors

• S1ng S1ng

• Carlos León

• Luis Canary

• Ramon Rodrigues

• James Pearce

• Tatev Aslanyan

• Eric Tech

• Rivaan Ranawat

• Khaiser Khanam

• Paulo Dichone

• Hitesh Choudhary

• Eamonn Cottrell

• Harsh Bhatt

• Radu Mariescu-Istodor

• Imad Saddik

• Faisal Memon

• JSLegendDev

• Andrew Brown

• Dave Gray

• Ebenezer Asabre

• Alberto Lerda

• Yacine Mahdid

• Alen Omeri

• Tunga Bayrak

• Haris Iftikhar

• Rola Dali

• Omar M. Atef

• Steven Garcia

• Rishi Kumar Tiwari

• Cole Blender

• Borys Cherednychenko

• Haider Malik

• Grant Huang

• Vuk Rosić

• Daniel Gakwaya

• Brijen Makwana

• Zura Sekhniashvili

• Vladimirs Hisamutdinovs

• Tapas Adhikary

• Richard Topchii

• Abel Gideon

• Chuck Schiemeyer

• Alexandru Cristian

• Virginia Ocana

• Vaibhav Mehra

• Kshitij Sharma

• Bhrugen Patel

• Mohammad Fahd Abrah

• Frank Andrade

• Chad McAllister

• Erik Yuzwa

• Bappy Ahmed

• Noor Fakhry

• Ayush Singh

• Gregory Kirchoff

• Sheldon Chi

• Muhammad Omar Al Najjar

• Chumki Biswas

• Alvin Zablan

• Qiang Hao

• Marco Peix

• Sumit Saha

• Yılmaz Alaca

• Bobby Roe

• Lane Wagner

• Shad Rayhan Mazumder

• Ervis Trupja

• Vivek Kalyanarangan

• David J. Malan

• Carlos Leon

• Carlos Valentin

• Parth Vyas

• Muhammad Abdullah

• Andrew Woan

• Alex Gordon

• Karol Kurek

News Top Contributors

• Manish Shivanandhan

• Nikheel Vishwas Savant

• Surya Teja Appini

• OMOTAYO OMOYEMI

• Casmir Onyekani

• Chukwudi Nweze

• German Cocca

• Shejan Mahamud

• Hew Hahn

• Moshe Siegel

• Mark Mahoney

• Atuoha Anthony

• Bala Priya C

• Ashutosh Krishna

• Hitesh Chauhan

• Mah Noor

• Andrew Baisden

• Alex Tray

• Gabor Koos

• Abhijeet Dave

• Sumit Saha

• Opaluwa Emidowojo

• Oluwatobi Sofela

• Shola Jegede

• Michael Yuan

• Chisom Uma

• Wisdom Usa

• Kuriko Iwai

• Cedd Burge

• Destiny Erhabor

• Ayodele Aransiola

• Temitope Oyedele

• Emdadul Islam

• Oyedele Tioluwani

• Soham Mehta

• Agnes Olorundare

• Tapas Adhikary

• Chirag Agrawal

• Ajay Yadav

• Mayur Vekariya

• Sharvin Shah

• Adejumo Ridwan Suleiman

• Sravan Karuturi

• Lane Wagner

• Nitheesh Poojary

• Alma Mohapatra

• Orim Dominic Adah

• Arunachalam B

• AYUSH MISHRA

• Shrijal Acharya

• Ikegah Oliver

• Olaleye Blessing

• Ifeoma Udu

• Oluwatobi

• Oladeji Oluwaseun

• Tarun Singh

• Grant Riordan

• Asfak Ahmed

• Tech With RJ

• Tim Kleier

• Ophy Boamah

• EZINNE ANNE EMILIA

• Happiness Omale

• Pedro

• Amanda Ene Adoyi

• Arun Shanmugam Kumar

• Andrew Ezeani

• Ajay Kalal

• Ijeoma Igboagu

• Prankur Pandey

• Augustine Alul

• Sanjay R

• Ayu Adiati

• Daniel García Solla

• Isaiah Clifford Opoku

• Ryan Michael Kay

• Idris Olubisi

• Aditya Vikram Kashyap

• brooklyn

• Tope Fasasi

• Ilknur Eren

• Soham Banerjee

• Vahe Aslanyan

• Tatev Aslanyan

• Henry Adepegba

• Oluwadamilola Oshungboye

• Shruti Kapoor

• Mfonobong Umondia

• Spruce Emmanuel

• Okoro Emmanuel Nzube

• Raju Manoj

• Udemezue John

• Oluchi Nwenyi

• Tooba Jamal

• Victoria Nduka

• Nneoma Uche

• Michael Ikoko

• Olowo Jude

• Ateev Duggal

• Oluwadamisi Samuel

• Mohit Menghnani

• Brandon Wozniewicz

• Hang Hu

• Rufai Mustapha

• Damilola Oniyide

• Fatuma Abdullahi

• Montasser Mossallem

• valentine Gatwiri

• Timothy Olanrewaju

• Han Qi

• Eti Ijeoma

• Yazdun

• deji adesoga

• Brian Barrow

• Chidiadi Anyanwu

• Andrew Maksimchenko

• Mario Casari

• Balajee Asish Brahmandam

• Gordan Tan

• Tilda Udufo

• Rahul gupta

• Eda Eren

• Josiah Adesola

• Venkata Sai Sandeep

• Tiago Capelo Monteiro

• Preston Osoro

• Ankur Tyagi

• Ben

• Vikram Aruchamy

• Dhruv Prajapati

• Prince Onukwili

• Daniel Adeboye

• Kumar Anand

• Lucas

• evaristo.c

• Rajdeep Singh

• Chaitanya Rahalkar

• Maham Codes

• Divya Valsala Saratchandran

• Joan Ayebola

• Omer Rosenbaum

• Nazneen Ahmad

• Kunal Nalawade

• Shamsuddoha Ranju

• Anamol Rajbhandari

• Sule-Balogun Olanrewaju

• Sara Jadhav

• Daniel Anomfueme

• Michael Para

• Elabonga Atuo

• Azubuike Duru

• Adalbert Pungu

• Kevine Nzapdi

• Hamdaan Ali

• Abdullah Salaudeen

• Rahul

• Alaran Ayobami

• Omolade Ekpeni

• Rob Walters

• Vivek Sahu

• oghenekparobo Stephen

• P S Mohammed Ali

• Gursimar Singh

• Olabisi Olaoye

• David Asaolu

• Jacob Stopak

• Emore Ogheneyoma Lawrence

• Hunor Márton Borbély

• Praise James

• Alex Pliutau

• Tanishka Makode

• Sonya Moisset

• Vivek Agrawal

• Syeda Maham Fahim

• Chidera Humphrey

• Danny

• Stefan Muzyka

• Samhitha Rama Prasad

• Nitin Sharma

• Programming with Shahan

• Juan P. Romano

• Anjan Baradwaj

• Manoel

• Kayode Adeniyi

• Akande Olalekan Toheeb

• David Clinton

• Jose Vicente Nunez

• Joe Attardi

• Mihail Gaberov

• Ashimi0x

• Zubair Idris Aweda

• Ibrahim Ogunbiyi

• Svitlana Lorman

• Ayantunji Timilehin

• Krishna Sarathi Ghosh

• David Jaja

• Francis Ihejirika

• Marco Venturi

• Fanny Nyayic

Discord Top Contributors

• hana-banana

• Science99

• Razzle Dazzle

• jeremylt (he/they)

• Makka Pakka jOoJ

• bradtaniguchi

• ʇɹǝqɯoɥɹ

• Versailles

• CapslockHero 🎃

• plamoni

• xCoffeeMan

• Dylan

• QC Failed (Brandon)

• minjo70

• tgrtim

• Yu14

• localhost

• ArielLeslie

• Wayloe

• Hordian

• Anna

• Starbreeze

• supertanno

• Hermit

• Aakash

• Ganesh

• Zino

• Cristina

• Pantalonians

• Cy4er

• himonshuuu

• Dumb ninja

• Kiseki 奇跡

• Sebastian

• alpox

• BasCat

Again, these are just the most prolific among the thousands of people involved in the freeCodeCamp community.

If you're interested in getting involved in the freeCodeCamp community as an open source contributor, I encourage you to read our Contributor Guide and to join our Contributor Discord.

Thanks again, and happy coding. 🏕️

Most community managers spend hours each week answering the same questions over and over. You might find yourself repeating instructions for how to join a project, what the process for submitting an event proposal is, or who to contact for a specific problem because "everyone just knows" how things work. The issue is that the information isn't easy to find or understand when your community members need it most.

Effective documentation is the unsung hero of a thriving community. In this tutorial, you will learn how to create documentation that genuinely serves your tech community. You will discover proven techniques for organizing information, writing clear instructions, and building systems that work for both newcomers and experienced contributors.

Table of Contents

• Why Community Documentation Often Falls Short

• Core Principles for Effective Community Documentation

• How to Know Who You're Writing For

• How to Organize Information for Easy Access

• How to Write Instructions That People Can Actually Follow

• Essential Documentation Every Tech Community Needs

• How to Create a New Member Onboarding Guide

• The Community Operating Procedures Handbook

• The Event Planning Handbook

• The Community Guidelines and Behavioral Expectations Handbook

• How to Test Whether Your Documentation Works

• How to Observe How People Actually Use Information

• How to Ask Targeted Questions for Improvement

• How to Monitor Community Health Indicators

• How to Maintain Documentation as Your Community Evolves

• How to Schedule Regular Review Cycles

• How to Create Systems for Community Input

• How to Build Documentation Updates into Regular Workflows

• How to Create a Culture of Clear Communication

• How to Model Excellent Communication Practices

• How to Integrate Clarity into Decision-Making

• How to Recognize Clear Communication

• Conclusion

Prerequisites

To get the most from this tutorial, you should have:

• Experience participating in or managing tech communities.

• Responsibility for creating processes or guidelines that others need to follow.

• Access to community platforms like Slack, Discord, or similar communication tools.

No formal writing experience is required. This guide focuses on practical approaches that work in community settings.

Why Community Documentation Often Falls Short

Documentation often fails because it is created for the wrong audience or stored in a way that makes it difficult to find. A common pitfall is creating documentation that is too technical or formal, using jargon that is not understood by new members. Another issue is that documentation is often a one-time effort, not a living resource. When processes or team members change, the documentation becomes outdated and unreliable, causing people to abandon it entirely.

Core Principles for Effective Community Documentation

Strong community documentation is built on four key principles that make information genuinely useful rather than just comprehensive.

How to Know Who You're Writing For

Different community members need different information depending on their experience level and involvement goals. Consider these main audiences:

• New members who are exploring how to participate.

• Active participants looking for specific opportunities or information.

• Volunteers needing clear instructions for their responsibilities.

• Organizers requiring detailed procedures and decision-making guidelines.

How to Organize Information for Easy Access

The way you structure information is just as important as the information itself. Good documentation anticipates a user's needs, allowing them to find what they are looking for without digging through endless pages.

A well-organized documentation hub should mirror your community's journey. Start with high-level, introductory information and then branch out into more specific, detailed guides. For example, a newcomer should see a clear pathway to finding a welcome guide, while an experienced volunteer should be able to jump directly to a detailed event checklist.

Think about using a central location that is easy to access, such as a dedicated channel, a pinned post in your community platform, or a simple, single-page website. Use subheadings and bullet points to break down long sections of text, making the content scannable and digestible.

How to Write Instructions That People Can Actually Follow

Clear instructions are the bedrock of effective documentation. When you write a guide, imagine you are sitting with a new volunteer, talking them through a task step-by-step. Use active voice and simple, direct language. For example, instead of writing "The event registration form should be created," write "Create the event registration form."

Use numbered lists to guide readers through a process in a logical order. You can use screenshots and diagrams to illustrate a point, but make sure they are clear and easy to understand. For instance, a screenshot of a community's Standard Operating Procedure (SOP) document can help a new team member visualize their tasks.

Essential Documentation Every Tech Community Needs

Different types of documentation serve different purposes in community management. Here are the most important ones to prioritize.

How to Create a New Member Onboarding Guide

Your onboarding documentation should help new members feel welcome and find their first meaningful way to participate. Effective onboarding includes:

• A welcome message explaining community values and culture.

• A quick overview of how to access and use community platforms.

• Immediate ways to get involved that match different comfort levels.

• A community calendar highlighting upcoming opportunities.

• Clear contact information for getting help.

The Community Operating Procedures Handbook

Standard procedures ensure consistent experiences regardless of which team member handles a situation. As community management expert Rosemary O'Neill notes:

"Clear processes are not about bureaucracy – they are about creating predictable, positive experiences that let community members focus on connection rather than confusion."

Comprehensive community procedures should address:

• Team Structure and Operations: Community mission statement and core values, team roles with clear responsibility boundaries, decision-making processes and approval workflows, communication protocols for different situations.

• Member Experience Management: Application review standards and timeline expectations, new member welcome sequence with multiple touchpoints, engagement strategies including regular check-ins and recognition programs, pathway documentation for members to increase involvement, feedback collection methods and response protocols, professional offboarding process for departing members.

• Community Building and Growth: Content creation guidelines and approval processes, partnership evaluation criteria with other organizations, volunteer recruitment strategies and management systems, leadership development opportunities and requirements.

• Event and Program Management: Event planning workflows from initial concept to post-event review, speaker recruitment, vetting, and coordination procedures; registration management and attendee communication templates, technical requirements and setup procedures for different event formats, post-event evaluation and improvement documentation.

• Community Health and Safety: Conflict resolution procedures with clear escalation paths, community guideline enforcement protocols and consequences, crisis communication plans and emergency contacts, member well-being resources and support systems.

• Evaluation and Improvement: Community health metrics and regular assessment schedules, member satisfaction measurement and analysis methods, growth tracking systems and reporting requirements, quarterly review processes and improvement planning.

The Event Planning Handbook

Events often drive community engagement and growth. Your event documentation should enable teams to create successful experiences consistently. Organize event documentation by timeline:

• 6-8 weeks prior: Initial planning, venue booking, speaker outreach.

• 4-6 weeks prior: Registration setup, marketing launch, logistics confirmation.

• 2-4 weeks prior: Final details, volunteer coordination, attendee communication.

• Week of event: Setup procedures, team briefings, backup plans.

• Event day: Detailed checklists for setup, execution, and wrap-up.

• Post-event: Follow-up tasks, feedback collection, documentation updates.

The Community Guidelines and Behavioral Expectations Handbook

Community guidelines should clearly communicate expectations while reflecting your community's specific culture and values. Effective community guidelines include:

• Specific behavioral expectations with concrete examples.

• Clear consequences that focus on community repair and learning.

• Accessible reporting procedures for concerns or conflicts.

• Resolution processes that prioritize healing and growth.

• Recognition systems for positive community contributions.

How to Test Whether Your Documentation Works

Creating documentation is only the first step. You need to verify that it actually helps people succeed in your community.

How to Observe How People Actually Use Information

The most valuable feedback comes from watching interactions between community members and your documentation. Observation methods:

• Ask new volunteers to follow your procedures while you watch (without providing extra help).

• Monitor community channels for repeated questions that suggest documentation gaps.

• Track completion rates for multi-step processes.

• Pay attention to member feedback about confusing or particularly helpful resources.

How to Ask Targeted Questions for Improvement

Generic feedback does not provide enough detail for meaningful improvements. Ask specific questions that reveal actual pain points. Useful feedback questions:

• "At what point did you feel unsure about what to do next?"

• "What information were you looking for that you could not easily find?"

• "If you were teaching this process to someone else, what would you explain differently?"

• "What would have made this experience smoother or more welcoming?"

How to Monitor Community Health Indicators

Good documentation should contribute to overall community sustainability and member satisfaction. Signs that documentation is working:

• Fewer repetitive questions in community channels.

• Higher volunteer retention and satisfaction scores.

• Faster integration of new members into community activities.

• More consistent execution of events and programs.

• Reduced administrative burden on community organizers.

How to Maintain Documentation as Your Community Evolves

Documentation requires ongoing attention to remain useful as your community grows and changes.

How to Schedule Regular Review Cycles

Establish predictable times for updating and improving your documentation:

• Monthly reviews of frequently-used resources like onboarding materials.

• Quarterly comprehensive reviews following major events or program cycles.

• Annual documentation audits to remove outdated information and improve organization.

• Immediate updates when processes change or new information becomes available.

How to Create Systems for Community Input

Make it easy for community members to suggest improvements and contribute updates. Simple contribution methods:

• Feedback forms or shared documents for quick suggestions.

• Regular "documentation improvement" sessions during community meetings.

• Recognition programs for members who contribute helpful updates.

• Clear guidelines explaining how community members can suggest or make changes.

How to Build Documentation Updates into Regular Workflows

Instead of treating documentation as separate work, integrate updates into existing community management processes:

• Include documentation reviews in event planning checklists.

• Assign specific documentation responsibilities to team members.

• Make documentation accuracy part of program evaluation processes.

• Train multiple people to update and maintain critical resources.

How to Create a Culture of Clear Communication

The most effective community documentation happens when your entire team values clarity and considers member experience in every decision.

How to Model Excellent Communication Practices

As a community leader, your communication style influences how everyone else approaches sharing information. Ways to model good documentation habits:

• Always include context when making announcements or giving instructions.

• Follow up on frequently asked questions with documentation improvements.

• Acknowledge and appreciate team members who create helpful resources.

• Treat documentation work as valuable community contribution, not administrative overhead.

How to Integrate Clarity into Decision-Making

Make "Will this be clear to community members?" a standard question in your planning processes. Consider documentation impact when:

• Launching new programs or changing existing procedures.

• Planning events or community initiatives.

• Onboarding new team members or volunteers.

• Responding to community feedback and implementing improvements.

How to Recognize Clear Communication

When community members create helpful resources, explain things well, or improve existing documentation, make sure their contribution is acknowledged and valued. This recognition encourages others to consider community accessibility and take ownership of shared information resources.

Conclusion

Effective community documentation is not about perfect writing or exhaustive detail. It is about understanding what your community members need and creating clear paths for them to succeed.

You've learned how to organize information around member goals, write instructions that prevent confusion, and build systems that keep documentation relevant as your community grows. Most importantly, you've discovered how to promote a culture where clear communication is valued and community accessibility becomes everyone's responsibility.

Remember, this key principle: good community documentation is measured by member success and community health, not by volume or technical perfection. When new members can easily find ways to get involved, volunteers feel confident in their roles, and your community operates smoothly without requiring constant intervention, your documentation is fulfilling its purpose.

Start with one small improvement. Choose a process that generates frequent questions, apply these techniques, and observe the impact on your community's experience. Each improvement is a step toward building a truly sustainable, welcoming tech community where everyone can contribute effectively.

You can also connect with me on LinkedIn, X (Twitter) and Medium. If you made it to the end of this tutorial, thanks for reading!

But I made one major miscalculation.

I underestimated people's desire to earn certifications within less than a year of study.

With our old curriculum, you could earn your first cert in as little as 300 hours of coursework.

With our new curriculum, it takes around 1,800 hours of coursework to earn the Full Stack Developer capstone cert.

The result is that a ton of people are still choosing to study our outdated legacy cert coursework, rather than studying our new and vastly-improved full stack coursework.

I'm kind of embarrassed that it took me months to understand this.

And to be clear, there are a few other reasons that not everybody has moved over to our new full stack curriculum:

1. The curriculum is still in beta.

2. The Back End JavaScript coursework isn't live yet.

3. Our exam environment isn't live yet. So you can't sit for exams yet.

The good news is that the freeCodeCamp community is working hard to finish these three items.

We're steadily shipping the remaining coursework and finishing our exam environment. And we're hoping to get the new curriculum out of beta as early as summer.

Still, this won't address the problem I mentioned at the beginning: it takes way longer to earn the full stack cert than it takes to earn our old certs.

Well I'm happy to say we've found a solution for that.

Introducing 6 Additional, More Granular Certifications

As you may remember, for the first 9 years of freeCodeCamp's existence, we had tons of shorter certs: Responsive Web Design, Front End Libraries, Relational Databases and more.

We're going back to this model by breaking the Full Stack Development curriculum down into a series of smaller certs. You can earn these new certs along the way as you progress toward earning our Certified Full Stack Developer capstone cert.

Here's the full list of certs you'll be able to earn along the way:

1. Responsive Web Design

2. JavaScript Algorithms and Data Structures

3. Front End Libraries

4. Python Programming

5. Relational Databases

6. Back End Development and APIs

The full progression will look something like this:

Each of these certs will require you to build certification projects and sit for an exam. They'll each involve around 300 hours of coursework, like our old legacy certs did.

The main difference: as you earn these certs, you'll progress toward earning our capstone cert: the Certified Full Stack Developer certification.

The finished curriculum will look something like this:

We're working to finish our exam environment so that you can sit for exams and earn our new Responsive Web Design cert and JavaScript cert as early as Halloween.

We'll release subsequent certs as we finish them, with the goal of having all six of these new certs live by summer.

So in conclusion: I underestimated people's desire for smaller, more specific certs that they could put on their résumé, CV, personal website, and LinkedIn.

I'm working hard with the freeCodeCamp community to get these new certs live and out of beta as quickly as we can.

As has always been the case, these will be FREE verified certifications with verification links and QR codes, that will live on freeCodeCamp's servers forever.

Over the past 11 years, people have earned more than 300,000 of these certifications. These represent millions of hours of learning by the global developer community.

I'm proud of our certification program, the rigor it communicates to employers, and the access it extends to anyone willing to put in the time and effort to learn.

These certs will remain a central part of our community and our mission.

FAQ

So instead of earning just one cert for completing the full stack cert curriculum, I'll earn 7?

That's correct. There will be 6 300-hour blocks of coursework (like with the old curriculum), each with their own projects and exam. After all this, you'll build a final capstone project and sit for a comprehensive final exam.

What will happen to the legacy versions of these certs?

They'll eventually expire and you'll want to earn the new version. The soonest they will expire will be 2028, and we may push that date back a bit to ensure people have time to earn the updated version of these certs.

What if I already earned a legacy version of one of these certs?

Great. You've probably learned most of the concepts that you need to earn the updated version. You'll just need to build the required final projects for that cert and sit for the exam. Then you can earn the updated cert.

Tell me about the exam environment

It's a desktop app you can use to securely take the exam for each certification. Instead of needing to go to a testing center, you can take exams at your convenience.

Our app strikes a balance between respecting people's privacy while also flagging for human review anyone who may be cheating.

Are there any other changes to the plans for the full stack cert that you haven't talked about here?

No. We're still proceeding with everything I talked about in my Christmas community update. We're making steady forward progress. The freeCodeCamp open source community is more locked-in and more productive than ever.

When should I switch from the legacy cert curriculum to the new full stack curriculum?

Immediately. If you start now, you can be one of the first people to sit for the Responsive Web Design and JavaScript Algorithms and Data Structures exams once they go live.

Again, the new coursework is WAY better than the old coursework. It's more granular, more interactive, and includes more theory and more practice.

So the only change is that you're adding these new certifications along the Certified Full Stack Developer path?

That's right.

Cool. Don't you usually sign off with your catch phrase? Say the line, Bart.

Happy coding.

In this article, we’ll discuss some common misconceptions that might be holding you back from contributing to open source. I’ll show you what you’re missing out on, and give you some advice to help you begin.

Table of Contents

1. What is Open Source?

2. Key Factors Influencing Open Source Contributions

3. Why People Hesitate to Contribute

   • You feel like an impostor

   • You have to do it for free

   • You have a busy schedule

4. Start Contributing to Open Source Today

What is Open Source?

Open source refers to software that has its code publicly available for viewing, modification, and use. The code is usually hosted on platforms like GitHub where developers can contribute to the codebase and share their expertise with the project.

Although open source software code is publicly accessible, it doesn’t mean that the software has to be free. Creators of the software can make money by charging a fee for things like optional plugins, consultation about the software, and so on.

Nginx is an example of open source software that charges a fee for additional but optional plugins. NestJS is open source too, but has an official paid course (and its maintainers charge a consultation fee for more complex uses of the software).

Key Factors Influencing Open Source Contributions

In 2023, roughly 10% of Alphabet’s full-time workforce actively contributed to open source projects. And according to GitHub’s 2024 Open Source Survey, respondents reported that the top five factors that influenced their contribution to open source projects, in order of importance, were:

• Whether the project had an open source license or not. Having an open source license was considered favourable.

• The responsiveness of the project’s maintainers. Fast and positive responses are encouraging.

• A welcoming community, indicating support from the maintainers and others contributing to the project.

• The level of activity on the project – lots of activity signifies an actively maintained project (which is more rewarding and useful to work on).

• Whether the project had a contribution guide that helps developers ease into contributing to the project.

But even though many projects are attractive, and their maintainers are welcoming, some people still hesitate to contribute for reasons not linked to the projects themselves.

Why People Hesitate to Contribute

After looking into responses from various discussions, I found that there are three primary barriers developers face when they’re considering contributing to open source:

• You feel like an impostor

• You have to do it for free

• You have a busy schedule

The rest of this article will address (and hopefully break down) these barriers. I hope that by the end, you’ll be encouraged to contribute to open source.

You feel like an impostor

Many people think that you have to know a lot about a project to work on it, but this misconception is one of the biggest barriers that holds developers back from contributing to open source. Some people say to themselves “I don't have the experience”, “I have nothing to contribute”, “What if I break something?”, “I don’t know enough”.

Here’s some advice from How to Overcome Imposter Syndrome that can help:

• Stop obsessing over not being good enough. It’s unproductive.

• Everyone excels at different things. You likely excel at some things that others don’t.

• Don’t compare yourself with others who are more experienced than you. In fact, stop comparing yourself with anyone else. You are unique.

Try to contribute to projects that you have used. You already understand them better than projects that you haven’t used. As a beginner, working on issues labeled “good first issue”, “up-for-grabs”, “beginner-friendly” and so on is a great place to start. If you find an issue that interests you, read the discussions under it if there are any so you can understand it better. State that you are interested in working on it and an experienced contributor will likely respond to let you know if you can proceed. They can also provide you with more information if you need it.

Put in the work to resolve it yourself first, and if you have any issues, then you can ask more questions. When you try to resolve it yourself before asking questions, it tells maintainers that you have put in the effort and they will be more willing to help. It also makes your question(s) sound thoughtful and direct.

“The three most powerful motives are curiosity, delight, and the desire to do something impressive. “

— How to Do Great Work by Paul Graham

I shared my experience in an article titled You Don't Need to Know It All to Contribute where I found out that the author of a popular JavaScript project was not the one that wrote the TypeScript part of the project and he was happy to receive my contribution.

If you still feel like you are not good enough, try to look at it as an opportunity to learn from a codebase built by developers with a wide range of experiences and expertise. If you dive into the code and try to improve it, you’ll learn things that you won’t find in online tutorials and blog posts.

Just keep in mind that you don’t always have to contribute code. Even though the majority of contributions are usually code-based, there are other areas that need attention, too, and are often overlooked. What happens if the documentation is nonexistent or outdated? What happens when issues aren’t triaged? You can help with these issues by:

• Discussing them with project maintainers and other contributors to clarify and improve docs and other resources

• Giving feedback on pull requests

• Adding labels for organising issues into proper categories

By doing this, you provide value to these projects. What matters is your interest in solving problems and your ability to do the required research.

You have to do it for free

Another misconception is that devs always do open source without getting paid. But this isn't true for all cases. Some open source repositories reward contributors via bounties, for example. With bounties, prize money is placed on an an issue and whoever solves it gets the prize money or reward. I earned money through this via my first contribution to Remotion.

And there are other benefits of contributing to open source projects aside from getting paid. And often, people contribute primarily for these other reasons.

For example, for beginner developers, there aren’t many opportunities to get hands-on experience building “real” projects, or to learn what working on a tech team is really like.

But by contributing to an open source project and becoming part of that community, you get to practice teamwork, contribute to code that’s constantly changing and growing, and solve real-life problems. This gives you valuable experience that’ll help prepare you for the workforce (and that you can put on your résumé). The image below is a screenshot of two people who received a scholarship from the Linux Foundation for their contributions to open source.

So as you can see, even if you don’t get monetary rewards, contributing to open source presents many other opportunities. You get to:

• Work with people from diverse cultures

• Develop clear written technical communication skills

• Improve your knowledge of various tools/frameworks

• Prove yourself to be a self-motivated developer

• Work asynchronously with people across multiple time zones

You also get the opportunity to network with other developers and grow your reputation and credibility in the software development space. Prosper Otemuyiwa and Anthony Fu are great examples and beneficiaries of this type of career growth.

You have a busy schedule

Having other pressing commitments is a reasonable barrier to contributing to open source. We’re all human, and our resources (time and energy) are limited – so we have to manage them judiciously.

But have you considered what would happen if the open source project that you use had a serious bug that affects your performance or deliverables at work? What happens when the problem you are trying to solve at work requires expert knowledge of that open source project that you heavily depend on?

Contributing to open source projects in the little ways that you can will give you insight into how the projects work. Since you have to maintain a rapport with other developers on the project, you’ll form a professional bond with them and they’ll be glad to help you out if you have questions or require expert opinions on the project. If you are a major contributor, you may have the chance to influence the project’s roadmap.

Continuing to develop your skills is paramount to you as a developer. If you can make time to improve your skills, then you can make time to contribute to open source because it offers more rewards than just skill improvement. You can start small – try dedicating, for example, one hour a week before work, or a couple hours on the weekend. Then you can ramp up once you get into the rhythm and find more time. Contributing to open source doesn’t have to be overly demanding.

You’re already solving problems. Why not solve them in a visible way that helps others and builds your own credibility?

Start Contributing to Open Source Today

We all should contribute to open source one way or another. If you feel that you don’t know enough, just keep in mind that other people feel (or felt, before starting) the same way. And know that nobody can claim to know it all – not even the founder of the project. So don’t let the feeling of impostor syndrome hold you back.

Remember also that Rome was not built in a day. It wasn’t also built by one person’s hand – but by countless laborers over many centuries and millennia. You could be part of building the next great open source project (or helping maintain the many great ones that are already out there and need your help).

So consider contributing today by visiting the issues tab of any of the open source projects that you use extensively and pick up something. You can find links to beginner-level issues from the following websites:

• Good First Issue

• Up For Grabs

• CodeTriage

• OnlyDust

If you see an issue that you are interested in, take the following steps as a new contributor:

• Look for a CONTRIBUTING.md file and read it for guidance on how to contribute

• Clone the repository and set it up locally

• State your intention to work on the issue by making a comment on the issue

Ask a question if an issue is unclear to you and you’ll get guidance.

Good luck on your open source journey!

Governance sounds serious. But at its core, it simply means: how do we make decisions, and who gets to make them? It doesn’t matter if you're working on a project at the grassroots level with a few maintainers or a mature open-source ecosystem – the guiding procedures influence how people contribute, manage issues, and develop into leaders.

And, like with anything in open source – if it isn't documented, it may as well not exist.

In this article, I'll explain why governance documentation is important, what to include, and how to document governing procedures that are useful, clear, and human.

Table of Contents

• Why Governance Matters (and Why You Should Document It)

• What your Governance Documentation Should Have

• Make Governing Documentation Clear and Welcoming

• How to Start Documenting Governing Procedures for Your Open Source Community

Why Governance Matters (and Why You Should Document It)

Every open-source community already has some kind of governance (even if it’s not written down). Sometimes it’s a single maintainer making all decisions. Sometimes it’s a small group of people “just knowing what’s best.” The danger here is not the structure itself but the lack of clarity around it.

When governing procedures aren’t documented:

• New contributors might be confused about how to get involved

• Decisions appear arbitrary or biased

• Power dynamics become invisible

• Conflict becomes harder to manage or resolve fairly

Documenting governance promotes trust, transparency, and predictability. It does not imply confining contributors to rigid rules – rather, it offers your community a common understanding of how things work and how they may change.

What Your Governance Documentation Should Have

You don’t need to start governance documentation from scratch. You probably already have fragments of governance in your README, CONTRIBUTING.md, or pinned messages in your community’s messaging platform. The goal is to bring them together into something clear, navigable, and contributor-friendly.

Think of your governance documentation as a map. It should help contributors understand where they are, how things work, and what paths they can take, including:

1. Mission and Values: Why does this project exist? What principles guide how decisions are made or prioritised? This can set the tone for governance and invite collaboration.

   

2. Roles and Responsibilities: Who are the maintainers? What can contributors, reviewers, and core team members do? Who can open pull requests? Review them? Approve proposals? Define expectations and boundaries clearly.

3. Decision-Making Process: How are technical decisions made? By consensus? By voting? Is there a lead maintainer with the final say? What types of decisions require community input? How are disputes resolved?

4. Conflict Resolution: What happens if people disagree? Is there a process to escalate issues respectfully?

5. Proposal Process: How are changes proposed and discussed? Do you use an RFC system, GitHub discussions, or something else? What’s the typical timeline for review or feedback?

6. Leadership Changes: How are new maintainers added? How can someone step down or be removed?

7. Amending Governance: How can the governing procedure itself and its documentation be changed? Who has the authority to do so?

8. Contributing Guidelines: How can contributors get started? How can they submit a pull request? What does review and approval look like? Is there a contributor ladder? What happens after someone contributes regularly? Make it easy for everyone to get around the overall contributor experience

   

9. Code of Conduct (linked or embedded): Governance and conduct are deeply connected. One shapes the culture, while the other protects it.

Make Governing Documentation Clear and Welcoming

Governance documentation doesn’t have to read like legal policy. In fact, it shouldn’t. A clear, welcoming tone helps readers feel included, especially newcomers or contributors from under-represented groups.

The tone you use in your governance docs will shape how people feel about your community. It can either feel like a locked gate or a clear, friendly path forward. Here’s how to keep them human:

• Use plain, clear language. Avoid overly complex terms, and explain acronyms if needed.

• Be specific. “You must be in the Discord server to vote” is better than “participation is required.”

• Keep it short and easy to read. Use lists, headings, and bullet points.

• Explain the “why.” Give more context. People are more likely to trust rules when they understand why they exist.

• Use examples or scenarios. For example, “when two maintainers disagree on a technical direction...”

• Make it feel open. Invite contributors to ask questions or suggest changes, including to governing procedures. That alone can help your community evolve with less friction.

How to Start Documenting Governing Procedures for Your Open Source Community

I’ve helped document governance in projects where things had been informal for years. The hardest part? Starting. There’s always a fear of overstepping or “making it too official.”

But writing things down doesn’t have to mean locking them in stone. In fact, the best governance docs are living documents, created with the community, reviewed regularly, and updated as the project grows.

Some lessons I’ve learnt:

• Start small. Even a bulleted list in a README is better than nothing.

• Use your community’s questions as your guide. If people keep asking, “how do I become a maintainer?” write that down.

• Let people review and comment. Co-create – don’t just impose.

If you’re not sure where to begin, look to open-source projects that have done this well. For example, Kubernetes has a well-structured governance model documented in its community repository, outlining everything from roles to decision-making processes.

The Tor Project also maintains transparent and community-driven governance documentation (a project I had the opportunity to contribute to) that defines roles, responsibilities, and decision-making pathways that are communicated to contributors all over the world.

Conclusion

Documenting governance doesn’t have to be scary. It’s just about making the invisible visible and doing it in a way that invites people in. When you write down how things work, you make space for others to contribute confidently, understand the community they’re joining, and grow within it. That’s what governance should be about.

So if your project doesn’t have its governing principles documented yet, don’t wait for it to get “big enough.” Start now, start small, and let it evolve with your community.

And remember: governance isn’t about control. It’s about clarity.

I didn't know it at the time, but fCC would quickly grow into a global community of busy adults learning to code together.

Many of these campers – as we now call ourselves – have gotten jobs as software engineers. And many campers have also contributed code to fCC's open source codebase.

Over the past 10 years, we've built:

1. An interactive 3,000-hour core curriculum that teaches Math, Programming, and Computer Science

2. A library of more than 12,000 programming tutorials – and dozens of full-length books – on our publication, freecodecamp.org/news

3. A YouTube channel with more than 1,000 free full-length courses. We just hit 10 million subscribers a few days ago.

4. The kindest, most supportive programming forum on the planet. And we have a similarly kind Discord server, too.

The team has grown from just me to a staff of 35 teachers and engineers. And this is just the tip of the iceberg. A huge chunk of the work is done by the open source community itself. Every day, volunteers step forward to improve our codebase, create new open learning resources, and help one another on the forum.

And we're just getting started. So rather than a sentimental write-up about the first 10 years of freeCodeCamp, we're going to focus instead on our plans for the next 10 years ahead of us.

After all, our charity's mission is to create free learning resources that help folks learn math, programming, and computer science. And there's still so much work left to be done.

In this article, I'll lay out our major initiatives for the next decade. And I'll show you some big improvements – a few of which are coming in time for Christmas.

One Certification to Rule Them All

The biggest improvement is we're combining most of our current curriculum into a single comprehensive Certified Full Stack Developer (CFSD) certification. And we're developing several new similarly comprehensive certifications from scratch.

We've sought inspiration from established developer certification nonprofits like CompTIA and (ISC)². We're overhauling our certifications to more closely resemble established industry certs.

Our new certifications will:

• Be even more comprehensive

• Involve a final exam

• Involve a capstone project

• And be valid for 3 years, with a path to renewal

And as with everything freeCodeCamp creates, these certifications will remain completely free.

The Certified Full Stack Developer certification prep curriculum will cover:

• Semantic HTML

• Accessibility

• CSS Fundamentals

• CSS Flexbox

• Design for Developers

• Typography

• Code Editors

• JavaScript Fundamentals

• Functional Programming

• Higher Order Functions and Callbacks

• DOM Manipulation and events

• Web Standards

• React Fundamentals

• TypeScript Fundamentals

• Testing Concepts

• Bash Scripting

• SQL and Relational Databases

• Git & GitHub

• Security and Privacy

• Node.js

• Express.js

• Python Fundamentals

• Algorithmic Thinking

• Data Structures

• Object Oriented Programming

• Dynamic Programming

• Security for Web Developers

• Tooling and Deployment

• Working with APIs

• AI Engineering Fundamentals

• How to Get a Developer Job

• and more

And by popular request, we're going to cover a lot more theory – right in the core curriculum.

Previously, our certs were 100% focused on building projects. We've received a lot of feedback from campers that we've swung too far in the direction of "learning by doing", and that many campers desire more explanation of theory as well.

That's right – you'll no longer have to supplement the core freeCodeCamp curriculum with theory videos from our YouTube or books from our publication. Going forward, we'll cover all the essential theory along the way.

We're doing this by adding short video lectures taught by freeCodeCamp's instructional design team, including Beau Carnes and Ania Kubów. Each of these will also have a full transcript, for campers who prefer reading over watching.

We're also adding lots of quizzes so you can review theory and double-check your comprehension. These – along with our built-in Spaced Repetition system – should dramatically improve your retention of key concepts and coding techniques.

And we'll drop you into the "blank canvas" style coding labs much earlier into the curriculum, to minimize hand-holding.

Here's the full contents of the new Certified Full Stack Developer path. It's a doozy:

• 64 Workshops – Interactive step-by-step coding courses on tools ranging from HTML to SQL to Python

• 513 Lectures – Short videos covering computer science concepts, with multiple choice questions to check your comprehension

• 83 Labs – Projects where you start with a blank editor and a test suite, and have to build your project so that all the tests pass

• 62 Review Pages – Comprehensive lists of topics from each module that you can review to help you prepare for quizzes and exams

• 66 Quizzes and 6 Prep Exams – To affirm your grasp of full stack development concepts and tools

• 1 Capstone Project – a large, unique project that you'll build for your portfolio, reviewed by teachers within the freeCodeCamp community

• 1 Final Exam – a comprehensive proctored 90-question certification exam taken within freeCodeCamp's exam environment

After you've completed all this course work, you'll qualify to sit for a final exam. We've built our own open source Exam Environment where you can take an in-depth exam on everything you've learned throughout all our prep work.

If you don't pass the exam, you'll be able to retake it once every 24 hours until you manage to pass it. Each time, the exam will be randomly generated from a massive corpus of exam questions.

You may have heard horror stories about people who take online exams who are falsely accused of cheating. We've put a ton of thought into how we're going to enforce our academic code of conduct. There will always be a human in the loop for these decisions.

There will be no automatic "you got up from your chair because your baby started crying" disqualifications. We will take all these things into consideration as we administer these exams.

And once you've passed, you'll earn a free verified, serialized certification that you can add to your Résumé or CV, and embed in your LinkedIn account. It will remain valid for 3 years – at which point you can complete a free continuing education process to re-certify.

Here's a 5 minute video that will walk you through some of the big updates to freeCodeCamp's curriculum.

We're Developing Three Other Certifications as Well

Once the new Certified Full Stack Developer certification is live, our instructional design team will turn our attention to building three additional certifications:

The Certified Machine Learning Engineer Certification (fCC-CMLE)

This certification will involve learning Python and its many libraries. You'll also learn a tremendous amount of math and theory. Many of the projects will involve creating your own models. Kylie Ying is already working with machine learning engineers to help design this. We're planning to ship some of this in 2025.

The Certified Software Systems Engineer Certification (fCC-CSSE)

This certification will involve lower-level programming and high performance computing. You'll learn how to program in C and C++, and build a number of projects – such as your own compiler and your own search engine. We're planning to ship some of this in 2026.

The Certified Data Scientist Certification (fCC-CDS)

We've been working on a comprehensive Data Science curriculum for several years. As you may know, freeCodeCamp already has many popular courses on Data Science tools like Python, R, and statistical suites on the freeCodeCamp community YouTube channel.

The challenge with teaching Data Science is teaching the vast amount of math involved in the field. We also need to assemble project-oriented learning that we can grade programmatically.

Our goal is to offer the best Data Science education available outside of a PhD program. This is going to be the biggest challenge of all. But we're up for it.

We're planning to ship some of this in 2027.

When will we have more information about these certifications and their coursework?

We're working on comprehensive curriculum outlines for these, and we plan to make some of them public in 2025.

What will happen to the current freeCodeCamp certifications?

freeCodeCamp has a long tradition of preserving old coursework from legacy certs. This time is no different.

We encourage you to switch over to the new Certified Full Stack Developer cert curriculum once it goes live this Christmas. You may have already completed some of the projects, since many of them come from our old certs.

This said, if you're half way through an old cert and want to continue your progress there, you can.

Will legacy certifications expire?

Yes. All of these legacy certs will expire on December 31, 2027. This also includes all freeCodeCamp certs people have earned in the past.

We wanted to give everyone plenty of time to use their current certs before they needed to earn the new Certified Full Stack Developer Certification. And we think 3 years is enough.

We've added this expiration date to all freeCodeCamp certifications.

Going forward, whenever you earn the Certified Full Stack Developer cert or the other 3 upcoming certs, it will remain valid for 3 years from the date you earned it.

Again, we're developing a continuing education program that you'll be able to use three years later to renew your certification. And again, all of this will be completely free.

Why is freeCodeCamp requiring exams and adding expiration dates to certifications?

We're doing this to bring these certifications more in line with other tech industry certifications. All of these major certifications require passing a certification exam, and expire after 3 years.

Our goal is for freeCodeCamp's certifications to be as conventional as possible, to make it easier for employers to understand them.

Will freeCodeCamp branch out into recruiting or job placement?

We have no plans of doing this. Our charity's mission is simple: to create free learning resources. We plan to keep our team of teachers small and focused, rather than bringing in a bunch of non-teachers.

How much of the coursework will overlap from one certification to another?

Some of the certifications will share a few common projects and lectures. For example, if you've already completed the intro to Python coursework during the Certified Full Stack Developer cert, you won't need to recomplete all this for the Certified Machine Learning Engineer cert.

Will my old certs remain online? Will the verification links continue to work?

Expired certs will still show up on your profile, and direct links to them will still continue to function. They'll be clearly marked as "Expired [date]" until you renew them. Again, this will not happen to any fCC certs until December 31, 2027 at the earliest.

What will happen to the 11 certifications currently listed on freecodecamp.org/learn?

They will continue to be available there for at least a few more years – listed as legacy certifications. Most of the coursework inside them will be repurposed and improved to serve as part of these new certifications.

Will I have to re-do projects that I've already done?

Some of the coursework in the old certifications will remain in these new certifications. And in most cases, you shouldn't have to redo projects you've already done. If you've already built some projects, there's a good chance that some of sections of the new certifications will already be marked as complete for you when you browse them.

What about teaching programming languages like Rust and Java, or NoSQL database tools?

We're keeping our core curriculum focused on the most popular tools to help put campers in the best place to work as developers. This means Python, JavaScript, SQL, and tools like Git and Linux.

We have tons of video courses on other popular tools on the freeCodeCamp community YouTube channel, as well as tutorials on the freeCodeCamp publication. We'll continue to teach these as extra-curricular topics for anyone who wants to learn them.

How is the English Curriculum coming along?

We've been working hard to create an interactive English curriculum to help campers improve their English.

We teach through a combination of videos and interactive exercises, followed by a formal certification exam.

We're currently finishing Level A2, and starting work on level B1.

How is the free University Degree Program coming along?

We're making steady progress toward offering an Associate of Mathematics degree and a Bachelor of Computer Science degree. We have already developed 2 of the math courses, and are hard at work on the remaining 38 university-level courses and their lectures, labs, and exams.

freeCodeCamp has a small team of instructional designers, and right now we're mostly focused on the Certified Full Stack Developer cert coursework and the English cert program. Once we finish these, we'll allocate more resources toward the degree programs to further accelerate their development.

10 Years is Nothing.

It’s amazing how much we’ve accomplished as a community in just 10 years.

• A free curriculum of 3,000 hours of interactive learning resources

• 1,000s of extra-curricular video courses, books, and tutorials

• 10,000s of campers who’ve gotten jobs as developers

• 10,000s of contributors who are getting experience by volunteering their time and talents through open source and through helping fellow campers

And we’re just getting started.

I encourage you to get involved in the global freeCodeCamp community. You can browse our 2024 Top Open Source Contributors. Here’s our contributor guide if you want to dive in.

I also encourage you to become a supporter. And if you're already supporting us each month, and want to make a year-end gift to our charity, by all means. Here are some tax-deductible ways you can support our mission.

And if you have any questions about ways you can support our charity's mission, or just need a donation receipt for your taxes, please email me directly: quincy@freecodecamp.org

Here’s to the next 10 years.

– Quincy

Over the past 12 months, the freeCodeCamp community has:

• Merged 2,455 code contributions into our open source repositories on GitHub

• Published 193 free, full-length courses on YouTube

• Published 850 text-based coding tutorials and 5 free books through freeCodeCamp Press

• Translated more than 1.5 million words from English, to make our curriculum and tutorials more accessible to speakers of many world languages

I'm so grateful for the kind folks who’ve volunteered this year. We’ve made substantial progress in several dimensions.

Here's our full list of top contributors, broken out by category of contribution.

GitHub Top Contributors

• Anna

• Lasse Jørgensen

• Supravisor

• Gagan Bhullar

• Krzysztof G.

• Duong The Pham

• Re1nGer

• RGHANILOO

• Manabu Matsumoto

• Nitish sharma

• Roy John Lee

• James

• zxc-w

• jnahan

• Yixuan Dai

• Giovanni Ruberto

• Moshe

• Alagu Muthiah

• Alan Luo

• Orest Sonich

• Anne Deepa Prasanna

• Andrew M. Yturaldi

• Sanskriti

• Srikanth Kandi

• Pedro Ramos

• Jose Bhrayn Colina

• Korada Shanmukh Sai

• Vijaychandra Govindapalle

• Lawrence Li

• Hein Htet

• Sulaiman

• Jeremy L Thompson

• Ritesh S Hiremath

• William Spanfelner

• Josh

• Deep Dhanuka

• Abhinav Kumar

• Mikey Esteban

• Jr Cenina

• Sushil Gupta

• jayanth920

• Louiza Mak

• CracktheDom

• Lalith Kanakamedala

• Kevin

• Sanjeev Murmu

• Akshat Tripathi

• dwrik

• Michael Ehme

• Patrick Wauschek

• André Barreira Dinis

• Lucas Gracia

• Chiara

• Vaibhav-Ace

• cheenu-1824

• Vicky Fernandez Busch

• Jiantao (Felix)

• Govardhan

• Steven Primeaux

• JeevaRamanathan

• Lalithkumarponnambalam

• Hammadh

• Arnav

• Anugrah

• Prajvala R C

• Shiva Sai Krishna Gadeela

• developwithabhinav

• ITS MAC

• Mayank Kamboj

• Nate Ben

• Israel Lopez

• Joz-Bruer Quince

• Sahil Chauhan

• Tobias Sirianni Melo

• Soham Tembhurne

• mccarreon

• Anikait Prasar

• Edwin Hung

• Mikhail Wahib

• Yatrik Patel

• Pramod Lumb

• Shivam Gupta

• Clarence Bakosi

• Joel Olawanle

• Yeldar Kudaibergenov

• Axel Soubielle Almada

• Kashinath Patkar

• Oleksandr Tkachenko

• v-i-k-a-s

• Faisal Arshed

• Usama Basharat

• budblack

Forum Top Contributors

• Hanaa B.

• Teller

• Jeremy

• Stephen Mutheu

• Lasse

• pkdvalis

• Hassan Zaib

• CODY BIGGS

• Bruce B

• Doug Badger

• DanielHuebschmann

• Ariel Leslie

• Zuhaira Ameer

• Anna

• Raymond

• sanity

• Toan

• Opudo Prince

• Vladimir Jovanović

• Infinity

• HungryBee

• a b

• Robert H.

• MostafaElbadry

• GrannyIsA-Dreamer

• Arakhsh Qanit

• ios-man

• Marcus Parsons

• Alan Bradnum

• Mohamed Amine (Mike)

• A1legalfreelance

• Daniel Bailey

• Jyothsna Lakshminarayanan

• Albert Kucz

• SanyiDiriba

• William Miller Jr

• Aldrin Sean Pereira

• SpookyBlump

• Luis Costantin

• Tahsin Önemli

• Carlos Bernad

• Madhav Mohan

• Christ-yvan KEMAJOU

• Aaron P Laju

• Kevin Smith

• Alabastor

• Answer

• ⛤Cherry-27⛤

• M

• ablairmorris

• Francisco Ecatl Melo Valle

• Anthony Bryson Jr.

• Tom M

• Alex

• Ibrahim Aq

• Andrey D

• mailforworkon

• AbbyGTech

• Opeyemi Richard

• Stroudy91

• Mike

• Tadesse Agegnehu

• Samuel Diriba

• Cryptic

• Easside MJ. Kamara

• KoduFCC

• shy_away

• Sebastian Włodarczyk

• Kesa Elizabeth Stallman

• Kyle O'Leary

• 💜💜purpleglow🌟🌟

• mohamed elmir

• Kai G

• jpccdirect

• Luca Tardito

• Logan Drake Cody

• Millie Bowers

• MilesWeb

• suleman khalil

• ghulamshabirbaloch

• Diego

• Maestro Goldring

Translation Top Contributors

• Afonso Branco

• rustamdocstranslator

• Madlen

• Alan Luo

• LisaGo

• majidah

• Karel Vanhelden

• SeunghyunKim

• Nadja Sellinat

• Kevin Matthew

• Siyana Zdravkova

• Ricardo Cuauro

• Liu dakang

• Álvaro Dávila

• Ira Bohach

• Laureline

• Nils Goeke

• ViktoriaKushnir0-

• ピンク人

• sohyun

• kimploo

• franciscomelov

• Andriana Cabrera

• Kostiantyn Melnyk

• athen

• JulianLobonAguilar

• moonki kim

• Suzie

• Kasia

• mamaruo

• VL

• Solomiia Karpachova

• Diana Kolosovska (Діана Колосовська)

• steven ding

• Elias Pereyra

• nin3lee

• Juanma

• Naelko

• Álvaro Dávila

• Tamiris

• Devan

• Leslie Suh

• Dario

• mix bo

• Eduardo Lima

• isaura-ribeiro

• nighttheduck

• Caroline Andrade

• salvatore luciano

• Nikolai

• Frankline Were

• Mikadifo

• MaxiNZ

• SleepyGogo

• Brendo Arruda

• rkang13

• TikaZ

• shaudvetis

• Minh Tuấn Nguyễn

• wdthor

• BeGeosDev

• Kristian Pavic

• Dalton Cuenca

• jonathanq

• Erick

• Sreya Satheesh

• Freddy R

• Wilmer Gulcochía Sánchez

• Shannon

• André Garcia

• Saikrishna Anumula

• Sharvio

• David Gómez Redondo

• Jimmy Yem

• Lucy Macartney

• vLeov

• Sunce

• 1615_P._Enrique

• Ener Octavio Buitrago Camelo

• ProjektMing

• nrached

• Camila

• Maria Luz Davico

• EricF

• Bobby M

• lime

• irabucha

• Filippo Crespi

• MrTL3

• Li Chuan (李川)

• Rodrigo Lajas

• Jarvis Hack

• invoker

• claudiomavi

• Kato Tsune (加藤恒)

• yk1537

• Jose Zambrano

• Takkapi

• BlackAndRed.eth

• leopard355

• DariaShu

• Daniel R. da Silva

• Adham Muhammadjonov

• Davi Stadlinger

• w w

• KenGan

• cezin17

• Dylan Gabriel Diroché

• luluhwenceslau

• Chinchu Ori

• albasantalo

• Dira R P

• William Hincapié

• aldid95

• Fran Martinez

• Yao990815

• Miracle

• Julian Andres Lasso Figueroa

• pame.gon

• watanaki

• Faisal Hanafi

• Jiwon

• Abo_AbdelSalam

• Vé

• Lu Mu (辂木)

• martinvostatek

• Patrick Hähnel

• Stanley S

• Alexia Javadd

• peperluiz

• Lina Guio

• adnen rebai

• Pasan Hewavitharana

• Monir Adam

• Adi Nugroho

• YumiClmpn

• Daniel Garcia Sanchez

• bugrahankaramollaoglu

• Hannibal_TN

• Ucky Deni Ulinnuha

• David Beyer

• Nicolás Folli

• IM Grigore

• Bill Gao

• Baris

• Simón San Juan Gallardo

• Eralpozcan

• Maria Fernanda Rios

• Tsukistar (月落星河)

• Tao

• Gabriel Kraemer

• mementog

• petyaDeveloper

• TrueJackWu

• Nicolvs

• Juan Diego Jaimes

• Cássio Barth

• Aekkapob Pangtan

• Sergitxin

• Bettina Neuwirth

• juanalbglz

• Marta Escriche

• adrianna

• pcaballero

• Nico Van Pletzen

• Rafael Quintero

• Ozat21

• Dinto

• orikes

• fanqie

• Kamil Kliczbor

• Francisco Mancuello

• Roberto Perez

• Luis Aguilar

• kersen

• miller-danilo

• castrovca

• ChristianMoya

• Felipe Navarro

• Felipe Hernández

• DongHyeon

• Denisse Lemos

• Meer Sajib

• AR Dhrubo

• Paola Rosati

• Andrea Sisti

• Charlotte Stone

• Saki Basken

• Yuki Shibata

• YUUSUKE OKAMOTO

• Constanza Areal

• Elias Ezequiel Pereyra Gomez

• Diego Lopez

• Cristian Fernando Villca Gutierrez

• Francisco Melo V.

• HeZean

• Mingxun Liu

• Tsukistar

• James Z. Zhang

• huqi

• JunoWei

• YiWei

• luojiyin

• herosql

• 李小宁

• Afonso Branco

• Kris Lagerström

• Filipe Barbosa

• David Esdras

• João Eduardo Gomes

• Luis Felipe L. C.

• Marcelo Pena

• Gabriel Balbueno

• Sabrina Alves

• Ana Laura Reis

• Isabel de Souza

YouTube Top Contributors

• Ramon Rodrigues

• Leosbel Poll Sotomayor

• David Ruiz

• Pedro Plasencia

• David Choi

• Sergie Code

• Leonardo Jose Castillo Lacruz

• Carpi Coder

• Jordan Alexander Cruz Garcia

• Luis Canary

• Abdul M

• Vyas Adithya

• AnthonyGG

• Ali Bouali

• Alen Omeri

• Matthew Hlazo

• Code Genix

• Amini

• Code Lab

• Haris Iftikhar

• Mukhtar Mukhtar

• Aba Codes

• Dauda Kolo

• Simpson Alfred

• Dan Vega

• Div Rhino

• Hayk Simonyan

• Hussein Nasser

• Dinesh Varyani

• Georgio Tunson

• Kerollos Magdy

• Krish Naik

• Ankita Kulkarni

• Patt Vira

• Umair Jameel

• Michael Minaca

• Utkarsh Seth

• Aleksa Robavs

• Bobby Roe

• Sangam Mukherjee

• Ramendu

• Steven Garcia

• Emilian Kasemi

• Deji Adesoga

• Wilson Mucheke

• Henry Ly

• Thomas Burns

• Ashokkumar Chavada

• Paulo Dichone

• Vlad Gheorghe

• Vuk Rosić

• Anthony Aragues

• Andrew Brown

• Zak Ali

• Burak Orkmez

• Ayush Singh

• Lane Wagner

• Code Bucks

• John Smilga

• Omar Zaki

• Nishant Singh

• Parth Vyas

• Dan Adams

• Elliot Arledge

• Haider Malik

• Hitesh Choudhary

• JSLegendDev

• Keerti Purswani

• Md Al Mamun

• Niklas Ziermann

• Dr. Radu Mariescu-Istodor

• Rohan from Self Made Data Scientist

• James McArthur

• Stein Helset

• Rex Jones

• Piyush Itankar

• Alaribe Bright

• Brijen Makwana

• Dr. Chuck

• Dr. Immanuel Trummer

• Dr. Lance Martin

• Fatos Morina

• Kshitij Sharma

• Tatev from LunarTech

• Tristan Willcox

• Zubin Pratap

News Top Contributors

• Joan Ayebola

• Sahil Mahapatra

• Manish Shivanandhan

• Matéu.sh

• Tiago Capelo Monteiro

• Vahe Aslanyan (YouTube channel)

• Oluwatobi

• David Jaja

• Tomer

• Kunal Nalawade

• Samyak Jain

• Nathan Sebhastian

• Alex Pliutau

• Oluwadamisi Samuel

• Ophy Boamah

• Reed

• Anjan Baradwaj

• Rajdeep Singh

• Timothy Olanrewaju

• David Clinton

• Md. Fahim Bin Amin

• Ankur Tyagi

• Ashutosh Krishna

• Ijeoma Igboagu

• Grant Riordan

• Elizabeth Lola

• Tapas Adhikary

• Anshul Sanghi

• Isaiah Clifford Opoku

• Destiny Erhabor

• Daniel Adetunji

• Hunor Márton Borbély

• Oyedele Tioluwani

• Fanny Nyayic

• Jakub T. Jankiewicz

• Daniel Kehoe

• Kamaldeen Lawal

• Jose Vicente Nunez

• Prankur Pandey

• Asfak Ahmed

• Obum

• Spruce Emmanuel

• Temitope Oyedele

• Marco Venturi

• Austin Asoluka

• Vikram Aruchamy

• Daniel Asaboro

• Eric Hu

• Victoria Burabari Poromon

• Anant Chowdhary

• Kealan Parr

• Oleh Romanyuk

• Okosa Leonard

• Fatuma Abdullahi

• San B

• Franklin Okolie

• Chris Blakely

• Niladri S. Jyoti

• Nikolaos Panagopoulos

• oghenekparobo Stephen

• Keyur Paralkar

• Aya Nabil Othman

• Tantoluwa Heritage Alabi NB

• Ashutosh Biswas

• Akande Olalekan Toheeb

• Oduah Chigozie

• Programming with Shahan

• Bhavishya Pandit

• Abimbola Adedotun Samuel

• Ifeanyi Otuonye

• Gor Grigoryan

• Alex Tray

• Andrico Karoulla

• valentine Gatwiri

• Juan Cruz Martinez

• Eamonn Cottrell

• Chidera Humphrey

• Tooba Jamal

• Bala Priya C

• Faith Olohijere

• Musab Habeeb

• Oluwatobi Sofela

• John Caleb

• Amr Hesham

• Andrew Baisden

• Yemi Ojedapo

• Kaushal Joshi

• Losalini Rokocakau

• Iroro Chadere

• Olabisi Olaoye

• Hamdaan Ali

• Sule-Balogun Olanrewaju

• Okoro Emmanuel Nzube Derek

• Nibesh Khadka

• Chepkirui Dorothy

• Alex Anie

• Juan P. Romano

• Zubair Idris Aweda

• Leonardo José Castillo Lacruz

Discord Top Contributors

• plamoni

• jeremylt

• Versailles

• Science99

• rhombert

• localhost

• goks563

• Razzle Dazzle

• hana

• SaintPeter

• Maestro

• xCoffeeMan

• Tex

• Jim

• bradtaniguchi

• Mohammed_malleck

• andrewdmitriev39r

• ilenia

• ArialLeslie

• Chara

• SaintElGandoSmokio

• CapslockHero

• g0vX

• tgrtim

• alpox

• AlexG

• dark

• Lycelia

• WangGang

• Saburo

• Bordin

• Dylan

• bulhaa

• bro keeps whining

• Tek

Again, these are just the most prolific among the thousands of people involved in the freeCodeCamp community.

If you're interested in getting involved in the freeCodeCamp community as an open source contributor, I encourage you to read our Contributor Guide and to join our Contributor Discord.

Thanks again, and happy coding. 🏕️

1. Fill out this form. It takes less than a minute.

2. Search your spam folder for "Quincy Larson" and if you find any of my emails in there, mark them "not spam"

Why did I stop receiving Quincy's emails, though?

For the past 8 years, I've sent out a weekly email: "5 freeCodeCamp Resources that are worth your time."

These include free books, courses, and tutorials created by the global freeCodeCamp community – mostly on math, programming, and computer science topics.

The freeCodeCamp community is so prolific that I have a difficult time choosing just 5 resources to share each week.

Up until May 2024, my email list was more than 7 million recipients. But we decided to require all recipients to opt-in again. This way we didn't have to send so many emails.

But you may have missed the announcement. (I mentioned it in three separate emails I sent in April 2024.)

So again, you can still opt-in again using this form.

Why does Quincy's email require double opting in? I've never heard of any other email newsletter requiring this.

Even though we had 7 million weekly recipients – all of whom explicitly chose to opt in when they were creating their freeCodeCamp account – some people told me they rarely opened these emails, or reported finding them in their spam folder.

By only sending emails to people who double opt-in, we can increase the likelihood that all of these people actually want the email, and will actually open them and read them.

Also, sending emails using Amazon's SES service is pretty inexpensive. You can send 10,000 emails for a penny. But sending 7 million emails still added up to $700 we were spending each week to send the email.

Now, after the double-opt-in, our cost of sending out the email newsletter is only a few dollars each week.

Some other interesting facts about Quincy's "5 freeCodeCamp resources" email

You can read through the entire archive of all of my emails, and search through them, thanks to Sourabh Joshi, who created this archiving bot that publishes them on a GitHub repository each week.

My emails are plain text. I don't use any HTML, CSS, or images. I do this because plain text is accessible, and looks good in any email client – on desktop, mobile, or even on the display of a smart watch.

Also, I don't include any sort of tracking. I'd rather be respectful of people's privacy than know how many people opened my email or clicked on a particular link. And it's nice to show people the exact URL of the link they're clicking on, so they know exactly what they're opening.

In short, I hold in high regard the fine people who sign up for my weekly email. I don't want to invade their privacy or waste their time.

I hope you find these emails and the open learning resources I share to be worth your time. 🏕️

You can join in the fun and learn from fellow campers who are going through freeCodeCamp's core curriculum.

You can use this link: https://discord.gg/KVUmVXA

If you don't already have a Discord account, this will walk you through creating real quick.

Here are some common things people use the freeCodeCamp Discord for:

1. Getting help when they're stuck. You can ask programming questions here in the Programming Help channel.

2. Practicing their English. We love teaching English and helping people improve their reading comprehension and writing skills. You can hang out in the English for Developer channel.

3. Taking the 100DaysOfCode Challenge. This is a popular coding challenge where you code at least 30 minutes each day for 100 days in a row, and encourage other people who are doing the same. This was originally a Twitter challenge, but has now become popular on Discord, too. Read more about 100DaysOfCode.

Again, here's the link for joining the freeCodeCamp Discord. See you there. 🏕️

Don't worry. I'm not tired. I love doing this, I'm going to keep working hard to share helpful learning resources with you.

I just need to make sure you're actually reading these emails. Please fill out this Google form real quick. It will take less than 1 minute.

Why I'm asking people to re-subscribe

Each week I send this email to all 7 million people who have opted in to receive it. This isn't cheap. Even with the cheapest email service on Earth (Amazon's Simple Email Service) it still costs our charity about $700 each week.

Now – I don't know exactly how many people open these emails. (Out of respect for your privacy, I refuse to add a tracking pixel or analytics to my emails, and instead send them in plain text.) But I suspect not all 7 million of you actually open them. 🙂

Again, if you want to keep getting these emails from me each week, please fill out this Google form real quick. It will take less than 1 minute.

Thanks, and happy coding! 🏕️

Claim Your Role

In any channel within our Discord server, type /supporter and you should see a command window pop up.

Click CamperChan's /supporter command, and enter the email address associated with your freecodecamp.org/learn account.

Then, hit enter to submit the command and you should see a success message! You'll now have the role with access to the supporter-only channels.

Error Messages

There are a few error messages you may encounter when claiming this role. For any of these messages, please ping Naomi directly in the server to assist you.

Already Have Role

This error message means you have already been assigned the Supporter role in the Discord server.

Record for Discord Server Exists

This error message means your Discord account has already been granted the Supporter role previously, but you have somehow lost it (for example by leaving the server and rejoining later).

Naomi will need to reset the database entry for you.

Record for Email Exists

This means your email address has already been used by another Discord account to claim the Supporter role. Naomi will give you instructions on how to verify ownership of the email address.

Not a Supporter

This means your curriculum account has not been flagged as having donated. Reach out to Naomi, and she will provide you instructions so she can fix that - make sure to have your latest donation receipt ready.

No freeCodeCamp account

This means the email address you entered does not have a curriculum account associated with it. Double check the spelling, and make sure you are using the email you use to sign in at freecodecamp.org

Thank You

Thanks again for supporting our charity's mission. Your donation will help us continue to provide free learning resources to millions of people around the world.

Robert was born in Detroit in 1949. After graduating high school, he joined the United States Air Force, learned Mandarin Chinese, and served as a translator in the Philippines.

After 3 years of service, Robert received an honorable discharged from the military. He moved to Texas, where he graduated from the University of Houston.

Robert spent the next 43 years working at energy companies, ascending in roles from a meter reader all the way up to a Telecom Analyst. Along the way, he developed a love of photography.

A life-long learner, Robert joined the freeCodeCamp community and continued to expand his skills.

Robert left this world in February. He left it a better shape than he found it. Among other things, he left a considerable gift to freeCodeCamp, so that other people around the world can learn new skills, regardless of their circumstances in life.

Please join me in saluting Robert for his military service, his support of our charity, and for being an all around kind human being. 🫡

A note on leaving a gift to the freeCodeCamp community

If you'd like to leave a legacy gift for freeCodeCamp like Robert did, you can add this language, or something like it, to your will:

I give, devise, and bequeath [the sum of _ USD (or other currency) OR _ percent of the rest and residue of my estate] to freeCodeCamp.org (Free Code Camp, Inc. tax identification number 82-0779546), a charitable corporation organized under the laws of the State of Delaware, United States, currently located at 3905 Hedgcoxe Rd, PO Box 250352, Plano, Texas, 75025 United States, to be used for its general charitable purposes at its discretion.

I'd like to thank Robert's brother John Yannaccone for helping me with Robert's gift, and the Wikimedia Foundation for providing this formal language for legacy gifts.

If you have any questions about this process, or are interested in other ways of supporting our charity and our mission, please email me at quincy@freecodecamp.org.

Community is a large part of open source. After all, Open Source projects can't thrive without a strong network of people (community) who contribute towards it, either through code contributions, design, documentation, financial contributions, advocacy, or adoption.

This article covers why community is important in Open Source, what a community manager role involves, and how to get started. I’ve also included additional resources, and some real life experiences from the Open Source Community to help you get started.

Table of Contents

1. Why Community?
2. Why are Open Source Community Managers Important?
3. Skills to have as an Open Source Community Manager
4. Roles of an Open Source Community Manager
5. How to Get Started as an Open Source Community Manager
6. How to Find Open Source Projects to Contribute To
7. Additional Resources

Before we head into the nitty-gritty of what an Open Source Community manager does, let’s take a look at the essence of community in open source.

Why Community?

The heart of a community is that it's a place where people gather, exchange thoughts, and collectively create something greater than the sum of its parts.

In the open source realm, this concept takes a digital form. Communities form around shared interests and the desire to build, refine, and improve software collaboratively. It's not just about the code – it's about the people behind it. A vibrant community enhances creativity, accelerates learning, and fosters an environment where innovation thrives.

Open source is a community project. It never happens in isolation, and it grows because of the communities that form around it. Whether you interact with open source as a user, contributor, or both, you're part of a community, and the community is better for it.

There are a variety of reasons why people join open source communities. A large number of people join because they are required to work on the software as part of their job. Maybe their organizations recruited them to develop it or maybe the project is essential to their jobs.

Some participate in communities in order to have a direct influence on the software development process that produces the essential functions for them and their businesses. Some join because communities provide them with chances to collaborate with and learn from others, which helps them hone their abilities.

Some people sign up because it enables them to work with others to solve a problem they're having. Some sign up because they think it's important to add to a shared resource that benefits everyone. And others sign up in order to socialize, or for a sense of identity and belonging.

So it's important to nurture the community, support its members, and find a way to reach a sustainable outcome.

Why Are Open Source Community Managers Important?

As community projects grow and become more complex with multiple product owners and contributors, they need to have a community manager.

Open source community managers act as the conductors, bringing together developers, users, and contributors to create a masterpiece. They are the bridge between the project and its community, ensuring that everyone's voice is heard, questions are answered, and collaboration flows seamlessly.

Skills to Have as an Open Source Community Manager

So, what makes a good community manager in the open source world? Here are some key qualities, encompassing both soft and hard skills:

• Communication Skills: A community manager must be an excellent communicator. Whether it's responding to GitHub issues, moderating discussions, or providing updates, clear and concise communication is key.
• Empathy: Understanding the needs and concerns of community members is crucial. OSCMs should have a high level genuine interest and concern for teaching others, engaging a range of stakeholders and balancing tensions as they arise.
• Adaptability and Inclusivity: Open source is dynamic, with contributors from diverse backgrounds. An effective community manager adapts to different communication styles and cultural nuances.
• Technical Understanding: While not mandatory, having a basic understanding of the technical aspects of the project can be immensely helpful. It facilitates better communication with developers and enhances problem-solving.
• Organizational Skills: Juggling multiple tasks, from handling forums to managing events, requires organizational finesse. Keeping things structured ensures that no message gets lost in the noise.
• A good command of English is a requirement for most jobs.

Recommended tools to learn as a community manager

Knowledge of all or some of these tools are 'nice-to-have'. You can check out job descriptions of OSCMs in job openings, and try to develop some or all of the skills that appear frequently.

Here are a few of the core skills you should learn:

• Git, GitHub, GitLab, and other version control systems for collaborative work.
• How to use Discord, slack, Discourse, and other communication tools.
• Markdown for documentation

Roles of an Open Source Community Manager

OSCMs work at the intersection of Developer Relations, Evangelism, Marketing, Engagement, and Advocacy. In fact, the majority of these responsibilities overlap so greatly that they are practically indistinguishable from one another.

Often times, the role of an open source community manager may be tricky to define, as there are many different aspects to it. Let's take a look at some of the responsibilities of OSCMs:

• Community Engagement—an open source community manager facilitates engagement by moderating, engaging, and supporting users in forums including Discourse, GitHub, and Reddit, Discord, Slack and Github discussions.
• Community recognition—when everyone feels like they have a home where they're appreciated, they’ll be encouraged to stay engaged. Impactful and meaningful recognitions such as celebrating community successes, sending swag, and recognizing top contributors is a great way to encourage a sense of belonging among contributors and build trust.
• Creating and managing new community and outreach programs—this could involve organizing meetups, events, hackathons, advocacy, and content (articles or newsletters, for example)
• Coordinating with other departments—such as product, engineering, and content marketing—to support community initiatives.
• Partner Management—keeping up to date with the various stakeholders and partners involved in the project
• Creating a good open source project—making the project discoverable, making the project easy to use, communicating feedback to project to maintainers, keeping documentation up to date and readable, spotting areas where the project could use more help.

How to Get Started as an Open Source Community Manager

Credit: John Cameron

Because of how vast and evolving the roles of OSCMs are, I sat down with three Open Source Community Managers to learn about how they started, and what their roles entailed. Each of these experiences differed in how the role was defined, the hiring process, and in their goals.

I spoke with Fiberesima Ibi, an Open Source Community Manager at Gnome Africa, whose journey started with an email and a desire to find the right open-source community where she could apply her skills.

“After exploring a few communities, I felt lost. Then, I stumbled upon GNOME Africa through Regina's tweet, and it clicked instantly.

What drew me in was GNOME's commitment to crafting an intuitive, accessible desktop environment. The African community was set up towards exposing Africans to contribute to GNOME projects and other open-source technologies.”

Fibi reached out to Gnome via mail, expressing her interest, which opened doors to becoming an Open Source Community Manager for GNOME Africa.

Speaking of her current role since joining the community, she has this to say:

“Reviving the community was a challenge I embraced. I've been focused on crafting strategies to boost engagement and contributions, and creating a welcoming space for everyone.

We recently started an X-series on “Recognizing your value as a contributor in the open source ecosystem” with the aim to empower contributors to leverage their open source journey to advance their career and personal growth.”

It's been an incredible journey of learning, empowering contributors, and advocating for GNOME's growth for Fibi. The main lesson she learned?

“Taking that first step, reaching out, and not underestimating the power of asking.”

Justin Dorfman (Open Source Community Manager at Sourcegraph) also shared his story:

“Starting in high school, I wanted to be a software engineer. The only problem was I wasn’t good at it. I would screw things up and sometimes create more work for senior engineers.

One of my mentors saw that I was very passionate and knowledgeable about open source and convinced me there were other ways to contribute.

At first, I was skeptical, but as the months and then years passed, I found I was making more impactful contributions to open source than I ever could have imagined. A non-code contributor as some say.”

“In my current role, I work with our community to get questions answered, I work with our engineering team to get content created, I recruit talented community members to join our company, and I make sure the open source dependencies we rely on are funded. From time to time, I update our docs or about the page, but the bulk of my time is spent out of an IDE.”

For Uriel Ofir, Community Manager at Ma'akaf, he recognized the challenges faced by Israeli programmers to connect with open source projects, and he built a community to address that.

As a community manager at Ma'akaf, my role is centered around creating an inclusive environment where Israeli programmers can seamlessly connect with open-source projects.

From overseeing our dynamic Discord server to facilitating knowledge-sharing through WhatsApp groups, every aspect of my work aims to foster collaboration within our community.

We provide valuable opportunities for members to network and learn by organizing physical and online meetups. Ultimately, my journey involves empowering individuals to engage, learn, and contribute effectively to the world of open source.

Many OSCMs perform their roles as volunteers, but sometimes communities hire for community managers. If you’re contributing on a voluntary basis, you’ll have a delicate balance to strike with regards to the community’s needs and your own commitments.

Open Source Community Manager Roadmap

Regardless of how you joined, it might still be intimidating to start as a new community manager, so it's better to approach the position similarly to any other development project. You'll need to identify your goals, define your idea of success, and then plan every step of your journey.

Here’s a simple getting started guide for new OSCMs:

• Choose an open source community that aligns with your goals.
• Join in—attend their events, join relevant groups, and connect with peers
• Contribute—read their documentation, check out the product features, make a contribution
• Volunteer—let the maintainers see your work, and approach to community management.

There are other ways to get started. In my case, I started my journey to Open Source Community Management through the Github Social Impact Digital Public Goods Open Source Community Manager, where I currently volunteer with Open Terms Archive as an Open Source Community Manager.

My role as a community manager involves various responsibilities. I help ensure that everyone collaborates in an effective way with less friction, I onboard users and contributors, I help improve our documentation, and I review and collaborate on pull requests.

How to Find Open Source Projects to Contribute to

I recommend starting with products, tools, and communities you already use or are a part of when looking for open source projects you want to contribute to. Since you are already familiar with the technology, there won't be much need for you to learn about it.

• Utilize your social media connections: Search for announcements on Twitter and LinkedIn.
• Use search engines to search with keywords such as "open source community manager"
• Send a pitch to maintainers of open source communities you're part of.

Additional Resources

Ready to dive deeper? Here are some resources to fuel your open source community management journey:

1. Building leadership in Open Source Communities by Linux Foundation
2. [Becoming]: Open Source Community Manager by Mary Blessing
3. The significance of a community manager in your Open Source project by Mary Blessing
4. How to Use Git and GitHub – Introduction for Beginners by Segun Ajibola
5. Community Management Resources by Amarachi Johnson-Ubah

Thank you for taking the time to read. I hope this article has been helpful, and if you have any questions, don't hesitate to reach out to me via Twitter.

I'm so grateful for the many kind volunteers who have helped us advance our mission of creating open learning resources.

Over the past 12 months, the freeCodeCamp community has:

• Merged 2,753 code contributions into our open source repositories on GitHub

• Published 114 free, full-length courses on YouTube

• Published 1,045 text-based coding tutorials and 20 free books through freeCodeCamp Press

• Translated more than 2 million words from English, to make our curriculum and tutorials more accessible to speakers of many world languages

• And we launched our Android and iOS mobile apps for using freeCodeCamp on the go.

We also launched Spanish, Portuguese, and Chinese weekly podcasts. And I personally published 19 interviews with software developers on the English freeCodeCamp podcast.

A screenshot of the freeCodeCamp mobile app, showing our podcast player which includes all 4 of the freeCodeCamp weekly podcasts.

A huge thanks to all 419 of our freeCodeCamp Top Open Source Contributors for 2023. 🏕️

Here's the full list, broken out by category of contribution. If you're one of these Top Contributors, expect an email from me in the coming days.

GitHub Codebase Top Contributors

• Bruce Blaser

• Huyen Nguyen

• Lasse Jørgensen

• Riya Dhawan

• Anmol Sarraf

• Krzysztof G.

• Manabu Matsumoto

• Jeremy L Thompson

• Dmitry Drepin

• Moshe

• Jacques Metevier

• Sriparno Roy

• Leon Feng

• Shabeeb Khalid

• Aashutosh Poudel

• Simon Legner

• ClasherKasten

• Jan Christoph Ebersbach

• Timothy Lim

Publication Top Contributors

• Shittu Olumide

• Arunachalam B

• David Clinton

• Eamonn Cottrell

• Oluseye Jeremiah

• Germán Cocca

• Md. Fahim Bin Amin

• Manish Shivanandhan

• Ashutosh Krishna

• Valentine Gatwiri

• Deborah Kurata

• Joan Ayebola

• Daniel Adetunji

• Edeh Israel Chidera

• Zubair Idris Aweda

• Jaja Ibifubara David

• Shane Duggan

• Christine T. Belzie

• Yazdun Fadali

• Isah Jacob

• Ijelekhai Faith Olohijere

• Kunal Nalawade

• Ijeoma Igboagu

• Austin Gil

• Tomer Ben Rachel

• Sonya Moisset

• Kingsley Ubah

• Rahul

• Sampurna Chapagain

• Njoku Samson Ebere

• Omer Rosenbaum

• Dickson Boateng

• Dhawal Shah

• Reed Barger

• Olasunkanmi Balogun

• Satyam Tripathi

• Kamaldeen Lawal

• Oluwatobi Sofela

• Casmir Onyekani

• Sophia Iroegbu

• Destiny Erhabor

• Nathan Sebhastian

• Grant Weatherston

• Bala Priya C

• Tapas Adhikary

• Daniel Iwugo

• David Fagbuyiro

• Mihail Gaberov

• Scott Gary

• Faith Oyama

• Edem Gold

• Rufai Mustapha

• Rajdeep Singh

• Juliet Ofoegbu

• Yogesh Chavan

• Mene-Ejegi Ogbemi

• Farhan Hasin Chowdhury

• Nishant Kumar

• Tiago Monteiro

• Shruti Kapoor

• Lane Wagner

• Atharva Shah

• Gideon Akinsanmi

• Adekola Olawale

• Jim Campbell

• Tamerlan Gudabayev

• Roy Chng

• Amazing Enyichi Agu

• Otavio Ehrenberger

• Mwendwa Bundi Emma

• Andrey Germanov

• Kedar Makode

• Eesa Zahed

• Alberto Gonzalez Rosales

• Ogundiran Ayobami

• Tatev Karen Aslanyan

• Joe Attardi

• Chris Blakely

• Tim Kleier

• Benjamin Semah

• Sameer Shukla

• Favour C. Felix

• Okoye Victor Chukwuebuka

• Ayu Adiati

• Eivind Kjosbakken

• Musab Habeeb

• Jose Vicente Nunez

• Vikram Aruchamy

• Tantoluwa Heritage Alabi

• Nibesh Khadka

• Ilknur Eren

• Krish Jaiswal

• Houssein Badra

• Tasnim Ferdous

• Adejumo Ridwan Suleiman

• Natalie Pina

• Andrew Brown

• Salim Oyinlola

• Marco Venturi

• Sule-Balogun Olanrewaju Ganiu

• Victor Eke

• Ridwan Yusuf

• Chidiadi Anyanwu

• Jessica Rose

• Clinton Joy

• Brenda Chepkorir

• Kelvin Moses

• Abdulwahab Ashimi

• Liz Johnson

• Brian Barrow

• Velda Kiara

• Manoel Cortes Mendez

• Vahe Aslanyan

• Mikael Lassa

• Idris Olubisi

• Swatej Patil

• Dmitry Dragilev

• Franklin Okolie

• Damilola Oladele

• Ibrahim Abayomi Ogunbiyi

• Andrej Kovacevic

• Aviator Ifeanyichukwu

• Chigozie Oduah

• Tejan Singh

• Tan Guangzhi

Forum Top Contributors

• Cody Biggs

• Jeremy

• Bruce B

• Hanaa B.

• Gray n Grey

• Vladimir Jovanović

• Lasse

• Doug Badger

• Starstruck

• Stephen Mutheu

• Kevin Smith

• Ariel Leslie

• Carlos Bernad

• Bappy Asif

• Zaklina Radivojevic

• Mel

• PKD Valis

• Dan Couper

• Infinity

• Kai

• Sanity

• Marcus Parsons

• Opudo Prince

• Cryptic

• Andrey D

• Daniel

• Maestro Goldring

• Kinome79

• Partum

• Teller

• Colin Thornton

• Jeremy A Gray

• Tato

• Adam Mauray

• Aram Nayebbandi

• Aaron

• Vivek rawat

• Albert Kucz

• Vivek rawat

• YC Wong

• Alabastor

• Daniel Ernst

• Jess Rose

• Ibrahim Aq

• Ramón Huidobro

• Jeff Beynon

• Solomon Chuks Nwante

• Sergio Yunsuk Lee

• Jim Mitchell

• EmmyOke

• Ringoj66

• Weslley

• Anthony Bryson Jr.

• Rajtanu Chakravarty

• Abz2023

• carlos

• Abz2023

• Morgan

• Ghadah

• Joseph Lee

• Francisco Ecatl Melo Valle

• Hal Jordan

• Zuko

• sean

• Julius

• Ayne Abreham

• Simon Morgan

• Ana Laura Berger

• Ayne Abreham

• lolek55507

• Nikhilreddy Manda

• Cmar

• Steve H

• Igor Snitkin

• Renan Botasse

• AviatorSea

• Coderostro

• Chukwudi Roxy Eneh

• Tom Carroll

• MJ

• Robert H.

• Edward Canale

• Diego

• Andy

• Bones

• Felix Adawu

• Sunil Aadewar

Translation Top Contributors

• Elias Ezequiel Pereyra Gomez

• BlackeyeB

• Andrés Torres

• Gibran Pelayo M.

• Estefania Cassingena Navone

• Enrique Viveros Acosta

• Constanza Areal

• CipherBoB

• Anna Aimeri

• Beatriz I Bravo

• Josué Leiva

• Jorge Sierra

• Santiago Toquica Yanguas

• Vanessa Pineiro Morales

• Fernando Campos

• Israel Palma

• Ezequiel Castellanos

• Limbert Lino Mattos

• Franciscomelov

• Sebastian Mendez

• Sofia Dominguez

• Johsttin Eduardo Curahua Gutierrez

• Rafael Fontenelle

• Afonso Branco

• João Eduardo Gomes

• Elizabete Nakamura

• Giálisson Rocha

• Carlos Silva.

• Gustavo Goulart Baptista

• Viviane Martini

• Barbara Reis Bayer

• Isabel Cristina Nunes de Sousa

• Marcos Adriano

• Arthur Fücher

• Matheus Ribeiro

• Ana Laura Reis

• Keveen Tenereli

• Felipe Archanjo

• Gabriel Galdino

• Erika Freitas

• Jorge Felipe Ribeiro Portela

• Renan Botasse

• Eduardo de Oliveira Machado

• Saki Basken

• luojiyin

• Narcissus91

• Songyp0505

• Herosql

• HeZean

• Papaya Huang

• xgqfrms

• Rhea Xiao

• John Cheng

• Jiajun Jiao

• Suxiong

• Leon Feng

• Humilitas

• Rudy Dong

• Xing Liu

• Keren Ma

• Kate Shao

• JasonLi

• Nicholas Zhan

• Alan Luo

• Casey Cui

• Liu Jun

• Frank Kong

• Paula

• Silvia Carrozza

• Roberto Pauletto

• Roberta Garavaglia

• Paola Rosati

• Paolo Pescosolido

• Giovanni Marletta

• Yeonsoo Jang

• Seunghyun Kim

• Nayoung Gu

• Janghan Park

• Jeeann Kim

• Minhyae Kim

• Heegu Yang

• Miri Joo

• Chaeyoon Kim

• Jeong Won Yoo

• Boyeon Ihn

• Younghyun Bae

• Hyojin Kim

• Yeseul Lee

• Yerim Kang

• Afonso Branco

• majidah

• rustamdocstranslator

• LisaGo

• Madlen

• Matthes-Baer

• Mikael

• SuperYang

• Farzana Jui1

• Drifting

• Farha Ahmed

• Shahana_Mahjubin_Supty

• Chengjun.L

• Kevin Matthew

• Hartato Cipta Jaya

• I_am_Vietnam

• Radi Totev

• Namso50

• Ada J

• SeunghyunKim

• Arthur CORBÈRES

• Christophe Thomas

• ZhichengChen

• Morpheus

• Suzie

• Kazuo Sekiguchi

• Felipe Navarro

• Marc Seira

• Yaron Shahrabani

• k0dai

• GianNipitella

• LaurelineP

• rkang13

• Rafael Fontenelle

• Syauqy Aziz

• Newton101

• Kishan Dasani

• twfplayer

• Harsh Mahajan

• Cinthia Mariel Orona

• chenzhazha

• Yena Yun

• Minhyae Kim

• christine phandi

• SHREYAS WANI

• Kuba Michalak

YouTube Contributors

• Gustavo Juantorena

• Carpi Coder

• Carlos Azaustre

• Tristan Willcox

• Robert Förster

• Kieth Galli

• Rivaan Ranawat

• Slobodan Gajic

• Arsalan Khattak

• John Elder

• Mustafa Esoofally

• Tim Ruscica

• Shad Sluiter

• John Smilga

• Brian Yu

• Michelle Krummel

• Aakash N S

• Frank Dvorak

• Craig Dennis

• Stein Helset

• Lane Wagner

• Shadee Merhi

• Nishant Singh

• Guillaume Duhan

• Gaurav Sen

• Gamium Dev

• Seth Goldin

• Frank Liu

• Ayush Singh

• Dr. David J. Malan

• Joe Kearney

• Jess Chan

• Niklas Ziermann

• Bob Ziroll

• Piyush Agarwal

• Omar Zaki

• Dr. Radu Mariescu-Istodor

• Rafid Hoda

• Herbert

• Emma Williams

• Zach Gollwitzer

• Bhrugen Patel

• Tom Chant

• Burak Orkmez

• Brian H. Hough

• Judy

• Simon Grimm

• Anil Kulkani

• Zura Sekhniashvili

• Akshath Nag

• Andrew Brown

• Tapas Adhikary

• Ryan Solomon

• Dr. Jason Adleberg, MD

• Priyanshu Bhattacharjee

• Hitesh Choudhary

• Pranjal Soni

• Valentin Despa

• Rishab Kumar

• Aryan Hegde

• Santiago Basulto

• Jalal Bounaim

• Arfan Zubi

• Folefac Martins

• Chris Sev

• James McArthur

• Dan Barahona

• James Q Quick

• Alex Cristian

• Akhil Sharma

• Elliot Arledge

• Code Bucks

• Dave Gray

• Elliott Chong

• Sriram Chundi

• Alvin Zablan

• Jerome McCree

• Net Ninja

• Mohammad Taheri

• Corey Ball

• Valters

• Rohan

• Parth Vyas

• Ankita Kulkarni

• Mathewos Wondwosen

• Jacob Lower

• Lachezar Haralampiev

• Josh L

• Farhan Ali

• Nikhil Thadani

• Haider Malik

• Treasure Porth

• Florian Walther

• Manuel Basanta

Discord Top Contributors

• plamoni

• texas2010

• Unrecover#5311

• bradtaniguchi

• AndreyDmitriev39r#1929

• bordin12

• neclo#0

• wanggang

• amineabdo

• tobyplaystheuke

• greatoverlordx

• alpox

• lycelia.com

• Randomized#0667

• vedamruta

• thaitiesthetie

• thebringerofcakes

• wistful_ocean

• dotty.dev

• sazk07

• sboon

• xcoffeeman

• materialisolari

• jluboff

• secondarymonitor

• cyclokitty

Again, these are just the most prolific among the thousands of people involved in the freeCodeCamp community.

If you're interested in getting involved in the freeCodeCamp community as an open source contributor, I encourage you to read our Contributor Guide and to join our Contributor Discord.

Thanks again, and happy coding. 🏕️