Developing OSS Leadership (LinuxCon NA - 2014)

796 views

Published on

Published in: Technology
3 Comments
4 Likes
Statistics
Notes
  • Ok It's clear ...

    I see at least 3 different startegies then

    1/ code drop and no support or including community contribs

    2/ closed developement model but connected to comminity contribs (ie provide support and accepting to review/merge patches for next release or sync)

    3/ open developmenent , this mean community count as much as any 'internal' workforces , then the question of priority remains ...

    Now I am wondering how open can the whole process could be and actually bring products to market if you see what I mean :)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Thanks Phil!

    Basically, it means, 'don't drop a chunk of code in an open source community and then not show up to support it going forward'. Most of the time, this is harder to do in communities with strong governance, as the contribution process is biased in favor of rejecting contributions from anonymous or suspect users.

    However, it still happens, especially in contributions from corporations, where they don't yet understand how to properly collaborate with communities.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Good slides, can you detail 'Dont dump and run' from p33 ? see you at next tizen event :)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
796
On SlideShare
0
From Embeds
0
Number of Embeds
26
Actions
Shares
0
Downloads
30
Comments
3
Likes
4
Embeds 0
No embeds

No notes for slide
  • SRA Open Source Group can help navigate licenses and legal obligations - helping choose proper license based on our compliance experience.
  • 57
  • Developing OSS Leadership (LinuxCon NA - 2014)

    1. 1. Developing Open Source Leadership Open Source Group –– Samsung Research America (Silicon Valley) 1 Guy Martin Senior Strategist Samsung Open Source Group guym@osg.samsung.com @guyma, @SamsungOSG
    2. 2. Content • Open Source Development Model • Best Practices • Communication & Community Skills Open Source Group – Samsung Research America (Silicon Valley) 2
    3. 3. Open Source Leadership: Why and How? Open Source Group –– Samsung Research America (Silicon Valley) 3
    4. 4. Product Dependency on Open Source Technologies Open Source Group – Samsung Research America (Silicon Valley) 4
    5. 5. New Open Source Skillsets Open Source Group – Samsung Research America (Silicon Valley) 5
    6. 6. Open Source Strategy Decide on the desired position based on company’s OSS strategy Consumer Participant Open Source Group – Samsung Research America (Silicon Valley) 6 Contributor Leader Start here!
    7. 7. 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 • Empower employees to seek contributor and maintainer status Open Source Group – Samsung Research America (Silicon Valley) 7
    8. 8. Open Source Development Model Open Source Group –– Samsung Research America (Silicon Valley) 8
    9. 9. Open Source Model Characteristics 1. Distributed development 2. Development community 3. Community organization 4. Scalable development 5. Decision process 6. “Release early, release often” Open Source Group – Samsung Research America (Silicon Valley) 9 7. Submitting code 8. Taking responsibility 9. Giving credit to others 10.Peer review 11.Continuous testing 12.Gaining influence 13.Modular designs
    10. 10. 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) Open Source Group – Samsung Research America (Silicon Valley) 10
    11. 11. 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 Open Source Group – Samsung Research America (Silicon Valley) 11 • 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
    12. 12. 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 Open Source Group – Samsung Research America (Silicon Valley) 12
    13. 13. Working with Upstream Open Source Group –– Samsung Research America (Silicon Valley) 13
    14. 14. 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. Open Source Group – Samsung Research America (Silicon Valley) 14
    15. 15. 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 Open Source Group – Samsung Research America (Silicon Valley) 15
    16. 16. 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 Open Source Group – Samsung Research America (Silicon Valley) 16
    17. 17. 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 useful to all platform users – that they don’t want to maintain themselves – Source code that will help them influence the direction of the project • 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 Open Source Group – Samsung Research America (Silicon Valley) 17
    18. 18. Best Practices: Requirements Open Source Group –– Samsung Research America (Silicon Valley) 18
    19. 19. 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 Open Source Group – Samsung Research America (Silicon Valley) 19
    20. 20. 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’ Open Source Group – Samsung Research America (Silicon Valley) 20
    21. 21. Best Practices: Design Open Source Group –– Samsung Research America (Silicon Valley) 21
    22. 22. 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 Open Source Group – Samsung Research America (Silicon Valley) 22
    23. 23. 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 Open Source Group – Samsung Research America (Silicon Valley) 23
    24. 24. 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 Open Source Group – Samsung Research America (Silicon Valley) 24
    25. 25. Best Practices: Implementation Open Source Group –– Samsung Research America (Silicon Valley) 25
    26. 26. 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 Open Source Group – Samsung Research America (Silicon Valley) 26
    27. 27. 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 Open Source Group – Samsung Research America (Silicon Valley) 27
    28. 28. 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 Open Source Group – Samsung Research America (Silicon Valley) 28
    29. 29. 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/ Open Source Group – Samsung Research America (Silicon Valley) 29
    30. 30. 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 Open Source Group – Samsung Research America (Silicon Valley) 30
    31. 31. 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 Open Source Group – Samsung Research America (Silicon Valley) 31
    32. 32. Best Practices: Maintenance Open Source Group –– Samsung Research America (Silicon Valley) 32
    33. 33. 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 Open Source Group – Samsung Research America (Silicon Valley) 33
    34. 34. 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 Open Source Group – Samsung Research America (Silicon Valley) 34
    35. 35. Open Source Community/Communication Skills Open Source Group –– Samsung Research America (Silicon Valley) 35
    36. 36. What are Communities? Open Source Group – Samsung Research America (Silicon Valley) 36
    37. 37. Rule #1 No two communities are exactly the same! Open Source Group – Samsung Research America (Silicon Valley) 37
    38. 38. Rule #2 Communities don’t work for individual companies Open Source Group – Samsung Research America (Silicon Valley) 38
    39. 39. Preparing to Engage with Community Open Source Group –– Samsung Research America (Silicon Valley) 39
    40. 40. 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. Open Source Group – Samsung Research America (Silicon Valley) 40
    41. 41. 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 Open Source Group – Samsung Research America (Silicon Valley) 41
    42. 42. Get to Know the Community Open Source Group –– Samsung Research America (Silicon Valley) 42
    43. 43. 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 Open Source Group – Samsung Research America (Silicon Valley) 43
    44. 44. 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 Open Source Group – Samsung Research America (Silicon Valley) 44
    45. 45. 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 Open Source Group – Samsung Research America (Silicon Valley) 45
    46. 46. 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’ Open Source Group – Samsung Research America (Silicon Valley) 46
    47. 47. Engage with the Community Open Source Group –– Samsung Research America (Silicon Valley) 47
    48. 48. 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’ Open Source Group – Samsung Research America (Silicon Valley) 48
    49. 49. 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! Open Source Group – Samsung Research America (Silicon Valley) 49
    50. 50. 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 Open Source Group – Samsung Research America (Silicon Valley) 50
    51. 51. Top 5 Things to Remember Open Source Group –– Samsung Research America (Silicon Valley) 51
    52. 52. #5 – Understand Community Governance • Each community is different • Contributions need to ‘fit’ with other code/patches Open Source Group – Samsung Research America (Silicon Valley) 52
    53. 53. #4 – Understand Community Motivators • Successful communities are powered by motivated people • Motivation can be: status, money, peer recognition Open Source Group – Samsung Research America (Silicon Valley) 53
    54. 54. #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 Open Source Group – Samsung Research America (Silicon Valley) 54
    55. 55. #2 – Communities Need Nurturing • Posting code to public sites is not collaboration • Community participation is a cycle – expect change Open Source Group – Samsung Research America (Silicon Valley) 55
    56. 56. #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 Leadership != Control Humble Bold Open Source Group – Samsung Research America (Silicon Valley) 56
    57. 57. Thank you. Open Source Group –– Samsung Research America (Silicon Valley) 57

    ×