Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

The Hitchhikers' Guide to Free and Open Source Software Development (CompCon 2013)

on

  • 506 views

There is only one serious course about Free and Open Source Software Development delivered in Australia annually, the postgraduate level COMP8440 at ANU. Moreover the course is delivered by Andrew ...

There is only one serious course about Free and Open Source Software Development delivered in Australia annually, the postgraduate level COMP8440 at ANU. Moreover the course is delivered by Andrew "Tridge" Tridgell who authored the seminal open source projects samba and the rsync algorithm. During this course he discusses his wealth of experience and trains then assesses students on contributing to the open source community.

This talk will be conveying as much of this week-long course as is possible in the time available, as seen through the eyes of a graduating student who was always keen about open source yet who hadn't made their first pull-requests until during this course. Now, more than a year later, the presenter is actively involved in several open source projects and will be talking about some of the characteristics of the open source community today and describing in specific detail about how to become involved. The presenter will discuss the highs, the lows, the awkwardness and unique sense of connection and achievement that can only be fulfilled by contributing to open source.

Elena Williams is a python/django web developer now working in Perth. She graduated from Master ITS program from CECS ANU in 2012. She's taught Django/Python, been involved with the Django, Python and Linux communities around Australia and organised the Python user group in Canberra whilst studying at ANU. She presented about open source participation at PyConAU 2012. She is also enthusiastic about teaching programming to non-programmers, kitesurfing, snowboarding, endurance navigation sports; is an active hacker/maker and was only called a Douglas Adams "tragic" by the Canberra Times once.

Statistics

Views

Total Views
506
Views on SlideShare
506
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The Hitchhikers' Guide to Free and Open Source Software Development (CompCon 2013) Presentation Transcript

  • 1. THE HITCHHIKER'S GUIDE TO FREE AND OPEN SOURCE SOFTWARE DEVELOPMENT
  • 2. @elequ or elena
  • 3. INTERESTING TIMES ~ stream-lined communication ~ broad acceptance of technology Golden age
  • 4. WHY? “DO” OPEN SOURCE Who here
  • 5. YOU
  • 6. PUBLIC CODE PRESENCE IS ATTRACTIVE TO POTENTIAL EMPLOYERS support companies can hire what they see … Hardware vendors have a big market for FOSS devs so that foss will work on their devices.
  • 7. PUBLIC CODE PRESENCE IS THE BEST CV EVA Bitbucket Gitorious CloudForge Google Code CodePlex Launchpad GitHub SourceForge
  • 8. github.com bitbucket.org
  • 9. WHY? “DO” OPEN SOURCE OPPORTUNITY if you want to be good
  • 10. WHY? “DO” OPEN SOURCE OPPORTUNITY People Projects best people that there are ...
  • 11. WHO “DOES” OPEN SOURCE
  • 12. WHO “DOES” OPEN SOURCE INVOLVEMENT Creator Contributor User
  • 13. WHO “DOES” OPEN SOURCE INVOLVEMENT USAGE Creator Personal Contributor Professional/ Corporate User
  • 14. WHO “DOES” OPEN SOURCE INVOLVEMENT USAGE Creator Personal Contributor Professional/ Corporate User Hobby
  • 15. WHO “DOES” OPEN SOURCE INVOLVEMENT USAGE Creator Personal Contributor Professional/ Corporate User Hobby Resource
  • 16. WHY? “DO” OPEN SOURCE Open source provides a unique opportunity for the trifecta of purpose, mastery and autonomy.
  • 17. WHY? “DO” OPEN SOURCE Learning Socialising Minions Glory! World Domination
  • 18. WHY? “DO” OPEN SOURCE SOCIAL Working with others Working with people better than you Exposure to other styles Get exposure for your project
  • 19. WHY? “DO” OPEN SOURCE EDUCATION Opportunity to learn from others Learn to avoid pitfalls/gotchas Fast intro to common patterns It’s exhausting
  • 20. WHY? “DO” OPEN SOURCE SKILL UP Try out new ideas. Try out new technology. Try out development, unstable versions. Do things you don’t do “during the day”. It’s exhausting
  • 21. WHY? “DO” OPEN SOURCE ETHICS/VALUES Political Reasons Altruism Democracy/Meritocracy
  • 22. WHY? “DO” OPEN SOURCE BUSINESS Best Solution Available Makes Sense for the Project
  • 23. WHY? BUSINESS REASONS • Security • Interoperability • Quality • Auditability • Customisability • Support • Freedom • Cost • Flexibility • Try-Before-You-Buy Options
  • 24. QUALITY “If you have enough eyeballs all bugs are shallow.” Linus’ Law (actually pre-dates him)
  • 25. CHOICE AND TRUST No need to trust software vendor. Choice to fix yourself. Right to fork if disagree. Can contribute. It’s healthy to question your own work! It’s healthy to freely collaborate! PRACTICAL terms
  • 26. WHAT IS “OPEN SOURCE” ANYWAY?
  • 27. FREEDOM
  • 28. FREEDOM Free as in “Beer”
  • 29. FREEDOM Free as in “Speech” or as in “Thought”
  • 30. PROGRESS
  • 31. community that emphasises the individual over the “organisation” vs. company presents a facade
  • 32. IN THE BEGINNING ... was the Command Line
  • 33. IN THE BEGINNING ... was the Command Line
  • 34. IN THE BEGINNING ... was the incident at MIT Artificial Intelligence Labs with the printer drivers in about 1971
  • 35. [COOKING]
  • 36. SOFTWARE SHOULD BE ... Completely PRIVATE v. Completely FREE
  • 37. SOFTWARE SHOULD BE ... Completely PRIVATE Sell v. Share Completely FREE
  • 38. SOFTWARE SHOULD BE ... Completely PRIVATE v. Completely FREE
  • 39. SOFTWARE SHOULD BE ... Completely PRIVATE (Bill Gates) .. v. (Richard Stallman) Completely FREE
  • 40. SOFTWARE SHOULD BE ... Completely PRIVATE v. Completely FREE
  • 41. SOFTWARE SHOULD BE ... Completely PRIVATE Corporations v. Hackers Completely FREE
  • 42. SOFTWARE SHOULD BE ... Completely PRIVATE v. Completely FREE rights individual higher purpose progress of technology
  • 43. SOFTWARE SHOULD BE ... Completely PRIVATE Protect Owner v. Protect Freedom Completely FREE rights individual higher purpose progress of technology
  • 44. SOFTWARE SHOULD BE ... Completely PRIVATE v. Completely FREE These rules hadn’t been made up In wasn’t obvious
  • 45. SOFTWARE SHOULD BE ... Completely PRIVATE Product v. Individual Completely FREE These rules hadn’t been made up In wasn’t obvious
  • 46. SOFTWARE SHOULD BE ... ... THE AUTHOR DECIDES
  • 47. COPYRIGHT
  • 48. AUTOMATICALLY GRANTS AUTHOR EXCLUSIVELY RIGHT TO: To produce copies or reproductions to sell or distribute. Create derivative works. To perform or display the work publicly; To transmit, import or export the work. This is the essence of why licenses matter.
  • 49. AUTOMATICALLY GRANTS AUTHOR EXCLUSIVELY RIGHT TO: To produce copies or reproductions to sell or distribute. Create derivative works. To perform or display the work publicly; To transmit, import or export the work. NO ONE ELSE CAN DO THESE THINGS WITHOUT THE AUTHOR’S PERMISSION This is the essence of why licenses matter.
  • 50. AUTOMATICALLY GRANTS AUTHOR EXCLUSIVELY RIGHT TO: To produce copies or reproductions to sell or distribute. Create derivative works. To perform or display the work publicly; To transmit, import or export the work. NO ONE ELSE CAN DO THESE THINGS WITHOUT THE AUTHOR’S PERMISSION If they do, the author can sue. This is the essence of why licenses matter.
  • 51. COPYLEFT
  • 52. ORIGINAL SOFTWARE FREEDOMS (~1976) * The freedom to run the program, for any purpose. * The freedom to study how the program works, and adapt it to your needs. * The freedom to redistribute. * The freedom to improve the program, and release your improvements (and modified versions in general) Access to the source code is a precondition. (obviously)
  • 53. OPEN SOURCE DEFINITION 1. Free Redistribution 2. Source Code 3. Derived Works 4. Integrity of The Author's Source Code 5. No Discrimination Against Persons or Groups Things that are explicitly stated.
  • 54. OPEN SOURCE DEFINITION 1. Free Redistribution ~ as in beer -- no royalties or fees 2. Source Code 3. Derived Works 4. Integrity of The Author's Source Code 5. No Discrimination Against Persons or Groups Things that are explicitly stated.
  • 55. OPEN SOURCE DEFINITION 1. Free Redistribution ~ as in beer -- no royalties or fees 2. Source Code ~ not obfuscated or require preprocessor, translator, etc 3. Derived Works 4. Integrity of The Author's Source Code 5. No Discrimination Against Persons or Groups Things that are explicitly stated.
  • 56. OPEN SOURCE DEFINITION 1. Free Redistribution ~ as in beer -- no royalties or fees 2. Source Code ~ not obfuscated or require preprocessor, translator, etc 3. Derived Works ~ can be remixed 4. Integrity of The Author's Source Code 5. No Discrimination Against Persons or Groups Things that are explicitly stated.
  • 57. OPEN SOURCE DEFINITION 1. Free Redistribution ~ as in beer -- no royalties or fees 2. Source Code ~ not obfuscated or require preprocessor, translator, etc 3. Derived Works ~ can be remixed 4. Integrity of The Author's Source Code ~ rename your version 5. No Discrimination Against Persons or Groups Things that are explicitly stated.
  • 58. OPEN SOURCE DEFINITION 6. No Discrimination Against Fields of Endeavor 7. Distribution of License 8. License Must Not Be Specific to a Product 9. License Must Not Restrict Other Software 10. License Must Be Technology-Neutral Need to be specified because they’ve been challenged
  • 59. OPEN SOURCE DEFINITION 6. No Discrimination Against Fields of Endeavor ~ eg. commercial use or “values” (genetic research) 7. Distribution of License 8. License Must Not Be Specific to a Product 9. License Must Not Restrict Other Software 10. License Must Be Technology-Neutral Need to be specified because they’ve been challenged
  • 60. OPEN SOURCE DEFINITION 6. No Discrimination Against Fields of Endeavor ~ eg. commercial use or “values” (genetic research) 7. Distribution of License ~ applies to next person down, but not next after that 8. License Must Not Be Specific to a Product 9. License Must Not Restrict Other Software 10. License Must Be Technology-Neutral Need to be specified because they’ve been challenged
  • 61. OPEN SOURCE DEFINITION 6. No Discrimination Against Fields of Endeavor ~ eg. commercial use or “values” (genetic research) 7. Distribution of License ~ applies to next person down, but not next after that 8. License Must Not Be Specific to a Product ... except if being repackaged and redistributed 9. License Must Not Restrict Other Software 10. License Must Be Technology-Neutral Need to be specified because they’ve been challenged
  • 62. OPEN SOURCE DEFINITION 6. No Discrimination Against Fields of Endeavor ~ eg. commercial use or “values” (genetic research) 7. Distribution of License ~ applies to next person down, but not next after that 8. License Must Not Be Specific to a Product ... except if being repackaged and redistributed 9. License Must Not Restrict Other Software 10. License Must Be Technology-Neutral ~ platform or “style of interface” Need to be specified because they’ve been challenged
  • 63. PROPRIETARY OPEN SOURCE? CAN: give away source and accepted changes (for free as in beer) CANNOT: use the term “Open Source” as it’s trademarked
  • 64. PROPRIETARY OPEN SOURCE? For your own sake be aware of where you’re directing your efforts.
  • 65. LIABILITY Giving away for free (as in beer) does not exempt from being sued. “This program comes with ABSOLUTELY NO WARRANTY” lifesaving landing aircraft
  • 66. OPEN SOURCE PHILOSOPHISING Traditional FOSS projects have strong technical focus and tend to avoid philosophy. There are dedicated channels for talking about FOSS philosophy and principles. In more modern projects there is a resurgence in interest if you learn some background. Aaron Schwartz
  • 67. FREE AND OPEN SOURCE SOFTWARE PROJECTS
  • 68. ACTUALLY LOOKS LIKE THIS:
  • 69. Mailing Lists ACTUALLY LOOKS LIKE THIS:
  • 70. Mailing Lists IRC ACTUALLY LOOKS LIKE THIS:
  • 71. Bug/Issue Tracking
  • 72. Bug/Issue Tracking AND THIS ...
  • 73. BUT SRSLY ... Completely PRIVATE Product v. INDIVIDUAL Completely FREE community that emphasises the individual over the company vs. company presents a facade
  • 74. One of most important messages of this talk! Beautiful bouquet that is humanity
  • 75. EVERY PROJECT is DIFFERENT One of most important messages of this talk! Beautiful bouquet that is humanity
  • 76. COMMUNITY CULTURE IS NOT SCIENCE You can not independently derive this stuff. ... and no one expects you to. Do your research and listen. Follow the precedent.
  • 77. PROJECT TECHNICAL SPECIFICS
  • 78. PROJECT TECHNICAL SPECS How: responsive, receptive and welcoming will vary dramatically
  • 79. PROJECT VARIABLES • Technology Andrew Tridgell says: spend a couple of weekends or whatever
  • 80. PROJECT VARIABLES • What’s its scope? • What’s • Technology its profile? • How big is it? • How old is it? • Where • How in its lifecycle it is? active is it? Andrew Tridgell says: spend a couple of weekends or whatever
  • 81. PROJECT VARIABLES • Technology • What’s its scope? • Who? • What’s its profile? • How well organised is it? • How big is it? • How is it structured? • How old is it? • How are decisions made? • Where • How does it communicate? • How active is it? in its lifecycle it is? Andrew Tridgell says: spend a couple of weekends or whatever
  • 82. PROJECT VARIABLES TECHNOLOGY Technical Depth [many possible dimensions] you know what? scratch that, I’m actually going to come back to this later.
  • 83. PROJECT VARIABLES What’s its scope? [Linux Kernel .. .. some niche script] What’s its profile? [Python .. .. some widget]
  • 84. PROJECT VARIABLES How old is it? FOSS Projects are hard to kill. Where in its lifecycle it is? [Alpha .. .. Established] Where in its story arc it is? [Surging .. Stable .. Dying] samba died twice dead cat bounce
  • 85. PROJECT VARIABLES How big is the codebase? How big is the program/application? [Twitter .. .. ] Sometime big codebase on small application is a good thing.
  • 86. PROJECT VARIABLES How big is the community? What kind of people are in the community? [technical, organisational, social, experimental ...]
  • 87. PROJECT VARIABLES CATHEDRAL
  • 88. PROJECT VARIABLES CATHEDRAL v. BAZAAR
  • 89. PROJECT VARIABLES How active is it? [17K emails/month .. .. couple of patches/year] Faster moving is less tolerant. Bigger can be more tolerant.
  • 90. WELCOMING COMMITTEE Projects might have someone whose role is to guide new people. Apache have a whole system. The project leader might give you all the time in the world for a brand new project. There will probably be nothing at all. this week, we found a big in plug in made a patch it was pushed and released in about 15 minutes
  • 91. PROJECT VARIABLES SUMMARY You will have completely different experiences depending on the project.
  • 92. PROJECT VARIABLES SUMMARY Have a basic idea of the nature of the project before diving in. It’ll grease the rails, make it easy for yourself.
  • 93. PROJECT GOVERNANCE (PEOPLE)
  • 94. DECISIONS NEED TO BE MADE Design Legal/License Development Environments and Tools Triaging (dealing with incoming) Someone has to make them.
  • 95. PROJECT GOVERNANCE Formal v. Informal Organisational Structure (gotta have one) OK so honestly very few projects have formal structure Most projects are informal If you have an organisation ... even if it’s rubbish
  • 96. PROJECT GOVERNANCE Formal Constitution Office holders, Board or Steering committee Annual election (Debian; Gnome) Not-for-profit “Software Foundation” (Apache SF, Python SF, Django SF) Usually happens when big enough to involve money and lawyers. Office holders, “official” membership common pattern
  • 97. PROJECT GOVERNANCE Serious v. Not (silly) Vast majority of projects are side-projects. Generally side-projects are less serious but not necessarily. Is someone basing their career on it?
  • 98. ROLES There is usually identifiable author or leader. Is there an identifiable team? What roles are there? What roles aren’t there?
  • 99. ROLES BDFL Benevolent Dictator/s For Life More commonly used in this era. Usually original author/s. Though there are exceptions. Dictates final decisions, arbitrage and ends disputes. Project leader for so long
  • 100. ROLES Release Manager Packaging Pass tests Right documentation Right internationalisation (i18n) No “release blocking” bugs Release announcement. Project leader for so long
  • 101. ROLES System Admin (servers, etc) Website Artwork Licenses Answering Questions Newb wrangling (we were all newbs once, we’re all newbs about most things ever, it’s just a phase) Karen/Russ, django users
  • 102. GETTING INVOLVED How many people use version control regularly/proficiently? 101 stuff ... most of are self-taught in most areas, worth glossing over.
  • 103. START SMALL A lot of people’s FOSS careers start with a one character patch. (particularly to big, old, established projects) You don’t have to “prove” your mad-coding-skillz or change the world in your first commit, moreover you certainly shouldn’t. If you know everything else I’m going to talk about here, but still aren’t involved: Particularly to big, old, established projects Goes against our instinct
  • 104. START SMALL Projects hate: Big, unexplained patches from people unknown to the community. Not impressive. Big old projects may dismiss out-of-hand. “dropping bombs” “drive by shootings” Even if it’s good code -- it’s just not done that way. It’s got to be consumable by the project.
  • 105. START SMALL Break up your feature in to patches. should do this anyway.
  • 106. VERSION CONTROL AKA SOURCE CONTROL MANAGEMENT (SCM) How many regularly use version control? Don’t want to bore to tears.
  • 107. VERSION CONTROL BASICS Assume: THERE IS NO UNDO BUTTON Everything you commit is on the public record. Forever. Commit with care. Do NOT be reckless.
  • 108. WHAT IS VERSION CONTROL? Writing code is easy, constructing programs is hard. Many people working on same codebase is hard. Solution: take small, logical, incremental steps. in the form of ...
  • 109. ALWAYS SMALL Always take the time to break up your patch into the smallest, logical unit. Easier to understand for everyone (committer, future-you). Easier to revert. Rule of thumb: what you may need to revert.
  • 110. DIFF/PATCH
  • 111. DIFF/PATCH The tiny step is called a: patch Small, logical, incremental steps. Official terms: diff and patch. These were the original tools that were used. Atomic unit of code development. Patch originally written by Larry Wall Tapes, TAR in the beginning, actually learning SCM takes years
  • 112. DIFF/PATCH Put code changes into standardised format. Standard is: “unified format” (or “unidiff” or “-u”) $ diff -u ... Atomic unit of code development. Tapes, TAR in the beginning, actually learning SCM takes years
  • 113. DIFF/PATCH
  • 114. DIFF/PATCH
  • 115. UNIDIFF wikipedians may be familiar
  • 116. UNIDIFF A PATCH! any unidiff scm will be able to “APPLY” this you can write these by hand if you want can be reversed (or “reverted”) some examples without original source
  • 117. DIFF/PATCH
  • 118. DIFF/PATCH
  • 119. UNIDIFF
  • 120. DIFF/PATCH Congratulations! You have a patch file! Atomic unit of code development. Tapes, TAR in the beginning, actually learning SCM takes years
  • 121. The patch/s are then “sent*” to the project. *what this means varies. Atomic unit of code development. Tapes, TAR in the beginning, actually learning SCM takes years
  • 122. COMMITTING/INTEGRATING Code change is then committed or integrated in to a version of project. Though it’s normal for patches to be rejected. Your patch might directly conflict with someone else’s work. this is known as a merge-conflict and usually needs human arbitrage to fix.
  • 123. ... sent* to the project ...
  • 124. SEND/MERGE/COMMIT/ PUSH/PULL-REQUEST ... sent* to the project ... This is where projects become so divergent own research needs to be done to on this process. A lot of project use multiple integration methods. Atomic unit of code development. Tapes, TAR in the beginning, actually learning SCM takes years
  • 125. PATCH SUBMISSION: LINUX KERNEL EXAMPLE Very strong rules. Very clear guidelines. https://www.kernel.org/doc/Documentation/ SubmittingPatches 5,000 word piece of documentation which is strongly adhered to.
  • 126. PATCH SUBMISSION: LINUX KERNEL EXAMPLE Patches to Linux Kernel are submitted by email. They get a lot of email: lkml.org/lkml/2013/ 20-25 emails an hour, depending where in the world
  • 127. SOURCE CODE MANAGEMENT (SCM) SYSTEMS
  • 128. WHAT IS SOURCE CODE MANAGEMENT (SCM)?
  • 129. WHAT IS SOURCE CODE MANAGEMENT (SCM)? Where is your MASTER codebase repository?
  • 130. WHAT IS SOURCE CODE MANAGEMENT (SCM)? Where is your MASTER codebase repository? Early version control system: CENTRALISED SERVER
  • 131. CENTRALISED VERSION CONTROL
  • 132. CENTRALISED VERSION CONTROL FIRST GENERATION SCM + - Provides development history Manages files individually Only one person editing at a time No merge capability eg, SCCS (1972), RCS (1982 free and more evolved) rcs 1982
  • 133. CENTRALISED VERSION CONTROL CVS (CONCURRENT VERSIONS SYSTEM) + + - Parallel development Merge & conflict resolution (based on diff/patch) Poor rename and directory support Poor branch merging Most operations require contacting centralised server Dominated FOSS 1991 to 2005. Use can still be found. 1990
  • 134. CENTRALISED VERSION CONTROL SUBVERSION (SVN) + + - ‘CVS done right’ Project-wide revisions Each developer has ‘checkout’ Most meta-data is only stored on central server Committing require contacting central server Very commonly used before new generation. Still commonly used.
  • 135. WHAT IS SOURCE CODE MANAGEMENT (SCM)? Where is your MASTER codebase repository?
  • 136. WHAT IS SOURCE CODE MANAGEMENT (SCM)? Where is your MASTER codebase repository? Since early 2000s DISTRIBUTED Everyone gets a ‘clone’: + entire codebase + entire revision history
  • 137. CENTRALISED VERSION CONTROL
  • 138. CENTRALISED VERSION CONTROL
  • 139. DISTRIBUTED VERSION CONTROL
  • 140. DISTRIBUTED VERSION CONTROL BAZAAR (BZ) MERCURIAL (HG) DARCS MONOTONE (peer-to-peer) GIT Since great Distributed Version Control wars of ~2005 started in the 90s, blew out ’02-05 when linux switched to not GIT (bitkeeper)
  • 141. Currently has a lot of support and momentum. People say it’s complicated. TAKE CARE MENTALLY VISUALISING STATE OF CODE necessarily complicated! install git
  • 142. WHAT IS A GIT REPOSITORY? Any file tree with the special /.git directory ~ delete and ceases to be ~ can put anywhere and it will try and figure out
  • 143. WHAT FILES ARE IN A GIT REPOSITORY? Explicitly add and rm files to/from repository can put in any dir, but won’t know until you tell it.
  • 144. WHAT FILES ARE IN A GIT REPOSITORY? Explicitly add and rm files to/from repository Be specific: $ git add hello.txt Or general: $ git add . can put in any dir, but won’t know until you tell it.
  • 145. WHAT FILES ARE IN A GIT REPOSITORY? You can explicitly tell git to ignore the existence of certain files listing files to be ignored in: .gitignore This can be per directory. Gotcha: .gitignore won’t work on files you’ve already added.
  • 146. GIT CLONE ~ all revision history ~ entire working codebase
  • 147. GIT CLONE Find an open source repository. ~ all revision history ~ entire working codebase
  • 148. GIT CLONE Find an open source repository. $ git clone https://github.com/jquery/jquery.git ~ all revision history ~ entire working codebase
  • 149. GIT CLONE Find an open source repository. $ git clone https://github.com/jquery/jquery.git ~ all revision history ~ entire working codebase
  • 150. GIT CLONE Find an open source repository. $ git clone https://github.com/jquery/jquery.git ~ all revision history ~ entire working codebase
  • 151. GIT CLONE Find an open source repository. $ git clone https://github.com/jquery/jquery.git ~ all revision history ~ entire working codebase
  • 152. GIT CLONE Find an open source repository. $ git clone https://github.com/jquery/jquery.git The the code is yours. All yours. ~ all revision history ~ entire working codebase
  • 153. MAKE CHANGES FORK If you’re going to make changes then fork the project. Only make changes to your own tree. Forking used to be an anathema.
  • 154. MAKE CHANGES BRANCH Create branch: $ git branch mydevbranch Use branch: $ git checkout mydevbranch
  • 155. MAKE CHANGES GENERATE PATCHES So you’ve changed the code. On your own fork. On a development branch. You need patches.
  • 156. WHAT’S GOING ON IN A GIT REPOSITORY? $ git status Will recognise file changes. Automatically translate to patches/hunks.
  • 157. WHAT’S GOING ON IN A GIT REPOSITORY? $ git status Recommended GUI tools Linux: gitg others: SourceTree
  • 158. git-scm.com/downloads/guis
  • 159. GIT WORKFLOW 1. Make code changes. Study your newly created patches/hunks. (debug, debug, check, check, proof, proof)
  • 160. GIT WORKFLOW 1. Make code changes. Study your newly created patches/hunks. (debug, debug, check, check, proof, proof) 2. “Stage” patches/hunks (using $ git add or GUI tool)
  • 161. GIT WORKFLOW “Stage” patches (using $ git add or GUI tool)
  • 162. GIT WORKFLOW 1. Make code changes. Study your newly created patches/hunks. (debug, debug, check, check, proof, proof) 2. “Stage” patches/hunks (using $ git add or GUI tool) 3. “Commit” staged changes to the repository.
  • 163. GIT WORKFLOW 1. Make code changes. Study your newly created patches/hunks. (debug, debug, check, check, proof, proof) 2. “Stage” patches/hunks (using $ git add or GUI tool) 3. “Commit” staged changes to the repository. (using $ git commit -m “handy mandatory message”)
  • 164. “Commit” staged changes
  • 165. “Commit” staged changes
  • 166. VERSION CONTROL BASICS Assume: THERE IS NO UNDO BUTTON Everything you commit is on the public record. Forever. Commit with care. Do NOT be reckless.
  • 167. VERSION CONTROL BASICS Rule #0: Assume everything you commit is FINAL and FOREVER Rule #1: NEVER commit your PASSWORDS or any other sensitive or personal settings or information.
  • 168. VERSION CONTROL BASICS Rule #: Don’t commit buggy code. Way to burn trust and respect. Rule #: Atomic changes. That is: SMALL, logical changes. Break up feature in to a bunch of smaller patches. Drive-by patches are universally despised. whole weekend
  • 169. VERSION CONTROL BASICS Rule #: Explain yourself. Be terse, clear and explain why change is necessary. Rule #: The committer’s time is probably more valuable than yours. Being fewer of them it’s probably true.
  • 170. COMMITTING Congratulations! You have a commit. Atomic unit of code development. Tapes, TAR in the beginning, actually learning SCM takes years
  • 171. PUSHING Atomic unit of code development. Tapes, TAR in the beginning, actually learning SCM takes years
  • 172. Got it? you make a change, you ask the main project to “pull” it in to their project
  • 173. COMMITS/PULL REQUESTS
  • 174. COMMITS/PULL REQUESTS Committed patches may then be “pulled” in to a version of project.
  • 175. COMMITS/PULL REQUESTS Committed patches may then be “pulled” in to a version of project. They usually don’t do this automatically.
  • 176. COMMITS/PULL REQUESTS Committed patches may then be “pulled” in to a version of project. They usually don’t do this automatically. You ask the “upstream” to accept your commit using a pull-request
  • 177. COMMITS/PULL REQUESTS Committed patches may then be “pulled” in to a version of project. They usually don’t do this automatically. You ask the “upstream” to accept your commit using a pull-request pull-requests are regularly not accepted. (it’s not personal).
  • 178. CONTRIBUTING “STYLE” Learn the “style” of the existing project. Phrasing, structure, etc. There will probably be rules. Follow them. eg: PEP8 If in doubt: copy Don’t make up a new style, you’ll look like a fool -- ASK! NOW you have TOOLS to COMMUNICATE and CONTRIBUTE TOO BIG: RKM learnt in weekend, core within a month or two. But noone on earth doing for linux kernel -- drive by shootings, gotta know you, trust you -LINUXCON LAST WEEK
  • 179. CONTRIBUTING COMMUNICATE Shallow and Often . NOW you have TOOLS to COMMUNICATE and CONTRIBUTE TOO BIG: RKM learnt in weekend, core within a month or two. But noone on earth doing for linux kernel -- drive by shootings, gotta know you, trust you -LINUXCON LAST WEEK
  • 180. CONTRIBUTING COMMUNICATE Don’t be out on a limb! . NOW you have TOOLS to COMMUNICATE and CONTRIBUTE TOO BIG: RKM learnt in weekend, core within a month or two. But noone on earth doing for linux kernel -- drive by shootings, gotta know you, trust you -LINUXCON LAST WEEK
  • 181. SAY THANK YOU Occasionally send an email or make a post saying: “Thanks!” No matter how big or famous a project, there’s usually more criticism than thanks. It’s nice to be grateful :)
  • 182. AN EXISTING PROJECT
  • 183. DON’ T ASK ME NOW you have TOOLS to COMMUNICATE and CONTRIBUTE TOO BIG: RKM learnt in weekend, core within a month or two. But noone on earth doing for linux kernel -- drive by shootings, gotta know you, trust you -LINUXCON LAST WEEK
  • 184. Growing Open Source Seeds How (Not) To Build An OSS Community Kenneth Reitz * Hello * Enjoying PyCon? Food Coma? * Talk about something near & dear: community Questions? github.com/kennethreitz Thanks. Questions? @daniellindsley https://github.com/toastdriven Running an open source project
  • 185. BE CORDIAL OR BE ON YOUR WAY
  • 186. OPEN SOURCING A PROJECT “cookiecutter” projects on github. Detailed blog posts.
  • 187. EXISTING PROJECTS Do you actually want help? “My Precious” Let others in. Consider the benefits of help! All the things you no longer have to think about.
  • 188. EXISTING PROJECTS Think about what needs to be done. Write a post about how other people can do. If you want help, be specific. Explain exactly what and how. Write a list. Make tasks and issues.
  • 189. EXISTING PROJECTS INSTALLATION and DEPENDENCIES For the love of humanity ... Ensure it’s possible to compile/install! er, documentation? Write it down as you’re doing it.
  • 190. EXISTING PROJECTS TEST DATA For the love of humanity ... Give us something to play with! JSON, XML, Sqlite3, scripts ... anything ...
  • 191. GOOD LEADERSHIP Don’t REJECT or REVERT without an explanation. Contact the contributor before you do it. Don’t let them find out publicly first. It’s gutting to have something rejected, but there’s usually a good reason -- explain it! It makes it OK.
  • 192. EXISTING PROJECTS COMMUNICATE 95% of human problems ... are caused by and can be solved by ...
  • 193. EXISTING PROJECTS COMMUNICATE Shallow and Often .
  • 194. EXISTING PROJECTS COMMUNICATE Things that seem obvious, often aren’t obvious. .
  • 195. EXISTING PROJECTS COMMUNICATE ... that includes listening. .
  • 196. EXISTING PROJECTS BURNOUT Take time off. Ignore everything except security issues. NOW you have TOOLS to COMMUNICATE and CONTRIBUTE TOO BIG: RKM learnt in weekend, core within a month or two. But noone on earth doing for linux kernel -- drive by shootings, gotta know you, trust you -LINUXCON LAST WEEK
  • 197. EXISTING PROJECTS BE NICE If someone leaves: Thank, don’t bitch Don’t bitch about open source project without contacting owners, reporting bug (random blog post!) >> if anyone you know does this call them out on it. NOW you have TOOLS to COMMUNICATE and CONTRIBUTE TOO BIG: RKM learnt in weekend, core within a month or two. But noone on earth doing for linux kernel -- drive by shootings, gotta know you, trust you -LINUXCON LAST WEEK
  • 198. LICENSES Don’t want to go too deep on licenses. It’s boring as batshit If you care, you care a lot.
  • 199. LICENSES Bad license decisions have long term consequences. Unfortunately there are no easy answers.
  • 200. LICENSES Original samba license: Copyright (C) Andrew Tridgell 1992. Permission to use, copy and distribute this software is given to anyone who wants to, for NON-PROFIT only. You may not charge for this software or any derivatives of it without first contacting the Author.
  • 201. LICENSES OSI lists 63 approved licenses, 9 as 'widely used' GNU lists 81 free software licenses plus 28 non-free licenses
  • 202. LICENSES GPL GNU Public License. You must keep the software open. You must give your changes back.
  • 203. LICENSES GPL V2 pre-GPLv3 (2007) FOSS Licenses were much simpler. 75%+ projects were GPL. If you liked a company, you would license as LGPL. Number of other licenses, notably: BSD (Berkely) LGPL: ● Allows linking with proprietary programs ● Also used to avoid inter-project licensing problems
  • 204. LICENSES GPL V3 (2007) Written to address: ● Internationalisation and clarification of legal language ● Stronger patent provisions ● Prevention of hardware restrictions (“tivoisation”) ● Optional clauses to aid license interoperability ● DMCA avoidance (“effective technological measure”) It is a very good license. Arguably too good. There has been a trend away from GPL. It would be impossible for apple to comply with the GPLv3 license requirements on iPad and iPhones unless they license devices' security systems as same. GPLv3 licensed software will not get in to any app store. full stop.
  • 205. LICENSES COMPATIBILITY Probably not fun. ~15% of all repositories had license files ~25% of those have the license only mentioned in the Readme file Read more: Armin Ronacher (author of Flask), Late July, 2013 Can tell because people like Apple and Google don’t want a bar of it.
  • 206. LICENSES POST-GPL Interesting Times Most popular: GPL Apache Software License 2.0 (ASL2) BSD (with additional clauses) (do whatever you like, just don’t sue me, even close source) MIT (do whatever you like, just don’t sue me)
  • 207. LICENSES Mongrel: popular ruby web server Zed Shaw Under one of “please don’t sue me” licenses. Later regretted decision. Until recently “Twitter” used it (on top of Apache).
  • 208. LICENSE: ZED SHAW “Open source to open source, corporation to corporation. If you do open source, you’re my hero and I support you. If you’re a corporation, let’s talk business.”
  • 209. LICENSES Watch this space.
  • 210. TOOLS Learn to use: Text Editor (pick a good one, learn to use it well) Source Control Management (SCM) (eg: git) These take YEARS to learn!
  • 211. TOOLS Learn to use: Issue tracker (not as obvious as it seems) IRC Mailing-lists “Design decision needed”/“close” v. “feedback” fields you should and shouldn’t fill in
  • 212. TOOLS Learn to use: Command Line (CLI) (eg: bash) grep (or ack) and find Regular Expressions (aka: regex) NOW you have TOOLS to COMMUNICATE and CONTRIBUTE TOO BIG: RKM learnt in weekend, core within a month or two. But noone on earth doing for linux kernel -- drive by shootings, gotta know you, trust you -LINUXCON LAST WEEK
  • 213. TOOLS Learn to: WRITE (clearly) Popular markups: ReST Markdown Honestly these 10-odd tools are my day-to-day everything.
  • 214. SAYING: I DON’T KNOW Harry Kroto On feeling stupid: Everyone does. Everyone is about most things. The “best” leverage this to their advantage (usually very humble.) HE ... was IT’S a CONTINUUM
  • 215. ASK/LISTEN Rule of Thumb: stuck for ½ hour. Go to: IRC, mailing-list Don’t agonise, spare yourself the pain! Often: ~ experienced people can see/feel you struggling (but seldom say anything) ~ so, in short term you feel like gumby BUT: learn something, might actually look clever ~ in medium term: your corpus is building faster
  • 216. ASK/EXPLAIN State as simply as possible. State it up front. Time is precious: be terse terse təәrs/ adjective 1. sparing in the use of words; abrupt. "a terse statement" synonyms: brief, short, to the point, concise, succinct, crisp, pithy, incisive, No fluffy language, no big explanation. BE CORDIAL Just get to the core of it.
  • 217. BEING INVOLVED Names/code to Faces/personalities
  • 218. TURN UP! Decisions are made by the people who turn up. Hackerspaces User Groups Conferences Congratulations you are already here. Connect and develop.
  • 219. SET PEOPLE’S EXPECTATIONS Probably the most valuable thing I’ve learnt in the last 5 years.
  • 220. CONTRIBUTING COMMUNICATE Find the venues to do so. Mail-list Might be several! IRC Issue Tracker Wiki NOW you have TOOLS to COMMUNICATE and CONTRIBUTE TOO BIG: RKM learnt in weekend, core within a month or two. But noone on earth doing for linux kernel -- drive by shootings, gotta know you, trust you -LINUXCON LAST WEEK
  • 221. BEING INVOLVED Real world is not uni. Flexible FOSS is really flexible. Young projects can turn on a dime for your idea. Envisioning and implementing all the fine details is expensive for new projects.
  • 222. TELL PEOPLE WHAT YOU’RE DOING For their sake. Save them from wondering.
  • 223. DO WHAT YOU SAY YOU’RE GOING TO DO But, if you can’t communicate! FOSS people are spectacularly understanding.
  • 224. Don’t get disheartened. All mistakes will eventually be washed clean by time and entropy. Communities are very robust.
  • 225. INTERESTING TIMES Stream-lined ability to contribute/communicate. Culture is changing: tech is becoming mainstream. Re-learning old lessons. Not just chicks, it’s older, multicultural.
  • 226. INTERESTING TIMES Stream-lined ability to contribute/communicate. Culture is changing: tech is becoming mainstream. Re-learning old lessons. Demographic imbalance is being addressed. Not just chicks, it’s older, multicultural.
  • 227. CHANGING DEMOGRAPHICS Difference is a continuum. Shared culture and technical knowledge. Skills! Not just chicks, it’s older, multicultural.
  • 228. INTERESTING TIMES Stream-lined ability to contribute/communicate. Culture is changing: tech is becoming mainstream. Re-learning old lessons. Demographic imbalance is being addressed. Copyright is being questioned. Patent-wars. WATCH THIS SPACE
  • 229. CONCLUSION There will always be some form of “Open Source”. People like us will make it happen. This is the version we’ve currently got and it’s changing.
  • 230. THANK YOU!
  • 231. Contributors: Be Cordial • Keep all interactions with a maintainer as respectful as possible. • They have likely donated a significant amount of time and energy into their project. • They don’t owe you a moment of their time.
  • 232. Maintainers: Be Cordial • You have the crucial responsibility of being immensely thankful to all contributors. • • • They are the lifeblood of your project. Ignore non-constructive feedback. Some people just take things too seriously.
  • 233. Maintainers: Be Cordial • Be careful with the words you chose. Contributors sometimes take what you say very personally. • • Take the opportunity to educate the user. • A little bit of kindness goes a long way. This could be their first ever interaction with an open source project.
  • 234. Sustainability • Sustainability is one of the biggest challenges of open source. • • Everyone has a limited amount of time. It’s easy to become the bottleneck of your own projects.
  • 235. Just Say No
  • 236. Learn to Say No • • Saying ‘No’ is extremely difficult. • If you say yes often, your project will be ruined. Tragedy of the Commons. People ask for crazy features. They send seemingly practical pull requests. They are trying to help. But it’s HOW YOU SELL IT ...
  • 237. Don’t make it complicated.
  • 238. Open source makes the world a better place.
  • 239. Focused Purpose Move together or be torn apart by momentum. * Be careful not to turn it into an end-all unless you’re sure it can be * Spin off advanced/specialized functionality as a plugin that builds on top
  • 240. Documentation Just because you built it doesn’t mean they will come. * Except for rare situations (absolute need or so sexy!), without this, no one will use it * Case in point: It’s why many of you know about Flask but virtually no one knows about Itty * Lack of docs means most people will get frustrated & move on
  • 241. Communication Will make or break you. * This goes along with focus * People want to know it’s actively developed on, what the future holds, how to get help, how they can help * IRC * Mailing lists * Website
  • 242. Make Contribution Easy It’s the only way you’ll get any contribution at all. * GH/BB model of fork & pull req * Define **how** others can contribute * I suck at this one
  • 243. Listen Graciously accept both positive & negative feedback. * You should consider yourself a success when you acquire haters * Remember there are lots of happy people who are quietly using the software * I’m super-thin-skinned, so I struggle with this one nightly