Participating in Open Source Projects

Practice · Chapter 17

Benefits of contributing

• Better code: public visibility motivates higher-quality work than private practice code.
• Personal / organizational brand: familiarity with your work advances careers and reflects well on your organization.
• Deeper knowledge: organizations that help maintain the OSS they depend on understand it far better than mere users, easing future changes and tapping community feedback.
• Hiring: some companies review a candidate’s open source portfolio; it can help land an interview even if it is not decisive.

Creating your own project

• Solve a real need — possibly one you have already coded a solution for — and publish it.
• Package it for reuse: understandable code, following the maintainability principles and practices from this book.
• Include unit tests, documentation, and a README.md.

Licensing

• An open source license sets the terms for using, modifying, and sharing the software.
• The Open Source Initiative (OSI) approves a well-known set of licenses, including: Apache 2.0, BSD 2-Clause, BSD 3-Clause, CDDL, Eclipse Public License, GPL, LGPL, MIT, Mozilla Public License 2.0.
• Contributing to an existing project → use its existing license (often required). New project in a community → adopt the community’s preferred license.
• No license = default copyright: any creative work, including software, is copyrighted automatically. Without explicit permission, no one may use, modify, distribute, or copy it. (Explicitly asserting copyright is no longer required.)

Citations

• Software Architect’s Handbook (Packt, 2018), Ch.17 “Participating in open source projects”, pp. 1166-1168.