Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Doing Open Source the Right Way


Published on

Have you ever used an open source project? Well of course you have, but how about contributed to one? Filed a bug report? Submitted a patch? Have you ever started your own OSS project, or taken a closed/private project public? What licenses should you use? How do you manage contributions? How do you encourage contributors and get work done? In this talk we'll go over the basics of OSS: how to get involved, how to start a project, how to manage contributions. We'll discuss project lifecycles, legal CYA tips, and how to keep projects moving. You'll see the inner workings of real OSS projects, and learn how to be a better OSS user and producer.

Published in: Technology
  • Be the first to comment

Doing Open Source the Right Way

  1. 1. Doing Open Source (The Right Way)
  2. 2. Charles Oliver Nutter @headius JRuby Guy at Red Hat
  3. 3. And you? Developer? Using open source? Contributor? Leader?
  4. 4. Open Source
  5. 5. Open Source Software
  6. 6. Open-source software (OSS) is computer software with its source code made available with a license in which the copyright holder provides the rights to study, change and distribute the software to anyone and for any purpose.
  7. 7. …study, change and distribute the software to anyone and for any purpose.
  8. 8. Free Software
  9. 9. Free as in freedom
  10. 10. Free as in liberty
  11. 11. Free and Open Source Software
  12. 12. …computer software that can be classified as both free software and open source software…anyone is freely licensed to use, copy, study, and change the software in any way, and the source code is openly shared so that people are encouraged to voluntarily improve the design of the software. software
  13. 13. freely licensed
  14. 14. use, copy, study, and change the software
  15. 15. source code is openly shared
  16. 16. people are encouraged to voluntarily improve the design of the software
  17. 17.
  18. 18.
  19. 19.
  20. 20. Big Wins Linux and the BSDs Firefox and Chrome PHP, Python, Ruby, Perl, Erlang, Go, Dart, … OpenJDK and Mono
  21. 21. Web Server Share Source Date Unix, Unix-like Windows W3Techs February 2014 67% 33% Security Space November 2012 62-82% 18-38%
  22. 22. Unix or Unix-like? Linux - 54.9% BSD - 1.4% Darwin, HP-UX, Solaris - < 0.1% Unknown - 43.6
  23. 23. Operating_systems_used_on_top_500_supercomputers.svg
  24. 24. %28Source_StatCounter%29.svg
  25. 25. Benefits to User Cost savings…sometimes Visibility Empowered to make changes Commercial support is available Red Hat, e.g.
  26. 26. All because of you
  27. 27. Not possible without you.
  28. 28. Finding a Project A tool or library you already use A technology you are interested in A language you want to learn A project you simply want to help
  29. 29. LiteStep
  30. 30. LiteStep A project I was using myself Development had slowed Large, monolithic codebase Languages and APIs I was familiar with
  31. 31. JRuby Implementation of Ruby Written in Java Development had slowed Many tasks Beginner to advanced
  32. 32. Getting Involved
  33. 33. Meet the Community Mailing lists and forums Chat services like IRC or Gitter Q/A sites like Stack Overflow Social sites like LinkedIn or Facebook
  34. 34. A Good Contributor 1. Respects and forgives others 2. Recognizes expertise 3. Increases the pool of resources
  35. 35. JRuby Commits 49% 51% Paid Unpaid
  36. 36. Things to Contribute Help field questions on lists, forums, IRC Improve documentation Present at a conf or user group File bugs or submit fixes
  37. 37. A Good Bug Reporter Clearly states expectation vs reality Provides code or steps to reproduce Volunteers relevant env details Responds to updates and comments
  38. 38. Going Deeper Bug triage Help guide other bug reporters Observe fixes for other bugs Attempt your own fix!
  39. 39. Fear Itself Afraid I’m not good enough Afraid I don’t know the best solution Afraid to make things worse Afraid I’ll be mocked or insulted
  40. 40. My JRuby Contributions Several rewrites of interpreter JIT compiler to JVM bytecode Native I/O and process subsystem Ruby/Java integration layer
  41. 41. I did not know how to do these things.
  42. 42. Bug Fix Types Behavior Performance Documentation Quality
  43. 43. Crafting a Fix Get a local copy of the code Make your changes Confirm they fix the original issue Confirm they do not fail tests Submit fix as a patch or pull request
  44. 44. A Good Patch Fixes the original problem Limits changes to the actual fix Matches coding style Maintains documentation truths Includes a regression test
  45. 45. More Tips Ask for help Accept that patch review takes time Not all patches are accepted Be willing to iterate
  46. 46. Into the Core Running a Project
  47. 47. Becoming a Committer Proven track record of fixes Respectful member of community Sustained interest Domain expertise
  48. 48. Profile: mkristian Maven integration expert Consistently submitting patches Maintaining related libraries Active user
  49. 49. Open Commit Bit Alternative path to core One accepted patch and you’re in Rapidly adds new core members Rewards early participation Debateable benefits over time
  50. 50. Core members are dev, manager, evangelist, and QA rolled into one.
  51. 51. A Good Core Contributor Respectfully handles bugs and patches Discusses changes where necessary Does not violate others’ fixes Remains humble
  52. 52. Assume you are wrong.
  53. 53. Not all bugs are in code.
  54. 54. User experience matters.
  55. 55. Starting a Project Missing tool or library Code others find useful Community needed An itch to scratch
  56. 56. Licensing
  57. 57. I am not a lawyer.
  58. 58. Criteria Sharing of source Assignment of rights Attribution Lifecycle of alterations
  59. 59.
  60. 60. Contributor Agreement? Requires users to “sign” an agreement Permission to release changes Copyright assignment Permission to change licensing Public assertion is often enough
  61. 61. Relicensing? Changing software license requires permission of all contributors Get it right the first time or you’ll be chasing people around Some licenses have upgrade clause CPL to EPL, e.g.
  62. 62. Get It Out There Use services familiar to community Include license from day 0 Include README, build scripts, examples Tell others in the community …but don’t expect a flood of users
  63. 63. Release the Hounds!
  64. 64. A Good Community Member Has a thick skin Expects to learn from everyone Remembers that these are real people
  65. 65. Encouraging Contribution Ask for help Be honest Be responsive Empathize
  66. 66. Final Words
  67. 67. The world runs on OSS.
  68. 68. OSS would not exist without your help.
  69. 69. You are the most important contributor.
  70. 70. Thank you! Charles Oliver Nutter @headius