Downloaded 17 times
Uploaded byMichael Klishin
Scalable Open Source
This document discusses scalable ways of doing open source work. It outlines how ClojureWerkz grew from 4 projects and 2 maintainers in 2011 to over 30 projects and 70 contributors by 2015. It emphasizes the importance of maintaining responsibility to users by having good documentation, communication channels, and processes to engage contributors and ensure projects don't become abandonware. Standardizing practices, automating tasks, and writing documentation throughout development can help projects scale sustainably.
More Related Content
Scalable Open Source
- 1. Scalable* Way of DoingOpen Source * for humans
- 2.
- 3.
- 4.
- 5.
- 6.
- 7. About me recognised animated gifconnoisseur
- 8.
- 11. More open sourceproducers
- 12. Exponentially more open sourceconsumers
- 13.
- 14.
- 15. In 2011 • 4projects
- 16. In 2011 • 4projects • 2 people
- 17. In 2011 • 4projects • 2 people • Single digit external users (tiny startups)
- 18. In 2011 • 4projects • 2 people • Single digit external users (tiny startups) • Little documentation
- 19. In 2015 • Over30 projects
- 20. In 2015 • Over30 projects • 5 people, ~70 contributors
- 21. In 2015 • Over30 projects • 5 people, ~70 contributors • SMEs, Fortune 100, governments, tiny startups, academics
- 23. In 2015 • Over30 projects • 5 people, ~70 contributors • SMEs, Fortune 100, governments, tiny startups, academics • Well over 1000 hours spent writing and editing doc guides
- 24.
- 25. responsibility |riˌspänsəˈbilətē| noun (pl. responsibilities ) the state or fact of having a duty to deal with something or of having control over someone
- 26. A responsible maintainer makessure the users aren’t angry
- 28. Why can theybe angry?
- 29.
- 30.
- 31. • Unexpected changes •Nobody to help
- 32. • Unexpected changes •Nobody to help • Too hard to contribute
- 33. • Unexpected changes •Nobody to help • Too hard to contribute • Maintainer is an a- hole
- 34.
- 35. Have a helpfulREADME
- 37. What does thisthing do?
- 38.
- 39. How do Iinstall it?
- 40. What runtimes and/or versionsare supported?
- 41. What license doesit use?
- 42. Where can Iget help?
- 43. Have a mailinglist
- 44. Let community members helpyou help your users
- 45. Helping others earns theirrespect
- 46.
- 47. Keep a usefulchange log
- 48. No, git logis not a change log
- 50. Do you writebrilliantly detailed commit messages?
- 51. git log isoften hard to interpret for project outsiders
- 52. Provide details forhumans
- 53.
- 54.
- 55. Have a projectblog
- 56. Have a Twitteraccount
- 57.
- 59.
- 61. My favourite partabout ClojureWerkz is documentation…”
- 62.
- 64. Make it easyto contribute
- 65. Explain the basicsof development process
- 66. Explain how toinstall & run dependencies
- 67.
- 69.
- 74. Don’t be ana-hole
- 76. “It sounds toofucking hard”
- 77. Does anyone havethe time for that?
- 78.
- 80.
- 81. Standardise • README • Changelog format
- 82. Standardise • README • Changelog format • Announcement format
- 83. Standardise • README • Changelog format • Announcement format • Project layout (Leiningen templates)
- 84. Standardise • README • Changelog format • Announcement format • Project layout (Leiningen templates) • Same process and practices across the board
- 85.
- 86. Automate • Clojure projects typicallyhave a highly regular structure
- 87. Automate • Clojure projects typicallyhave a highly regular structure • Release process
- 88. Automate • Clojure projects typicallyhave a highly regular structure • Release process • Documentation deployment
- 89. Automate • Clojure projects typicallyhave a highly regular structure • Release process • Documentation deployment • Some things (e.g. announcements) are still better done by hand (our experience)
- 90.
- 91.
- 92. Engage contributors• Respond quickly •Be respectful
- 93. Engage contributors• Respond quickly •Be respectful • Provide context
- 94. Engage contributors• Respond quickly •Be respectful • Provide context • Encourage them to help
- 95. Engage contributors• Respond quickly •Be respectful • Provide context • Encourage them to help • Give them credits (in the change log, on Twitter, etc)
- 96. Engage contributors• Respond quickly •Be respectful • Provide context • Encourage them to help • Give them credits (in the change log, on Twitter, etc) • Add frequent contributors as collaborators
- 97.
- 98. Use data • Commonquestions
- 99. Use data • Commonquestions • Bug reports
- 100. Use data • Commonquestions • Bug reports • Your time
- 101. Use data • Commonquestions • Bug reports • Your time • Who contributes most
- 102.
- 103. Writing documentation • Don't putit off till release time
- 104. Writing documentation • Don't putit off till release time • Write guide structure first
- 105. Writing documentation • Don't putit off till release time • Write guide structure first • Ask others to edit
- 106. Writing documentation • Don't putit off till release time • Write guide structure first • Ask others to edit • A complete Getting Started guide is better than 4 unfinished ones
- 107. Writing documentation • Don't putit off till release time • Write guide structure first • Ask others to edit • A complete Getting Started guide is better than 4 unfinished ones • Guides reduce amount of time spent doing support
- 108. Writing documentation • Don't putit off till release time • Write guide structure first • Ask others to edit • A complete Getting Started guide is better than 4 unfinished ones • Guides reduce amount of time spent doing support • Guides encourage people to contribute by giving them confidence
- 110. “But what ifI’m no longer interested in maintaining X?”
- 111.
- 112. No matter whatyou do, don’t release abandonware
- 113. ”But who cares,it’s not my problem what the users will do”
- 114.
- 115. But it’s yourreputation
- 116. Open source isone of the best ways to market yourself as an engineer
- 118.
- 119.