Your SlideShare is downloading. ×
Developing Open Source Leadership
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Developing Open Source Leadership

1,543
views

Published on

Guy Martin, Senior Strategist with Open Source Group, discusses how you can build open source leaders within your enterprise.

Guy Martin, Senior Strategist with Open Source Group, discusses how you can build open source leaders within your enterprise.

Published in: Technology, News & Politics

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,543
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
21
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • SRA Open Source Group can help navigate licenses and legal obligations - helping choose proper license based on our compliance experience.
  • 107
  • Transcript

    • 1. 1 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 1 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Guy Martin Senior Strategist, Open Source Group Samsung Research America guy.martin@samsung.com Developing Open Source Leadership
    • 2. 2 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) About Your Instructor • 21 years in software/technology • 12 years in open source • Leading strategy for Samsung Open Source Group • Built open source consulting/communities for several organizations
    • 3. 3 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) About This Course • You’ll get out of it what you put into it • Training is just the beginning • Open source is > 50% collaboration – so is this course • Please ask questions :)
    • 4. 4 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Course Content • Open Source Development Model • Best Practices • Communication & Community Skills
    • 5. 5 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 5Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Open Source Leadership Why and How?
    • 6. 6 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Product Dependency on Open Source Technologies
    • 7. 7 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) New Open Source Skillsets
    • 8. 8 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Open Source Strategy Consumer Participant Contributor Leader Start here! Decide on the desired position based on company’s OSS strategy
    • 9. 9 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Contributor Scenario - Recommendations • Actively participate • Follow community development processes • Contribute to development, documentation and testing efforts • Hire open source developers • Build up internal open source leaders • Host open source activities, meetings, events, etc.
    • 10. 10 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Leader Scenario • Leadership roles in open source communities are earned by establishing trust with the project members, and by maintaining a high level of continuous contribution to the project • Requires significant investment in targeted open source communities and consortia to establish leadership agenda • Requires incremental investment primarily in engineering, product management and legal organizations
    • 11. 11 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Leader Scenario – IBM Example 2001
    • 12. 12 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Leader Scenario – Recommendations • Achieve a higher level of contributions • Empower employees to seek contributor and maintainer status • Sponsor events, provide financial support for the projects • Establish open source office • Establish an open source architect role(s) to pro-actively guide the use of and contributions to open source software • Open source proprietary technologies • Lead architectural and requirements initiatives within these communities and consortia to achieve commercial objectives
    • 13. 13 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 13Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Open Source Development Model
    • 14. 14 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Closed Source Process Software Client Software Vendor Requirements Design Implementation Test / Integration Deployment Maintenance
    • 15. 15 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Open Source Model User Community Developer Community Project or Feature Ideas Architecture and Design Discussion Implementation (coding) Continuous Testing and Integration Deployment (release) Maintenance Patches (submitted by developers and users) Feature Requests (submitted by developers and users) Test Projects to Automate Testing and Validation
    • 16. 16 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Open Source Model Characteristics 1. Distributed development 2. Development community 3. Community organization 4. Scalable development 5. Decision process 6. “Release early, release often” 7. Submitting code 8. Taking responsibility 9. Giving credit to others 10.Peer review 11.Continuous testing 12.Gaining influence 13.Modular designs
    • 17. 17 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Distributed Development • Characteristics – Worldwide teams working in their own local time zone – Communication channels that reduce the impact of language barriers – Responsibility for development allocated to the individual or team with best capacity to deliver – Strict quality standards when changing code – Multiple levels of review before entering final release • From an organizational perspective, it’s not that different from traditional large scale software development
    • 18. 18 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Development Community • Accessible to newcomers – Open development generally strives for inclusiveness • Focused on visibility – Strong emphasis on open decision making processes and communication • Self-organizing – Most projects take guidance from internal sources (i.e., the people doing the work)
    • 19. 19 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Community Organization • Tight vertical hierarchy • Loose horizontal structure • Small incremental changes flow upward Maintainer Subsystem maintainer Subsystem maintainer Subsystem maintainer Sub-subsys tem mainta iner Sub-subsys tem mainta iner Sub-subsys tem mainta iner Sub-subsys tem mainta iner Sub-subsys tem mainta iner Developer Developer Developer Developer Developer Developer Developer Developer Developer Developer Developer Developer Developer Developer Meritocracy drives advancement and acceptance Not influenced by marketing
    • 20. 20 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Small project Large project A Scalable Development Model #include <file1.h> #include <file2.h> #include <file3.h> ... Single body of code Releases available “when they are ready” Single maintainer
    • 21. 21 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Small project Large project A Scalable Development Model Releases available “when they are ready” #include <file1.h> #include <file2.h> ... Code divided into subsystems #include <file1.h> #include <file2.h> ... Single maintainer
    • 22. 22 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Small project Large project A Scalable Development Model Release criteria become more stringent #include <file1.h> #include <file2.h> ... Code divided into subsystems #include <file1.h> #include <file2.h> ... Single maintainer
    • 23. 23 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Small project Large project A Scalable Development Model Release criteria become more stringent #include <file1.h> #include <file2.h> ... Code divided into subsystems #include <file1.h> #include <file2.h> ... Delegated maintainership
    • 24. 24 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Small project Large project A Scalable Development Model Delegated maintainership Releases overseen by dedicated maintainers #include <file1.h> #include <file2.h> ... Further subsystem divisions #include <file1.h> #include <file2.h> ... #include <file1.h> #include <file2.h> ...
    • 25. 25 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Decision Process • Decisions are decentralized by appointing trusted delegates – In Linux, called “subsystem maintainers” – Trust built by past record of good participation and wise decisions on smaller issues • Not all decisions need pass through delegates – Trivial fixes may go directly to any maintainer • Decentralized nature requires extra focus on transparency – Discussions must happen in the open: Mailing lists, IRC • Often the discussion itself is the documented record of the outcome
    • 26. 26 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Influence Within Open Source Communities • Influence in a project is based on reputation in that project/community – Reputation is gained through code contributions and participation – Reputation in one community doesn't necessarily carry to others – Reputation in own company doesn't carry to open source community – Must prove oneself on each project to gain influence • The writer of the best code has the most influence – It doesn’t matter who you are, who you work for, how it was done before, or how smart you are • Behavior is important – Willingness to take and provide feedback (politely) – Ability to explain motivations behind decisions
    • 27. 27 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Submitting Code to an Open Source Project • Well-defined, highly structured – Retrieve current source code from project repository – Write new code, generate patch using diff – Submit code as an email to appropriate subsystem maintainer, via project mailing list – Subsystem maintainer decides whether patch should be accepted or rejected – If accepted, maintainer will apply patch to their own tree – In complex projects, patch proceeds through several layers of maintainers, and appears in a main project release • Comprehensive list of guidelines can be found in: – Linux kernel sources (under Documentation/SubmittingPatches), and – http://linux.yyz.us/patch-format.html Development ongoing, with discussions on mailing lists or IRC Code functional, tests clean, ready for first integration Patch submitted to maintainer / mailing list Patch reviewed Patch integrated, tested, accepted by maintainer Patch integrated through maintainers’ trees Code integrated into mainline release Patchrejectedtobereworked
    • 28. 28 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Taking Responsibility for Source Code • OSS development methods favor extra scrutiny on code origins – Less direct oversight on any individual developer – Low barriers to entry in distributed development • Anonymous contributions are almost universally unwelcome – Who wrote this? – Who do we go to if there’s a problem? – What if it wasn’t submitted by the owner of the code? • Requiring submitters to claim ownership of their code using real names results in higher quality code and better maintenance – Credit can be given where due – If there are questions on the code, anyone can easily see who to ask – Each developer is personally guaranteeing the quality and the origin of the code
    • 29. 29 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 29Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Working with Upstream
    • 30. 30 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) What is Upstream? upstream (noun) – The originating open source software project upon which a derivative is built – This term comes from the idea that water and the goods it carries float downstream and benefit those who are there to receive it. to upstream (verb) – A short-hand way of saying "push changes to the upstream project“, i.e. contribute the changes you made to the source code program back to the original project dedicated for that program.
    • 31. 31 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) When is it Time to Start Contributing Upstream? • When the costs of keeping your code in sync with the mainline project exceed the convenience of working alone • When you want your code to be used by others (including customers) • When you want to drive your implementation to become a defacto standard, or drive adoption of the mainline project • If you anticipate relying on a certain codebase repeatedly in upcoming products that complements the mainline project
    • 32. 32 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Motivations for Contributing Upstream • Private code is never considered in public development – Integrating changes upstream means others are aware of them, and can plan for and around them – Reduces the risk of accidental breakage • Integrating changes into the mainline project reduces the amount of effort to build a finished product • Contributed code is reviewed and may attract external developers • Contributions strengthen and influence direction of project
    • 33. 33 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) What Should Go Upstream? • The decision of what source code to push to upstream is guided by your open source strategy • Generally, you should drive to upstream: – Technology enablers contributions – (non-strategic) code that will make your differentiating offering run better/faster/etc. – Source code that is of usefulness to all platform users – that they don’t want to maintain themselves – Source code that will help them influence the direction of the project – Source code that will help them push a given implementation to become defacto standard – Source code that will help them undercut the competition – Etc. • A good guide is to determine what parts of your product are sources of strategic advantage, and what supports those parts – The supporting parts are generally good candidates for upstream
    • 34. 34 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Typical Upstreaming Process Identify in-house modifications Are there dependencies on private code? Does it meet coding and security standards? Obtain company approval to participate by following your company’s technical and compliance policies Plan the submission strategy Prepare the code for submission (code style, generate patch, verify it applies properly, etc.) Follow the project’s submission process Maintain the code, update it based on feedback and contributions from others Rework the code Yes No Not accepted – Take feedback
    • 35. 35 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 35Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Best Practices: Requirements
    • 36. 36 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Propose New Features & Signal Intent • Public discussion is a prerequisite – Ensures maintainers are aware of the need and the problems you are working to solve – Recruit others to help do the work – Gather feedback on the usefulness and design considerations before doing a lot of work (and being rejected) – Some projects have active mailing lists, multiple tries may be needed • Over-communicate – Assume you have one chance to convince others
    • 37. 37 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Propose New Features & Signal Intent • Accept incoming feedback and work with it – Incorporating feedback increases the likelihood a contribution will be accepted – Feedback is generally legitimate, as others will only take time to respond if what you’re doing is important to them • How it happens in Linux: – When a feature request is controversial, it generally requires public discussion on the Linux Kernel Mailing List (lkml) before code is considered
    • 38. 38 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Getting Buy-in for a Feature Request • Contributed features should be: – Useful to others and not just to your specific usage models • Features that benefit only a few users will tend to be rejected if there is no benefit to the majority – Implemented in small parts, and delivered in a way that provides immediate benefit – Strong on security • Open Source developers tend to be more security conscientious than closed source developers – Backed by resources ready to implement and maintain • Don’t ‘dump code and run’
    • 39. 39 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Typical Feature Request Process • What happens in this phase: – Requester’s opportunity to make the case for why the project should plan for their feature – In most cases, the requester already has enough resources to implement the feature • Typical actions: – Requester/developer sends email to a project mailing list • The need for the feature • The problem it solves • How it fits into the project • Possible implementations Feature request sent to mailing list Discussion on mailing list and IR C Feature request is accepted Feature is tracked Feature is prioritized Feature aligned with future releas e Development / QA
    • 40. 40 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Typical Feature Request Process • What happens in this phase: – Interested parties are given an opportunity to comment – Major or intrusive feature requests will typically be discussed in great detail – Other Opportunity to recruit other development resources to help implement • Typical actions: – Initial email stimulates discussion on the mailing list – Maintainer may comment on when the project would be ready to accept feature – Comments range from brief approval, to detailed implementation considerations Discussion on mailing list and IRC Feature request sent to mailing li st Feature request is accepted Feature is tracked Feature is prioritized Feature aligned with future releas e Development / QA
    • 41. 41 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Typical Feature Request Process • What happens in this phase: – Maintainer and other interested parties agree • Feature is strategic to project • Belongs on roadmap • Implementation is ok • Typical actions: – General consensus that feature will be beneficial to project – Acknowledgement that feature will not impact • Stability • Security • Functionality of project – Maintainer gives approval Feature request is accepted Feature request sent to mailing li st Discussion on mailing list and IR C Feature is tracked Feature is prioritized Feature aligned with future releas e Development / QA
    • 42. 42 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Typical Feature Request Process • What happens in this phase: – Most projects or subsystems within a project have a process for tracking features in upcoming releases – This is often considered the authoritative record of what was proposed and accepted • Typical actions: – Developer adds detailed feature information into tracking tool Feature is tracked Feature request sent to mailing li st Discussion on mailing list and IR C Feature request is accepted Feature is prioritized Feature aligned with future releas e Development / QA
    • 43. 43 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Typical Feature Request Process • What happens in this phase: – Maintainers prioritize features • What is core to the project • What is needed, and when – Maintainers generally have a global view of dependencies and future deliverables, and may prioritize to align features. – Minor features and enhancements may be requested as soon as they are ready. • Typical actions: – Maintainer may determine the priority of the request relative to other queued features Feature is prioritized Feature request sent to mailing li st Discussion on mailing list and IR C Feature request is accepted Feature is tracked Feature aligned with future releas e Development / QA
    • 44. 44 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Typical Feature Request Process • What happens in this phase: – Project maintainer communicates when they will be ready to integrate the feature. – This helps them plan for a manageable number of features per release. • Typical actions: – Maintainer may assign feature to a specific release. Feature aligned with future release Feature request sent to mailing li st Discussion on mailing list and IR C Feature request is accepted Feature is tracked Feature is prioritized Development / QA
    • 45. 45 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Typical Feature Request Process • What happens in this phase: – Developer and any other resources recruited in former steps begin implementing the feature, targeting the release set by the maintainer. • Typical actions: – Development team begins work. Development / QA Feature request sent to mailing li st Discussion on mailing list and IR C Feature request is accepted Feature is tracked Feature is prioritized Feature aligned with future releas e
    • 46. 46 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 46Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Best Practices: Design
    • 47. 47 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Design In the Open • Communicate early and often on mailing lists • Provide examples and possibly reference implementations • Anticipate feedback – Acknowledge good feedback and re-work your contribution • Respond promptly to questions, particularly from potential contributors – Signal willingness to adapt your design if someone else will do the work • Plan for modularity, even if the first designs are not
    • 48. 48 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Recruit Others • Scratch your own itch, nobody else will scratch it for you… unless they have the same itch • If you are wanting to decrease your development burden, write code that will attract others for the same reason – Make sure your contribution is scoped broadly enough to attract other contributors – Be responsive and proactive if someone indicates interest in your email to the mailing list • Don’t be surprised if it’s a competitor – Often the companies with the most to gain from a feature in an open source project are in the same line of business – There is a rich history of collaboration between competitors
    • 49. 49 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Design for Acceptance • Design your contribution to be written and integrated in the smallest parts possible – Smaller patches are easier for maintainers to integrate – Many open source projects favor a modular approach, because it promotes extensibility • Scope the design, and subdivide your plans if necessary – Larger changes are more likely to be adopted if a series of smaller changes with concrete milestones – Communicate the overall plan to provide context, but don’t expect universal buy-in • Be as non-intrusive as possible to other subsystems – If you believe you need to change a core system component, communicate far in advance and solicit input from their maintainers before getting started
    • 50. 50 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 50Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Best Practices: Implementation
    • 51. 51 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Be Agile • The line between design and implementation is very blurry in open source development – Multiple iterations are expected and encouraged • Don’t expect perfection the first time – Code stabilization is part of the community process – Allow the developer community to help guide and shape the code
    • 52. 52 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Start From a Fresh Pull From the Right Tree • It is not uncommon to have many versions of the same project – Each maintainer may have their own tree – Some projects maintain stable and development trees • In almost all cases, you should base your work on the tree that builds the official release – In Linux, this is Linus’ tree on kernel.org • Ultimately the project maintainer is final arbiter on what gets accepted – If your patch does not apply cleanly to their tree, it will be rejected • Never assume code as a dependency that isn’t already part of mainline, unless you’re submitting it yourself – It’s impossible to test without replicating your custom setup, and maintainers usually don’t have the resources to do this
    • 53. 53 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Implement Functionality in Smallest Reasonable Chunks • Will result in more constructive feedback – Easier to understand small patches • Simplified testing – A small change is less like to have unintended consequences – Very important because of lack of traditional test phase • You will be expected to submit in small parts
    • 54. 54 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Reuse Existing, Accepted Code Wherever Possible • It makes your contribution smaller • It reduces the code you must personally debug and maintain • It increases your chance of acceptance – Maintainer already familiar with accepted code – Most maintainers are very averse to duplicating existing functionality • If existing code has most of the functionality you need, submit a patch to extend it – Always try this before building your own – If this is for a key dependency, get your patch accepted before beginning work in earnest on the main feature
    • 55. 55 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Typical Patch Submission Process Development ongoing, with discussions on mailing lists or IRC Code functional, tests clean, ready for first integration Patch submitted to maintainer / mailing list Patch reviewed Patch integrated, tested, accepted by maintainer Patch integrated through maintainers’ trees Code integrated into mainline release Patchrejectedtobereworked
    • 56. 56 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Creating a Patch • The patch should be created against the most recent version of the mainline source code • The patch should be offset from the root of the tree • The patch must apply cleanly • A freshly-patched version of the code should build without errors • A patch should do one thing, and do it well http://lwn.net/Articles/139918/
    • 57. 57 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Writing a Patch Email 1. Find and follow project guidelines on how to format patch emails – Some projects use scripts to extract patch information from emails 2. Send one patch per email – Particularly true when sending large numbers of related patches 3. Include [PATCH] in the subject line – Mailing lists usually have a lot of traffic
    • 58. 58 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Writing a Patch Email 4. Maintain threading when replying – When sending an update, reply to your original message 5. Numbers don’t lie – Include benchmarks or quantitative justification for your approach 6. Avoid attachments and MIME – Both can cause errors for scripts that automatically import accepted patches
    • 59. 59 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Deconstructing a Linux Patch Email To: subsystem.maintainer@project.org CC: project-mailing-list@project.org Subject: [PATCH {version} {x/y}] {Subsystem}: {Single-line description} Body: {Detailed description of changes to go into git log} Signed-off-by: Developer Name <developer.email@example.com> Acked-by: Another Person <another.person@company.com> --- {properly formatted patch as plaintext} Sent to subsystem maintainer CC to the project mailing list Version of project If patch is part of series (e.g., 1/5) Area of the projec t patch applies Meaningful description Detailed explanatio n Patch content Required authorship line Optional acknowledgement Required delimiter http://linux.yyz.us/patch-format.html
    • 60. 60 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Be Patient and Persistent • Send patches and responses in public, never in private • Accept criticism, and rework the code • Make incremental changes that are well communicated • Resubmit the patch • Be persistent and polite
    • 61. 61 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) What if My Patch is Rejected? • Code may be rejected for any reason – Poor quality, inconsistent formatting – Too much function in one submission – Inconsistent with broader subsystem strategy • This doesn’t make you a bad coder – Revise and try again • When replying, filter unnecessary feedback and focus just on the technical aspects
    • 62. 62 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Escalation • Sometimes patches slip through the cracks • If you haven’t received an acknowledgement after a reasonable amount of time, resend it – Typically one week – Add this line to the top of the email: • “Patch escalation: no response for 7 days”
    • 63. 63 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Checklist Before Submitting Patch follows all coding style guidelines – Run scripts/checkpatch.pl to scan your patch for coding standard violations Patch applies cleanly against main project tree Project builds cleanly after patch is applied Patch is tested to do what it claims Header of file is documented properly, is in English, and follows kernel style guidelines
    • 64. 64 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Checklist Before Submitting  Patch email has: – A detailed subject line – Signed-off-by line – Detailed description of what the code does and why it is being submitted – Notification of any dependencies being sent as additional patches – Only one patch  Patch email is properly formatted – Follows code submission guidelines – Has no attachments – Is not in HTML or “rich text” format  Email is being sent to the right person, and CCs the proper mailing list
    • 65. 65 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Reporting Bugs • Not uncommon to uncover bugs in other peoples’ code during development • If the project uses Bugzilla – Search for duplicate bugs first – Report the bug in relevant components – File separate bugs for separate issues • If the bug is in the Linux kernel – Email the maintainer of the code, and cc linux-kernel@vger.kernel.org – Read the files REPORTING-BUGS and MAINTAINERS in kernel sources – If the bug include an ‘OOPS’ message, see Documentation/oops-tracing.txt – If you can, try to create a shell script that replicates the problem, and send it with your bug report – Running scripts/ver_linux in the kernel source will provide useful information for the bug report
    • 66. 66 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 66Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Best Practices: Testing
    • 67. 67 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Testing is Continuous • Source code change management processes favor continuous testing – Every developer works on a complete branch of the tree • Community processes require basic QA from the start – A patch must compile and meet basic standards before it will be considered at any level • Tools like git are built with continuous testing and integration in mind – Patches that cause problems can be found and reverted • Automated build suites help detect problems quickly – Detect major problems within 24 hours – May automatically file bugs in bugzillas • Some projects create and maintain test suites specific to their codebase – Community QA engineers may simultaneously develop the test suite and analyze the builds
    • 68. 68 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 68Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Best Practices: Maintenance
    • 69. 69 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Maintaining Your Code • Don’t “dump and run” – Abandoned code will be worked around and eventually removed • Disclose problems quickly, and provide workarounds and fixes – Pretending nothing is wrong will only buy you trouble • If you can’t maintain it, pass responsibility along to a successor, or arrange to have it removed – If your code is important, someone else will step up
    • 70. 70 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Responding to Bugs • Many projects use Bugzilla – Register an account, and contact the bugzilla maintainer to add your project and name to the list of components – You should be the default assignee – Respond promptly, and close or transfer bugs as appropriate • The Linux kernel uses email instead of bugzilla – Respond to bug emails promptly, and CC the kernel mailing list
    • 71. 71 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Accepting Patches to Your Code • If your code is useful, others may want to enhance it – Be open to the community process – Be available to the maintainer if asked for your input on a patch – Consider the technical comments people make on the code, and justify any disagreements that you have with them
    • 72. 72 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 72Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Open Source Community/Communication Skills
    • 73. 73 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) What are Communities?
    • 74. 74 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Rule #1 No two communities are exactly the same!
    • 75. 75 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Rule #2 Communities don’t work for individual companies
    • 76. 76 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Internal versus External • As leaders, you have to ‘manage’ internal vs. external expectations about open source projects you are involved in • You serve as a ‘consultant’ to other internal co- workers and managers who may not be as familiar with Open Source as you will be • Be honest with both groups – If you cannot comment to external community about something, tell them why (‘internal product decision’, etc.) – If the community wants something your company doesn’t, try to find common ground with both parties
    • 77. 77 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 77Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Preparing to Engage with Community
    • 78. 78 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Determine your Strengths There are many skills required in open source projects, and many roles to fill: • Software Developers • Testers/Quality Assurance • Documentation Writers • User Experience/GUI Designers • Evangelists/Communications Experts You can have more than one role if you have the time and necessary skills.
    • 79. 79 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Determine your Time Commitment • Commit to what you can realistically deliver • Communities respect completed work more than hollow offers of help • Your commitment reflects not only on you, but on your company
    • 80. 80 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 80Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Get to Know the Community
    • 81. 81 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Understand How the Community Communicates • Learn which methods are accepted & preferred: – Email lists – IRC – Web forums – Bug trackers • Observe and learn how questions are asked/answered – http://catb.org/~esr/faqs/smart-questions.html
    • 82. 82 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Understand How the Community Communicates • Before asking a question of the community – Search any message archives/logs for the answer – Read any user documentation – Search the web for the answer – Read any Frequently Asked Questions (FAQ) documents – Read the source code! – Experiment and document your experiments • Find the correct forum – Don’t post technical questions to a user list, for example – Show how you’ve tried to find the answer on your own
    • 83. 83 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Understand How the Community is Governed • Some communities (such as Linux Kernel) are hierarchies with clear chains of command • Some communities (such as the Debian project) are flat democracies • Understanding community governance helps you address your questions to the right audience
    • 84. 84 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Get to Know the People • Relationships (even virtual ones) matter in communities • Understanding how people work helps get your ideas accepted in the community • Participate in conferences/meetups as much as possible to help build ‘human networks’
    • 85. 85 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 85Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Engage with the Community
    • 86. 86 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Communicate What You’re Working On • Don’t work on something for the community ‘in private’ – Someone else will probably have duplicated your effort – Other changes in the project may obsolete/conflict with your work • Project maintainers can help plan for future releases if they know what’s coming • Community participants don’t like last minute feature ‘surprises’
    • 87. 87 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Acknowledge Resources You Use • Give credit where it is due for libraries/resources you use – Helps others find these resources – Provides positive feedback for the creators, encouraging them to keep maintaining these and creating new ones
    • 88. 88 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Give Back to the Community • Code contributions • Answer questions from other members • Facilitate hardware gifts if possible • Help arrange conferences/meetups • Offer to speak at conferences/events • Your contributions reflect on you and your company!
    • 89. 89 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Plan an Exit Strategy • Train your potential successor • Introduce your successor to the community • Insure that your code contributions will be maintained by someone from your company • Inform the community as soon as possible so that they have time to plan for the transition
    • 90. 90 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 90Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Communication Tools Etiquette
    • 91. 91 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Mailing List Etiquette • All communication is generally in English • Keep on topic – Try to stick to one topic per email, and make the subjects descriptive – Keep subject lines intact, as archives and mail clients use them for threading – If the topic changes, start a new thread • Don't use attachments – If you want to email code or documents, copy/paste in the email message or provide a link to a web site (such as pastebin) • Don't use HTML email – It may confuse some mail clients, and cause formatting problems • Reply and forward messages “inline” – Some mail clients forward as attached text files; disable this
    • 92. 92 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Mailing List Etiquette • Reply at the bottom of messages – Also called “bottom posting” – Put your response after the text to which you are responding • Posts with CAPITAL LETTERS will be ignored • The way you communicate matters – You will never lose points for professionalism – Many participants are international, so be as clear and straightforward as possible – Avoid sarcasm, don’t take things personally – Not everyone will be professional - “Don’t feed the trolls” • Your conduct reflects on you and your company!
    • 93. 93 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Responding to Feedback • Feedback is likely to come in short, small bursts. – Read, revise, and retransmit the code – If you get someone that is reading and commenting on the code each time, that's great! Keep sending the code. • Feedback from developers may be brief or strongly worded – Do not take it personally – Maintainers process a lot of code, and must triage quickly – Their goal is to improve code quality through intensive review • Work with the community – Take the good suggestions you get and incorporate them into your code – If there are solid technical reasons why bad suggestions are bad, explain those reasons clearly
    • 94. 94 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Etiquette When Replying to a Patch • Use "reply-all" by default, except in special circumstances • Never make a privileged conversation public without the consent of the other party • Keep the subject line intact, so you don’t break threading • Ensure HTML formatting is disabled
    • 95. 95 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Etiquette When Replying to a Patch • Avoid mail clients that convert the original message to an attachment when replying • Always comment inline • Do not delete the body of a message when replying
    • 96. 96 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Internet Relay Chat (IRC) Etiquette • ‘Lurking’ is acceptable behaviour on an IRC channel – Just listening in on a channel helps you understand how the project developers interact • Don’t ‘ask to ask’ (or say ‘Is anyone here?’) – If there is another conversation going on, wait until it completes – If there is no other conversation, just ask your question – Keep the question concise and to the point – You never lose points by being professional • Don't paste large code segments into an IRC channel – Provide a link to a web site (such as pastebin)
    • 97. 97 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Internet Relay Chat (IRC) Etiquette • Be aware of time zones – In large geographically-distributed projects, not all developers are online at the same time – Be patient and wait at least 24 hours for a response • Ask your question multiple times – Give updates on what you’ve tried to fix a problem – Provide a summary later of any solution – Consider posting a summary of any solution to the project mailing list for archival purposes • Your conduct reflects on you and your company!
    • 98. 98 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Bug Tracking (Bugzilla) Etiquette • Keep bug reports concise but thorough – Add all important details, but leave out unnecessary information – Provide specific details on how to recreate the bug – Provide access to error messages – Provide log file snippets, or, if the data is large, links to pastebin or another website • No pointless comments in bugs – Don’t put ‘me too’ messages in comments – In general, don’t comment unless adding something new or important for the bug assignee to know
    • 99. 99 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Bug Tracking (Bugzilla) Etiquette • There is no community obligation to fix bugs – Do not demand bug fixes by a certain date/release point – If the bug is critical to you, offer to fix it yourself or help the bug assignee fix it • Criticize code, not people – Be constructive in your criticism, do not attack people
    • 100. 100 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) Bug Tracking (Bugzilla) Etiquette • Don’t change fields of bugs you don’t own – Do not change priority, target milestones, etc. – If you need to request a change, put a comment in the bug itself • Don’t complain about decisions – If a maintainer has marked a bug as INVALID or WONTFIX, don’t file a duplicate bug – If you believe the decision was invalid, provide supporting evidence in a comment • Your conduct reflects on you and your company!
    • 101. 101 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 101Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Top 5 Things to Remember
    • 102. 102 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) #5 – Understand Community Governance • Each community is different • Contributions need to ‘fit’ with other code/patches
    • 103. 103 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) #4 – Understand Community Motivators • Successful communities are powered by motivated people • Motivation can be: status, money, peer recognition
    • 104. 104 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) #3 – Be Careful of ‘Custom’ Licenses • Communities do not work well with ‘custom licenses’ • Gaining contributors/momentum requires low barriers to entry http://opensource.org/licenses/index.html
    • 105. 105 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) #2 – Communities Need Nurturing • Posting code to public sites is not collaboration • Community participation is a cycle – expect change
    • 106. 106 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) #1 - Be Humble, But Bold • Community leadership is earned, not granted – Accept community feedback and rework code • Bring technical expertise to the table – Contributions need to be ongoing to maintain leadership status Humble Bold Leadership != Control
    • 107. 107 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 107Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co. Thank you.