Life.Church Digerati Open Source - Family Reunion 2017 Breakout Session

Why should we open source our projects?
What makes a good open source project?
What are some guidelines to follow to set your open source project up for success?

*Some of this content is adapted from GitHub's Open Source Guide at http://opensource.guide

Transcript

1. Open Digerati Open Source Software Family Reunion Breakout Session
3. I interpret Open Source by Default to mean that the work I do should go towards the benefit of humanity, and I think that through this pattern, we as developers can create a better world, faster. - Orta Therox, CocoaPods Community Manager
4. We will lead the way with irrational generosity. We truly believe it is more blessed to give than to receive.
5. How can we as engineers and designers impact the lives, provide value and create a better world for other engineers and designers?
6. How can we as engineers and designers impact the lives, provide value and build a community of active contributors that can give back to a greater cause?
7. We’re Building an Army of Developers and Designers that are Growing in Their Craft
8. It’s amazing what happens when you regularly read code written by many different people and when many different people read your own code. Learning happens. Kent Dodds - Javascript Engineer, PayPal
9. https://github.com/playframework/playframework/pull/616 Dec 16, 2012
12. Who’s the next Kent?
13. What Makes a Good Open Source Project?
14. Open Source doesn’t necessarily equate to giving away an entire app.
16. When Choosing to use an Open Source Project, What Key Things Do You Look For?
17. Guidelines
18. Defining the Goal Why am I open-sourcing this project?
19. https://github.com/WhiteHouse/datacenters README
20. README
21. Great README Examples https://github.com/matiassingers/awesome-readme
22. Defining the Goal Know Your Project Scope
25. 2 Years Later...
26. Identifying Responsibilities Who’s maintaining this project after launch?
27. Just because you’re the only maintainer today, doesn’t mean you need to be the only maintainer tomorrow. How can you set your project up to live on without you? Identifying long-term maintainers comes through building a foundation of active contributors
29. Twitter Bootstrap 7 Core Maintainers How many maintainers for Bootstrap work at Twitter?
30. Some things to consider: How is a contribution reviewed and accepted (Do they need tests? An issue template?) The types of contributions you’ll accept (Do you only want help with a certain part of your code?) When it’s appropriate to follow up (ex. “You can expect a response from a maintainer within 7 days. If you haven’t heard anything by then, feel free to ping the thread.”) Set Clear Expectations/Ground Rules for Contributing
31. Licensing
32. Pre-Launch Checklist Documentation ❏ Project has a LICENSE file with an open source license ❏ Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT) ❏ The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks ❏ The issue queue is up-to-date, with issues clearly organized and labeled
33. Pre-Launch Checklist Code ❏ Project uses consistent code conventions and clear function/method/variable names ❏ The code is clearly commented, documenting intentions and edge cases ❏ There are no sensitive materials in the revision history, issues, or pull requests (ex. passwords or other non-public information)
34. Pre-Launch Checklist People ❏ You've talked to your legal department ❏ You have a marketing plan for announcing and promoting the project ❏ Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests) ❏ At least two people have administrative access to the project
35. opensource.guide
36. Conceptual Groupings OpenWorks OpenForTweaks OpenData OpenTalks OpenPlans
37. Open Source Challenge Week November 8-14