Download to read offline
Uploaded byRob Reynolds
Running a Successful Open Source Project
Rob Reynolds outlines key strategies for running a successful open-source project, emphasizing the importance of defining success, being passionate about the project, and establishing a clear decision-making structure. He recommends effective time management, legal considerations, thorough documentation, and marketing to ensure community engagement and project sustainability. Collaboration is crucial, and he advises learning to take feedback while maintaining standards in the management of contributors.
More Related Content
Similar to Running a Successful Open Source Project
![UiPath Automation Suite Installation (Hands-On) [2/3]](https://cdn.slidesharecdn.com/ss_thumbnails/automationsuitecommunitysession2-251015095633-a6d862f1-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
Running a Successful Open Source Project
- 1. Running a Successful OpenSource Project Rob Reynolds Puppet, Inc
- 3. Rob Reynolds • SeniorSoftware Engineer on the Windows Team at Puppet • Creator of Chocolatey • Enjoys long walks on the beach and designing solutions that make hard things easy • Co-wrote infrastructure framework known as the Chuck Norris Framework • Over 10 years experience in infrastructure automation • Obsesses over user experience
- 4. Open Source SoftwareExperience • Work on Puppet • Work on Chocolatey • Work on RoundhousE and other Chuck Norris Framework tools • Contributed to numerous OSS projects
- 5. Topics • Success? • Passion •Go It Alone • Decision Structure • Legal • Versioning / Release Structure • Time Management • Documentation • Contributors / Committers • Learn to Take Critical Feedback • Collaboration • The Long Haul • Finding New Owners • Final Thoughts
- 6. So How DoYou Run A Successful OSS Project?
- 8. Define Success • Whatdoes it mean for you when working in open source?
- 9. Defining Success forRob • Solving a Problem • Building a Community • User Experience
- 10. Find a Passion •You must be passionate about your project • No one else will be for you • You must be a user of your project
- 11. Go It Alone •“I know, I’ll open source this and get help” <- The wrong idea
- 12. Decision Structure • BenevolentDictator? • Small Group? • By Vote? • Design By Committee?
- 14. Decision Structure • Recommendation- Benevolent Dictator • “Open Source is not a democracy.” • Standards Committees
- 15. Legal • Pick aFriendly Open Source License - https://opensource.org/licenses • Recommend Apache 2 or MIT • GPL if you want CopyLeft • Contributor License Agreement • http://harmonyagreements.org/
- 16. Versioning / ReleaseStructure • Semantic Versioning - https://semver.org • Where will your releases be? • Will you offer multiple versions at a time? • Do not force someone to upgrade • ChangeLog - What breaks, how to mitigate
- 17. Time Management • Setsome time aside • “If you are not good at time management now, learn to be.” • Email Filters • Still many messages per day • Find Community Members To Help • Documentation
- 18. Documentation • Docs areusually most hated thing to do • Very important • “An Ounce of Documentation Saves A Hundred Requests”
- 19. Marketing • You musttell folks about what you are doing • Blogging, showing it to prominent folks for them to blog • Put it on package managers for discovery • Build info/demo into talks at conferences • Develop an elevator pitch • Does it make sense to non-technical folks?
- 20. Contributors / Committers •Set expectations • Document processes • Document Code Design • Provides direction for folks
- 21. Learn to TakeCritical Feedback • Project is Your Baby • “Not everyone will think your baby is beautiful.” • Most feedback is helpful • Some negative feedback is helpful once you get to issue • Some folks are just trolls • Know the difference between abuse and feedback
- 22. You Are GoingTo Break Stuff
- 23. How Not ToCollaborate
- 24. How Not ToCollaborate • http://lkml.iu.edu/hypermail/linux/kernel/1510.3/02866.html
- 25. How Not ToCollaborate • https://lkml.org/lkml/2012/12/23/75
- 26. How Not ToCollaborate • https://github.com/ParsePlatform/parse-server/issues/1050
- 28. Collaboration - TheArt of Being Nice • Be Humble • Be Friendly • Understand Context Prior to Judgment • Learn to Say No - https://blog.jessfraz.com/post/the-art-of- closing/
- 29. Collaboration - FixingIssues
- 30. It’s Not AllSunshine and Roses • https://sethvargo.com/leaving-chef/ • https://plus.google.com/+LennartPoetteringTheOneAndOnly/pos ts/J2TZrTvu7vd
- 31. Collaboration Mediums • MailingList • Stack Overflow • Chat - Gitter, IRC and/or Slack
- 32. The Long Haul •Does this project have costs? • How do you plan to pay for those costs? • Your time and effort • Monetize? Sponsorship? Or Both?
- 33. Finding New Owners •Life Events • New Projects • Passions Shift • No Longer a User
- 34. Finding New Owners •No Owners • Letting the Project End • Backing Off - Is the community strong enough?
- 35. Getting Started -Contributing • When In Rome • Ask • Documentation • Smaller Things - Get Familiar • http://up-for-grabs.net/
- 36. Final Thoughts • OpenSource is Rewarding • Notoriety • Opens doors for new careers • “It’s amazing to hear when folks find what you have created useful.”