sharing code

talk to ing

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 ...
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