Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Contributing to Open Source

4.825 visualizaciones

Publicado el

How open source projects work and how to effectively contribute to open source projects.

Publicado en: Tecnología
  • Inicia sesión para ver los comentarios

Contributing to Open Source

  1. 1. Contributing to Open Source Daniel Stenberg, October 16th 2014
  2. 2. Agenda About FOSS How FOSS works Two examples The first patch
  3. 3. Please ask! Feel free to interrupt and ask at any time!
  4. 4. Daniel Stenberg Email: Twitter: @bagder Web: Blog:
  5. 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. 6. What is Open Source?
  7. 7. I'll skip •history •how Open Source conquers the world •why people participate
  8. 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. 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. 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. 11. How to contribute
  12. 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. 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. 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. 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. 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. 17. Two projects in the real world
  18. 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. 19. Contributing to curl •Join the mailing list •Read the TODO / bug tracker •Ask around or grab something you feel like
  20. 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. 21. Contributing to Firefox • • • •
  22. 22. Making your first contribution
  23. 23. What? Which project owns what you want to do? Join mailing list/forum Or start your own!
  24. 24. Source Where's the canonical source?
  25. 25. License Are we good?
  26. 26. Tests Are there tests we can run to verify our changes?
  27. 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. 28. Send it off •Send your contribution •Wait for review •Update your work •Send new version
  29. 29. Simple enough, huh? Now, let's try this for real!
  30. 30. Learn more!
  31. 31. Doing good is part of our code