Participating in Open Source

Transcript

1. Participating in Open Source Matthew Wedgwood, RetailMeNot Adapted from “Contributing to Open Source” by Amol Sale
2. Why Open Source?
3. – Michael Tiemann “When the people are invested with the power to control their own destiny, they take an interest.” Open Source is about trust, confidence, and empowerment Transparency Build upon and improve the work of others Free to take ownership of their work
4. Why is Open Source Better? • Empowerment • Comprehensiveness • Quality Others can use your work with confidence. Not the same as freeware. No such thing as complete code (approaches, requirements, bugs) Quality not inherent. More eyes (find bugs, improved standards), More minds.
5. Revenue Models • Support/consulting • Installables • Stable Releases • Open Core Open Core detracts from the Open Source model by reverting to a proprietary lock-in model for important features.
6. Why Contribute?
7. Project Owner ! • “Free” resources • Promote compatibility • Licensing • Altruism The work of others is valuable Third parties will extend the reach of your project Open licensing increases adoption Give what you take
8. Individual Contributor • Learn • Reduce maintenance overhead (upstreaming) • Resume building • Altruism Learn • from experienced developers • new technologies • diversity Upstreaming frees you from being a lone maintainer Experience that others can see Give back
9. Getting Started
10. Scratch Your Own Itch Important You won’t finish something you don’t need Pick something useful to you and approach the problem in a generally useful way
11. Get to Know the Project • Communication • Coding standards • Documentation • Licensing • Ask questions mailing list, wiki, issue tracker, meetings follow the quality standards and idioms of the project. docs, tests, linking docs can reveal the design decisions, shortcomings, and scope licensing, contributor agreements, obligations
12. Propose/submit
 your change Participate in the discussion Learn from the experience
13. What to Contribute It’s not all about the code
14. Valuable Contributions • Documentation • Visual Design • Localization • Packaging • Infrastructure • Code Docs - external, inline, doc generation code, bug reports Logos, stylesheets, templates, etc Translate to your language Make it easier for others to use the project Hosting resources - demo servers, mail/file/collaboration servers Code - features, bugfixes, tests, code reviews
15. Personalities
16. Being a Project Owner • Confidence • Humility • Patience • Responsiveness In successful projects, this can be a big responsibility Decide how things should be done. Insist on quality. Listen to others, be open to criticism and suggestions Be patient, take the time to help those who want to help you Stay on top of discussions, contributions, and reviews
17. Individual Contributor • Attention to detail • Flexibility • Perseverance • Humility … especially to project standards. Communicate clearly. Often need to solve problems in a different way Don’t give up, own your contribution Be open to criticism and differing opinions
18. Learn Git Most projects use git for managing change Experience is applicable elsewhere (mostly other SCMs) Maybe learn bzr too, if you’ll be working on Debian-based projects
19. Common Project Management Platforms Github and Launchpad
20. Github
21. Github - Issues
22. Github - Pull Requests
23. Github - Forks & Branches
24. Github - Documentation Not all projects have a wiki. Also look into Github Pages (hosting static content)
25. Launchpad Launchpad has great features that hidden behind a complicated UI
26. Launchpad - Bugs
27. Launchpad - Branches Launchpad features are incredibly hard to discover
28. LP - Merge Proposals Launchpad features are incredibly hard to discover
29. LP - Package Archives Launchpad features are incredibly hard to discover
30. Discussion