Download as PDF, PPTX
Linux Foundation Collaboration Summit 2016 (rvagg): New Models in Open Source
- 1. March 30, 2016 NewModels in Open Source Rod Vagg @rvagg
- 2. © 2016 NodeSource Whoam I? 2 Who am I? • Recovering Former Java developer • Current Node.js developer and cat herder • Chief Node Officer @ NodeSource, Inc. • Member of the Node.js TSC & CTC • Open software governance aficionado
- 3. © 2016 NodeSource Wut? 3 Whatthis talk is about • What does the next generation of open source look like? • Trends toward greater openness • The Node.js journey; openness in the ecosystem influencing a new open governance model in core • The role of leadership • Challenges for companies
- 4. © 2016 NodeSource Storytime: NAN 4
- 5. © 2016 NodeSource Storytime: NAN 5
- 6. © 2016 NodeSource Storytime: NAN 6
- 7. © 2016 NodeSource Storytime: NAN 7 42 months of progress • From 287 LOC (1 file) to 6,148 LOC (17 files) • From supporting Node.js 0.10 and 0.11 to supporting 0.8, 0.10, 0.12 (io.js 1, 2, 3), 4, 5, 6 • Depended on by every major C++ Node.js addon, 95th most downloaded package in npm • Successfully navigated a major rewrite (v2) • Adopted by Node.js core as the official solution for writing compatible C++ addons
- 8. © 2016 NodeSource OpenGovernance 8
- 9. © 2016 NodeSource Opensource history 9 Open source history can be defined by its tools
- 10. © 2016 NodeSource Opensource history 10 SCM tools CVS Subversion Git
- 11. © 2016 NodeSource Opensource history 11 Source code hosting, sharing & “social” Wild West / self-hosted SourceForge (and Freshmeat?) GitHub
- 12. © 2016 NodeSource CVS SVN Git Self-hosted SourceForge GitHub Opensource history 12 Trend Reduced collaboration friction Focus on community / social Openness and visibility
- 13. © 2016 NodeSource Opensource history 13 CVS SVN Git What’s next? Self-hosted SourceForge GitHub What’s next?
- 14. © 2016 NodeSource Opensource history 14 With a trend toward reduced friction, increased community and greater openness, the future of open source looks more like a wiki
- 15. © 2016 NodeSource “OPENOpen Source” An example open governance model 15
- 16. © 2016 NodeSource OPENOpen Source 16 “Individuals making significant and valuable contributions are given commit-access to a project to contribute as they see fit. A project is more like an open wiki than a standard guarded open source project.” http://openopensource.org/
- 17. © 2016 NodeSource OPENOpen Source 17 Basic guidelines • Don’t mess with Git history (master is sacred) • Internal pull requests to solicit feedback are preferred, particularly for non-trivial changes • Consensus-seeking for everything • New contributors get equal ownership and a seat at the decision-making table • No BDFL (“benevolent dictator for life”); respect and moral authority are earned
- 18. © 2016 NodeSource OpenGovernance in Practice 18
- 19. © 2016 NodeSource Opengovernance in practice 19 Impact: projects better reflect their users Projects are driven by the people and groups that value them the most Those who put in the most resources (companies and individuals) get influence: encourages participation
- 20. © 2016 NodeSource Opengovernance in practice 20 Impact: better bus-factor & sanity for developers The individual drivers of a project can change smoothly over time Key individuals can move on when they run out of steam New individuals join and earn influence Group dynamics adapt according to the make-up of the group at any point in time
- 21. © 2016 NodeSource Opengovernance in practice 21 Impact: vision & roadmap become nebulous A project’s “vision” or “roadmap” exists as the intersecting interests and desires of those most willing and able to invest in the project at any point in time
- 22. © 2016 NodeSource Opengovernance in practice 22 Impact: restraint by consensus-seeking The need to work toward consensus: • Forces restraint, compromise and stability • Increases the scope of discussion to include diverse user perspectives • Provides a key touch-point for community building
- 23. © 2016 NodeSource Opengovernance in practice 23 Impact: focus on key areas by consensus- seeking The need to work toward consensus: • Forces discussion of what really matters • Highlights the areas of difference • Encourages dialog with the other
- 24. © 2016 NodeSource Opengovernance in practice 24 Impact: openness Openness begets openness • More welcoming of new contributors • More embracing of a diversity of perspectives • Focus on discussion and consensus-seeking rather than dictates and imposition
- 25. © 2016 NodeSource TheNode.js Journey 25
- 26. © 2016 NodeSource TheNode.js journey 26 v0.10 represented a high-water mark for Node.js • Contributions peaked • Engagement peaked • Release frequency peaked • Downloads peaked • v1 was near!
- 27. © 2016 NodeSource TheNode.js journey 27 Toward stagnation instead of v1 • BDFL model began to be a hinderance • Project stewardship under a single company limited avenues for contribution and skewed incentives • Lack of technical progress • Lack of communication and transparency around decision making
- 28. © 2016 NodeSource Node.jsin contrast to its ecosystem 28 # of packages http://modulecounts.com/ # of downloads https://twitter.com/seldo
- 29. © 2016 NodeSource Adesire for openness 29 A growing desire for openness Large sectors of the Node.js open source ecosystem were transitioning to greater openness and exploring new open governance models Node.js core was frustratingly closed in comparison
- 30. © 2016 NodeSource Node.js:v0.10 to v0.12 30 Commitspermonth 0 100 200 300 400 Releasespermonth 0 3 6 9 12 Uniquecommiters permonth 0 23 46 69 92 Mar 2013 Jun 2013 Sep 2013 Dec 2013 Mar 2014 Jun 2014 Sep 2014 Dec 2014 Mar 2015 Jun 2015 Sep 2015 Dec 2015 Node.js v0.10.0 Node.js v0.12.0
- 31. © 2016 NodeSource Node.js:v0.10 and beyond 31 Commitspermonth 0 100 200 300 400 Releasespermonth 0 3 6 9 12 Uniquecommiters permonth 0 23 46 69 92 Mar 2013 Jun 2013 Sep 2013 Dec 2013 Mar 2014 Jun 2014 Sep 2014 Dec 2014 Mar 2015 Jun 2015 Sep 2015 Dec 2015 Fork io.js Convergence Node.js Foundation Node.js v4.0.0 Node.js v0.10.0 Node.js v0.12.0
- 32. © 2016 NodeSource OpenGovernance and Node.js 32
- 33. © 2016 NodeSource Outcomes:open governance 33 Open Governance • Managed by 61 “Collaborators” (18 Core Technical Team “CTC” members) • 9 individuals authorised to publish releases • Contributors control and own the project • No single point of failure • Diversity of perspectives, backgrounds and expertise
- 34. © 2016 NodeSource Outcomes:open governance (the Node.js team) 34 Ben Noordhuis Сковорода Никита Андреевич Chris Dickinson Colin Ihrig Evan Lucas Jeremiah Senkpiel Fedor Indutny James M Snell Michael Dawson Julien Gilli Brian White Ali Ijaz Sheikh Alexis Campailla Bert Belder Rod Vagg Shigeki Ohtsu Trevor Norris Rich Trott Andreas Madsen Benjamin Gruenbaum Brendan Ashworth Calvin Metcalf Claudio Rodriguez Domenic Denicola Wyatt Preul Rebecca Turner Isaac Z. Schlueter Johan Bergström João Reis Julian Duque Minwoo Jung Aleksey Smolenchuk Matthew Loring Matteo Collina Nicu Micleușanu Mikeal Rogers Christopher Monsanto Oleg Elifantiev Petka Antonov Phillip Johnsen Stephen Belanger Alex Kocharin Ryan Graham Robert Kowalski Roman Klauke Saúl Ibarra Corretgé Sam Roberts Nikolai Vavilov Roman Reiss Steven R Loomis Michaël Zasso Christian Tellnes Myles Borins Sakthipriyan Vairamani Glen Keane Thorsten Lorenz Mike Tunnicliffe Vladimir Kurchatkin Jeremy Whitlock Yosuke Furukawa Kat Marchán
- 35. © 2016 NodeSource Opengovernance & Node.js 35 Node.js uses a variant of OPEN Open Source • Two-tiered governance structure for making difficult decisions • CTC as a backstop, Collaborators for everything else
- 36. © 2016 NodeSource Opengovernance & Node.js 36 Node.js CTC (Core Technical Committee) • Has a ¼ company membership rule • Meets weekly to address concerns that have been elevated to it on GitHub • Often pushes decisions back to Collaborators • Is self-selecting - Seeks diversity in perspective, skill and background - Recognises technical and organisational merit
- 37. © 2016 NodeSource Opengovernance & Node.js 37 Node.js Collaborators • Are effectively self-selecting—nominate new members based on contribution • Operate primarily via pull request and discussion, require minimum sign-off but allow maximum input • Must recognise objections and concerns and work in a consensus-seeking process, no railroading! • Organically form interest and expertise groups • Earn respect and deference from other Collaborators for different aspects of the project (crypto, C++, V8, Windows, debugging, build, testing, documentation, even grammar!)
- 38. © 2016 NodeSource Opengovernance & Node.js 38 Node.js is self-sustaining • Better bus-factor than most: in terms of individuals and corporate involvement • Relationships and people-structures are dynamic and adjust over time - People move on when their passion and interests fade - New people join as they see needs and ways to make an impact Natural community structures and evolution are harnessed for the long-term health of the project
- 39. © 2016 NodeSource Opengovernance & Node.js 39 Node.js has guard rails • Collaborators answer to the CTC • CTC reports to the TSC (Technical Steering Committee) which acts as an administrative facilitator • TSC reports to the Node.js Foundation Board, although it has independence on the technical process • Node.js Foundation Board answers to member companies
- 40. © 2016 NodeSource Theimportance of leadership 40
- 41. © 2016 NodeSource Leadership 41 Theimportance of leadership is directly proportional to the size and complexity of a project
- 42. © 2016 NodeSource Leadership 42 Leadershipis important • Imposed leadership structures expose a project directly to the absolute best and absolute worst of a leader • A collaborative process rewards, encourages and capitalises on great leadership • A collaborative process can guard against not so great leadership • Quality leadership is rare but easily recognised
- 43. © 2016 NodeSource Leadership 43 Earnedleadership > imposed leadership
- 44. © 2016 NodeSource Challengesfor companies 44 Challenges for companies engaging in open source • How do you buy in to existing projects? Play a long-game of influence building, buy existing talent? • Asserting strong influence over roadmaps and requirements becomes increasingly difficult • Finding audience for new projects becomes difficult without embracing openness • The need for exercise of soft power is only increasing: leadership
- 45.