sharing code

sharing code

talk to ing

75935a034e6c04dfd6f6946a299c3937?s=128

Harish Pillay

January 20, 2015
Tweet

Transcript

  1. Effective Code Sharing Practices Harish Pillay Head, Community Architecture and

    Leadership @harishpillay• hpillay@redhat.com January 2015
  2. 2 2 HERE WE GO What is open source, anyway?

    What this process is, and where you can find it in your everyday life. Where did it start? A brief history of nerds changing the world. How does it work? The mechanics of freedom. How can I use it? Some practical advice.
  3. 3 3 THE OPEN SOURCE WAY http://www.theopensourceway.org/ Create. When we

    are free to collaborate, we create and solve problems that no one person may be able to solve on their own Share. We learn more from each other when information is open Collaborate. Through “meritocracy”, the best ideas win Through Communities formed around a common purpose Let everyone else do the same.
  4. 4 4 “Software is Eating the World” Marc Andreessen WSJ

    August 20, 2011 (http://tinyurl.com/n85jsjx)
  5. 5 5 “Open Source is Eating the Software World” Jim

    Zemlin, Linux Foundation OpenStack Summit Paris Nov 2014 (http://tinyurl.com/owbz8l) And the corollary ...
  6. 6

  7. 7 7 THE BASICS

  8. 8 8 HOW DEVELOPMENT WORKS COMPILERS MAKE SOURCE INTO BINARIES

    int main() { printf(“Hello world.\n”); exit (0); } DEVELOPER SOURCE CODE $ ./hello-world Hello world. $ BINARY 10101011010101010101010101 01010100101010101110101010 10111101010101111010001001 01010101010011001010101101 USER COMPILER
  9. 9 9 WE STARTED SHARING CODE... int main() { printf(“Hello

    world.\n”); exit (0); } DEVELOPER COPY #1 USER #1 int main() { printf(“Hello world.\n”); exit (0); } COPY #2 USER #2 int main() { printf(“Hello world.\n”); exit (0); } BINARY #1 $ ./hello-world Hello world. $ BINARY #2 $ ./hello-world Hello world. $
  10. 1 0 10 AND ANYONE COULD IMPROVE IT COPY #1

    USER #1 int main() { printf(“What up.\n”); exit (0); } COPY #2 USER #2 int main() { printf(“Bonjour!\n”); exit (0); } BINARY #1 $ ./hello-world What up. $ BINARY #2 $ ./hello-world Bonjour! $ int main() { printf(“Hello world.\n”); exit (0); } DEVELOPER
  11. 1 1 11 WE STARTED SELLING BINARIES int main() {

    printf(“Hello world.\n”); exit (0); } DEVELOPER DEVELOPER’S BINARY $ ./hello-world Hello world. $ DEVELOPER’S BINARY USER #1 $ ./hello-world Hello world. $ USER #2 DEVELOPER’S BINARY $ ./hello-world Hello world. $
  12. 1 2 12 OPEN SOURCE int main() { printf(“Hello world.\n”);

    exit (0); } COMMITTER int main() { printf(“What up.\n”); exit (0); } DEVELOPER’S CODE USER #1 int main() { printf(“Wassup.\n”); exit (0); } BINARY #1 $ ./hello-world Wassup. $ int main() { printf(“Bonjour.\n”); exit (0); } DEVELOPER’S BINARY $ ./hello-world Hello world. $ USER #2
  13. 1 3 13 “Moore's Law” for Software? http://www.slideshare.net/blackducksoftware/2014-future-of-open-source-survey-re

  14. 1 4 14 OPEN SOURCE EVERYWHERE

  15. 1 5 15 Attribution Text MOBILE PHONES

  16. 1 6 16 Attribution Text STOCK EXCHANGES

  17. 1 7 17 Attribution Text AUTOMOBILES

  18. 1 8 18 Attribution Text WEATHER

  19. 1 9 19 Attribution Text AIRPLANES

  20. 2 0 20 HOW IT WORKS

  21. 2 1 21 Attribution Text TEST CODE SUBMIT REQUESTS PROVIDE

    FEEDBACK USERS CREATE PATCHES WRITE DOCUMENTATION CONTRIBUTORS REVIEW + COMMIT COMMITTERS THE COMMUNITY
  22. 2 2 22 THE TOOLS CODE REPOSITORY MAILING LIST One

    for developers. One for users. One for casual watchers. The heart of the project. A complete history of all changes. Anyone can read, only committers can write. The to-do list. Where users and developers interact. Where you’ll learn why a change was made. ISSUE TRACKER
  23. 2 3 23 THE WORKFLOW BUG ISSUE TRACKER USER MAILING

    LIST USERS CONTRIBUTORS COMMITTERS PATCH DEVELOPER MAILING LIST CODE REPOSITORY SOURCE CODE BUILD SYSTEM (OPTIONAL) RELEASE
  24. 2 4 24 THE LEADERS PROJECT LEAD

  25. 2 5 25 THE LEADERS PROJECT LEAD LIEUTENANT LIEUTENANT LIEUTENANT

    CONTRIBUTOR CONTRIBUTOR CONTRIBUTOR
  26. 2 6 26 RELEASE PROCESS DEVELOPER MAILING LIST SOURCE CODE

    BUG ISSUE TRACKER USER MAILING LIST USERS CONTRIBUTORS COMMITTERS PATCH CODE REPOSITORY BUILD SYSTEM (OPTIONAL) RELEASE
  27. 2 7 27 RELEASE PROCESS MAIN TRUNK (“HEAD”) BRANCH (“1.0”)

    PATCH #1 PATCH #2 PATCH #3 PATCH #6 BRANCH (“1.1”) PATCH #7 PATCH #8 FASTER RISKIER SLOWER SAFER
  28. 2 8 28 A COMMUNITY OF PRACTICE • Design for

    evolution. • Open a dialogue between inside and outside perspectives. • Invite different levels of participation. • Develop both public and private community spaces. • Focus on value. • Combine familiarity and excitement. • Create a rhythm for the community. Etienne Wenger, Richard McDermott, and William M. Snyder Cultivating Communities of Practice, 1st ed. (Harvard Business Press, 2002)
  29. 2 9 29 http://www.flickr.com/photos/don_brubeck/3954973900/ Licensed CC-BY-NC-ND 2.0. A WEAPON AGAINST

    TYRANTS
  30. 3 0 30 THE FORK

  31. 3 1 31 THE FORK BUG ISSUE TRACKER USER MAILING

    LIST USERS CONTRIBUTORS COMMITTERS PATCH DEVELOPER MAILING LIST CODE REPOSITORY SOURCE CODE BUILD SYSTEM (OPTIONAL) RELEASE
  32. 3 2 32 RELEASE PROCESS MAIN TRUNK (“HEAD”) BRANCH (“1.0”)

    NEW TRUNK X
  33. 3 3 33 FORKING IS GREAT AND AWFUL A “nuclear

    option” for consensus failure. Everyone loses in a fork, so when it happens, it is usually the only alternative. Keeps despots honest. By threatening the loss of their user and contributor community, project leaders become very accommodating. Proof that you have freedom. If you can fork the code, your fate is in your hands. For better or worse.
  34. 3 4 34 HOW TO AVOID FORKS Working groups make

    decisions through a "rough consensus" process. IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, it must be noted that "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement). Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached. IETF Working Group Guidelines and Procedures http://tools.ietf.org/html/rfc2418
  35. 3 5 35 GREAT FORKS IN HISTORY Apache Most popular

    web server on the planet was “a patch-y” fork of the NCSA web server. Android The popular mobile operating system forked Linux over irreconcilable design goals. WebKit The KDE project’s web browser engine was forked by Apple for its Safari web browser. KDE is considering “un-forking” the projects. X.org The ubiquitous windowing system for UNIX and Linux forked the XFree86 project over a licensing dispute.
  36. 3 6 36 Attribution Text FOGEL http://producingoss.com

  37. 3 7 37 Attribution Text LICENSING

  38. 3 8 38 LICENSING IS CRUCIAL Licensing creates the community.

    It tells us how contributions are handled. Licensing determines the business model. If you compel source redistribution, how do you build a business? Licensing should be easy. If it’s too complicated, you lose contributors.
  39. 3 9 39 OPEN SOURCE INITIATIVE http://opensource.org Free redistribution. Anyone

    can make a copy. Include the source code. If you have the binary, you should have the code. Allows derived works. Let people change what they’re given. Non-discriminatory. You can’t restrict who can use it. Must not restrict other software. You can’t restrict what can use it. Technology-neutral. The “how” shouldn’t change anything.
  40. 4 0 40 THREE LICENSING CAMPS WEAK COPYLEFT Mozilla Eclipse

    LGPL PERMISSIVE BSD MIT Apache Beerware Public Domain STRONG COPYLEFT GPL AGPL EUPL
  41. 4 1 41 OPEN SOURCE LICENSING MUST BE FLEXIBLE

  42. 4 2 42 I will not write my own software

    license. I will not write my own software license. I will not write my own software license. I will not write my own software license. I will not write my own software license. I will not write my o
  43. 4 3 43 Attribution Text http://www.blackducksoftware.com/oss/licenses

  44. 4 4 44 Attribution Text WHAT ALL THIS GETS YOU

  45. 4 5 45 MODULAR BY DESIGN SMALL PIECES, LOOSELY COUPLED.

    "a change to one element in Mozilla is likely to impact three times as many other elements as a similar change in Linux. We conclude that the first version of Mozilla was much less modular than a comparable version of Linux." MacCormack, Rusnak, and Baldwin. “Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code” http://opensource.mit.edu/papers/maccormackrusnakbaldwin2.pdf “Mozilla, after its release as open source, was rapidly and successfully redesigned to become much more modular - at least as modular as Linux, in fact.... the differences in code appear to result from differences in organization.” Nick Carr, http://www.roughtype.com/archives/2006/01/open_sources_du.php
  46. 4 6 46 Modularity leads to Microservices and Containers

  47. 4 7 47 Effective Use of Resources Open Source permits

    innovation all the way down. A FARM TEAM USING THE LONG TAIL OF DEVELOPERS
  48. 4 8 48 More Ideas Good ideas comes from lots

    of good ideas. LONG TAILS MEAN INNOVATION MORE PARTICIPANTS, MORE GOOD IDEAS
  49. 4 9 49 HIGHER QUALITY MORE CODE, FEWER BUGS Coverity

    has tracked the code quality of open source software since 2004. Proprietary software, on average, has 20,000 to 30,000 defects per million lines of code. This has been true since 1960. 2004 Linux has 985 defects in 5.7 MLOC, or 99.3% lower than a proprietary system. 2005 Linux grew 4.7%, but defect density went down 2.3%. 2006 Funded by DHS, Coverity adds the LAMP stack and 32 OSS projects, and defect density stayed the same. 2008 Now covers 250 projects, with 434 defects per MLOC. Worst performer has 1237 defects per MLOC. 2009 Now covers 280 projects, with defect density down 16%.
  50. 5 0 50 Attribution Text MAKING MONEY

  51. 5 1 51 Attribution Text Attribution Text INNOVATION IT’S MORE

    THAN PRODUCTS SERVICES PRODUCTS HOBBIES AMATEURS
  52. 5 2 52 5 2

  53. 5 3 53 Attribution Text now what?

  54. 5 4 54 OPEN SOURCE IS RAPID INNOVATION

  55. 5 5 55 OPEN SOURCE STRATEGY - I Create a

    use policy. Open source software is commercial software. Create a release policy. When can employees and contractors contribute? When should they? Track your software and license use. But you’re already doing that, right?
  56. 5 6 56 OPEN SOURCE STRATEGY - II CREATE A

    USE POLICY: BASICS Strategy Why are we bothering with a policy? Background What’s the state of the organization now? Process Who does the policy govern, who’s keeping track, and how decisions get made.
  57. 5 7 57 Create a level playing field. OSS is

    commercial software. Licenses are licenses. Manage licensing questions. Just like proprietary software, pay attention to the license. Which licenses will you accept, and under what circumstances? Define the support requirements. When is support required? At what level? Help projects decide what SLAs they need, and how those SLAs can be fulfilled. OPEN SOURCE STRATEGY - III CREATE A USE POLICY: PROCUREMENT
  58. 5 8 58 Define the sources. Can you download code,

    or do you require media? Where will the code be stored? Define the code evaluation process. How will you determine the code’s fitness? The quality of the community? Suitability of the license? Accommodate different use cases. Research and development is different than production. Encourage experimentation. OPEN SOURCE STRATEGY - IV CREATE A USE POLICY: SOURCING
  59. 5 9 59 Define the process. When will you contribute?

    Who approves contributions? Define the norms. Should changes be encouraged at all? When developers work with the outside, do they use their official email addresses? Expect new projects. Ensure a clear, obvious, and simple process for approving the release of brand-new projects. OPEN SOURCE STRATEGY - V CREATE A RELEASE POLICY
  60. 6 0 60 Define the metrics. How will you measure

    progress? What will indicate progress in different use cases? Define the tools. Where will downloaded code live? Where will you track license use? How can your staff discover what work their colleagues have already done? Define the reporting. How frequently will you report on your OSS use? What do you want people to know? OPEN SOURCE STRATEGY - VI TRACK SOFTWARE AND LICENSE USE
  61. 6 1 61 Stormy’s Policy Guide http://olex.openlogic.com/wazi/2009/create-open-source-policy/ A great walkthrough

    of policy creation. FOSSBazaar http://fossbazaar.org/ http://fossology.org/ A project to simplify open source policies. Open Source for America http://opensourceforamerica.org/resources http://opensourceforamerica.org/helpdesk References and a helpdesk for policy writers. OPEN SOURCE STRATEGY - VII RESOURCES
  62. 6 2 62 Government and Civic OSS Organizations Open Source

    for America http://opensourceforamerica.org/ Helps government and industry use and make open source together. CivicCommons http://civiccommons.org/ Building an open source government stack. Mil-OSS http://mil-oss.org/ DoD and intelligence open source advocates.
  63. 6 3 63 YOU ARE HERE 63

  64. 6 4 64 THANK YOU. hpillay@redhat.com @harishpillay

  65. 6 5 65 A BRIEF HISTORY OF OPEN SOURCE

  66. 6 6 66 http://www.flickr.com/photos/knobil/114698681/ Licensed CC-BY 2.0 ANARCHISTS.

  67. 6 7 67 http://www.flickr.com/photos/knobil/114698681/ Licensed CC-BY 2.0 COMMUNISTS.

  68. 6 8 68 http://www.flickr.com/photos/knobil/114698681/ Licensed CC-BY 2.0 PROBLEM SOLVERS.

  69. 6 9 69 Attribution Text RMS

  70. 7 0 70

  71. 7 1 71

  72. 7 2 72

  73. 7 3 73 Attribution Text GNU’s Not Unix

  74. 7 4 74 FOUR FREEDOMS http://fsf.org Free to use. Anyone

    can use it, however they like. Free to copy. Anyone can get a copy for the cost of media. Free to modify. If I don’t like how it works, I can change it. Free to distribute. I can share my changes.
  75. 7 5 75 GNU PUBLIC LICENSE http://gnu.org Implements the four

    freedoms. Use, copy, modify, distribute. Built on copyright. The author provides additional rights for additional responsibilities. In some cases, problematic. But more on that later.
  76. 7 6 76 Attribution Text Attribution Text LINUX IS BORN

    From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: What would you like to see most in minix? Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI> Date: 25 Aug 91 20:57:08 GMT Organization: University of Helsinki “I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix...” From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: What would you like to see most in minix? Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI> Date: 25 Aug 91 20:57:08 GMT Organization: University of Helsinki “I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix...”
  77. 7 7 77 http://catb.org/~esr/writings/homesteading/cathedral-bazaar/ ESR http://catb.org/esr/writings/cathedral-bazaar/

  78. 7 8 78 Attribution Text NETSCAPE

  79. 7 9 79 Attribution Text FIREFOX