Download as PDF, PPTX
Uploaded byDaniel Stenberg
Contributing to Open Source
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.
More Related Content
Similar to Contributing to Open Source
Contributing to Open Source
- 1. Contributing to OpenSource Daniel Stenberg, October 16th 2014
- 2. Agenda About FOSS How FOSS works Two examples The first patch
- 3. Please ask! Feelfree 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 ofDaniel • 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 OpenSource?
- 7. I'll skip •history •how Open Source conquers the world •why people participate
- 8. Definition Open sourcesoftware 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 •Whichlicense – 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.
- 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 • UseEnglish • 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'susually 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 •Adhereto 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 inthe real world
- 18. curl •Most copyrightsbelong 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 • Drivenby 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 firstcontribution
- 23. What? Which projectowns what you want to do? Join mailing list/forum Or start your own!
- 24. Source Where's thecanonical source?
- 25. License Are wegood?
- 26. Tests Are theretests we can run to verify our changes?
- 27. Change it! •Correctbranch •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.
- 31. Doing good ispart of our code