This document provides an overview of contributing to open source software projects. It discusses what open source software is, how open source projects generally work, and offers advice on how to make a first contribution. Specifically, it recommends joining a project's mailing list, finding an issue to work on, making the code change along with any necessary tests or documentation, and submitting the contribution for review. It also uses the curl and Firefox projects as examples to illustrate different open source project structures and contribution processes.

1. Contributing to
Open Source
Daniel Stenberg, October 16th 2014

2. Agenda
About FOSS
How FOSS works
Two examples
The first patch

3. Please ask!
Feel free to interrupt and ask at any time!

4. Daniel Stenberg
Email: daniel@haxx.se
Twitter: @bagder
Web: daniel.haxx.se
Blog: daniel.haxx.se/blog

5. FOSS history of Daniel
• 1991 - Discovered Unix (AIX), working for IBM
• Wow, there's a lot of source code given away free by cool people!
• 1994 – an IRC bot called Dancer was my first “own” project
• ...
• 2014 – I'm employed to work entirely on open source software

6. What is Open Source?

7. I'll skip
•history
•how Open Source conquers the world
•why people participate

8. Definition
Open source software is software that can be freely
used, changed, and shared (in modified or
unmodified form) by anyone.
“Free software” means software that
respects users' freedom and
community. Roughly, it means that
the users have the freedom to run,
copy, distribute, study, change and
improve the software.

9. Not defined
•Which license – 100s to pick from
• Collaboration – if at all or how
• How to get the code
• How to figure out how things work
• How to contribute changes
• How to get binaries or packages built from
the code
• How to behave and accepted behavior
•Which (human) language to use
• ...

10. Common practices
• A “project” develops one or more “products”
• Anyone can join an open source project
• A limited set of core people can “accept” changes
•Meritocracies – those who do and can things get more to do and say
• A project usually has a web site explaining the project or the
product(s)
• Some projects work under “Umbrella organizations”
•Most projects are small teams with volunteers
• Some projects are run and cared for by commercial entities
• Development and communications are done “in the open”

11. How to contribute

12. License and copyright
•Each project is released under an Open
Source License
•Which?
• Are you OK with that?
• Can you use another?
•All contributions are owned by a
copyright owner
• “hand it over”
• license it
• you own it

13. Communicate
• Use English
• Follow the mailing list / forum a while before you post
• Don't be afraid of email, delete what you don't need to
keep!
• Absorb the tone and listen in on “how stuff works”
• Think of the project as “we”, not “you”
•When posting: be polite and stick to the subject
• Before asking: try to figure out the answer yourself
• But also: it is much better to ask before wasting a lot of
time
• Always discuss before posting changes/improvements
• Respect that it may take time to get a reply

14. Communities
• white, male, western, middle-class, christian
• Everyone is not like you, others may think differently
• Flame wars, trolls and spam will occur
• People have invested time, sweat and tears
• Participants are usually around by choice and interest

15. Work
• There's usually a TODO somewhere
• There's usually a bug tracker or list of known problems or bugs
• Dig in and help out where you think you can, it is needed or where you
think is most fun
•More than code counts:
• Repeat bugs
• Test bug fixes
• Answer questions
• Translations
• Art work / graphics
• Documentation
• Web site / admin

16. Send contributions
•Adhere to license and copyright rules
•Use the correct tools (version control, diff tools, editors, mail
etc)
•Base it on the right version, branch or source tree
•Send contributions using the right format
•Follow code standards
•Assume reviews to point out (several) faults
•Prepare to make several iterations before okayed
• If no response, send reminder after a grace period
•Argue for your way and for your changes.

17. Two projects in the real world

18. curl
•Most copyrights belong to Daniel
• One release every 8 weeks
• < 100,000 lines of code
• 100 commits per month
• 40 authors per release
• 5-7 core people, one maintainer
• All volunteers
•MIT licensed
• 1400 bugs in the bug tracker
• An IRC channel

19. Contributing to curl
•Join the mailing list
•Read the TODO / bug tracker
•Ask around or grab something you
feel like

20. Firefox
• Driven by Mozilla
• Hundreds of paid developers
• Hundreds of daily commits
• Hundreds of daily new bug reports
• > 1,000,000 bug reports filed
• Very distributed responsibilities
• A hundred(?) mailing lists?
• A hundred(?) IRC channels
•Most committers are paid staff
• > 12 million lines of code

21. Contributing to Firefox
•http://whatcanidoformozilla.org/
•http://www.joshmatthews.net/bugsahoy/
•https://developer.mozilla.org/en-US/docs/Introduction
•http://codefirefox.com/

22. Making your first contribution

23. What?
Which project owns what you want to do?
Join mailing list/forum
Or start your own!

24. Source
Where's the canonical source?

25. License
Are we good?

26. Tests
Are there tests we can run to verify our changes?

27. Change it!
•Correct branch
•Right tool
•Use tool correctly
•Change only what you need to
•Add tests and documentation
•Make a good commit message or description

28. Send it off
•Send your contribution
•Wait for review
•Update your work
•Send new version

29. Simple enough, huh?
Now, let's try this for real!

30. Learn more!

31. Doing good is part of our code