Exploring Leadership, Mangement, and Mentorship in Open Source

Exploring Leadership, Mangement, and Mentorship in Open Source

Leadership. Management. Mentorship. When considering decentralized Open Source projects all of these ideas come into play is a truly unique way. That is because of the nature of Open Source itself: self-motivation and self-determination. The individual has considerably more control over their own destiny with respect to what, why, and how they do work as a contributor when compared to "work" inside a more traditional corporate structure. Further there is often a disparity in goals between the create of an Open Source project and those who go on to maintain that same project months or years down the road.

This talk will explore the value systems that exist in Open Source communities and discuss how they shape the ideas of leadership, management, and mentorship in Open Source projects. It will compare these ontologies in projects (both Open Source and not) of varying size, scope, and focus and demonstrate how they manifest directly into actions or structures in the projects. If you've ever wondered how Open Source gets made, this is the talk for you!

D43e8ea63b61e7669ded5b9d3c2e980f?s=128

Charlie Robbins

July 14, 2017
Tweet

Transcript

  1. Exploring Leadership, Mangement, and Mentorship In Open Source Charlie Robbins


    FullStack London 2017
 July 14th, 2017
  2. None
  3. Hello There. Why Get Started. Let’s

  4. What am I going to talk about? 3 1 What

    is Open Source, practically speaking? 2 Open Source methodology, by default. 3 On Value Systems and incentives. 4 Moving mountains of code vs. the long tail in Open Source 5 Bottle your own lightning
  5. 4 What am I NOT going to talk about?

  6. 4 Open Source Foundations Standards Bodies Open Source Licensing What

    am I NOT going to talk about?
  7. Who am I? Just

  8. @INDEXZERO GITHUB TWITTER

  9. UX PLATFORM ENG. DIRECTOR FORMER BOARD MEMBER, NODE.JS FOUNDATION FORMERLY

    FOUNDER at NODEJITSU
  10. None
  11. Creator of … winston forever http-proxy nconf

  12. Creator of … winston forever http-proxy nconf and literally hundreds

    more
  13. None
  14. npm i -g footage \ && footage indexzero

  15. npm i -g footage \ && footage indexzero 38 MILLION

    … … LAST MONTH
  16. None
  17. I know a few things Basically

  18. I know a few things Basically Open Source about

  19. None
  20. What is Open Source… … practically speaking?

  21. None
  22. What is Software Development?

  23. What is Software Development? … well … good question …

  24. … trust me. I know this feel. … Software Development

  25. None
  26. 
 Reliability & Ops New Feature Requests Technical Debt Planning

    Support Meetings EMAIL
  27. A N D P E O P L E P

    E O P L E lots of
  28. None
  29. Junior?
 Senior? Product Manager Ops / ITSec Project Manager Engineer

    UX Designer Individual Contribut or Program Manager Engineeri ng Manager
  30. None
  31. Process Process lots of

  32. None
  33. What then is Open Source… … practically speaking?

  34. None
  35. (Different) Process Process but still lots of

  36. None
  37. DECISION MAKING 1 CONTRIBUTIONS 2 RELEASES 3 SUPPORT 4

  38. DECISION MAKING 1 CONTRIBUTIONS 2 RELEASES 3 SUPPORT 4 AND

    SO MANY MORE PROCESSES … PROCESS!
  39. A N D P E O P L E P

    E O P L E even more
  40. None
  41. “Every good work starts by of software scratching a developer’s

    personal itch”
  42. None
  43. In other words: no specialization by default there is

  44. None
  45. Open Source BY DEFAULT methodology

  46. None
  47. See… happened was what had

  48. None
  49. IN EARLY 2015 WAS acquired by

  50. IN EARLY 2015 WAS acquired by thinking … I was

    At the time
  51. None
  52. What is Open Source…

  53. What is Open Source… … on a company scale?

  54. None
  55. Practically Open Source implementing at

  56. None
  57. Any UI Platform single-point of failure is a for both

    customer experience A N D developer experience
  58. None
  59. All of requests are these coming (mostly) from other JavaScript

    developers
  60. None
  61. Thrown fence over the

  62. None
  63. W H Y should work be any different?

  64. Any organization that designs a system (defined broadly) will produce

    a design whose structure is a copy of the organization's communication structure. — Melvyn Conway, 1967 “ BETTER KNOWN AS CONWAY’S LAW
  65. None
  66. Code OWNERSHIP anti-pattern is an for any organization

  67. open source what would do?

  68. open source what would do? TRY TO MAKE EVERYONE A

    CONTRIBUTOR
  69. Copyright© 2017 Godaddy Inc. All Rights Reserved.

  70. Copyright© 2017 Godaddy Inc. All Rights Reserved. WHAT DOES INTERNAL

    OPEN SOURCE LOOK LIKE?
  71. Copyright© 2017 Godaddy Inc. All Rights Reserved. Science cat says

    GOOD QUESTION
  72. It all starts with support.

  73. It all starts with support. treat contributors team members We

    like
  74. and onboarding using Slack & Github Code reviews, ad-hoc Q&A,

  75. and onboarding using Slack & Github Code reviews, ad-hoc Q&A,

    If you time to contribute can make
  76. and onboarding using Slack & Github Code reviews, ad-hoc Q&A,

    If you time to contribute can make then your problems are our problems
  77. When you are done & the PR is merged

  78. take over bug fixes other support We and When you

    are done & the PR is merged
  79. None
  80. Modularity helping is really

  81. None
  82. Shifting towards contribution-based a model is

  83. Shifting towards contribution-based a model is fundamentally changing HOW work

    is done at GoDaddy.
  84. 0 15 30 45 60 Q1 2016 Q2 2016 Q3

    2016 Q4 2016 Q1 2017 Q2 2017 Contributors New Contributors Total "Inner Source" has proven 43 VERY effective.
  85. 0 15 30 45 60 Q1 2016 Q2 2016 Q3

    2016 Q4 2016 Q1 2017 Q2 2017 Contributors New Contributors Total "Inner Source" has proven 43 VERY effective. Growth of more than linear! contributors is
  86. None
  87. value systems On and incentives

  88. None
  89. are YOU doing YOU are doing? Why what

  90. JUST HOW people do

  91. JUST HOW people do get BETTER?

  92. None
  93. mentors Everyone someone else

  94. None
  95. We make decisions value-based

  96. None
  97. recognition
 matters How vs. what is recognized

  98. None
  99. Creator Paradox of maintainer vs.

  100. None
  101. all contributors Accept that create value

  102. all contributors Accept that create value kentcdodds/all-contributors IT’S NOT JUST

    ABOUT CODE.
  103. None
  104. prioritize being INCLUSIVE TO basically everyone

  105. None
  106. HAVE A CODE conduct of policy

  107. HAVE A CODE conduct of policy TL;DR? READ THIS AND

    USE IT. contributor-covenant.org
  108. None
  109. OMG DO IT

  110. OMG DO IT YES, RIGHT MEOW! right meow!

  111. None
  112. It’s all about CONFLICT RESOLUTION

  113. It’s all about CONFLICT for serious… RESOLUTION

  114. Every Open Source governance model is a shallow wrapper (defined

    broadly) to a basic conflict resolution strategy. — Me? I guess? Today? “
  115. Every Open Source governance model is a shallow wrapper (defined

    broadly) to a basic conflict resolution strategy. — Me? I guess? Today? PLEASE DON’T CALL THIS A LAW “
  116. Every Open Source governance model is a shallow wrapper (defined

    broadly) to a basic conflict resolution strategy. — Me? I guess? Today? PLEASE DON’T CALL THIS A LAW IT’S JUST HUMAN NATURE “
  117. None
  118. Moving mountains of code? of

  119. None
  120. Let’s talk about GOVERNANCE

  121. None
  122. B D F L Simple?

  123. None
  124. Democracy. meritocracy N O T

  125. None
  126. Meritocracy a lie is

  127. Meritocracy a lie is MERITOCRACY COMPLETELY IGNORES BASIC POWER &

    SOCIAL DYNAMICS INHERENT IN all human relationships
  128. None
  129. about we just COMMITTEE
 BASED? How say

  130. WITH THE EXCEPTION OF A “CLASSIC” BDFL STRUCTURE IT’S ALL

    COMMITTEES source: Harvard Law School, ‘17
  131. SERIOUSLY. THIS IS WHAT APACHE CONSIDERS “MERITOCRACY” source: Harvard Law

    School, ‘17
  132. SERIOUSLY. THIS IS WHAT APACHE CONSIDERS “MERITOCRACY” source: Harvard Law

    School, ‘17 Hierarchy implicit I S
  133. source: Harvard Law School, ‘17

  134. source: Harvard Law School, ‘17 SIMILAR TO BUT NOT EXACTLY

    NODE.JS’ GOVERNANCE MODEL
  135. source: Harvard Law School, ‘17 SIMILAR TO BUT NOT EXACTLY

    NODE.JS’ GOVERNANCE MODEL Let’s talk about COMMITTEES?
  136. None
  137. IMPLICATIONS lazy consensus of

  138. IMPLICATIONS lazy consensus of /** ‘contributor’ !== ‘martyr’ **/

  139. None
  140. The long tail Open Source of … the average project

    is TINY.
  141. None
  142. Moving mole-hills of code. of

  143. None
  144. Guess what? It’s GOVERNANCE again

  145. None
  146. HOT POTATO the classic governance model

  147. None
  148. ANARCHY the UK not in

  149. ANARCHY the UK not in maybe on the Internet

  150. None
  151. burnout Coping with

  152. None
  153. LEARNING handle growth to effectively

  154. LEARNING handle growth to effectively gets EASIER. I PROMISE IT

    IS TRUE.
  155. None
  156. ABANDONDED? is this project is an anti-pattern

  157. None
  158. Turns out that: PUBLIC SHAMING does NOT work

  159. None
  160. Bottle lightning your own

  161. None
  162. a mountain with moving Help

  163. None
  164. Build molehill your own or a hundred!

  165. None
  166. WHEN IN DOUBT disconnect from it

  167. WHEN IN DOUBT disconnect from it it is just software

  168. {github, twitter}.com/indexzero THANKS. Q&A TIME. MAY THE SOURCE BE WITH

    YOU