Doing Open Source the Right Way
•
10 likes•2,293 views
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.
Recommended
More Related Content
Viewers also liked
Similar to Doing Open Source the Right Way
Similar to Doing Open Source the Right Way (20)
More from Charles Nutter
More from Charles Nutter (20)
Recently uploaded
Recently uploaded (20)
Doing Open Source the Right Way
- 1. Doing Open Source (The Right Way)
- 2. Charles Oliver Nutter @headius JRuby Guy at Red Hat
- 3. And you? Developer? Using open source? Contributor? Leader? http://upload.wikimedia.org/wikipedia/en/a/ad/UnknownComic.jpg
- 4. Open Source
- 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. http://en.wikipedia.org/wiki/Open-source_software
- 7. …study, change and distribute the software to anyone and for any purpose.
- 9. Free as in freedom
- 10. Free as in liberty
- 11. Free and Open Source Software
- 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. http://en.wikipedia.org/wiki/Free_and_open-source_ software
- 13. freely licensed
- 14. use, copy, study, and change the software
- 15. source code is openly shared
- 16. people are encouraged to voluntarily improve the design of the software
- 20. Big Wins Linux and the BSDs Firefox and Chrome PHP, Python, Ruby, Perl, Erlang, Go, Dart, … OpenJDK and Mono
- 21. Web Server Share Source Date Unix, Unix-like Windows W3Techs February 2014 67% 33% Security Space November 2012 62-82% 18-38% http://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Servers_on_the_Internet
- 22. Unix or Unix-like? Linux - 54.9% BSD - 1.4% Darwin, HP-UX, Solaris - < 0.1% Unknown - 43.6 http://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Servers_on_the_Internet
- 25. Benefits to User Cost savings…sometimes Visibility Empowered to make changes Commercial support is available Red Hat, e.g.
- 26. All because of you
- 27. Not possible without you.
- 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
- 30. LiteStep A project I was using myself Development had slowed Large, monolithic codebase Languages and APIs I was familiar with
- 31. JRuby Implementation of Ruby Written in Java Development had slowed Many tasks Beginner to advanced
- 32. Getting Involved
- 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
- 36. A Good Contributor 1. Respects and forgives others 2. Recognizes expertise 3. Increases the pool of resources
- 37. JRuby Commits 49% 51% Paid Unpaid
- 38. Things to Contribute Help field questions on lists, forums, IRC Improve documentation Present at a conf or user group File bugs or submit fixes
- 39. A Good Bug Reporter Clearly states expectation vs reality Provides code or steps to reproduce Volunteers relevant env details Responds to updates and comments
- 43. Going Deeper Bug triage Help guide other bug reporters Observe fixes for other bugs Attempt your own fix!
- 44. 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
- 45. My JRuby Contributions Several rewrites of interpreter JIT compiler to JVM bytecode Native I/O and process subsystem Ruby/Java integration layer
- 46. I did not know how to do these things.
- 47. Bug Fix Types Behavior Performance Documentation Quality http://upload.wikimedia.org/wikipedia/commons/9/9b/Insect_antennae_comparison.jpg
- 48. 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
- 49. A Good Patch Fixes the original problem Limits changes to the actual fix Matches coding style Maintains documentation truths Includes a regression test
- 52. More Tips Ask for help Accept that patch review takes time Not all patches are accepted Be willing to iterate
- 53. Into the Core Running a Project http://upload.wikimedia.org/wikipedia/commons/0/07/Earth_poster.svg
- 54. Becoming a Committer Proven track record of fixes Respectful member of community Sustained interest Domain expertise
- 55. Profile: mkristian Maven integration expert Consistently submitting patches Maintaining related libraries Active user
- 56. 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
- 57. Core members are dev, manager, evangelist, and QA rolled into one.
- 58. A Good Core Contributor Respectfully handles bugs and patches Discusses changes where necessary Does not violate others’ fixes Remains humble
- 59. Assume you are wrong.
- 61. Not all bugs are in code.
- 63. Starting a Project Missing tool or library Code others find useful Community needed An itch to scratch http://upload.wikimedia.org/wikipedia/commons/1/13/Michelangelo%2C_Creation_of_Adam_06.jpg
- 65. I am not a lawyer.
- 66. Criteria Sharing of source Assignment of rights Attribution Lifecycle of alterations
- 68. Contributor Agreement? Requires users to “sign” an agreement Permission to release changes Copyright assignment Permission to change licensing Public assertion is often enough
- 69. 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.
- 70. 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
- 76. A Good Community Member Has a thick skin Expects to learn from everyone Remembers that these are real people
- 77. Encouraging Contribution Ask for help Be honest Be responsive Empathize
- 78. Final Words
- 79. The world runs on OSS.
- 80. OSS would not exist without your help.
- 81. You are the most important contributor.
- 82. Thank you! Charles Oliver Nutter @headius