├── OSPO-101 ├── module5 │ ├── audit.png │ ├── devops.png │ ├── linking.png │ ├── notices.png │ ├── reviews.png │ ├── tools.png │ ├── approvals.png │ ├── copyright.png │ ├── diy-audit.png │ ├── outbound.png │ ├── questions.png │ ├── tools-alt.png │ ├── components.png │ ├── modification.png │ ├── own-software.png │ ├── registration.png │ ├── review-team.png │ ├── translation.png │ ├── distributions.png │ ├── diy-audit-alt.png │ ├── identification.png │ ├── incorporation.png │ ├── policy-process.png │ ├── verifications.png │ ├── analyzing-inbound.png │ ├── analyzing-usage.png │ ├── binary-scanning.png │ ├── initiate-review.png │ ├── license-scanning.png │ ├── process-overview.png │ ├── resolving-issues.png │ ├── review-oversight.png │ ├── source-scanning.png │ ├── traditional-audit.png │ ├── compliance-process.png │ ├── compliance-tooling.png │ ├── final-verifications.png │ ├── inject-into-output.png │ ├── license-categories.png │ ├── software-situation.png │ ├── audit-inputs-outputs.png │ └── working-through-review.png ├── module6 │ ├── setup.png │ ├── tracking.png │ ├── acceptance.png │ ├── cumulative.png │ ├── discussion.png │ ├── development-qa.png │ ├── priortization.png │ ├── pull-requests.png │ ├── signal-intent.png │ ├── time-to-commit.png │ ├── commits-over-time.png │ ├── internal-mirror.png │ ├── percent-over-time.png │ ├── pull-requests-alt.png │ ├── release-planning.png │ ├── supply-chain-funnel.png │ ├── cumulative-by-company.png │ ├── dev-with-upstreaming.png │ ├── dev-without-upstreaming.png │ └── README.md ├── module2 │ ├── os-ladder.png │ └── strategic-use.png ├── module3 │ ├── comcast-ospo.png │ ├── ospo-structure.png │ └── oss-foundations.png ├── module4 │ ├── linux-example.png │ ├── humble-but-bold.png │ ├── waterfall-model.png │ ├── single-body-of-code.png │ ├── continuous-integration.png │ ├── what-is-a-contributor.png │ ├── delegated-maintainership.png │ ├── overlapping-test-cycles.png │ ├── overlapping-release-cycles.png │ ├── open-source-development-model.png │ ├── release-criteria-become-more-stringent.png │ └── release-overseen-by-decicated-maintainers.png ├── module7 │ ├── release-early.png │ ├── questions-to-ask.png │ ├── good-reasons-to-opensource.png │ ├── bad-reasons-to-create-opensource.png │ └── README.md ├── module1 │ ├── community-org-structure.png │ └── README.md ├── README.md └── ospo101.svg ├── Contribution-and-Creation ├── Module-4.md ├── Module-3.md ├── Module-1.md ├── Module-2.md ├── README.md └── Module-00.md ├── .github └── settings.yml ├── README.md ├── LICENSE └── LICENSE-DOCS /OSPO-101/module5/audit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/audit.png -------------------------------------------------------------------------------- /OSPO-101/module5/devops.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/devops.png -------------------------------------------------------------------------------- /OSPO-101/module5/linking.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/linking.png -------------------------------------------------------------------------------- /OSPO-101/module5/notices.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/notices.png -------------------------------------------------------------------------------- /OSPO-101/module5/reviews.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/reviews.png -------------------------------------------------------------------------------- /OSPO-101/module5/tools.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/tools.png -------------------------------------------------------------------------------- /OSPO-101/module6/setup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/setup.png -------------------------------------------------------------------------------- /OSPO-101/module2/os-ladder.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module2/os-ladder.png -------------------------------------------------------------------------------- /OSPO-101/module5/approvals.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/approvals.png -------------------------------------------------------------------------------- /OSPO-101/module5/copyright.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/copyright.png -------------------------------------------------------------------------------- /OSPO-101/module5/diy-audit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/diy-audit.png -------------------------------------------------------------------------------- /OSPO-101/module5/outbound.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/outbound.png -------------------------------------------------------------------------------- /OSPO-101/module5/questions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/questions.png -------------------------------------------------------------------------------- /OSPO-101/module5/tools-alt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/tools-alt.png -------------------------------------------------------------------------------- /OSPO-101/module6/tracking.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/tracking.png -------------------------------------------------------------------------------- /OSPO-101/module3/comcast-ospo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module3/comcast-ospo.png -------------------------------------------------------------------------------- /OSPO-101/module5/components.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/components.png -------------------------------------------------------------------------------- /OSPO-101/module5/modification.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/modification.png -------------------------------------------------------------------------------- /OSPO-101/module5/own-software.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/own-software.png -------------------------------------------------------------------------------- /OSPO-101/module5/registration.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/registration.png -------------------------------------------------------------------------------- /OSPO-101/module5/review-team.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/review-team.png -------------------------------------------------------------------------------- /OSPO-101/module5/translation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/translation.png -------------------------------------------------------------------------------- /OSPO-101/module6/acceptance.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/acceptance.png -------------------------------------------------------------------------------- /OSPO-101/module6/cumulative.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/cumulative.png -------------------------------------------------------------------------------- /OSPO-101/module6/discussion.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/discussion.png -------------------------------------------------------------------------------- /OSPO-101/module2/strategic-use.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module2/strategic-use.png -------------------------------------------------------------------------------- /OSPO-101/module3/ospo-structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module3/ospo-structure.png -------------------------------------------------------------------------------- /OSPO-101/module4/linux-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module4/linux-example.png -------------------------------------------------------------------------------- /OSPO-101/module5/distributions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/distributions.png -------------------------------------------------------------------------------- /OSPO-101/module5/diy-audit-alt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/diy-audit-alt.png -------------------------------------------------------------------------------- /OSPO-101/module5/identification.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/identification.png -------------------------------------------------------------------------------- /OSPO-101/module5/incorporation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/incorporation.png -------------------------------------------------------------------------------- /OSPO-101/module5/policy-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/policy-process.png -------------------------------------------------------------------------------- /OSPO-101/module5/verifications.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/verifications.png -------------------------------------------------------------------------------- /OSPO-101/module6/development-qa.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/development-qa.png -------------------------------------------------------------------------------- /OSPO-101/module6/priortization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/priortization.png -------------------------------------------------------------------------------- /OSPO-101/module6/pull-requests.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/pull-requests.png -------------------------------------------------------------------------------- /OSPO-101/module6/signal-intent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/signal-intent.png -------------------------------------------------------------------------------- /OSPO-101/module6/time-to-commit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/time-to-commit.png -------------------------------------------------------------------------------- /OSPO-101/module7/release-early.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module7/release-early.png -------------------------------------------------------------------------------- /OSPO-101/module3/oss-foundations.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module3/oss-foundations.png -------------------------------------------------------------------------------- /OSPO-101/module4/humble-but-bold.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module4/humble-but-bold.png -------------------------------------------------------------------------------- /OSPO-101/module4/waterfall-model.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module4/waterfall-model.png -------------------------------------------------------------------------------- /OSPO-101/module5/analyzing-inbound.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/analyzing-inbound.png -------------------------------------------------------------------------------- /OSPO-101/module5/analyzing-usage.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/analyzing-usage.png -------------------------------------------------------------------------------- /OSPO-101/module5/binary-scanning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/binary-scanning.png -------------------------------------------------------------------------------- /OSPO-101/module5/initiate-review.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/initiate-review.png -------------------------------------------------------------------------------- /OSPO-101/module5/license-scanning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/license-scanning.png -------------------------------------------------------------------------------- /OSPO-101/module5/process-overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/process-overview.png -------------------------------------------------------------------------------- /OSPO-101/module5/resolving-issues.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/resolving-issues.png -------------------------------------------------------------------------------- /OSPO-101/module5/review-oversight.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/review-oversight.png -------------------------------------------------------------------------------- /OSPO-101/module5/source-scanning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/source-scanning.png -------------------------------------------------------------------------------- /OSPO-101/module5/traditional-audit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/traditional-audit.png -------------------------------------------------------------------------------- /OSPO-101/module6/commits-over-time.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/commits-over-time.png -------------------------------------------------------------------------------- /OSPO-101/module6/internal-mirror.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/internal-mirror.png -------------------------------------------------------------------------------- /OSPO-101/module6/percent-over-time.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/percent-over-time.png -------------------------------------------------------------------------------- /OSPO-101/module6/pull-requests-alt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/pull-requests-alt.png -------------------------------------------------------------------------------- /OSPO-101/module6/release-planning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/release-planning.png -------------------------------------------------------------------------------- /OSPO-101/module7/questions-to-ask.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module7/questions-to-ask.png -------------------------------------------------------------------------------- /OSPO-101/module4/single-body-of-code.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module4/single-body-of-code.png -------------------------------------------------------------------------------- /OSPO-101/module5/compliance-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/compliance-process.png -------------------------------------------------------------------------------- /OSPO-101/module5/compliance-tooling.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/compliance-tooling.png -------------------------------------------------------------------------------- /OSPO-101/module5/final-verifications.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/final-verifications.png -------------------------------------------------------------------------------- /OSPO-101/module5/inject-into-output.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/inject-into-output.png -------------------------------------------------------------------------------- /OSPO-101/module5/license-categories.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/license-categories.png -------------------------------------------------------------------------------- /OSPO-101/module5/software-situation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/software-situation.png -------------------------------------------------------------------------------- /OSPO-101/module6/supply-chain-funnel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/supply-chain-funnel.png -------------------------------------------------------------------------------- /OSPO-101/module4/continuous-integration.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module4/continuous-integration.png -------------------------------------------------------------------------------- /OSPO-101/module4/what-is-a-contributor.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module4/what-is-a-contributor.png -------------------------------------------------------------------------------- /OSPO-101/module5/audit-inputs-outputs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/audit-inputs-outputs.png -------------------------------------------------------------------------------- /OSPO-101/module5/working-through-review.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module5/working-through-review.png -------------------------------------------------------------------------------- /OSPO-101/module6/cumulative-by-company.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/cumulative-by-company.png -------------------------------------------------------------------------------- /OSPO-101/module6/dev-with-upstreaming.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/dev-with-upstreaming.png -------------------------------------------------------------------------------- /OSPO-101/module1/community-org-structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module1/community-org-structure.png -------------------------------------------------------------------------------- /OSPO-101/module4/delegated-maintainership.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module4/delegated-maintainership.png -------------------------------------------------------------------------------- /OSPO-101/module4/overlapping-test-cycles.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module4/overlapping-test-cycles.png -------------------------------------------------------------------------------- /OSPO-101/module6/dev-without-upstreaming.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module6/dev-without-upstreaming.png -------------------------------------------------------------------------------- /OSPO-101/module4/overlapping-release-cycles.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module4/overlapping-release-cycles.png -------------------------------------------------------------------------------- /OSPO-101/module7/good-reasons-to-opensource.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module7/good-reasons-to-opensource.png -------------------------------------------------------------------------------- /OSPO-101/module4/open-source-development-model.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module4/open-source-development-model.png -------------------------------------------------------------------------------- /OSPO-101/module7/bad-reasons-to-create-opensource.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module7/bad-reasons-to-create-opensource.png -------------------------------------------------------------------------------- /OSPO-101/module4/release-criteria-become-more-stringent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module4/release-criteria-become-more-stringent.png -------------------------------------------------------------------------------- /OSPO-101/module4/release-overseen-by-decicated-maintainers.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/node/ospo-career-path/main/OSPO-101/module4/release-overseen-by-decicated-maintainers.png -------------------------------------------------------------------------------- /Contribution-and-Creation/Module-4.md: -------------------------------------------------------------------------------- 1 | --- 2 | Status: work in progress 3 | Content guide: https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/#build-an-open-source-metrics-strategy-when-releasing-to-open-source-projects 4 | Instructors: ??? 5 | --- 6 | 7 | ## Areas to cover: 8 | 9 | Build an open source metrics strategy when contributing to and/or releasing to open source projects 10 | * Defining community health goals 11 | * Creating questions and building metrics around 12 | -------------------------------------------------------------------------------- /Contribution-and-Creation/Module-3.md: -------------------------------------------------------------------------------- 1 | --- 2 | Status: work in progress 3 | Content guide: https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/#technical-considerations-tooling-and-best-practices 4 | Instructors: ??? 5 | --- 6 | 7 | ## Areas to cover: 8 | 9 | Technical considerations, tooling and best practices 10 | * User management 11 | * Setting up a repository 12 | * Providing license and copyright information 13 | * CLA/DCO Management 14 | * Credential scanning 15 | * Quality criteria / CII Best Practices Badge Program 16 | * Repository Linting 17 | -------------------------------------------------------------------------------- /Contribution-and-Creation/Module-1.md: -------------------------------------------------------------------------------- 1 | --- 2 | Status: work in progress 3 | Content guide: https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/#how-to-contribute-to-oss-projects 4 | Instructors: ??? 5 | --- 6 | 7 | ## Areas to cover: 8 | 9 | How to contribute to OSS projects 10 | * Define your open source goal and strategy 11 | * Establish open source guiding principles and processes 12 | * Guiding principle 13 | * Responsibility: decision rests with unit 14 | * General structure and scope of the process 15 | * Process for expressing company approval for contributions 16 | * Contribution models 17 | -------------------------------------------------------------------------------- /Contribution-and-Creation/Module-2.md: -------------------------------------------------------------------------------- 1 | --- 2 | Status: work in progress 3 | Content guide: https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/#starting-open-source-projects 4 | Instructors: ??? 5 | --- 6 | 7 | ## Areas to cover: 8 | 9 | Starting open source projects 10 | * Motivation 11 | * Project life cycle 12 | * Planning or Concept Phase 13 | * Active or Development Phase 14 | * Mature or Maintenance Phase 15 | * Obsolete or End of Life Phase 16 | * Legal and governance considerations 17 | * Which license to select 18 | * Contributor License Agreement (CLA), Developer Certificate of Origin (DCO) 19 | * Project governance 20 | * Different Project Levels 21 | * Community management 22 | * Code of Conduct 23 | -------------------------------------------------------------------------------- /.github/settings.yml: -------------------------------------------------------------------------------- 1 | repository: 2 | # See https://developer.github.com/v3/repos/#edit for all available settings. 3 | 4 | # The name of the repository. Changing this will rename the repository 5 | name: ospo-career-path 6 | 7 | # A short description of the repository that will show up on GitHub 8 | description: 📖 OSPO Career Path - Training Courses 9 | 10 | # A URL with more information about the repository 11 | homepage: https://todogroup.org 12 | 13 | # Collaborators: give specific users access to this repository. 14 | # see /governance/roles.md for details on write access policy 15 | # note that the permissions below may provide wider access than needed for 16 | # a specific role, and we trust these individuals to act according to their 17 | # role. If there are questions, please contact one of the chairs. 18 | collaborators: 19 | 20 | - username: caniszczyk 21 | permission: admin 22 | 23 | - username: anajsana 24 | permission: admin 25 | 26 | - username: misappi 27 | permission: maintain 28 | 29 | - username: OliverFendt 30 | permission: maintain 31 | 32 | - username: cornelius 33 | permission: maintain 34 | 35 | - username: jlprat 36 | permission: maintain 37 | 38 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 👋 Welcome OSPO Career Path Repo 2 | 3 | OSPO Career Path is a set of vendor-neutral, open source, and free courses created by folks from the TODO / OSPO community to support training inside the organization. Each course is intended to be modularized so the content is reusable in a piecemeal fashion. 4 | 5 | The target audience of the OSPO Career path is intended to Open Source professionals that are in a role that manages, oversees, or guides the organization’s policies and/or contributions to open source projects. This includes: 6 | 7 | * Security, compliance, and licensing open source roles 8 | * Open Source developer relations, developer advocates, or community managers 9 | * Open Source project managers 10 | * Open Source leaders and general managers 11 | 12 | ## 📖 OSPO Definition 13 | 14 | Please read the [OSPO Definition featured in the OSPO Glossary](https://ospoglossary.todogroup.org/ospo-definition/) to learn more 15 | 16 | 17 | ## 🧩 OSPO Career Path Scope and Mission 18 | 19 | The OSPO Career Path is led by participants from the [OSPO Career Path Working Group](https://lists.todogroup.org/g/WG-ospo-career-path). This working group has identified four different types of personas that engage in an OSPO at some level: 20 | 21 | * (1) Open Source / OSPO managers shaping the process within an organization 22 | * (2) Open Source / OSPO contributors within an organization (code and non-code contributors) 23 | * (3) Open Source / OSPO managers executing the process (e.g Project Managers, DevRels, etc) 24 | * (4) Software staff within an organization that is involved in using open source software 25 | 26 | The scope of the OSPO Career Path focuses on persona (1) and (2) and works together with the LF Training & Certification team to turn the free modules developed in the working repo into future courses that will be part of the best practices catalog. 27 | 28 | ## 🚀 2024 Roadmap 29 | 30 | | January - April | May - August | September - December | 31 | | --- | --- | --- | 32 | | Finish content [LFC115 Course](https://github.com/todogroup/ospo-career-path/tree/main/Contribution-and-Creation) in the working repo; Assign course instructors | Launch [LFC115 Course](https://github.com/todogroup/ospo-career-path/tree/main/Contribution-and-Creation) with LF Training; set up distribution campaign with LF | Propose new course title and course outline |  33 | 34 | ## 💡 Theme Wishlist 35 | Below is a set of topics that the working group brainstormed as the baseline to start developing the career path. While some of the courses shared here already exist, others will need to be created from scratch or include additional 36 | sections to be customized for open source managers and worker contributors. 37 | 38 | Open Source Strategy 39 | 40 | * Building Effective Open Source Programs 41 | * Open Source Management & Strategy 42 | 43 | Policy and Compliance 44 | * Open Source Program Office Essentials 45 | * OpenChain Conformance Training 46 | * Open Source Standards Essentials 47 | 48 | Community Engagement & Contribution 49 | * Open Source Community Management 50 | * Building Effective Open Source Programs 51 | * Open Source Contribution Fundamentals 52 | 53 | Legal Support 54 | * Open Source Licensing Basics (for Developers) 55 | * Open Source License Compliance (for Lawyers) 56 | 57 | Security Support 58 | * Open Source Security Essentials (for Developers) 59 | * Open Source Security Essentials (for Managers) 60 | 61 | Technical Integration 62 | * Open Source Development with Git 63 | 64 | 65 | ## 🙋‍♀️ Contribute 66 | 67 | [OSPO Career Path Working Group](https://lists.todogroup.org/g/WG-ospo-career-path)is dedicated to build an OSPO Career Path composed of different modules on open source strategy, project governance, compliance, and community engagement from beginner to advanced. 68 | This team meets bi-monthly on Tuesdays (the invite link is sent via their mailing list) and is open to everyone willing to help build a training path for open source managers (those shaping the policies and processes) and open source contributors within an organization 69 | (both code and non-code contributors). 70 | 71 | ## 👩‍⚖️ License 72 | 73 | All code is offered under the Apache 2.0 and documentation is offered under the Creative Commons Attribution 4.0 International License: http://creativecommons.org/licenses/by/4.0/ 74 | -------------------------------------------------------------------------------- /OSPO-101/README.md: -------------------------------------------------------------------------------- 1 | # OSPO 101 Training Modules 2 | 3 | 4 | 5 | OSPO 101 is a course on everything you need to know about open source program office management. 6 | 7 | It is intended to be modularized so the content is reusable in a piecemeal fashion: 8 | 9 | * [Open Source Introduction](module1/README.md) 10 | * [Open Source Business Strategy](module2/README.md) 11 | * [Effective Open Source Program (OSPO) Management](module3/README.md) 12 | * [Open Source Development Practices](module4/README.md) 13 | * [Open Source Compliance Programs](module5/README.md) 14 | * [Collaborating Effectively with Open Source Projects](module6/README.md) 15 | * [Creating Open Source Projects](module7/README.md) 16 | 17 | The OSPO 101 course material is also available on LF Training as a full fledged packaged course for your organization: 18 | 19 | https://training.linuxfoundation.org/training/open-source-management-and-strategy/ 20 | 21 | ## Course Outline 22 | 23 | * [Open Source Introduction](module1/README.md) 24 | * [Introducing Open Source](module1/README.md#section-introducing-open-source) 25 | * [A Short History of Open Source Software](module1/README.md#section-a-short-history-of-open-source-software) 26 | * [Reasons to Use Open Source](module1/README.md#section-reasons-to-use-open-source) 27 | 28 | * [Open Source Business Strategy](module2/README.md) 29 | * [Introducing Open Source Business Models](module2/README.md#section-introducing-open-source-business-models) 30 | * [Developing an Open Source Strategy](module2/README.md#section-developing-an-open-source-strategy) 31 | * [Developing Open Source Policies](module2/README.md#section-developing-open-source-policies) 32 | * [Introducing the Open Source Program Office (OSPO)](module2/README.md#section-introducing-the-open-source-program-office) 33 | 34 | * [Effective Open Source Program (OSPO) Management](module3/README.md) 35 | * [Open Source Program Offices & Your Organization](module3/README.md#open-source-program-offices-ospo-and-your-organization) 36 | * [Building an Effective Open Source Program Office](module3/README.md#building-an-effective-open-source-program-office) 37 | * [Additional Information & Case Studies](module3/README.md#additional-resources) 38 | 39 | * [Open Source Development Practices](module4/README.md) 40 | * [Effective Open Source Development & Participation](module4/README.md#effective-open-source-development--participation) 41 | * [The Role of Continuous Integration & Testing](module4/README.md#the-role-of-continuous-integration--testing) 42 | * [Applying Open Source Methodologies Internally](module4/README.md#applying-open-source-methodologies-internally) 43 | 44 | * [Open Source Compliance Programs](module5/README.md) 45 | * [Open Source Licensing and Compliance Basics](module5/README.md#open-source-licensing-and-compliance-basics) 46 | * [Building an Effective Compliance Program](module5/README.md#section-building-an-effective-compliance-program) 47 | * [Choosing the Right License Compliance Tool](module5/README.md#section-choosing-the-right-license-compliance-tool) 48 | * [The Role of Open Source Audits During M&A Activities](module5/README.md#section-the-role-of-open-source-audits-during-ma-activities) 49 | 50 | * [Collaborating Effectively with Open Source Projects](module6/README.md) 51 | * [Understanding Upstream Open Source Projects](module6/README.md#understanding-upstream-open-source-projects) 52 | * [Effective Upstream Contribution Strategies](module6/README.md#section-effective-upstream-contribution-strategies) 53 | * [Upstream Development Practices](module6/README.md#section-upstream-development-practices) 54 | 55 | * [Creating Open Source Projects](module7/README.md) 56 | * [Open Source Project Creation Overview](module7/README.md#open-source-project-creation-overview) 57 | * [New Project Preparations](module7/README.md#section-new-project-preparations) 58 | * [Successful Project Launch & Sustainment](module7/README.md##section-successful-project-launch-and-sustainment) 59 | 60 | ## Acknowledgements 61 | 62 | We would like to thank [Guy Martin](https://twitter.com/guyma) for helping seed the initial content for the course. The course was converted to friendly markdown format by the TODO Group community, including contributions from [Chris Aniszczyk](https://twitter.com/cra) and Greg Back. 63 | 64 | ## License 65 | 66 | All code is offered under the Apache 2.0 and documentation is offered under the Creative Commons Attribution 4.0 International License: http://creativecommons.org/licenses/by/4.0/ 67 | -------------------------------------------------------------------------------- /Contribution-and-Creation/README.md: -------------------------------------------------------------------------------- 1 | # Contributing and Launching Open Source Projects within Organizations (LFC115) 2 | 3 | ## Course Description 4 | 5 | *Contribute and Launch Open Source Projects* is a 5-module course series designated for workers within organizations managing open source that builds on the accumulated wisdom of the previous [Guide to Outbound Open Source Software](https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/) documentation. This course offers management and strategic skills into why and how the organizations's team units can efficiently contribute to open source projects. 6 | 7 | Upon course completion, learners will be equipped to establish and manage open source projects more effectively. They will gain a clear understanding of how to tailor these practices to their specific organizational context and teams, whether in a large or small organization. 8 | 9 | ## Course Learning Outcomes 10 | 11 | By the end of this course, you should be able to: 12 | 13 | * **Understand and Communicate the Strategic Importance of Open Source Contribution:** You will gain an in-depth understanding of why contributing to open source projects is strategically beneficial for organizations 14 | * **Develop Project Management Skills in Open Source Context:** You will be equipped with skills to effectively establish and manage open source projects in an organization context. 15 | * **Enhance Team Collaboration in Open Source Projects:** You will learn techniques to improve collaboration and coordination across teams/departments 16 | 17 | ## Course Audience 18 | 19 | This course series is designed to help executives and managers who shape open source processes within organizations, understand and articulate the basic concepts for contributing and launching open source projects in their organization. 20 | 21 | ## Knowledge/Skills Prerequisites 22 | 23 | Before enrolling, students should have a basic understanding of software development and business concepts. We recommend students take the following courses in advance: 24 | 25 | * LFD102 - A Beginner’s Guide to Open Source Software Development 26 | * LFC202-207 - Open Source Management & Strategy 27 | * LFC193 - Introduction to Open Source License Compliance Management 28 | * LFC105 - Antitrust Laws and Open Source Software Project Management and Participation 29 | 30 | Students involved in the finance sector are advised to consider the following industry-vertical course for additional guidance: 31 | 32 | * LFD137 - Open Source Contribution in Finance 33 | 34 | ## Lab/System Prerequisites 35 | 36 | None 37 | 38 | ## What the Course Prepares For 39 | 40 | This course prepares students working in organizations for advanced roles in IT management, focusing on the strategic and efficient contribution to open source projects. Learners are equipped with the skills necessary for roles such as Open Source Project Manager or Open Source Program Office Lead. 41 | 42 | ## Outline 43 | Chapter titles and learning objectives for each chapter 44 | 45 | * Introduction 46 | * Understand the maturity levels in open source projects. 47 | * Explore the motivations for contributing to open source, including: 48 | * Building software faster and better. 49 | * Exercising strategic influence. 50 | * Attracting, growing, and retaining talent. 51 | * Sustaining the open source ecosystem. 52 | * How to Contribute to OSS Projects 53 | * Define your organization's open source goals and strategy. 54 | * Establish guiding principles and processes for open source contribution, including: 55 | * Understanding the guiding principles. 56 | * Identifying who holds decision-making responsibilities. 57 | * Outlining the general structure and scope of the contribution process. 58 | * Process for obtaining company approval for contributions. 59 | * Learn about various open source contribution models. 60 | * Starting Open Source Projects 61 | * Analyze the motivation behind starting open source projects. 62 | * Understand the project life cycle, including: 63 | * Planning or Concept Phase. 64 | * Active or Development Phase. 65 | * Mature or Maintenance Phase. 66 | * Obsolete or End of Life Phase. 67 | * Delve into legal and governance considerations: 68 | * Choosing the right license. 69 | * Understanding the Contributor License Agreement (CLA) and Developer Certificate of Origin (DCO). 70 | * Establishing project governance. 71 | * Differentiating between various project levels. 72 | * Master community management, including creating a Code of Conduct. 73 | * Technical Considerations, Tooling, and Best Practices 74 | * Learn about user management in open source projects. 75 | * Set up and maintain a repository. 76 | * Provide appropriate license and copyright information. 77 | * Manage CLA/DCO effectively. 78 | * Implement credential scanning. 79 | * Understand quality criteria and the CII Best Practices Badge Program. 80 | * Learn about repository linting. 81 | * Building an Open Source Metrics Strategy 82 | * Develop strategies for measuring and evaluating the success and impact of open source releases. 83 | 84 | ## Course Length 85 | 86 | 1. Introduction: 87 | * Estimated lecture time: 1 hour 88 | * Touchpoint exam: 10 minutes 89 | 2. How to Contribute to OSS Projects: 90 | * Estimated lecture time: 3 hours 91 | * Touchpoint exam: 10 minutes 92 | 3. Starting Open Source Projects: 93 | * Estimated lecture time: 3 hours 94 | * Touchpoint exam: 10 minutes 95 | 4. Technical Considerations, Tooling, and Best Practices: 96 | * Estimated lecture time: 2 hours 97 | * Touchpoint exam: 10 minutes 98 | 5. Building an Open Source Metrics Strategy: 99 | * Estimated lecture time: 1 hour 100 | * Touchpoint exam: 10 minutes 101 | 102 | 6. Final Exam 103 | * Estimated time: 15 minutes 104 | 105 | TOTAL LECTURE TIME: 10 Hours 106 | TOTAL EXAM TIME: 1 Hour 107 | 108 | 109 | ## Course Author Bio and Picture 110 | 111 | TBD 112 | 113 | 114 | ## Digital Badge Description, Skills and Tags 115 | 116 | Earners of the Contributing and Launching Open Source Projects within Organizations badge showcase expertise in managing open source projects. 117 | They excel in strategy implementation and cross-team collaboration to manage employee contributions. 118 | 119 | `open source management and strategy`; `open source governance`; `project management`; `open source project life cycle` 120 | -------------------------------------------------------------------------------- /OSPO-101/ospo101.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Contribution-and-Creation/Module-00.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | - Maturity Levels 4 | - How companies manage open source 5 | - Motivation for open source contribution 6 | 7 | ## 0.1 Maturity levels 8 | 9 | Corporate adoption of open source software can typically be classified with a model of maturity levels. These levels describe how open source software is used in an increasingly effective fashion to drive value and address business needs. One of the distinguishing factors for the different maturity levels is how outbound open source is handled in an organization. The insight that influencing the open source ecosystem is mainly done by participation in and contributing to open source projects is seen as a critical factor. 10 | 11 | A typical maturity model of corporate open source adoption looks like this (see for example [Haddad: Open Source Program Offices](https://www.linkedin.com/pulse/open-source-program-offices-primer-organizational-roles-haddad)): 12 | 13 | 0. Denial - No or unconscious use of open source 14 | 1. Consumption - Passive use of open source software 15 | 2. Participation - Engagement with open source communities 16 | 3. Contribution - Pragmatic contributions to open source projects 17 | 4. Leadership - Strategic involvement with open source to drive business value 18 | 19 | To advance from one level to another, certain initiatives and structural and organizational elements are required. 20 | 21 | Going from consumption to participation, for example, will start with informal engagement and low-effort activities such as reporting bugs in upstream projects, which typically is driven by technical needs. On that level, decisions about open source contributions will normally be ad-hoc and be taken for individual cases only. 22 | 23 | Establishing dedicated decision making processes and formalizing contribution policies will lead to the next level. A typical step on this level is to establish an Open Source Program Office to support open source engagement and maintain an open source strategy and processes. 24 | 25 | On the leadership level, contribution processes are mature and scale. Corresponding tool chains are implemented. Own projects with the goal to create new open source communities are started if that's required and appropriate. This will typically come with leveraging open source foundations to enable cross-company collaboration to strategically use open source to accelerate creating business value. 26 | 27 | A company may decide to not progress to levels which are based on more contributions, and it's of course possible to build mature processes to consume open source software without contributing. In most cases, there will be some pressure to contribute back, though. This can arise from practical technical needs (missing functionalities or required bug fixes are typical reasons for contributing to open source projects), from the expectation to take responsibility in the open source ecosystem, or from the desire to reap the full benefits of the open source model. 28 | 29 | ## 0.2 How companies manage open source: Open Source Program Offices 30 | 31 | An increasing number of organizations realized the tasks of managing open source in an enterprise, and the complex relationships that are inherent to the open source ecosystem when they are advancing in their engagement in open source, required dedicated support. For this reason, many of them started Open Source Program Offices (OSPOs) - though perhaps under a different name, such as Open Source Technology Centers, Open Source Community Development Team etc. OSPOs are a designated place where open source is supported, nurtured, shared, explained, and grown inside an organization. With such an office in place, businesses can establish and execute on their open source strategies with clear terms and responsibilities, giving their leaders, developers, marketers, and other staff the processes and tools they need to make open source a success within their operations. 32 | 33 | The TODO Group offers a [set of guides](https://todogroup.org/guides/) on how to get started with an OSPO. Companies that are new to this topic, might want to first take a look at [**How to create an open source program**](https://todogroup.org/guides/create-program/) 34 | 35 | ## 0.3 Motivation for Open Source Contribution 36 | 37 | There is a broad spectrum of motivations for contributing to open source projects or starting new projects. Here, we can only list some examples. 38 | 39 | ### Build software faster and better 40 | 41 | Consuming open source software typically increases the development speed and decreases development costs since one builds upon existing code and a working and tested functionality. One risk however is that required features or bug fixes are not provided by the community as quickly as needed. To mitigate that risk, it might make sense to build up the required skills and create these bug fixes and/or features yourself. Contributing them back to the upstream projects has important benefits: 42 | 43 | * Integrating "own" features into upstream projects makes maintenance a lot easier 44 | * Upstream versions can be directly used in own products and services 45 | * More features are obtained in shorter period of time 46 | * Higher quality is achieved in shorter period of time 47 | * Support available from core experts 48 | 49 | ### Exercise strategic influence 50 | 51 | In addition to the benefits of open source software wrt. development velocity and quality mentioned above, contributing to open source projects can also be important from a strategic point of view. In the open source world, reputation and the ability to influence is typically build up by engaging in the community and by contributing. Thus, contributions to open source projects can help to: 52 | 53 | * Influence the direction of upstream open source projects 54 | * Gain (co)copyright on open source software packages 55 | * Access to the creativity of everyone interested in software 56 | 57 | Companies sometimes have the tendency to use money to exert influence. With open source projects this is not the most effective method. The currency of influence is contributions, because open source projects are usually much more driven by the work of individuals than the decisions of committees. So contributions work much more directly and effectively than being a member in an organization or paying for support or other services. 58 | 59 | Open source communities (particularly those run by the big open source foundations) provide a neutral place for collaboration between companies and other organizations. Thus, an open source approach could offer new ways of collaboration with suppliers, customers, partner and even competitors, just to mention industry- or domain-specific projects such as [Linux Foundation Energy](https://www.lfenergy.org/) or [Eclipse Tractus-X](https://projects.eclipse.org/proposals/eclipse-tractus-x). Establishing open source communities can also be a powerful means to create and maintain ecosystems and to establish de facto standards. 60 | 61 | ### Attract, grow and retain talents 62 | 63 | Software (and therefore also open source software) becomes more and more ubiquitous in many products and areas. Thus, for many companies it is crucial to have a skilled and motivated software development workforce. This is not only true for software or cloud companies, but also for companies from other segments, such as traditional hardware producers who integrate software into their products more and more, or any other company which is becoming more dependent on software due to accelerating digital transformation. An open source strategy including open source contributions and community engagements supports this: 64 | 65 | * Increase developer satisfaction 66 | * Improve quality and boosts developer skills by peer review of each contribution by core experts 67 | * Make company visible as an attractive employer 68 | * Improve company's reputation, and with it the standing of developers in their communities 69 | 70 | ### Be resilient and keep open source sustainable 71 | 72 | Open source software development is living from its communities. As mentioned above, the usage (also called consumption) of open source software helps to decrease costs and speed up development, but that's only possible because there is a community behind these projects maintaining the software. 73 | To keep the open source development model sustainable, each consumer of open source software has therefore the responsibility to think about ways how to support these projects. These are some ways of engagement and support: 74 | 75 | * Contributions in terms of code, documentation, time, security reviews, testing 76 | * Donating infrastructure resources, e.g. compute resources for CI/CD and testing 77 | * Dedicating a "DevRel" person to the project 78 | * "Marketing support", for instance by featuring a project in company blogs etc. 79 | * Monetary support (some important projects are maintained by developers who do this in their spare time and thus can only invest limited time in the project) 80 | * Hosting hackathons and local community meet-ups 81 | 82 | It is important to understand that though open source software has no license costs when consuming it, it is not available for free. To keep these projects attractive for its consumers, steady engagement and support is required. That's why it is important to have a strategy for open source contributions in place. 83 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /LICENSE-DOCS: -------------------------------------------------------------------------------- 1 | Attribution 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More_considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution 4.0 International Public License 58 | 59 | By exercising the Licensed Rights (defined below), You accept and agree 60 | to be bound by the terms and conditions of this Creative Commons 61 | Attribution 4.0 International Public License ("Public License"). To the 62 | extent this Public License may be interpreted as a contract, You are 63 | granted the Licensed Rights in consideration of Your acceptance of 64 | these terms and conditions, and the Licensor grants You such rights in 65 | consideration of benefits the Licensor receives from making the 66 | Licensed Material available under these terms and conditions. 67 | 68 | 69 | Section 1 -- Definitions. 70 | 71 | a. Adapted Material means material subject to Copyright and Similar 72 | Rights that is derived from or based upon the Licensed Material 73 | and in which the Licensed Material is translated, altered, 74 | arranged, transformed, or otherwise modified in a manner requiring 75 | permission under the Copyright and Similar Rights held by the 76 | Licensor. For purposes of this Public License, where the Licensed 77 | Material is a musical work, performance, or sound recording, 78 | Adapted Material is always produced where the Licensed Material is 79 | synched in timed relation with a moving image. 80 | 81 | b. Adapter's License means the license You apply to Your Copyright 82 | and Similar Rights in Your contributions to Adapted Material in 83 | accordance with the terms and conditions of this Public License. 84 | 85 | c. Copyright and Similar Rights means copyright and/or similar rights 86 | closely related to copyright including, without limitation, 87 | performance, broadcast, sound recording, and Sui Generis Database 88 | Rights, without regard to how the rights are labeled or 89 | categorized. For purposes of this Public License, the rights 90 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 91 | Rights. 92 | 93 | d. Effective Technological Measures means those measures that, in the 94 | absence of proper authority, may not be circumvented under laws 95 | fulfilling obligations under Article 11 of the WIPO Copyright 96 | Treaty adopted on December 20, 1996, and/or similar international 97 | agreements. 98 | 99 | e. Exceptions and Limitations means fair use, fair dealing, and/or 100 | any other exception or limitation to Copyright and Similar Rights 101 | that applies to Your use of the Licensed Material. 102 | 103 | f. Licensed Material means the artistic or literary work, database, 104 | or other material to which the Licensor applied this Public 105 | License. 106 | 107 | g. Licensed Rights means the rights granted to You subject to the 108 | terms and conditions of this Public License, which are limited to 109 | all Copyright and Similar Rights that apply to Your use of the 110 | Licensed Material and that the Licensor has authority to license. 111 | 112 | h. Licensor means the individual(s) or entity(ies) granting rights 113 | under this Public License. 114 | 115 | i. Share means to provide material to the public by any means or 116 | process that requires permission under the Licensed Rights, such 117 | as reproduction, public display, public performance, distribution, 118 | dissemination, communication, or importation, and to make material 119 | available to the public including in ways that members of the 120 | public may access the material from a place and at a time 121 | individually chosen by them. 122 | 123 | j. Sui Generis Database Rights means rights other than copyright 124 | resulting from Directive 96/9/EC of the European Parliament and of 125 | the Council of 11 March 1996 on the legal protection of databases, 126 | as amended and/or succeeded, as well as other essentially 127 | equivalent rights anywhere in the world. 128 | 129 | k. You means the individual or entity exercising the Licensed Rights 130 | under this Public License. Your has a corresponding meaning. 131 | 132 | 133 | Section 2 -- Scope. 134 | 135 | a. License grant. 136 | 137 | 1. Subject to the terms and conditions of this Public License, 138 | the Licensor hereby grants You a worldwide, royalty-free, 139 | non-sublicensable, non-exclusive, irrevocable license to 140 | exercise the Licensed Rights in the Licensed Material to: 141 | 142 | a. reproduce and Share the Licensed Material, in whole or 143 | in part; and 144 | 145 | b. produce, reproduce, and Share Adapted Material. 146 | 147 | 2. Exceptions and Limitations. For the avoidance of doubt, where 148 | Exceptions and Limitations apply to Your use, this Public 149 | License does not apply, and You do not need to comply with 150 | its terms and conditions. 151 | 152 | 3. Term. The term of this Public License is specified in Section 153 | 6(a). 154 | 155 | 4. Media and formats; technical modifications allowed. The 156 | Licensor authorizes You to exercise the Licensed Rights in 157 | all media and formats whether now known or hereafter created, 158 | and to make technical modifications necessary to do so. The 159 | Licensor waives and/or agrees not to assert any right or 160 | authority to forbid You from making technical modifications 161 | necessary to exercise the Licensed Rights, including 162 | technical modifications necessary to circumvent Effective 163 | Technological Measures. For purposes of this Public License, 164 | simply making modifications authorized by this Section 2(a) 165 | (4) never produces Adapted Material. 166 | 167 | 5. Downstream recipients. 168 | 169 | a. Offer from the Licensor -- Licensed Material. Every 170 | recipient of the Licensed Material automatically 171 | receives an offer from the Licensor to exercise the 172 | Licensed Rights under the terms and conditions of this 173 | Public License. 174 | 175 | b. No downstream restrictions. You may not offer or impose 176 | any additional or different terms or conditions on, or 177 | apply any Effective Technological Measures to, the 178 | Licensed Material if doing so restricts exercise of the 179 | Licensed Rights by any recipient of the Licensed 180 | Material. 181 | 182 | 6. No endorsement. Nothing in this Public License constitutes or 183 | may be construed as permission to assert or imply that You 184 | are, or that Your use of the Licensed Material is, connected 185 | with, or sponsored, endorsed, or granted official status by, 186 | the Licensor or others designated to receive attribution as 187 | provided in Section 3(a)(1)(A)(i). 188 | 189 | b. Other rights. 190 | 191 | 1. Moral rights, such as the right of integrity, are not 192 | licensed under this Public License, nor are publicity, 193 | privacy, and/or other similar personality rights; however, to 194 | the extent possible, the Licensor waives and/or agrees not to 195 | assert any such rights held by the Licensor to the limited 196 | extent necessary to allow You to exercise the Licensed 197 | Rights, but not otherwise. 198 | 199 | 2. Patent and trademark rights are not licensed under this 200 | Public License. 201 | 202 | 3. To the extent possible, the Licensor waives any right to 203 | collect royalties from You for the exercise of the Licensed 204 | Rights, whether directly or through a collecting society 205 | under any voluntary or waivable statutory or compulsory 206 | licensing scheme. In all other cases the Licensor expressly 207 | reserves any right to collect such royalties. 208 | 209 | 210 | Section 3 -- License Conditions. 211 | 212 | Your exercise of the Licensed Rights is expressly made subject to the 213 | following conditions. 214 | 215 | a. Attribution. 216 | 217 | 1. If You Share the Licensed Material (including in modified 218 | form), You must: 219 | 220 | a. retain the following if it is supplied by the Licensor 221 | with the Licensed Material: 222 | 223 | i. identification of the creator(s) of the Licensed 224 | Material and any others designated to receive 225 | attribution, in any reasonable manner requested by 226 | the Licensor (including by pseudonym if 227 | designated); 228 | 229 | ii. a copyright notice; 230 | 231 | iii. a notice that refers to this Public License; 232 | 233 | iv. a notice that refers to the disclaimer of 234 | warranties; 235 | 236 | v. a URI or hyperlink to the Licensed Material to the 237 | extent reasonably practicable; 238 | 239 | b. indicate if You modified the Licensed Material and 240 | retain an indication of any previous modifications; and 241 | 242 | c. indicate the Licensed Material is licensed under this 243 | Public License, and include the text of, or the URI or 244 | hyperlink to, this Public License. 245 | 246 | 2. You may satisfy the conditions in Section 3(a)(1) in any 247 | reasonable manner based on the medium, means, and context in 248 | which You Share the Licensed Material. For example, it may be 249 | reasonable to satisfy the conditions by providing a URI or 250 | hyperlink to a resource that includes the required 251 | information. 252 | 253 | 3. If requested by the Licensor, You must remove any of the 254 | information required by Section 3(a)(1)(A) to the extent 255 | reasonably practicable. 256 | 257 | 4. If You Share Adapted Material You produce, the Adapter's 258 | License You apply must not prevent recipients of the Adapted 259 | Material from complying with this Public License. 260 | 261 | 262 | Section 4 -- Sui Generis Database Rights. 263 | 264 | Where the Licensed Rights include Sui Generis Database Rights that 265 | apply to Your use of the Licensed Material: 266 | 267 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 268 | to extract, reuse, reproduce, and Share all or a substantial 269 | portion of the contents of the database; 270 | 271 | b. if You include all or a substantial portion of the database 272 | contents in a database in which You have Sui Generis Database 273 | Rights, then the database in which You have Sui Generis Database 274 | Rights (but not its individual contents) is Adapted Material; and 275 | 276 | c. You must comply with the conditions in Section 3(a) if You Share 277 | all or a substantial portion of the contents of the database. 278 | 279 | For the avoidance of doubt, this Section 4 supplements and does not 280 | replace Your obligations under this Public License where the Licensed 281 | Rights include other Copyright and Similar Rights. 282 | 283 | 284 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 285 | 286 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 287 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 288 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 289 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 290 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 291 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 292 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 293 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 294 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 295 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 296 | 297 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 298 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 299 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 300 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 301 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 302 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 303 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 304 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 305 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 306 | 307 | c. The disclaimer of warranties and limitation of liability provided 308 | above shall be interpreted in a manner that, to the extent 309 | possible, most closely approximates an absolute disclaimer and 310 | waiver of all liability. 311 | 312 | 313 | Section 6 -- Term and Termination. 314 | 315 | a. This Public License applies for the term of the Copyright and 316 | Similar Rights licensed here. However, if You fail to comply with 317 | this Public License, then Your rights under this Public License 318 | terminate automatically. 319 | 320 | b. Where Your right to use the Licensed Material has terminated under 321 | Section 6(a), it reinstates: 322 | 323 | 1. automatically as of the date the violation is cured, provided 324 | it is cured within 30 days of Your discovery of the 325 | violation; or 326 | 327 | 2. upon express reinstatement by the Licensor. 328 | 329 | For the avoidance of doubt, this Section 6(b) does not affect any 330 | right the Licensor may have to seek remedies for Your violations 331 | of this Public License. 332 | 333 | c. For the avoidance of doubt, the Licensor may also offer the 334 | Licensed Material under separate terms or conditions or stop 335 | distributing the Licensed Material at any time; however, doing so 336 | will not terminate this Public License. 337 | 338 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 339 | License. 340 | 341 | 342 | Section 7 -- Other Terms and Conditions. 343 | 344 | a. The Licensor shall not be bound by any additional or different 345 | terms or conditions communicated by You unless expressly agreed. 346 | 347 | b. Any arrangements, understandings, or agreements regarding the 348 | Licensed Material not stated herein are separate from and 349 | independent of the terms and conditions of this Public License. 350 | 351 | 352 | Section 8 -- Interpretation. 353 | 354 | a. For the avoidance of doubt, this Public License does not, and 355 | shall not be interpreted to, reduce, limit, restrict, or impose 356 | conditions on any use of the Licensed Material that could lawfully 357 | be made without permission under this Public License. 358 | 359 | b. To the extent possible, if any provision of this Public License is 360 | deemed unenforceable, it shall be automatically reformed to the 361 | minimum extent necessary to make it enforceable. If the provision 362 | cannot be reformed, it shall be severed from this Public License 363 | without affecting the enforceability of the remaining terms and 364 | conditions. 365 | 366 | c. No term or condition of this Public License will be waived and no 367 | failure to comply consented to unless expressly agreed to by the 368 | Licensor. 369 | 370 | d. Nothing in this Public License constitutes or may be interpreted 371 | as a limitation upon, or waiver of, any privileges and immunities 372 | that apply to the Licensor or You, including from the legal 373 | processes of any jurisdiction or authority. 374 | 375 | 376 | ======================================================================= 377 | 378 | Creative Commons is not a party to its public 379 | licenses. Notwithstanding, Creative Commons may elect to apply one of 380 | its public licenses to material it publishes and in those instances 381 | will be considered the "Licensor." The text of the Creative Commons 382 | public licenses is dedicated to the public domain under the CC0 Public 383 | Domain Dedication. Except for the limited purpose of indicating that 384 | material is shared under a Creative Commons public license or as 385 | otherwise permitted by the Creative Commons policies published at 386 | creativecommons.org/policies, Creative Commons does not authorize the 387 | use of the trademark "Creative Commons" or any other trademark or logo 388 | of Creative Commons without its prior written consent including, 389 | without limitation, in connection with any unauthorized modifications 390 | to any of its public licenses or any other arrangements, 391 | understandings, or agreements concerning use of licensed material. For 392 | the avoidance of doubt, this paragraph does not form part of the 393 | public licenses. 394 | 395 | Creative Commons may be contacted at creativecommons.org. 396 | -------------------------------------------------------------------------------- /OSPO-101/module1/README.md: -------------------------------------------------------------------------------- 1 | # Section: Introducing Open Source 2 | 3 | ## Lesson: Introduction 4 | 5 | ### Section Overview 6 | 7 | In this section, we will provide definitions of open source, open standards and closed source software, as well as comparisons between them. We will also provide an overview of how these three elements are used together to deliver technology solutions that we all rely on. 8 | 9 | ### Learning Objectives 10 | 11 | By the end of this section, you should be able to: 12 | 13 | * Define open source, open standards and closed source software. 14 | 15 | * Explain the differences and similarities for all three concepts. 16 | 17 | * Understand how all three concepts work together. 18 | 19 | ## Lesson: Definitions 20 | 21 | ### What is Open Source Software? 22 | 23 | According to [Wikipedia](https://en.wikipedia.org/wiki/Software_license): 24 | 25 | **Open source software** (**OSS**) is a type of computer software in which source code is released under a license in which the copyright holder grants users the rights to study, change, and distribute the software to anyone and for any purpose. Open source software may be developed in a collaborative public manner. 26 | 27 | Let's break down this definition and explore it a bit: 28 | 29 | **Computer Software** 30 | 31 | Computer Software refers to a program or firmware written by an author. The author of the software can be one or many people, and possibly doing the work on behalf of a company. The program is runnable on a particular computer through a machine-readable format that is achieved through conversion of ‘source code’ to what is known as ‘binary format.’ 32 | 33 | **Source Code** 34 | 35 | Source Code refers to the human-readable set of instructions used to represent an algorithm or idea for a computer to execute. Many computer languages can be used to write source code, which will get converted to machine-readable binary format through the process of compilation or real-time interpretation. Having the source code allows you to study and efficiently modify the software. 36 | 37 | **License** 38 | 39 | License is a **legal** document that records and formally expresses a set of legally enforceable acts, processes, or contractual duties, obligations, or rights related to the software and/or source code. 40 | 41 | **Study, Change and Distribute** 42 | 43 | A fundamental component of open source software is the freedom granted by various open source licenses allowing individuals to study the software, change it for their own purposes, and then redistribute their changes to anyone else for any purpose. The requirements placed on the changed version vary depending on the type of open source license used. More details will be provided on this in later modules in this course series. 44 | 45 | **Collaborative Public Manner** 46 | 47 | Collaborative Public Manner is important here because the freedoms provided by the license allow for large and diverse communities to form around popular open source software, helping drive innovation and allowing companies to both contribute to and reap the benefits of these software projects. Linux is a key example of one such community, but there are many others like the Apache Web Server, Kubernetes and OpenStack. 48 | 49 | ### What is Closed Source Software? 50 | 51 | Software that is not open source software is closed source software. Here’s an explanation of what the closed source software is based on the [Wikipedia](https://en.wikipedia.org/wiki/Software_license) definition: 52 | 53 | **Closed source** software, also often referred to as **proprietary** software, is non-free computer software for which the software's publisher or another person retains intellectual rights beyond those allowed for open source software— usually [copyright](https://en.wikipedia.org/wiki/Copyright) of the source code but sometimes also patent rights. 54 | 55 | As before, let’s unpack this definition a bit and explore some key elements: 56 | 57 | **Closed Source** 58 | 59 | In contrast to open source, closed source software’s human-readable instructions are not made available by the author or authors of the software. What is delivered and installed on a computer is the machine-readable format only. Popular programs like Microsoft Office, for example, are delivered this way. 60 | 61 | **Non-free** 62 | 63 | Non-free here refers to the fact that the author(s) distribute it under a license that is not open source software, that forbids studying, modifying or redistributing the program to anyone. There may or may not be a fee for its use. 64 | 65 | **Intellectual Rights** 66 | 67 | The author(s) retain access not only to the source code, but also to the ideas and/or algorithms used to design the program. 68 | 69 | The other main distinction here is that closed source software is designed and developed by teams of developers (usually working for a corporation, but not always) who are typically not collaborating with outside community members (as is typically done with open source software). 70 | 71 | ### What are Open Standards? 72 | 73 | There are various definitions available for what an ‘open standard’ is, and we can coalesce pieces of them here: 74 | 75 | **Open Standards** are publicly available and royalty-free, while 'standard' means a technology approved by formalized committees that are open to participation by all interested parties and operate on a consensus basis. An open standard is publicly available, and developed, approved and maintained via a collaborative and consensus driven process. 76 | 77 | Additionally, **Open Standards** should not prohibit conforming implementations in open source software. 78 | 79 | Let’s go ahead and dive a bit deeper here as well: 80 | 81 | **Publicly available** 82 | 83 | The standard is available to the public at no cost. 84 | 85 | **Royalty-free** 86 | 87 | This is an important distinction between open and non-open standards. This is the ability for anyone to utilize the standard to build a solution without having to obtain a license from an entity (or pay an entity) is paramount to wider adoption. 88 | 89 | **Collaborative and Consensus Driven Process** 90 | 91 | This should now be familiar to you from the previous definitions of open source, and it is also critical here as it allows for both a wider set of perspectives and also the best chance at broad adoption by a variety of companies and individuals. It also sometimes makes defining standards a lengthy process. 92 | 93 | **Conforming Implementations** 94 | 95 | This is a specific definition set forth by the Open Source Initiative (OSI), an industry consortium that helps maintain both approved open source licenses as well as the formal definition of open source. Their Open Standards Requirement (OSR) adds in this definition to further clarify that there should be nothing in the standard’s definition that would preclude someone building a piece of open source software that conforms to the standard itself. Abiding by this gives those who use the standard confidence that they will have both open source and closed source options to choose from when picking an implementation. 96 | 97 | There are many standards that we rely on every day, including **TCP/IP** (the underlying standard for communications on the Internet), **HTTP** (the protocol behind the World Wide Web), **HTML** (the language used by web page authors to format content), **GSM** (the standard for much of the world’s cellular phone communications), **ODF** (the Open Document Format used to exchange documents between various word processors), and **PDF** (the Portable Document Format used to produce print-ready documents). 98 | 99 | In many of those cases, there are open source implementations of these standards to allow many individuals and organizations to participate in helping build and advance these technologies. 100 | 101 | **Mixing and Matching** 102 | 103 | In today’s technology landscape, there is rarely a case where only one of these three elements (open source, open standards, closed source software) is used in isolation. 104 | 105 | Most often, you’ll experience open source implementations of open standards (like the Apache Web Server’s implementation of HTTP), but you can also find instances of closed source software that implement an open standard, such as cryptography software companies who implement the Key Management Interoperability Protocol (KMIP) standard, allowing interoperability among many vendors, and even other open source software. 106 | 107 | You’ll also see closed source software being used alongside open source software, as in the case of people using the popular open source Firefox browser on closed source operating systems like Windows and Mac OS X. Even open source operating systems like Linux are used to run closed source applications like stock exchange applications and other financial software. 108 | 109 | # Section: A Short History of Open Source Software 110 | 111 | ## Lesson: Introduction 112 | 113 | ### Section Overview 114 | 115 | In this section, we will provide a brief overview of the roots of the free software movement, and the subsequent birth of open source software. We’ll include a discussion of how pragmatism vs. idealism played into open source becoming a critical component of business and technology strategies in organizations. There will also be a short discussion on the evolution of open standards play in this space. 116 | 117 | ### Learning Objectives 118 | 119 | By the end of this section, you should be able to: 120 | 121 | * Explain how the Free Software movement gave birth to open source. 122 | 123 | * Describe how the notions of idealism vs. pragmatism affected the adoption of open source. 124 | 125 | * Articulate the evolution of open standards and the role they play in this ecosystem. 126 | 127 | ## Lesson: Free Software & Open Source 128 | 129 | ### A Long and Storied History 130 | 131 | Sharing of software has gone on since the beginnings of the computer age. In fact, not sharing software was the exception and not the rule. The concept of **Open Source Software (OSS)** long predates the use of the term. For a detailed history of the early days of software, there are many resources you can check, including [Wikipedia](https://en.wikipedia.org/wiki/History_of_free_and_open-source_software), but we’ll give a condensed version here. It’s important also to note that there are many disagreements about certain details of this evolution, but it’s important to understand the basic timeline. 132 | 133 | In the early days of computing (1950s-1960s), software was produced mainly by academics and corporate researchers working for early computer companies. It was difficult and time consuming to write, and generally shared as works of **public-domain**. These works are not owned by an individual author or artist. Anyone can use a **public domain** work without obtaining permission, but no one can ever own it. The software was not seen as a commodity in and of itself, as it required the specialized (and expensive) computer hardware to even run. 134 | 135 | In the late 1960s, things began to change, as computer operating systems and compiler technologies began to make it less cumbersome to build effective software that ran on a variety of computer platforms. This led directly to the rise of software-only companies, and with software gaining the right to be copyrighted in 1974, the die was cast for software to become an important commodity that these companies fought to protect. 136 | 137 | The late 1970s and early 1980s saw the increasing trend of only distributing machine-readable code without the associated human-readable source code. In the early 1980s, MIT researcher Richard Stallman began a project to write what would become the GNU operating system (which would later inspire the popular Linux kernel). During this time, he established the Free Software Foundation and wrote the [Free Software Definition](https://en.wikipedia.org/wiki/The_Free_Software_Definition) in an attempt to wrest control of software created at MIT back from corporate interests who had changed and co-opted it. 138 | 139 | The Free Software Foundation’s other main claim to fame is the creation of the GNU Public License (GPL), which used the notion of ‘Copyleft’ to require any changes made to Free Software to be made available to the user receiving the free software. Linus Torvalds (creator of the Linux operating system) released his first kernel in 1991, licensed with the GPL. As we now know, it has become the basis for a significant portion of the world’s technology. 140 | 141 | In 1997 Eric. S. Raymond published *The Cathedral & The Bazaar,* an analysis of the former academic hacker community and free software principles, which led to a strategy meeting in 1998 of several industry and free software individuals, including Christine Peterson, who coined the term ‘open source software.’ In the next section, we’ll examine the reasons for this change in ‘brand.’ 142 | 143 | ### Pragmatism vs. Idealism 144 | 145 | At the heart of the naming debate between ‘Free Software’ and ‘Open Source Software’ is an oddity in the English language. Specifically, the two different meanings of ‘free’: 146 | 147 | * Free as in free speech, freedom to distribute. 148 | 149 | * Free as in no cost, or as is often said as in "free beer". 150 | 151 | Christine Peterson and the others involved in advocating for ‘open source’ were attempting to clarify the concept of free here - making it clear that the source code would be open for inspection, redistribution and modifications. As more corporations became involved with these software ecosystems, open source gained traction, in large part due to the perception that ‘free’ software didn’t have as much value as ‘professionally’ developed code. In reality, the amount of quality open source software has only continued to increase, and much of it is professionally developed. 152 | 153 | With more corporate involvement though came a bifurcation in the world view of Free Software Foundation advocates and the open source community. Specifically, this centers around idealism vs. pragmatism. 154 | 155 | **Idealism** 156 | 157 | Here "free" means as in freedom, not beer. There is a profound belief that all software should be open for ideological and ethical reasons, not just technological ones. 158 | 159 | **Pragmatism** 160 | 161 | Here the primary considerations are technical ones including faster and better development involving more contributors and reviewers, easier debugging, etc. 162 | 163 | It’s important to note the more ideological perspective has strong technical imperatives as well, and in many cases the objectives of both streams coincide. For example: 164 | 165 | * Should the software powering a life-saving medical device (such as a pacemaker, or an insulin pump), be secret? Do we not have the right to know what is controlling such devices? How do we know they are not vulnerable to external attacks that can kill us? 166 | 167 | * Should the software powering voting machines be closed? How can we be sure we can respect the integrity of tabulated results? This is particularly true when experiment after experiment has shown closed source voting machines to be full of security vulnerabilities. 168 | 169 | Unfortunately, the conflicts between these two attitudes towards open source have often been acrimonious and destructive. It is unlikely to ever end; but it’s important to note the pragmatic approach has most of the economic resources behind it due to corporate buy-in, and the more philosophical camp will always have determined adherents. The vast majority of the work in open source happens somewhere between these two extremes, but it’s important for each to exist to provide valuable boundaries. 170 | 171 | ### The Evolution of Open Standards 172 | 173 | In many ways, the evolution of standards mirrors that of free software to open source. In this case, three kinds of standards began to evolve—closed standards, *de facto* standards, and open standards. 174 | 175 | Closed standards are not publicly available, require implementers to pay royalties to third parties, or both. For example, most common wireless standards the average person recognizes, including 4G, Bluetooth, or WiFi are closed standards. These standards have specifications that are restricted either by access or intellectual property terms. 176 | 177 | As the software market began to grow, and the kinds of problems customers were solving became so large that they required multiple areas of speciality, it became apparent that interoperability was going to be a key requirement for businesses of all kinds. 178 | 179 | Customers began to pressure vendors to allow for heterogeneous systems that brought best-of-breeds solutions to bear on their problems. To make this possible, open standards began to develop, allowing many people to collaborate on ways of effectively moving data between and among applications and systems. Some open standards didn’t start as intentional standards. Some started as open source projects that through widespread adoption became *de facto* standards. The most common example is the Linux kernel which has become a *de facto *standard for classes of devices, such as in high performance computing where Linux powers 100% of the world’s Top 500 Supercomputers. 180 | 181 | There are too many open standards to list here, but you can find a reasonably good list on [Wikipedia](https://en.wikipedia.org/wiki/Open_standard). Perusing that list you’ll find ones that you probably know about (TCP/IP, PDF), as well as others you probably rely on but didn’t know as much about (HTML, USB). 182 | 183 | ### History is Always Happening 184 | 185 | The main reason for providing this historical background is that it both informs what has come before, but also symbolizes that nothing is ever static in the software and technology industry. There will always be questions of balancing the idealist aspects of free software with the more commercial values of pragmatism. 186 | 187 | There is also a growing movement around thinking about the ethical aspects of computing and how that affects everything from licensing, to intellectual property and collaboration models. 188 | 189 | Understanding where we’ve come from in open source and open standards will give us the context to properly evaluate where we need to go in the future. 190 | 191 | # Section: Reasons to Use Open Source 192 | 193 | ## Lesson: Introduction 194 | 195 | ### Section Overview 196 | 197 | In this section, we will give an overview of how the community and collaborative model of open source ensures continued efficient development of enterprise-grade software. We’ll also discuss some potential ways to effectively marry open source with open standards for increased value. 198 | 199 | ### Learning Objectives 200 | 201 | By the end of this section, you should be able to: 202 | 203 | * Describe the community and collaborative model of open source. 204 | 205 | * Articulate solid business reasons why open source provides value for enterprises. 206 | 207 | * Explain how open source and open standards can be combined to increase the overall value of a technology solution. 208 | 209 | ## Lesson: Why Should I Use Open Source & Standards 210 | 211 | ### What Is an Open Source Community? 212 | 213 | There is not some mythical ‘open source community’ that magically makes all open source development happen. There are many different open source communities, with many different types of cultures. However, the community construct harkens back to the earliest days of computers, rooted in the academic/corporate/sharing/hacker mentality. Almost all communities have the following main characteristics: 214 | 215 | * Geographic distribution of development resources. 216 | 217 | * Decentralized decision-making capabilities. 218 | 219 | * Transparency of both development and decision making. 220 | 221 | * Meritocracy - influence is earned through sustained valuable contributions. 222 | 223 | In addition, most communities exhibit a tight vertical hierarchy, with loose horizontal structure, which allows small changes (the lingua franca of open source) to flow upward, passing through many rapid review cycles that provide a significant set of ‘checks and balances’ that help ensure software quality. 224 | 225 | An example community organizational structure: 226 | 227 | ![image alt text](community-org-structure.png) 228 | 229 | ### How Does This Model Differ from Other Development Models? 230 | 231 | While modern software development teams inside of technology corporations can share some of the ‘agile’ principles illustrated above, they generally have some significant differences. These differences are neither good nor bad, and often exist for very good reasons. They do, however, provide a challenge for organizations as they begin the journey toward more open source community participation. 232 | 233 | Here are some of the most significant practices of open source software projects that are different from corporate development teams: 234 | 235 | * Influence and stature are not conveyed by title or position - meritocracy rules the day. 236 | 237 | * Transparency in both source code and decision making is paramount - no side conversations or decisions. 238 | 239 | * Support for geographically-distributed teams is built in - asynchronous modes of communication and culture are the norm. 240 | 241 | Some organizations have applied lessons from the open source community to their own internal efforts (a practice known as ‘Inner Source’) to take advantage of the speed and flexibility they offer. Doing this can also help build the necessary institutional culture that allows for easier engagement with the upstream open source ecosystem. 242 | 243 | ### The Business Perspective 244 | 245 | Now that we’ve covered a bit of what the community development model looks like, let’s look at some reasons that businesses of all sizes have chosen open source as a valuable technology tool to help them solve real-world problems. 246 | 247 | Open source usage within an enterprise provides the following advantages: 248 | 249 | * Speed 250 | 251 | * Lower Cost 252 | 253 | * Customizability 254 | 255 | * Innovation 256 | 257 | * Security 258 | 259 | * Business Advantage 260 | 261 | * Flexibility in licensing 262 | 263 | We’ll cover each of these in the next few sections. 264 | 265 | ### How Does Open Source Speedup Development? 266 | 267 | Open Source Software has proven instrumental in speeding software development cycles. One of the most striking examples is in the mobile device market where we are seeing major new products being released in 6-12 month cycles. Open source is essential to fast evolutionary delivery. 268 | 269 | So exactly how does open source speed up development? 270 | 271 | * Open Source software acquisition is often faster and easier – no purchase orders, contracts, SOW or license negotiations to get started. 272 | 273 | * Open source deployments are usually much quicker. Unlike commercial installation, configuration, and implementation cycles which are often too long and cumbersome, open source comes from a download-and-go culture. 274 | 275 | * The leading open source projects are evolving faster with community driven features, instead of revenue driven management. Fast decision making in open source (often a form of [lazy consensus](http://community.apache.org/committers/lazyConsensus.html)) enables projects to incorporate new features and fixes very rapidly. 276 | 277 | * Because it is subjected to broad community testing, mature open source is often of higher quality. In fact, software quality met or exceeded expectations 92% of the time according to a [Forrester Research study](https://fossbazaar.org/system/files/OpenSourceForTheNextGenerationOfEnterpriseIT.pdf). 278 | 279 | * Open source supports customization with the source code, a collaborative community, interfaces and tools. 280 | 281 | * With an evolutionary delivery approach, open source is usually up and running in hours instead of weeks or months. 282 | 283 | ### Why Is Open Source Lower Cost? 284 | 285 | Using open source software can significantly reduce development costs in a number of proven ways: 286 | 287 | * A recent [Red Hat study](https://www.redhat.com/cms/managed-files/rh-enterprise-open-source-report-detail-f21756-202002-en.pdf) has shown that open source has a 30% lower total cost of ownership compared to commercial/closed source solutions. 288 | 289 | * With open source you can avoid functionality overkill. Many closed source products have an overload of capabilities that clients rarely use, need, or even want. And they are often bundled so that they must be paid for anyway. 290 | 291 | * Open source helps prevent vendor lock in and promotes competition. Even where commercial open source vendors are utilized, you have the freedom to switch vendors or even drop support without changing your application. 292 | 293 | * Open source also helps with consulting, training and support costs because there is no exclusive access to the technology. You can often multi-source support from vendors or even receive support from a vibrant community of developers. Many companies hire developers from the community to support their implementations, and contribute fixes back to the upstream project. 294 | 295 | * Active communities often provide higher quality support than commercial support agreements, and what’s more, it’s free. 296 | 297 | ### Why Is Open Source More Flexible? 298 | 299 | Open source offers the most flexibility of any 3rd party software alternative: 300 | 301 | * With open source you are never locked into a vendor, their costs, their buying structures or their re-distribution terms. Open source enables vendor independence and competitive options. 302 | 303 | * Open source often has very liberal contractual limits on deployment, if any, so you have the greatest possible flexibility on platforms, numbers of users, number of processors. 304 | 305 | * Because you have access to the source code, you may create any customizations you need, and if they are of value to others, the community may support them in a future release. 306 | 307 | * Open source communities encourage and facilitate customization making it easier to extend the solution for particular use cases or to integrate with other products. 308 | 309 | * Healthy open source communities provide ongoing support and encourage input and suggestions for improvements. 310 | 311 | ### How Does Open Source Support Innovation? 312 | 313 | Open source software was originally conceived as a way to facilitate development and innovation through collaboration. 314 | 315 | The open source approach has proven so effective for innovation that many leading edge software technologies are driven by open source communities. For instance: 316 | 317 | * The Internet has been developed primarily as a large collection of open source projects. 318 | 319 | * Software development tool innovation and integration is largely an open source domain. 320 | 321 | * The incredible rate of innovation in the mobile communications space is only possible through open source. Although Android is the primary example, even closed source platforms like Apple’s iOS are largely built using hundreds of open source software libraries and components. 322 | 323 | * Like the rest of the Internet, social media software platforms have emerged from and grown through open source software. 324 | 325 | * The arena of scientific computing and massively parallel computing are almost exclusively open source domains. 326 | 327 | Many open source communities exhibit rapid evolution that can be harnessed through participation to speed your own innovation. The open source ethos of bottom-up meritocracy directs ownership and accountability back to development teams 328 | 329 | One of the best ways to introduce a new software idea, test new capabilities and grow an active user base is through an open source community 330 | 331 | And finally, the innovation that open source enables is not just technical innovation. The lack of contractual constraints in open source licensing allows for creative new uses, new distribution schemes, flexible and creative packaging and pricing approaches and other forms of business and market innovation. 332 | 333 | ### What are the Security Advantages of Open Source Software? 334 | 335 | Unfortunately attackers are targeting and attacking software systems around the world. Neither open source software nor closed source software is always more secure. Security depends on many factors, such as how the software was designed, implemented, verified (including testing), and deployed. 336 | 337 | However, open source software does come with a *potential* fundamental security advantage over closed source software. One of the key principles of secure software design is "open design", that is, secure software design should presume that everyone knows how its protection mechanism works. Doing this enables mass worldwide peer review to find security vulnerabilities and fix them before the software is deployed. 338 | 339 | Of course, potential is not always realized. To be secure, open source software projects must be developed with security in mind, actually be reviewed, and have those problems fixed before the software is deployed. Many open source software projects already take steps to employ this potential advantage, and the Linux Foundation is working with various open source software projects to help them take advantage of it as well. 340 | 341 | ### How Does Open Source Provide a Business Advantage? 342 | 343 | All of the factors above add up to a software competitive advantage for your organization. 344 | 345 | * In today’s rapidly evolving markets, the company that consistently produces software solutions the most quickly at lowest cost will win. 346 | 347 | * At this point, open source software has become such a mainstream phenomenon that **not using** open source effectively will almost certainly place your organization in a disadvantaged position. 348 | 349 | Research firm Gartner had this to say about open source: 350 | 351 | "**Open source is ubiquitous**, it’s unavoidable… having a policy against open source is impractical and places you at a **competitive disadvantage"** 352 | 353 | As a recent [McKinsey & Co. report ](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/developer-velocity-how-software-excellence-fuels-business-performance)described, the "biggest differentiator" for top-quartile companies in an industry vertical was “open source adoption,” where they shifted from users to contributors. The report’s data shows that top-quartile company adoption of open source has three times the impact on innovation than companies in other quartiles. 354 | 355 | ### Bridging Open Source and Open Standards 356 | 357 | There has been a growing trend in the last several years of both the standards world and the open source ecosystem attempting to find better ways of working together. While there are sometimes challenges (primarily around the execution speed mismatch of the two groups), there are many good reasons to continue to advocate for a closer relationship between the two. 358 | 359 | There are some good examples of projects where this is or already has worked: 360 | 361 | * The Linux Foundation's JDF ([Joint Development Foundation](https://www.jointdevelopment.org/)) efforts - GraphQL among others. 362 | 363 | * OASIS Open’s [Open Cybersecurity Alliance](https://opencybersecurityalliance.org/), which is providing open source reference implementations of existing open standards for sharing cyber threat data. 364 | 365 | * [IETF](https://www.ietf.org/)’s mantra of "rough consensus and running code" has led to many open standards collaborating with open source projects such as OpenDaylight, OPNFV, OpenStack, and others. 366 | 367 | Standards and open source move at different paces, and work on interoperability in different ways, but being able to build open source implementations of open standards helps drive more open source usage in customer supply chains that have traditionally relied primarily on standards - areas like government, finance and NGOs, for example. 368 | 369 | Additionally, by supporting standards, the open source ecosystem gets the ability to interoperate even with closed source software, which provides businesses with more choices and more flexibility. 370 | 371 | -------------------------------------------------------------------------------- /OSPO-101/module7/README.md: -------------------------------------------------------------------------------- 1 | # Open Source Project Creation Overview 2 | 3 | ## Lesson: Introduction 4 | 5 | ### Section Overview 6 | 7 | In this section, we’ll look at the rationale and value proposition for creating new open source projects. We’ll spend time discussing good and bad reasons to create new open source projects, as well as how to evaluate the business potential of a new project. 8 | 9 | ### Learning Objectives 10 | 11 | By the end of this section, you should be able to: 12 | 13 | * Describe the value proposition for open sourcing internal code or creating new open source projects from scratch 14 | * Give some good and bad examples of reasons to open source code 15 | * Explain how to evaluate the business potential of a new open source project 16 | 17 | ## Lesson: Where To Begin? 18 | 19 | ### Ask The Right Questions 20 | 21 | It’s important to ask the right questions before you begin the journey of creating a new open source project. While there may be some additional specific questions you should consider depending on your company’s unique situation, the following picture will give you a great start to help you figure out what to ask. 22 | 23 | ![Questions to Ask Before Open Sourcing Project](questions-to-ask.png) 24 | 25 | The top line of this graphic really deals with the question of understanding what the value proposition is for you to create an open source project. The first question is one that, unfortunately, doesn’t get asked often enough - you should seriously evaluate whether or not you need to create another open source project. There are many thousands of projects in existence - will your code provide differentiated value on its own, or would you be better off making an established and successful open source project even better? 26 | 27 | If your organization understands the open source development model (covered in previous sections of this course series) and is committed to building a project with that structure, you’ll still need to evaluate **before** deciding to launch the project what constitutes success and what metrics you’ll use. Just creating a project for the purposes of public relations or to improve internal metrics for the number of open source projects started will usually result in an unsuccessful project. 28 | 29 | The second row of questions focuses more on the ability of your organization and the community to build value in the new open source project. Too many companies have tried (and failed) with the strategy of simply throwing code over their firewall, without internal financial and engineering investment, and hoping that their corporate reputation will attract outside enterprise participation. 30 | 31 | Take the time to consider how to make your potential new open source project successful. It’s ok if you come to the conclusion that creating an open source project isn’t right for a particular piece of code - there are many opportunities to participate in the open source ecosystem or contribute your technology to other open source projects. 32 | 33 | ### What Should You Open Source? 34 | 35 | Just as in the decision you must make on what to contribute back to an upstream open source community (from previous coursework in this series), the decision on what code or technology you’ll build initially in the open, or what proprietary code you’ll release is an important one. Here are some criteria that can help you consider this choice. 36 | 37 | * Determine what parts of your product are sources of strategic advantage, and what simply supports those parts 38 | * Non-strategic parts are often great candidates for creating open source projects 39 | * Chances are good that other companies feel the same way, and might help you maintain and advance your new project. 40 | 41 | Examples: 42 | 43 | * A filesystem or file format widely used in the industry 44 | * The network stack for connected IoT devices 45 | 46 | Another place to start includes secondary coding projects where an enterprise does not need to be an authority, and where there may be a larger group of technologists around the world who can help you solve a problem. If it is not mission-critical code, then it is likely a good candidate to be open sourced. However, it should also be code that your company is still actively using and maintaining. Commercial dependencies on code enable a continuous feedback loop of bug fixes, patches and new features. 47 | 48 | 49 | ### When To Create an Open Source Project 50 | 51 | The decision to release or create a new open source project depends on your circumstances. Your company should first achieve a certain level of open source mastery by using open source software and contributing to existing projects (as we covered in previous coursework in this series). 52 | 53 | Understanding how to consume open source can teach you how to leverage external projects and developers to build your products. Participation can bring more fluency in the conventions and culture of open source communities. But once you have achieved open source fluency, the best time to start launching your own open source projects is simply “early” and “often.” 54 | 55 | ![Release Early Release Often](release-early.png) 56 | 57 | This graphic is a bit of a reminder about what we covered in the _Open Source Development Practices_ portion of this coursework series. It’s not only important when you’re contributing back to open source, it’s important as you consider your first new open source projects. 58 | 59 | Not everything has to be absolutely perfect before you create your first open source project. There are some minimums in terms of process, legal review, etc. (which we’ll cover shortly), but building out the minimum necessary in both code and governance to get started allows you to get earlier participation and earlier feedback to help you evolve your new project. 60 | 61 | Before you create that first project though, we should discuss some good (and bad) reasons for creating an open source project... 62 | 63 | ### Good Reasons to Create an Open Source Project 64 | 65 | ![Good Reasons to Create an Open Source Projects](good-reasons-to-opensource.png) 66 | 67 | This graphic shows five good reasons why you should start an open source project. While they all come back to business goals, the first two deal with getting a unique business advantage in the market. It’s important to note, however, that this ‘first-mover’ business advantage can be fleeting (6-10 months) until the rest of the community becomes proficient with the technology you’ve open sourced. 68 | 69 | The third and fourth items focus on engaging customers and helping build value for your non open-source products. Remember that in open sourcing code you provide value on top of, you’re making your products better as a result. 70 | 71 | Finally, if you are in an industry with technical customers (or developers) who have the ability to self-support themselves with your technology, you can realize value in not having to provide extra technical or support resources for the code you choose to open source. 72 | 73 | ### Bad Reasons to Create an Open Source Project 74 | 75 | Just as important as open sourcing for the right reasons is making sure you don’t try to create an open source project for the **wrong** reasons. The open source ecosystem is littered with failed projects from organizations that meant well, but simply didn’t consider fully why they should be open sourcing code or creating a new project. 76 | 77 | ![Bad Reasons to Create Open Source Projects](bad-reasons-to-create-opensource.png) 78 | 79 | Here’s some examples of bad reasons to create a new open source project: 80 | 81 | * Getting rid of obsolete software 82 | * Expecting free engineering from the open source community when you aren’t willing to invest 83 | * As a positive marketing spin on an end-of-life announcement 84 | * To gain publicity or marketing outreach without the intention to support the project long term 85 | * As a means of fulfilling internal success metrics 86 | 87 | Hopefully it’s obvious why all of these are bad reasons to create an open source project, but let’s look at what they all have in common - an inward focus and/or expectation of support from the larger open source community. 88 | 89 | Working in open source has often been described (from the corporate point of view) as ‘enlightened self-interest.’ It’s apropos in this case because everyone understands that corporations don’t work with open source necessarily for altruistic reasons - there has to be business value aligned with what goes on in open source. However, the reasons shown above sow a seed of mistrust with the rest of the open source community, which is, after all, composed of both partners and competitors. 90 | 91 | ### Evaluating the Business Potential of an Open Source Project 92 | 93 | Just like any business decision, determining what, if, and when you should create an open source project comes back to what value is ultimately delivered to the business. As you consider these questions, it’s best to think in terms of building a business case. 94 | 95 | First, you must decide if your company wants to create or release the code while maintaining ownership of it and the project, or if you want to donate the code to others to maintain and administer the project. If the code already exists, then there is the related issue of whether you will release all the code in a project or just some of it as an open source project. 96 | 97 | To make these decisions, consider stepping back to determine the objectives you have in mind for the code. Is this code something that will be useful outside of your organization and also transformative to the industry? Is your company likely to attract partners (and/or competitors) to work on this technology in support of your organization’s product portfolio? 98 | 99 | For example, you might want to attract fresh insights from other developers on a part of an application that isn’t core to your work. Or you might seek additional real-life algorithms to detect logs in a system monitoring application. Rather than releasing the whole product as open source, you could release only the code related to the algorithms. This allows you to gain the contributions of others and help others who are needing similar help, without compromising your core business. 100 | 101 | Starting a project and maintaining overall control lets you have oversight and gives you the ability to help shape it into what you need, while still giving freedom and control to the contributing developers to do their work. 102 | 103 | # Section: New Project Preparations 104 | 105 | ## Lesson: Introduction 106 | 107 | ### Section Overview 108 | 109 | In this section, we will explore how to prepare for creating a new open source project, including discussion of legal, business and community considerations. We’ll also discuss required processes, tools and staffing requirements necessary for success. 110 | 111 | ### Learning Objectives 112 | 113 | By the end of this section, you should be able to: 114 | * Explain the overall steps for preparing to create a new open source project 115 | * Understand what processes, considerations, tools and requirements are needed for success in project creation 116 | 117 | ### Lesson: Internal Preparations 118 | 119 | ### Identify an Executive Sponsor 120 | 121 | Since there will be a lot of required investment to create a successful open source project, it’s **critical** to get the buy in of an executive sponsor in your organization. It can help if you have more than one sponsor, but at a minimum, you should aim for someone who can provide and commit to the following things: 122 | 123 | #### Technical and Community 124 | 125 | * Continually reaffirm commitment to the project in public 126 | * Foster a culture of merit-based recognition 127 | * Ensure neutrality 128 | * Commit to following open source methods and processes 129 | 130 | #### Financial 131 | 132 | * Internally: Fund enough development to get project going 133 | * Externally: Commit to funding IT resources and sysadmins 134 | 135 | ### Allocate Resources 136 | 137 | You’ll need to get your executive sponsor to appropriately allocate funds, as noted in the previous page, but also be able to direct appropriate staff time to make the project successful. Developer time will likely be similar initially to the amount of time they spend on internal code efforts. However, you’ll also need to consider what time, materials or help your developers will need to provide to help others in the new community get up to speed on the codebase. 138 | 139 | There will also be resources needed for the legal team that will be involved in creating an open source project that could involve competitors, as well as marketing investments to ensure that the project gains support and contributors after launch. 140 | 141 | You’ll also have to set budgets for the infrastructure used to begin and maintain the project. This includes a project hosting and source control website like GitHub, where the code will reside and be maintained, as well as bug resolution, and other needed tools. 142 | 143 | We’ll cover tools and infrastructure in more detail shortly. 144 | 145 | ### Educate Your Workforce 146 | 147 | Even if your organization has taken training on open source topics (such as this course series), it’s important to remind engineering teams and managers of particular items that may differ from how they normally approach building products or evaluating work. 148 | 149 | #### For Engineers 150 | 151 | * Review open source development methods and processes 152 | * Review your company's open source policies and compliance rules 153 | * Integrate open source software within your software development model 154 | * Follow open source best practices internally if possible 155 | * Practice and encourage community thinking to help craft more general solutions 156 | 157 | #### For Managers 158 | 159 | * Traditional performance metrics may no longer apply 160 | * Only results count, not whose code is used 161 | * Influencing an outcome is just as valid a solution as writing code 162 | * Manage your developers, not their maintainers 163 | * You can’t control the open source process 164 | * There is a learning curve for your employees and the community 165 | * Building influence and respect takes time (even if it’s your company’s project) 166 | 167 | 168 | ### Lesson: Reviews 169 | 170 | ### Overview 171 | 172 | While some audiences don’t necessarily appreciate lengthy reviews before launching efforts such as a new open source project, it’s important to take some time to properly plan for reviews from the legal team, the engineering team and also the marketing team. 173 | 174 | These don’t necessarily have to be painful, as a simple set of checklists to verify that the most often missed elements don’t slip through the cracks can be helpful. Taking this time at the start of the process of creating a new open source project can save a lot of headaches once a project is out and gaining visibility. 175 | 176 | We’ll cover some best practices in the following sections for how to streamline these review processes. 177 | 178 | ### Legal Review 179 | 180 | One of the worst things that can happen to a new project is for the community to have distrust in the legal cleanliness of a codebase. It’s important to ensure the code you release has clear licensing and provenance. A full legal review is often helpful in making sure what gets contributed will be acceptable by others in the community. 181 | 182 | Your legal review should also include trademark due diligence and registration. Note that if you are contributing the project into a foundation (more on this later in the governance section), make sure you’re aligned on the trademark strategy before open sourcing your codebase. 183 | 184 | You’ll also need to choose a license for your project. It’s important to document any licensing or intellectual property requirements. Projects will typically need to consider both the outbound license (e.g., the license under which downstream users receive the code) and the inbound contribution mechanism (e.g., the process under which contributions are made into the project). Many projects will use the [Developer’s Certificate of Origin](https://developercertificate.org/) (DCO) sign-off process for their inbound contribution mechanism. If you anticipate needing explicit corporate commitments for patent grants, or the ability to relicense the project later, you may want to look at some of the more common Contributor License Agreements (commonly referred to as CLAs). Not all CLAs are alike, so consider this option carefully. Also be aware that CLAs can be an impediment to participation as developers often have to go through arduous approval processes to get them signed. Refer to the _Open Source Compliance Program_ module of this training series for more detailed information on licensing options. 185 | 186 | Your project may also produce deliverables that are not software. If your project is producing documentation, discuss whether you should use a specific license for the documentation. For example, many open source projects will use an open source license for the software and a Creative Commons license for the documentation. Additionally, some projects seek to create specifications that may be implemented in various ways by others. Those projects should consider the option to use a specification license. 187 | 188 | Each licensing approach has its advantages and disadvantages, but be aware of the potential for fragmenting your project, which is a particular problem for software that needs to be interoperable or provide portability across various vendor solutions. Often this issue is addressed by creating conformance programs that permit usage of the project trademark if the commercial solutions pass a community created test or set of requirements. Thinking about this up front will help inform your legal review and plans for the project. 189 | 190 | In summary, the steps in the legal review process include: 191 | 192 | * Consider the impact of open sourcing on your company’s intellectual property 193 | * Ensure full compliance with open source licenses 194 | * Select an open source license for the source code to be released, document all licensing requirements very clearly in your project 195 | * Decide if you need a contributor agreement 196 | * Consider the possible non-software outputs from the community and the appropriate licenses, such as documentation and specifications 197 | * Decide on any trademark related considerations 198 | * Decide whether there are additional factors to build into your plans for an ecosystem, such as conformance testing 199 | 200 | ### Technical Review 201 | 202 | The technical review verifies that the source code can function without dependencies on other internal code or development practices (including any custom internal build systems), and that it does not include third-party code the company cannot include in the open source release. 203 | 204 | The technical review should include verification of all license and copyright notices, and any private or internal code comments should be scrubbed. Steps include: 205 | 206 | * Remove critical dependencies on non-public components 207 | * Provide documentation and use case examples 208 | * Remove internal comments, references to other internal code, etc. 209 | * Ensure coding style is consistent 210 | * Update copyright notices in source code files 211 | * Add license notice in source code files 212 | * Ensure the code compiles and builds on any external target platforms 213 | * Add license text as a file in the root directory 214 | 215 | ### Marketing Review 216 | 217 | Successful open source projects can’t live strictly on the merits of the code and technology alone - to keep the project moving along, there are a series of additional business and marketing steps that need attention as well. They include promoting the project, laying out a successful operational strategy, providing a realistic budget and project branding, as well as establishing lively social media accounts and useful domain names to bolster long-term success. 218 | 219 | A marketing review establishes guidelines for branding. This is particularly important, as it helps to ensure a consistent message in the market. Steps in the marketing review include: 220 | 221 | * Design a project logo, color scheme, website, collateral, etc. 222 | * Formalize branding guidelines 223 | * Register social media accounts for the project (Twitter, Facebook, LinkedIn, etc.) 224 | * Register domain names for the project 225 | 226 | By performing this marketing review ahead of the project launch, you can deal with any potential branding issues (like domain names not being available for your preferred name) before they threaten to derail the success of your project. Make sure that you engage your marketing team early on so that they can help you navigate these (and other) issues. 227 | 228 | You’ll probably find that your marketing team will be excited, because it’s a fun challenge to see how many people you can drive to the project to contribute code, participate in forums, offer bug fixes and report issues. 229 | 230 | ### Lesson: Governance and Processes 231 | 232 | ### Governance Models 233 | 234 | It’s important to consider what the governance model will be for your new open source project. But what do we mean by governance? Quite simply, governance is the structure around a project that enables decisions on: 235 | 236 | * Participation guidelines and requirements 237 | * Architectural changes 238 | * Nominating maintainers 239 | * Final arbiter on disputes 240 | * Suspension of participants 241 | 242 | There are several ways that projects can be governed, with varying degrees of business and/or technical leadership. We’ll cover leadership in a moment, but if you want more details on the different types of governance models, please refer to the "Collaborating Effectively with Open Source Projects" course in this training series. 243 | 244 | ### Leadership 245 | 246 | Setting leadership roles is also important before getting underway. That can mean different things for different projects. If you are starting a multi-company project with several enterprise participants, the project may need more formal governance, such as a governing board or other management group. 247 | 248 | Other arrangements could simply require a technical committee that oversees all facets of the open source project from a technical perspective. The composition of the committee would include mostly technical leadership, as well as a liaison back to the executive team to provide updates about progress and project needs. The legal team can then be brought in as the technical members and executives see fit. 249 | 250 | Your top architectural minds will also certainly be there, as well as others who know how the code base will work. Altogether, the members of the committee will have a vision for where the project is going as well as support from within the developer community. Those are the people you want there at the table to plan the process. 251 | 252 | ### Foundation or Independent 253 | 254 | Another question that often comes up as new open source projects are created is whether to donate your code to a vendor-neutral, non-profit organization or retain some control by owning and running your own project. The answer depends on what you are trying to achieve - if you are working with a small number of partners on building a nascent technology for the industry, you probably don’t need to consider a non-profit foundation at the beginning. 255 | 256 | However, if what you are planning has wide applicability across your industry, is cross-industry, or has grown from a small effort into something large and complex, it’s often good to consider a non-profit open source/open standards consortium to host your project. Besides the value of having a truly vendor-neutral place to host your project, these foundations have legal, governance, marketing and project infrastructure services that can dramatically streamline the process of getting your project on the path to success. 257 | 258 | There are many foundations (and sub-foundations) you can choose from, and each offers unique value propositions, pricing and service levels. Some examples of these foundations are: 259 | 260 | * [Apache Foundation](https://www.apache.org/foundation/) 261 | * [Eclipse Foundation](https://www.eclipse.org/org/foundation/) 262 | * [Linux Foundation](https://www.linuxfoundation.org/) 263 | * [OASIS Open](https://www.oasis-open.org/) 264 | 265 | Which foundation you choose depends on what area of speciality your project resides in, as well as considerations like cost, governance models, etc. 266 | 267 | ### Technical Processes 268 | 269 | Prior to launch it is often helpful to create a standard release process to schedule regular releases of the code as changes and improvements are made by the project maintainers. A schedule should be set up with well-defined and visible details for the development community and the business side of the project. 270 | 271 | How often those releases should be made depends on your community’s expectations. If the project is enterprise-focused and you’re trying to build something that is very hardened, your release schedule might be twice a year. If the project is smaller in scope and more agile and you are trying to get pieces of it out there, perhaps you might be releasing the code monthly or weekly. The key to the schedule is that the community must dictate the timeline and understand its ability to support the project from a velocity standpoint, while giving users what they need and expect. If the community provides feedback that the releases are coming too soon or too slowly, then you need to look at the process and make some adjustments. The big thing here is consistency, predictability, and visibility. 272 | 273 | You should also have well defined processes for submitting code, patches, feature ideas, documentation, or other project artifacts. Some of this can be dealt with in the project infrastructure/tooling (a topic we’ll cover shortly), but part of the technical process is not just the tools, but the expectations of workflow - e.g. - how will code be submitted, what kinds of coding standards will be followed, when will new code be accepted in the release cycle, etc. 274 | 275 | ### Lesson: Project Infrastructure 276 | 277 | ### Development Tools 278 | 279 | Before the launch of your project can ever happen, you need to prepare a repository for the project. This is essentially the infrastructure for a code repository where the project will be available to contributors all the time. Many projects use the well-known [GitHub](https://github.com/) or [GitLab](https://about.gitlab.com/) repositories, or host their own repositories with tools such as [Gerrit](https://www.gerritcodereview.com/). 280 | 281 | There are many other options available as well, but remember it’s often useful to consider making it simple for developers to participate and engage in your project. Choosing a tooling platform that is familiar to the greatest number of developers will help accelerate contributions and growth in your project. 282 | 283 | Bug, issue, and feature tracking also should be included as part of a project’s infrastructure plans. You want to provide an easy place for contributors to make reports of problems that need to be fixed as well as requests for new features that might be useful added. Then there are automated build and test system processes which may need to be included as part of your project’s GitHub repository to keep your systems and project flowing smoothly, while scanning and checking the code to ensure its quality. 284 | 285 | You can get more detailed information on things like automated testing and continuous integration by reviewing the _Open Source Development Practices_ module in this course series. 286 | 287 | ### Website 288 | 289 | A critical step is creating a company-neutral web presence for the project. Don’t try to place the open source project website as a subdomain of a company web page - even if you have the best intentions, the visual distinction of a neutral home of the project is important. The webpage provides a place for the community to find information about the project including documentation, links to download the code, and more. The webpage can also provide details about the project’s leadership, scope, users and contributors, budget, governance, and other details. As a central information repository, your website should also have very clear calls to action/places for new developers to join the community. 290 | 291 | ### Communication Tooling 292 | 293 | Offering communication channels for your community to ask questions for help is critical. You’ll want to find tools that can be integrated into the entire development workflow (for example, receiving notifications for support requests, code check-ins, error logs, and other tasks). You’ll also want to provide critical discussion forums and a mechanism for community members to get quick answers from others who are also working on a project. All are important means of communication that help move projects forward in real-time. 294 | 295 | One project tool to consider is [Slack](https://slack.com/) , an online team project management and communications platform where users can access and share messages and files, organize workflows, perform searches for information, and more. However, Slack is a proprietary tool and can cost money to maintain beyond a certain usage threshold. There are open source options out there such as IRC, [Gitter.im](https://gitter.im/), [Mattermost](https://mattermost.com/), [Rocketchat](https://rocket.chat/) and others. 296 | 297 | Depending on your developer and user community, you may also need modern forum tooling. [Discourse](https://www.discourse.org/) is a great option that is fully open source and also provides optional hosting. When choosing a communication system, be mindful about any form of lock-in, financial costs, and how easy it is to migrate to a new system in the future. 298 | 299 | As your community grows, you need to be able to adapt to any new communication channels out there. Make sure you involve your community in tooling decisions as your project evolves - you may find that users and developers naturally gravitate to other tools over time if they find them useful. 300 | 301 | ### Documentation Tooling 302 | 303 | Some form of document management is often useful for open source projects, especially if it makes the process of creating documentation, how-tos and other text-based projects easier. While many projects feel comfortable using the built-in markdown text tool features of GitHub or GitLab, other projects prefer using wikis or other shared-editing software. 304 | 305 | For a list of potential Wiki tooling options, you can check (not surprisingly), [Wikipedia](https://en.wikipedia.org/wiki/List_of_wiki_software). The same caveats that apply to communications tools also apply here - consider how you can avoid any kind of data or tool lock-in so that when (not if) you users and developers decide to migrate to a different platform, you can migrate your hard-won documentation, Frequently Asked Questions lists and how-to content. 306 | 307 | # Section: Successful Project Launch And Sustainment 308 | 309 | ## Lesson: Introduction 310 | 311 | ### Section Overview 312 | 313 | In this section, we’ll discuss the final steps required for successful open source project launches, as well as present some additional information on how to sustain and encourage adoption and contribution to the project. 314 | 315 | ### Learning Objectives 316 | 317 | By the end of this section, you should be able to: 318 | 319 | * Describe the last steps required to successfully launch an open source project. 320 | * Explain how to build strong community processes that allow for increased project adoption and a strong contribution pipeline. 321 | 322 | 323 | ## Lesson: Project Launch 324 | 325 | ### Final Code Review 326 | 327 | At this point in the process, it’s always a good idea to take one final pass through the source code in preparation for launching. If you’ve been following the process outlined earlier, this shouldn’t be a big burden, but it can be very helpful to make sure that no easy-to-fix items haven’t been forgotten. 328 | 329 | Specifically, the goal of this final review should be to ensure that all requirements identified by the legal, technical, and marketing reviews are completely met. Some examples of what to look for are: 330 | 331 | * License, attribution, and copyright texts are all complete and in place 332 | * Source code scanner reports clean bill of materials 333 | * Every line of code is licensed appropriately for release 334 | * Comments are sanitized of casual or unrelated language 335 | * Source code does not inadvertently reveal internal projects 336 | * Source code is sufficiently complete that it will build 337 | * Source code builds using publicly available tools 338 | * File and function names reflect the project’s name, if it has changed 339 | * MAINTAINERS file is up to date, if used 340 | 341 | ### Pre-Launch 342 | 343 | Before you go live officially with your new project, there are some things you can do to ensure the best launch experience for your organization and for the community at large. One of the biggest things you can do to ensure success is making sure that you have critical mass before launching. 344 | 345 | You should have identified which partners and customers are going to be there with you when you announce the new project. They should have had preview access to the repositories so that they can be familiar with the code and ready to contribute (or have already been contributing). 346 | 347 | If this is one of your early open source projects, it also doesn’t hurt to have a quick refresher with your own developers to make sure they are following open source development methods and processes in anticipation of interacting with others in the open source community that will be contributing to your project. 348 | 349 | After you have verified that all of your project infrastructure is up and running, make sure that your internal developers have joined the project’s communication tools and are beginning to monitor for questions or new contributions. 350 | 351 | Now it’s time for the big moment! You can upload any final remaining code and flip the switch to make the project live to the world. 352 | 353 | ### Good Open Source Citizenship 354 | 355 | Now that your project has launched, it’s just the beginning of the work ahead. You’ll need to make sure that your organization continues to be a good open source citizen and operates in a way that encourages others to come alongside you and work together on your project. Here are some ways you can do that: 356 | 357 | * Have conversations and make decisions in the open 358 | * This builds goodwill, and reduces overhead in documenting decisions 359 | * This streamlines onboarding process for new participants 360 | * Having open archives ensure continuity when participants change 361 | * Listen to the community 362 | * Their experience is invaluable, especially in integration and testing 363 | * Encourage generalized implementations that extend what you need 364 | * Allocate resources as though you will be the only company doing the work 365 | * Set goals, and make sure they have resources to get accomplished 366 | * This builds momentum until the leveraged development model takes effect 367 | 368 | Being a good open source citizen takes work, and it’s not altruistic - it’s good business practice for your organization to get the best return on the investment you’ve put into launching your open source project. 369 | 370 | ## Lesson: Project Maintenance 371 | 372 | ### Build the Community 373 | 374 | After the project has launched, it is essential to monitor the vitality of the external developer and user community. Community building does not happen automatically. In the early stages of the project, it may be necessary to host developer events or sponsor meetups at major conferences to build momentum. It’s also extremely important to manage expectations and fulfill obligations for project governance and transparency. 375 | 376 | Ongoing activities include: 377 | 378 | * Ensure any changes to direction or governance are clearly communicated 379 | * Follow best practices of other similar communities 380 | * Encourage and provide opportunities for face-to-face community building 381 | * Identify appropriate events and have the community submit talks 382 | * Consider doing local meetups 383 | 384 | By building up a diverse group of contributors, you can later decide to move your project to the next level by having discussions with other enterprises and organizations that see the work as valuable to determine if they are interested in investing their time, money and other resources to expand your initial efforts. By gaining input and resources from others, the project can be expanded and grown to do more for additional contributors. 385 | 386 | Such growth means that additional businesses may want to contribute more money to bring their own developers in to join the efforts and help move the work forward by putting their weight behind the efforts you’ve begun. That may involve $10,000 or $250,0000 or more, depending on the importance of the project and what it means to other companies. Once your project begins, other companies can come in to contribute funding toward the work if it will aid their missions. 387 | 388 | This happens regularly today, as enterprises and organizations realize that the technology problems they are trying to solve are larger than any of them individually. That’s when they can begin to see strategic value in joining together with other companies in vendor-neutral joint projects that are working for the greater good in solving technical problems faced by businesses. 389 | 390 | ### Designate a Community Advocate 391 | 392 | One of the most important roles you can hire for to help a new open source project succeed is a community advocate (also sometimes called a community manager). This person’s role is to do whatever is needed to make the community successful. 393 | 394 | It’s a challenging role to execute, and can be a challenging role to hire for, because the person needs a wide variety of skills, including marketing, developer advocacy, business development, crisis management, peacemaker, etc. A good place to start looking for someone for this role is to consider internal development or marketing resources in your organization. Also, don’t ignore people like technical writers, program managers, or even non-traditional fields of study like sociology, psychology, etc. 395 | 396 | A good community advocate can be the difference between a technically successful project that no one uses, and a reasonably good technical project that grows by leaps and bounds because of the community building and bridging skills deployed. The Linux Foundation [TODO Group](https://todogroup.org/) is a good place to find help in identifying community management resources. 397 | 398 | ### Evaluate and Adapt 399 | 400 | As with any new project effort, you’ll need to evaluate frequently and be ready to adapt your approach if you aren’t seeing the kind of adoption and contribution you were expecting. It’s important to remember that your organization’s reputation is only part of the equation in the success or failure of a new open source project. 401 | 402 | Remaining flexible and agile when the community provides feedback gives you the opportunity to increase the project’s reputation as a good place to collaborate and be listened to. You should be looking at a few key metrics as your project gets off the ground: 403 | 404 | * Number of code commits/pull requests from outside your initial developer base 405 | * Amount of discussion/topics on whatever communications channels you’ve deployed 406 | * Number of bug reports or feature requests submitted 407 | 408 | It’s also important to remember that even negative feedback means that your community is engaging with your project. By practicing transparency and accountability and trying to fairly address concerns, your project will gain a positive reputation. 409 | 410 | Remember the adage that has been repeated throughout this training course series - ‘Release Early, Release Often.’ Your new project doesn’t have to be perfect on day one, but by keeping this adage in mind, you’ll be well on your way to building a successful and robust open source effort. 411 | -------------------------------------------------------------------------------- /OSPO-101/module6/README.md: -------------------------------------------------------------------------------- 1 | # Understanding Upstream Open Source Projects 2 | 3 | ## Lesson: Introduction 4 | 5 | ### Section Overview 6 | 7 | In this section, we'll explain what upstream means in the context of open source projects and discuss governance models, and their effect on your contribution strategies. 8 | 9 | ### Learning Objectives 10 | 11 | By the end of this section, you should be able to: 12 | 13 | - Describe what an upstream open source project is and why it's important 14 | - Explain some typical governance models and strategies for successful contributions 15 | 16 | ## Lesson: Introduction to Upstream Open Source 17 | 18 | ### What Do We Mean by Upstream? 19 | 20 | We've used the term _upstream_ already in this module, but what do we mean by that? 21 | 22 | Here's a quick definition: 23 | 24 | **Upstream (noun)** 25 | 26 | The originating open source software project upon which a derivative is built 27 | 28 | This term comes from the idea that water and the goods it carries float downstream and benefit those who are there to receive it. 29 | 30 | **To upstream (verb)** 31 | 32 | A short-hand way of saying "push changes to the upstream project", i.e. contribute the changes you made to the source code program back to the original project dedicated for that program. 33 | 34 | If you think about upstream in the context of a supply chain, it would like like this: 35 | 36 | ![Open Source Supply Chain Funnel](supply-chain-funnel.png) 37 | 38 | ### Why Should You Contribute Upstream? 39 | 40 | The biggest question often asked by organizations is why even contribute upstream to begin with. While it may seem easier to just consume and never contribute back, there are many reasons why you should consider making the effort to contribute, including: 41 | 42 | - Private code is never considered in public development 43 | - Integrating your changes upstream means others are aware of them, and can plan for and around them 44 | - Reduces the risk of accidental breakage in your own code - if you make local changes which are incompatible with the upstream project, it takes time and resources to fix those issues 45 | - Integrating changes into an upstream project reduces the amount of effort to build a finished product 46 | - Contributed code is reviewed and may attract external resources to changes you'll need in the upstream project 47 | - Contributions strengthen the project and give you an opportunity to influence future project directions 48 | 49 | ### When Should You Contribute Upstream? 50 | 51 | Organizations new to open source often struggle with when the right time is to start contributing upstream. The following guidelines give a good overview of reasons/timing for upstream contributions: 52 | 53 | - When the costs (time or $) of keeping your code in sync with the upstream project exceed the convenience of working alone 54 | - When you want your code to be used by others (including customers) 55 | - When you want your code to become a defacto standard, or drive adoption of the mainline project 56 | - If you anticipate relying on a certain codebase repeatedly in upcoming products that complements the upstream project 57 | 58 | ### Example: Development Without Upstreaming 59 | 60 | To give you a better perspective on what can happen if you don't effectively participate in an upstream project, here's a graphical example: 61 | 62 | ![Development Without Upstreaming](dev-without-upstreaming.png) 63 | 64 | As you can see, it can become quite burdensome when you need to bring in the "mainline" of an upstream open source project, for example when a security bug or feature that you need is released. Keeping up with major releases of an upstream project on a regular basis means that you are paying that cost incrementally, instead of all at once. 65 | 66 | ### Example: Development With Upstreaming 67 | 68 | As a counter-example, here's what development looks like with an effective upstream contribution strategy: 69 | 70 | ![Development With Upstreaming](dev-with-upstreaming.png) 71 | 72 | The important thing to note here is the application of fewer custom patches because problems and integration issues can be found more quickly when making frequent upstream contributions and keeping better in sync with the upstream project. 73 | 74 | ### Upstream Governance Models 75 | 76 | There is no shortage of governance models used by upstream open source projects. They differ according to the degrees of centralization, strong influence by one or a few organizational entities, and existence of democratically-inspired decision mechanisms and leadership selection. 77 | 78 | The choice of model and how well it is executed have profound influences on the quality of a project, as well as how quickly it is adopted and evolves, improves and succeeds. There is no one-size-fits-all model and each has its advocates and detractors. Furthermore, different projects have different inherent needs, which may be better satisfied by one particular model. 79 | 80 | In the following pages, we'll cover the most often used governance models. 81 | 82 | ### Company Led Governance 83 | 84 | Company-led projects have a mostly-closed process with the following characteristics: 85 | 86 | - Development is strongly led by one corporate or organizational interest 87 | - One entity controls software design, releases 88 | - May or may not solicit contributions, patches, suggestions etc. 89 | - Internal discussions, controversies, may not be aired very much 90 | - Exactly what will be in next software release not definitively known 91 | - Upon release, all software is completely in the open 92 | 93 | Examples: **Google Android**, **Red Hat Enterprise Linux (RHEL)** 94 | 95 | As you can imagine, it can be hard to influence direction of these projects except by making contributions to projects further upstream from these efforts - for example, the Linux kernel is upstream from both Google Android and Red Hat Enterprise Linux and getting features accepted there (if appropriate) is one way to influence Android and RHEL. 96 | 97 | ### Benevolent Dictator 98 | 99 | Projects with this type of governance typically have the strong leadership of one or a few key individuals. They also have the following characteristics: 100 | 101 | - One individual has overriding influence in every decision 102 | - Project's quality depends on that of the benevolent dictator(s) 103 | - Can avoid endless discussions and lead to quicker pace 104 | - As project grows, success depends critically on dictator's ability to: 105 | - Handle many contributors 106 | - Use a sane, scalable, version control system 107 | - Appoint and work with sub-system maintainers 108 | - Benevolent dictator's role may be social and political, not structural: Forks can occur any time 109 | - Maintainers write less and less code as projects mature 110 | 111 | Example: **Linux kernel** 112 | 113 | ### Governing Board 114 | 115 | Projects with a Governing Board structure have the following characteristics: 116 | 117 | - A body (group) carries out discussions on open mailing lists 118 | - Decisions about design, release dates, etc., are made collectively 119 | - Decisions about who can contribute, how patches and new software are accepted, are made by governing body 120 | - Much variation in governing structures, rules of organization, degree of consensus required, etc. 121 | - Tends to release less frequent, but hopefully well debugged versions 122 | 123 | Examples: **FreeBSD**, **Debian** 124 | 125 | Projects with this form of governance can be composed of either hobbyists or corporate developers, but tend to have less overt corporate influence than the Foundation/Consortium model (covered next). 126 | 127 | ### Foundation/Consortium 128 | 129 | Projects within Foundations or Consortiums have a mix of the previously-discussed governance models, usually with the following unique characteristics: 130 | 131 | - Business/strategic governance oversight committee/board 132 | - Provides overall business and strategic direction 133 | - Membership usually composed of corporate sponsors of the project 134 | - Separate technical steering committees for technical decisions 135 | - Public decisions/mailing lists for technical discussions 136 | - Leadership composed of technical resources of corporate sponsors 137 | - Ability to have non-corporate-affiliated technical resources appointed/voted on 138 | - Regular releases with longer testing/acceptance cycles 139 | 140 | Examples: **Open Stack**, **Kubernetes**, **Academy Software Foundation** 141 | 142 | We'll have more to say about Foundations and open source partnerships in a future training module. 143 | 144 | ### Participation Considerations 145 | 146 | Many people ask which of the governance models above is best or which should their organization participate in. The reality is that each model has advantages and disadvantages, but in many cases, you may not have a choice of which model to participate in, especially if the project is one that is core to your product or business. 147 | 148 | The biggest thing you should consider as an organization is making sure that you have the proper staffing (engineering and leadership) to participate effectively in whichever model the project you need is using. The biggest challenge many organizations face is participating with either too many or two few engineering or management resources. 149 | 150 | Understand what your organization needs from a project - if you need strategic input, making sustained engineering contributions as well as monetary support or leadership may be your best bet. If you are primarily a consumer of the technology with only the occasional need to make upstream contributions, having a primarily engineering-driven resourcing approach may work better. 151 | 152 | # Section: Effective Upstream Contribution Strategies 153 | 154 | ## Lesson: Introduction 155 | 156 | ### Section Overview 157 | 158 | In this section, we will discuss how to most effectively work with upstream open source projects, including understanding the best ways to engage with development communities, strategies for success, and what behaviors to avoid. 159 | 160 | ### Learning Objectives 161 | 162 | By the end of this section, you should be able to: 163 | 164 | - Describe the most important factors in working effectively with upstream communities 165 | - Explain best practices for successful upstream contributions 166 | - Understand what processes and considerations you'll need to address in your organization to be an effective upstream contributor 167 | 168 | ### Lesson: Upstream Collaboration 169 | 170 | ### Where to Contribute 171 | 172 | After understanding why it's important to contribute to upstream projects, the next most important determination is finding out **where** you should be contributing. As we covered in Module 2, Open Source Business Strategy, having a clear understanding from both an engineering and business perspective about what open source projects are important to you will help guide you in this important decision. 173 | 174 | In general, you should be evaluating open source projects, and your contributions, based on what provides the most overall value for your organization, for the amount of engineering resources you'll have to spend to enable these contributions. 175 | 176 | Some important questions and considerations include: 177 | 178 | - **Which open source projects do we use within the organization?** Take some time to assess which open source projects are already in use across the entire organization to determine which ones are strategic to your business. A few places you might want to focus your assessment: critical business infrastructure (operations), development and deployment tools that impact your ability to release products, and software that is important for customer-facing products or services. 179 | - **Which projects should we target for contribution?** Most organizations use many open source projects, so it's important to make sure that your plan focuses on just the most important ones. Just because a project isn't on the target list doesn't mean that people can't contribute to that project; it just means that it isn't a critical focus for your organization. If an open source project is critical to your business and has the potential to cause significant downtime or disruption to your ability to serve your customers, it's probably a good candidate for contributions. 180 | 181 | ### What to Contribute 182 | 183 | Other than where you should be contributing to upstream projects, one of the most important questions to ask is "**Why are these contributions important?**" 184 | 185 | It's easy to jump in and start talking about all the great things you plan to do, but don't forget to include compelling arguments for why this work is important and strategic to the organization, as well as how you plan to parlay any and all contributions into strategic value. 186 | 187 | Sometimes the contributions are important to supporting a product you are building, and sometimes they are important just to keep the overall upstream project strong and healthy so that you can rely on it in your downstream efforts. You also need to consider this from the upstream project's point of view - your planned contributions need to be valuable to the wider community for the upstream project. 188 | 189 | It's important to avoid the bad behavior of proposing contributions that may be strategic for your organization, but only useful for your own use cases, and not generally applicable to the whole upstream project community. 190 | 191 | ### How to Contribute 192 | 193 | There are many great resources for the technical process of how you contribute to upstream open source projects, but, let's concentrate at a high level here on some best practices you can use when considering how your organization will contribute. 194 | 195 | Here are some things to consider as you start your contribution journey: 196 | 197 | - Adopt an "upstream first" philosophy 198 | - Always plan to merge back with the main branch 199 | - Forks and side branches are ok as long as there is a plan to merge with upstream 200 | - Align internal development effort with the upstream branch release cadence 201 | - Require all code to be properly documented to be better understood by upstream reviewers, which will likely contribute to a faster acceptance cycle 202 | - Follow the release early and often practice. Don't build a huge code base and then decide to upstream it. Share design, early code and submit large contributions in smaller, independent patches that build on each other. 203 | - Track the code you choose to not upstream: Reevaluate at every opportunity. If you spot an upward trend in the internal maintained code's size, this calls for a discussion and reevaluation of prior decisions. 204 | 205 | ### Effective Contribution Policies 206 | 207 | Though it's important to have effective compliance policies implemented as part of your open source strategy, it's also critical that your legal & leadership teams be involved to help set up lightweight policies of fast approval of upstream contributions. 208 | 209 | These policies should be less about rules and regulations and more about helping people be successful in making contributions to open source projects. It can help if people have guidelines and checklists to make sure that they have everything they need to make a successful contribution without running into licensing or confidentiality issues. 210 | 211 | Especially for new contributors, it can also help to have an internal review process available as a safe place to get feedback before making a contribution. 212 | 213 | In many cases, contribution policies have predefined lists of approved open source licenses used by upstream projects, and take a "sandbox" approach with developers, where they are allowed to contribute to upstream projects if they are doing so for a project using one of the pre-approved licenses. 214 | 215 | The goal is to balance corporate governance of open source with a process to facilitate interactions with upstream developers. 216 | 217 | ### Staffing Considerations 218 | 219 | Staffing is a critical element to successful upstream contribution. You may already have relevant expertise in your organization, if you have engineering teams that have made some small upstream contributions. However, as you start to look at upstream projects that are critical for your business, you'll need to ascertain whether you have the relevant expertise in-house to make sustained contributions, or whether you need to hire for it. 220 | 221 | If you have to hire externally, it's important to make sure to find people with the skills not only to produce the contributions, but also people who are skilled at getting their upstream contribution accepted by the community. 222 | 223 | One way to seed your hiring is to consider hiring key developers and maintainers from the upstream project community. Be aware that these people are in high demand, so you have to be prepared to offer not only an appropriate salary, but also an engineering culture that allows them to continue working on the upstream project that they are a part of. 224 | 225 | The goal is to find people who have enough peer recognition to be influential in the community. There are typically three pillars to this: domain expertise, open source methodology, and working practices. You also need to align corporate interests with individual interests: it's very hard to motivate a senior open source developer to work when their personal interests don't meet with corporate interests in a given project. For example, a Linux memory management expert may not be interested in working on file systems, a corporate priority. Therefore, finding a match in interests is critical for a long lasting relationship. 226 | 227 | ### Schedule/Timing Considerations 228 | 229 | Providing adequate time in project schedules for upstream contributions is essential. If you have internal developers who are making upstream contributions, you'll need to budget time in their schedules to allow for these contributions to be made. If you are hiring external open source developers into your organization to work upstream, and also work on your product, you'll need to consider how to balance their schedules as well. 230 | 231 | The core principle for hiring open source developers is to support your open source development and upstream activities. There is also the expectation that they should support product teams in their expertise areas. However, it's not uncommon for product teams to exercise their influence in an attempt to hijack the time of the open source developers by having them work on product development as much as possible. If this happens, many open source developers will head to the door, seeking a new job that allows them to work on their upstream project before you realize what just happened. 232 | 233 | Therefore, it's important to create and maintain a separation of upstream work and product work. In other words, it's recommended to provide your open source developers with guaranteed time to meet their upstream aspirations and responsibilities, especially if they are a maintainer. For junior developers or other internal developers who are using open source in product components, such interactions with the upstream community will increase their language, communication, and technical skills. 234 | 235 | In the absence of such an upstream time guarantee, it's easy for these team members to be sucked into becoming an extension of product teams, resulting in their upstream focus drying up in favor of product development, which may help in the short term, but can ultimately lead to loss of your organization's reputation in the upstream community, which can negatively affect your ability to help guide the upstream project in areas beneficial to your organization. 236 | 237 | ### Training Considerations 238 | 239 | Even if you hire the best outside open source developers, you'll need to consider providing training opportunities for your existing engineering staff, as working with upstream communities can be a very different experience than they may have been used to in the past. 240 | 241 | What are some of the kinds of training you should be considering? 242 | 243 | - Best practices for making upstream contributions 244 | - General training on open source, licenses, governance, etc. 245 | - Training on conflict resolution or dealing with challenging people 246 | 247 | To scale your efforts over time, include in your training plan some programming that provides experienced open source contributors as mentors for new contributors. Mentoring is a powerful way to grow open source talent in specific technology areas relevant to your products. 248 | 249 | It's easy to hire a few resources from outside the company, but there are several limitations to this approach. The alternative approach is to convert your existing developers into open source contributors via training on the technical domain and open source methodology. These developers can then be paired with a mentor to further expand their skills. 250 | 251 | Set up a mentorship program where senior, experienced open source developers provide mentorship to junior, less experienced developers. Typically, the mentorship program would run for 3 to 6 months; during this time, the mentor should supervise the work of the mentee, assign tasks, and ensure proper results. The mentor would also do code reviews for anything the mentee produces, and provide feedback before the mentee pushes the code to the upstream project. 252 | 253 | The goal is to increase the number of developers the company has contributing code to the upstream project, and to improve individual effectiveness by increasing the quality of code and the percentage of code that is accepted into the upstream project. Generally speaking, no more than 4-5 mentees should be assigned to a given mentor, and ideally they should work in the same area as the mentor to make code reviews more efficient. 254 | 255 | ### Tooling Considerations 256 | 257 | It's important to provide a flexible IT infrastructure that allows developers to communicate and work with the open source community without any challenges. Additionally, you should consider setting up internal IT infrastructure that matches the tools used externally by upstream communities. This helps to help bridge the gap between internal teams and the upstream project community. 258 | 259 | Much of this infrastructure will naturally evolve with your organization's open source culture, but it's important to be aware of the necessity and plan for its implementation. There are three primary domains of IT services that are used in open source development: 260 | 261 | - Knowledge sharing (wikis, collaborative editing platforms, and public websites) 262 | - Communication and problem solving (mailing lists, forums, and real-time chat) 263 | - Code development and distribution (code repositories and bug tracking) 264 | 265 | Some or all of these tools will need to be made available internally to properly support open source development. There is a chance this might conflict with existing company-wide IT policies. If so, it's vital to resolve these conflicts and allow open source developers to use the tools they are familiar with. These open source practices typically require an IT infrastructure that is free from many standard, limiting IT policies. 266 | 267 | ### Other Forms of Contribution 268 | 269 | Remember that upstream communities also need other kinds of support that may not be code related. Look at the governance models for the projects you're interested in to determine whether there is an option for corporate membership or sponsorship for the project or the foundation responsible for it. This provides funding to help the project be successful, and in some cases, it can help your organization get more involved in an advisory role or provide some influence into the project. 270 | 271 | In addition to funding projects directly, consider sponsoring related conferences. These can be great for getting the word out about your work and for meeting people who you might want to recruit. In particular, don't overlook your participation in local user groups where you have employees. Sponsoring those local groups and sending contributors to give talks can be a great way to recruit local people who are passionate about particular open source projects. 272 | 273 | ### Evaluating your Upstream Efforts 274 | 275 | Because you are making a significant investment in time, people and money, it's important to consider how you are going to evaluate your upstream efforts. You can track non-code contributions like sponsorship dollars in the standard way you would any accounting investment, but you should give considerable thought to tracking contributions for projects you care about. 276 | 277 | Contributions can include upstream code development, supporting product teams, knowledge transfer (mentoring, training), and visibility (publications, talks). 278 | 279 | There are several toolkits that help track source code contributions; for instance, The Linux Foundation uses a tool called gitdm, which produces the data reported in the Linux Foundation yearly Linux Kernel report. This can be used to track both individual developers as well as the overall team performance. Individual developers can be tracked for the number of patches they submit, the patch acceptance rate (patches submitted divided by patches accepted), and the type of patch (e.g. if it is a new feature, enhancement of existing functionality, bug fix, documentation, etc.). 280 | 281 | Other tools like [GrimoireLab](http://grimoirelab.github.io/) can also be used to chart and visualize the metrics you want to track. See the next section on metrics for specific examples of what you should track. 282 | 283 | ## Metrics for Tracking Progress 284 | 285 | Once you start implementing these open source best practices, you'll need proper open source metrics to drive the desired development behavior. But the traditional metrics often used in product organizations don't apply in the context of open source development. 286 | 287 | For example, tracking the number of changesets or lines of code can be a good metric for open source development impact. But you may have multiple instances of desired functionality being implemented upstream because your open source developers lobby for support from the community. In this case, the number of changesets or lines of code doesn't matter nearly as much as the technical leadership that team members provide to get code upstream and reduce the company's downstream maintenance efforts. So the metrics you track should account for both activities. 288 | 289 | ### Commits and lines of code over time 290 | 291 | One of the most basic things to track is the number of commits and lines of code changed over a specific period of time, such as every week, month, or year. 292 | 293 | ![Commits and lines of code over time](commits-over-time.png) 294 | 295 | ### The total commits and lines changed per project per week is a good place to start tracking metrics. 296 | 297 | With this data, you can compare contributions from various internal development teams to identify where source code contributions are coming from and help ensure that resources are allocated appropriately. 298 | 299 | From here you can create charts that compare various internal teams for their cumulative contributions, percent of total contributions, and the amount of time it takes to get code committed upstream (see the following charts). 300 | 301 | ![Cumulative contributions over time](cumulative.png) 302 | 303 | **Figure 2:** Cumulative contributions over time can be tracked to compare internal teams and identify teams that are increasing their involvement in a particular open source community (in this chart, it's the Linux kernel). 304 | 305 | ![contributions as a percent of total over time](percent-over-time.png) 306 | 307 | **Figure 3:** Displaying your company's contributions as a percent of total over time allows you to identify the teams that contribute the most code. 308 | 309 | ![Time to Commit](time-to-commit.png) 310 | 311 | **Figure 4:** The amount of time it takes to commit code upstream can be valuable for tracking your development efficiency. This table and chart shows how quickly various teams are getting their code contributed upstream and compares it to the community as a whole. 312 | 313 | You can also use these metrics to compare your performance to other companies who are involved in the Kernel ecosystem for instance (Figure 5). This competitive analysis helps you be better informed about the overall developer ecosystem for the project. 314 | 315 | ![Cumulative Contributions by Company](cumulative-by-company.png) 316 | 317 | **Figure 5:** Cumulative contributions can be sorted by company to see how your company stacks up against others. 318 | 319 | These metrics provide a much better idea of where your strengths and weaknesses are and can help inform your overall development strategy. Tracking your own contributions relative to competitors', for example, provides valuable information that helps an organization position its products relative to competitors' in the marketplace. 320 | 321 | Being a top contributor isn't a goal, in and of itself, but rather an indication that the organization's development efforts are being accepted by the communities in which it participates. 322 | 323 | ### Things to Remember 324 | 325 | We've presented a lot of information so far about working most effectively with upstream open source projects. We'll try to distill this down to some key things to remember: 326 | 327 | 1. Establish a policy and process to guide open source contributions 328 | 2. Set up a team to oversee approvals for all open source contributions 329 | 3. Focus contributions in the areas that will enable your technologies 330 | 4. Provide the needed IT infrastructure and tooling for contributors 331 | 5. Offer training to your staff on contribution best practices 332 | 6. Track contributions, measure impact, improve, and communicate 333 | 7. Establish a mentorship program to train less experienced developers 334 | 8. Provide contribution guidelines, how-to's, do's and don'ts 335 | 9. Make open source legal support accessible to developers 336 | 10. Hire from the open source communities you value the most 337 | 11. Always follow the community processes and practices specific to each project 338 | 12. Always consider if what you're upstreaming is valuable to the whole community, and isn't a specific case just for your product 339 | 340 | # Section: Upstream Development Practices 341 | 342 | ## Lesson: Introduction 343 | 344 | ### Section Overview 345 | 346 | In this section, we will look in more detail at the development processes and practices used by most upstream projects, to help give you practical guidelines on how to implement the contribution strategies we discussed in the previous section. 347 | 348 | ### Learning Objectives 349 | 350 | By the end of this section, you should be able to: 351 | 352 | - Describe the overall process for how to make upstream contributions 353 | - Explain how to best align internal processes for better upstream collaboration 354 | 355 | ## Lesson: Process Overview 356 | 357 | ### Before You Begin 358 | 359 | After you've identified the projects you'll need to contribute to, spending a little time understanding the project's inner workings (including governance, as mentioned previously) will be helpful. Here are some ways to begin: 360 | 361 | - Follow the project discussions (mailing lists, IRC, Slack, discussion forums) to understand ongoing efforts 362 | - Who are the core developers? 363 | - What are areas of high priority? 364 | - How do release cycles work? 365 | - What are the major bugs currently outstanding 366 | - Experiment with latest stable and experimental releases 367 | - Determine how your interests and priorities align with those of the project 368 | - Find others in the community who share your interests and priorities, and work with them 369 | 370 | ### Signal Intent 371 | 372 | ![Signal Intent](signal-intent.png) 373 | 374 | It's important to communicate with the community about what changes you are planning to submit. The process typically starts with sending a message to the community through whatever mechanism they are using. 375 | 376 | This public discussion is a prerequisite and helps make maintainers aware of the need and the problems you are working to solve. It can often help you recruit others to help do the work, as well as let you gather feedback on the usefulness and design considerations before doing a lot of work (and having your change rejected). 377 | 378 | As you propose your change, keep these important things in mind: 379 | 380 | - It should be useful to others and not just to your specific usage models 381 | - It should be implemented in small parts, and delivered in a way that provides immediate benefit 382 | - It should be backed by resources ready to implement and maintain it within your organization 383 | 384 | ### Discussion and Rationale 385 | 386 | ![Discussion and Rationale](discussion.png) 387 | 388 | After a change request has been submitted, there is often some form of discussion in whatever tool the community uses for primary communication. At this time, it gives other interested parties an opportunity to comment, provide feedback, critiques, and it also gives maintainers an opportunity to comment on whether the project is ready to accept such a change. 389 | 390 | The comments at this stage could range from brief approval to detailed questions about implementation, especially if the change is considered high-risk or potentially intrusive to core parts of the project. It's a good idea to have some thoughts about how you want to convince others and address potential challenges you may see when you first send this communication. 391 | 392 | ### Acceptance 393 | 394 | ![Acceptance](acceptance.png) 395 | 396 | After the community discussion, if the maintainers and other interested parties agree, the change is accepted, and some additional considerations are debated, including ascertaining how strategic the change is to the project, an indication that the proposed implementation seems ok, and general consensus that the change is unlikely to affect stability, security, or overall functionality of the project. 397 | 398 | One or more of the project maintainers will usually signal their approval at this phase. 399 | 400 | ### Tracking Proposed Contribution 401 | 402 | ![Tracking Proposed Contribution](tracking.png) 403 | 404 | Once a change has been accepted, it needs to be tracked, and this usually occurs in some form of feature or bug tracking, depending on what tools are used by the project community. This tracking entry is considered the authoritative record of what was proposed and what was accepted as a change. 405 | 406 | At this stage, the original submitting developer adds detailed feature information into the tracking tool so that a record is maintained of what subsystems the change will affect and what the overall plan for implementation is. 407 | 408 | ### Prioritization 409 | 410 | ![Prioritization](priortization.png) 411 | 412 | After a change has been accepted and tracked, its acceptance needs to be prioritized in conjunction with all other pending changes to the project. At this point, maintainers get involved again to prioritize which incoming changes are core to the project, and which are needed right away versus which can be accepted later. 413 | 414 | Because maintainers generally have a global view of dependencies and future releases, they can work to prioritize changes and align features correctly. However, if a change is minor enough, or doesn't touch too many core parts of the project, they may signal they are ready to accept it as soon as it's ready. 415 | 416 | ### Release Planning 417 | 418 | ![Release Planning](release-planning.png) 419 | 420 | Once a maintainer has completed prioritization of the incoming change, they will work to communicate the original developer who submitted the change request (as well as the entire community) on when they will be ready to integrate the change. This helps the maintainer and community plan for a manageable number of features per release. 421 | 422 | During this phase, the original submitter will get notification of what specific future release their change is planned for. 423 | 424 | ### Development & QA 425 | 426 | ![Development & QA](development-qa.png) 427 | 428 | After all of the prerequisites in the process are completed, the actual development and Quality Assurance can take place, where the developer and any other resources recruited from the community step in and begin to implement the new change, targeting the specific release set by the maintainer. 429 | 430 | If for some reason the development runs into issues or it looks like they won't be able to make the specific release window they were assigned to, it's important for them to communicate early with the maintainer and community so that any dependencies on their change can be adjusted in the upcoming release cycles. 431 | 432 | ## Lesson: Aligning Internal Processes 433 | 434 | ### Where to Start 435 | 436 | It's important to consider how to best align your internal development processes to be more effective when you are contributing changes back to an upstream community. While you may still have unique development processes for internal or closed source software products, being able to shift contexts and work effectively when collaborating with upstream open source projects is important both for your upstream contributions, but also to help you most effectively consume the open source projects into your internal code. 437 | 438 | To get yourself setup for a contribution, you generally follow the process outlined below (this example is from Github, but can be generalized to any system utilizing git as the source control system): 439 | 440 | ![Set up to Contribute](setup.png) 441 | 442 | If this is a small open source project or one that is unlikely to be used by others in your organization, you can generally leave the fork on Github in your own account, but if it's likely to be used by other teams in your organization, you may want to fork the upstream project into a company-owned organization for easier maintenance. 443 | 444 | Once you've done the initial setup, the general workflow of pushing changes up through "pull requests" looks like this: 445 | 446 | ![Pull Requests](pull-requests.png) 447 | 448 | ### Internal Mirrors 449 | 450 | For some organizations, especially those that have potential concerns about the long-term availability of open source repositories on the Internet, it may make sense to have an additional layer of repository structure inside your organization. For example: 451 | 452 | 453 | 454 | ![Internal Mirror](internal-mirror.png) 455 | 456 | Additionally, for some orgs, the "comfort factor" of having this internal mirror of an open source project gives them the ability to more easily have legal sign-off on usage of open source in products. 457 | 458 | While it does provide a layer of safety, it does also increase the workload for changes going upstream, as you'll need to push those changes from your local developer repo to the internal mirror, and then on to the actual fork on Github before proposing your pull request. 459 | 460 | ### Internal Collaboration 461 | 462 | Whether you choose to have your consumption of and contribution to upstream projects happen with or without an internal mirror, you'll still need to build communication and collaborative practices within your organization to make sure that: 463 | 464 | - You're working on a small set of approved versions of the upstream project 465 | - Changes you're making are not redundant or in conflict with your internal teams 466 | - Changes that you're proposing to the upstream project are consistent across the company 467 | 468 | ### Coordinating Upstream Pull Requests 469 | 470 | If you have multiple teams consuming and potentially making changes to an upstream open source project, it's important that you work to coordinate any changes that are being made to that project. Whether you monitor and prioritize/clarify those changes in an internal mirror repo, or your public organizational repo, it helps to identify internal "maintainers" inside of your organization that have a responsibility for acting as an intermediate "upstream" review team. 471 | 472 | Effectively coordinating your upstream project contributions in a large engineering organization can seem like a lot of extra work, but it's needed if you want to keep the upstream project effective and healthy so you can rely upon it, and, also so that your organization's reputation with the upstream community remains intact. Having many conflicting changes from a single organization going to the upstream project can have a detrimental effect on how your organization is viewed by the open source community, which negatively affects your ability to work with them long-term. 473 | --------------------------------------------------------------------------------