├── module5 ├── audit.png ├── tools.png ├── devops.png ├── linking.png ├── notices.png ├── reviews.png ├── approvals.png ├── components.png ├── copyright.png ├── diy-audit.png ├── outbound.png ├── questions.png ├── tools-alt.png ├── modification.png ├── own-software.png ├── registration.png ├── review-team.png ├── translation.png ├── analyzing-usage.png ├── binary-scanning.png ├── distributions.png ├── diy-audit-alt.png ├── identification.png ├── incorporation.png ├── initiate-review.png ├── policy-process.png ├── source-scanning.png ├── verifications.png ├── analyzing-inbound.png ├── license-scanning.png ├── process-overview.png ├── resolving-issues.png ├── review-oversight.png ├── traditional-audit.png ├── audit-inputs-outputs.png ├── compliance-process.png ├── compliance-tooling.png ├── final-verifications.png ├── inject-into-output.png ├── license-categories.png ├── software-situation.png └── working-through-review.png ├── module6 ├── setup.png ├── acceptance.png ├── cumulative.png ├── discussion.png ├── tracking.png ├── development-qa.png ├── internal-mirror.png ├── priortization.png ├── pull-requests.png ├── signal-intent.png ├── time-to-commit.png ├── commits-over-time.png ├── percent-over-time.png ├── pull-requests-alt.png ├── release-planning.png ├── dev-with-upstreaming.png ├── supply-chain-funnel.png ├── cumulative-by-company.png ├── dev-without-upstreaming.png └── README.md ├── module2 ├── os-ladder.png ├── strategic-use.png ├── involvement-over-time.png └── README.md ├── module3 ├── comcast-ospo.png ├── ospo-structure.png ├── oss-foundations.png └── README.md ├── module4 ├── humble-but-bold.png ├── linux-example.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 ├── code-diveded-into-subsystems.png ├── open-source-development-model.png ├── release-criteria-become-more-stringent.png ├── release-overseen-by-decicated-maintainers.png └── README.md ├── 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 ├── LICENSE └── LICENSE-DOCS /module5/audit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/audit.png -------------------------------------------------------------------------------- /module5/tools.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/tools.png -------------------------------------------------------------------------------- /module6/setup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/setup.png -------------------------------------------------------------------------------- /module5/devops.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/devops.png -------------------------------------------------------------------------------- /module5/linking.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/linking.png -------------------------------------------------------------------------------- /module5/notices.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/notices.png -------------------------------------------------------------------------------- /module5/reviews.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/reviews.png -------------------------------------------------------------------------------- /module2/os-ladder.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module2/os-ladder.png -------------------------------------------------------------------------------- /module5/approvals.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/approvals.png -------------------------------------------------------------------------------- /module5/components.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/components.png -------------------------------------------------------------------------------- /module5/copyright.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/copyright.png -------------------------------------------------------------------------------- /module5/diy-audit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/diy-audit.png -------------------------------------------------------------------------------- /module5/outbound.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/outbound.png -------------------------------------------------------------------------------- /module5/questions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/questions.png -------------------------------------------------------------------------------- /module5/tools-alt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/tools-alt.png -------------------------------------------------------------------------------- /module6/acceptance.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/acceptance.png -------------------------------------------------------------------------------- /module6/cumulative.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/cumulative.png -------------------------------------------------------------------------------- /module6/discussion.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/discussion.png -------------------------------------------------------------------------------- /module6/tracking.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/tracking.png -------------------------------------------------------------------------------- /module3/comcast-ospo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module3/comcast-ospo.png -------------------------------------------------------------------------------- /module5/modification.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/modification.png -------------------------------------------------------------------------------- /module5/own-software.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/own-software.png -------------------------------------------------------------------------------- /module5/registration.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/registration.png -------------------------------------------------------------------------------- /module5/review-team.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/review-team.png -------------------------------------------------------------------------------- /module5/translation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/translation.png -------------------------------------------------------------------------------- /module2/strategic-use.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module2/strategic-use.png -------------------------------------------------------------------------------- /module3/ospo-structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module3/ospo-structure.png -------------------------------------------------------------------------------- /module3/oss-foundations.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module3/oss-foundations.png -------------------------------------------------------------------------------- /module4/humble-but-bold.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module4/humble-but-bold.png -------------------------------------------------------------------------------- /module4/linux-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module4/linux-example.png -------------------------------------------------------------------------------- /module4/waterfall-model.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module4/waterfall-model.png -------------------------------------------------------------------------------- /module5/analyzing-usage.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/analyzing-usage.png -------------------------------------------------------------------------------- /module5/binary-scanning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/binary-scanning.png -------------------------------------------------------------------------------- /module5/distributions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/distributions.png -------------------------------------------------------------------------------- /module5/diy-audit-alt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/diy-audit-alt.png -------------------------------------------------------------------------------- /module5/identification.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/identification.png -------------------------------------------------------------------------------- /module5/incorporation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/incorporation.png -------------------------------------------------------------------------------- /module5/initiate-review.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/initiate-review.png -------------------------------------------------------------------------------- /module5/policy-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/policy-process.png -------------------------------------------------------------------------------- /module5/source-scanning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/source-scanning.png -------------------------------------------------------------------------------- /module5/verifications.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/verifications.png -------------------------------------------------------------------------------- /module6/development-qa.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/development-qa.png -------------------------------------------------------------------------------- /module6/internal-mirror.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/internal-mirror.png -------------------------------------------------------------------------------- /module6/priortization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/priortization.png -------------------------------------------------------------------------------- /module6/pull-requests.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/pull-requests.png -------------------------------------------------------------------------------- /module6/signal-intent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/signal-intent.png -------------------------------------------------------------------------------- /module6/time-to-commit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/time-to-commit.png -------------------------------------------------------------------------------- /module7/release-early.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module7/release-early.png -------------------------------------------------------------------------------- /module5/analyzing-inbound.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/analyzing-inbound.png -------------------------------------------------------------------------------- /module5/license-scanning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/license-scanning.png -------------------------------------------------------------------------------- /module5/process-overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/process-overview.png -------------------------------------------------------------------------------- /module5/resolving-issues.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/resolving-issues.png -------------------------------------------------------------------------------- /module5/review-oversight.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/review-oversight.png -------------------------------------------------------------------------------- /module5/traditional-audit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/traditional-audit.png -------------------------------------------------------------------------------- /module6/commits-over-time.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/commits-over-time.png -------------------------------------------------------------------------------- /module6/percent-over-time.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/percent-over-time.png -------------------------------------------------------------------------------- /module6/pull-requests-alt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/pull-requests-alt.png -------------------------------------------------------------------------------- /module6/release-planning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/release-planning.png -------------------------------------------------------------------------------- /module7/questions-to-ask.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module7/questions-to-ask.png -------------------------------------------------------------------------------- /module4/single-body-of-code.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module4/single-body-of-code.png -------------------------------------------------------------------------------- /module5/audit-inputs-outputs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/audit-inputs-outputs.png -------------------------------------------------------------------------------- /module5/compliance-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/compliance-process.png -------------------------------------------------------------------------------- /module5/compliance-tooling.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/compliance-tooling.png -------------------------------------------------------------------------------- /module5/final-verifications.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/final-verifications.png -------------------------------------------------------------------------------- /module5/inject-into-output.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/inject-into-output.png -------------------------------------------------------------------------------- /module5/license-categories.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/license-categories.png -------------------------------------------------------------------------------- /module5/software-situation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/software-situation.png -------------------------------------------------------------------------------- /module6/dev-with-upstreaming.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/dev-with-upstreaming.png -------------------------------------------------------------------------------- /module6/supply-chain-funnel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/supply-chain-funnel.png -------------------------------------------------------------------------------- /module2/involvement-over-time.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module2/involvement-over-time.png -------------------------------------------------------------------------------- /module4/continuous-integration.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module4/continuous-integration.png -------------------------------------------------------------------------------- /module4/what-is-a-contributor.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module4/what-is-a-contributor.png -------------------------------------------------------------------------------- /module5/working-through-review.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module5/working-through-review.png -------------------------------------------------------------------------------- /module6/cumulative-by-company.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/cumulative-by-company.png -------------------------------------------------------------------------------- /module1/community-org-structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module1/community-org-structure.png -------------------------------------------------------------------------------- /module4/delegated-maintainership.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module4/delegated-maintainership.png -------------------------------------------------------------------------------- /module4/overlapping-test-cycles.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module4/overlapping-test-cycles.png -------------------------------------------------------------------------------- /module6/dev-without-upstreaming.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module6/dev-without-upstreaming.png -------------------------------------------------------------------------------- /module4/overlapping-release-cycles.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module4/overlapping-release-cycles.png -------------------------------------------------------------------------------- /module7/good-reasons-to-opensource.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module7/good-reasons-to-opensource.png -------------------------------------------------------------------------------- /module4/code-diveded-into-subsystems.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module4/code-diveded-into-subsystems.png -------------------------------------------------------------------------------- /module4/open-source-development-model.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module4/open-source-development-model.png -------------------------------------------------------------------------------- /module7/bad-reasons-to-create-opensource.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module7/bad-reasons-to-create-opensource.png -------------------------------------------------------------------------------- /module4/release-criteria-become-more-stringent.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module4/release-criteria-become-more-stringent.png -------------------------------------------------------------------------------- /module4/release-overseen-by-decicated-maintainers.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innovationacademy-kr/ospo101/HEAD/module4/release-overseen-by-decicated-maintainers.png -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # OSPO 101 교육 모듈 2 | 3 | 4 | 5 | OSPO 101은 오픈 소스 프로그램 오피스 관리에 대해 알아야 할 모든 것에 대한 과정입니다. 6 | 7 | 콘텐츠를 단편적으로 재사용할 수 있도록 모듈화하기 위한 것입니다. 8 | 9 | * [오픈 소스 소개](module1/README.md) 10 | * [오픈 소스 비즈니스 전략](module2/README.md) 11 | * [효과적인 오픈 소스 프로그램(OSPO) 관리](module3/README.md) 12 | * [오픈 소스 개발 사례](module4/README.md) 13 | * [오픈 소스 준수 프로그램](module5/README.md) 14 | * [오픈 소스 프로젝트와 효과적인 협업](module6/README.md) 15 | * [오픈 소스 프로젝트 만들기](module7/README.md) 16 | 17 | OSPO 101 과정 자료는 조직을 위한 본격적인 패키지 과정으로 LF 교육에서도 사용할 수 있습니다. 18 | 19 | https://training.linuxfoundation.org/training/open-source-management-and-strategy/ 20 | 21 | ## 강의 개요 22 | 23 | * [오픈 소스 소개](module1/README.md) 24 | * [오픈 소스 소개](module1/README.md#섹션-오픈-소스-소개) 25 | * [오픈 소스 소프트웨어의 간략한 역사](module1/README.md#섹션-오픈-소스-소프트웨어의-짧은-역사) 26 | * [오픈 소스를 사용하는 이유](module1/README.md#섹션-오픈-소스를-사용하는-이유) 27 | 28 | * [오픈 소스 비즈니스 전략](module2/README.md) 29 | * [오픈 소스 비즈니스 모델 소개](module2/README.md#섹션-오픈-소스-비즈니스-모델-소개) 30 | * [오픈 소스 전략 개발](module2/README.md#섹션-오픈-소스-전략-개발하기) 31 | * [오픈 소스 정책 개발](module2/README.md#섹션-오픈-소스-정책-개발) 32 | * [오픈 소스 프로그램 오피스(OSPO) 소개](module2/README.md#섹션-오픈-소스-프로그램-오피스-소개) 33 | 34 | * [효과적인 오픈 소스 프로그램(OSPO) 관리](module3/README.md) 35 | * [오픈 소스 프로그램 오피스 및 조직](module3/README.md#오픈-소스-프로그램-오피스ospo-및-조직) 36 | * [효과적인 오픈 소스 프로그램 오피스 구축](module3/README.md#효과적인-오픈-소스-프로그램-오피스-구축) 37 | * [추가 정보 및 사례 연구](module3/README.md#추가-정보-및-사례-연구) 38 | 39 | * [오픈 소스 개발 사례](module4/README.md) 40 | * [효과적인 오픈 소스 개발 및 참여](module4/README.md#효과적인-오픈소스-개발-및-참여) 41 | * [지속적 통합 및 테스트의 역할](module4/README.md#지속적인-통합-및-테스트의-역할) 42 | * [내부적으로 오픈 소스 방법론 적용](module4/README.md#내부적으로-오픈-소스-방법론-적용) 43 | 44 | * [오픈 소스 준수 프로그램](module5/README.md) 45 | * [오픈 소스 라이선스 및 규정 준수 기본 사항](module5/README.md#오픈-소스-라이선스-및-규정-준수-기본-사항) 46 | * [효과적인 규정 준수 프로그램 구축](module5/README.md#섹션-효과적인-규정-준수-프로그램-구축) 47 | * [올바른 라이선스 준수 도구 선택](module5/README.md#섹션-올바른-라이선스-준수-도구-선택) 48 | * [M&A 활동 중 오픈 소스 감사의 역할](module5/README.md#섹션-ma-활동-중-오픈-소스-감사의-역할) 49 | 50 | * [오픈 소스 프로젝트와 효과적인 협업](module6/README.md) 51 | * [업스트림 오픈 소스 프로젝트 이해하기](module6/README.md#업스트림-오픈-소스-프로젝트-이해) 52 | * [효과적인 업스트림 기여 전략](module6/README.md#섹션-효과적인-업스트림-기여-전략) 53 | * [업스트림 개발 사례](module6/README.md#섹션-업스트림-개발-관행) 54 | 55 | * [오픈 소스 프로젝트 만들기](module7/README.md) 56 | * [오픈 소스 프로젝트 생성 개요](module7/README.md#오픈-소스-프로젝트-생성-개요) 57 | * [새로운 프로젝트 준비](module7/README.md#섹션-새로운-프로젝트-준비) 58 | * [성공적인 프로젝트 시작 및 유지](module7/README.md#섹션-성공적인-프로젝트-시작-및-유지) 59 | 60 | ## 감사의 말 61 | 62 | 과정의 초기 콘텐츠를 시드하는 데 도움을 준 [Guy Martin](https://twitter.com/guyma)에 감사드립니다. 코스는 [Chris Aniszczyk](https://twitter.com/cra) 및 Greg Back의 기여를 포함하여 TODO 그룹 커뮤니티에 의해 친숙한 마크다운 형식으로 변환되었습니다. 63 | 64 | ## 라이선스 65 | 66 | 모든 코드는 Apache 2.0에서 제공되며 설명서는 크리에이티브 커먼즈 저작자표시 4.0 국제 (CC BY 4.0) 라이선스: http://creativecommons.org/licenses/by/4.0/ 에 따라 제공됩니다. 67 | 68 | ## 이 문서의 출처 69 | 70 | 이 Repository의 문서는 [리눅스 재단(Linux Foundation)](https://www.linuxfoundation.org/)의 [Todo Group](https://todogroup.org/)에서 만든 것으로 원본(영어) 문서는 https://github.com/todogroup/ospo101 에서 보실 수 있습니다. 71 | -------------------------------------------------------------------------------- /ospo101.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /module1/README.md: -------------------------------------------------------------------------------- 1 | # 섹션: 오픈 소스 소개 2 | 3 | ## 수업: 소개 4 | 5 | ### 섹션 개요 6 | 7 | 이 섹션에서는 오픈 소스, 오픈 표준 및 폐쇄 소스 소프트웨어의 정의와 이들 간의 비교를 제공합니다. 또한 이 세 가지 요소를 함께 사용하여 우리 모두가 의존하는 기술 솔루션을 제공하는 방법에 대한 개요도 제공합니다. 8 | 9 | ### 학습 목표 10 | 11 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 12 | 13 | * 오픈 소스, 오픈 표준 및 폐쇄 소스 소프트웨어를 정의합니다. 14 | 15 | * 세 가지 개념의 차이점과 유사점을 설명할 수 있습니다. 16 | 17 | * 세 가지 개념이 함께 작동하는 방식을 이해합니다. 18 | 19 | ## 수업: 정의 20 | 21 | ### 오픈 소스 소프트웨어란 무엇입니까? 22 | 23 | [Wikipedia](https://en.wikipedia.org/wiki/Software_license)에 따르면: 24 | 25 | **오픈 소스 소프트웨어** (**OSS**)는 저작권 소유자가 사용자에게 소프트웨어를 연구, 변경 및 배포할 수 있는 권한을 사용자에게 부여하는 라이선스 하에 소스 코드가 공개된 컴퓨터 소프트웨어 유형입니다. 오픈 소스 소프트웨어는 공동의 공개 방식으로 개발될 수 있습니다. 26 | 27 | Let's break down this definition and explore it a bit: 28 | 29 | **컴퓨터 소프트웨어** 30 | 31 | 컴퓨터 소프트웨어는 작성자가 작성한 프로그램 또는 펌웨어를 말합니다. 소프트웨어 작성자는 한 명 또는 여러 명이 될 수 있으며 회사를 대신하여 작업을 수행할 수도 있습니다. 프로그램은 '소스 코드'를 '바이너리 형식'으로 알려진 변환을 통해 달성되는 기계 판독 가능 형식을 통해 특정 컴퓨터에서 실행할 수 있습니다. 32 | 33 | **소스 코드** 34 | 35 | 소스 코드는 컴퓨터가 실행할 알고리즘이나 아이디어를 나타내는 데 사용되는 사람이 읽을 수 있는 명령 집합을 나타냅니다. 많은 컴퓨터 언어를 사용하여 소스 코드를 작성할 수 있으며 컴파일 또는 실시간 해석 과정을 통해 기계가 읽을 수 있는 이진 형식으로 변환됩니다. 소스 코드가 있으면 소프트웨어를 연구하고 효율적으로 수정할 수 있습니다. 36 | 37 | **라이선스** 38 | 39 | 라이선스는 소프트웨어 및/또는 소스 코드와 관련된 법적으로 집행 가능한 일련의 행위, 프로세스 또는 계약 의무, 의무 또는 권리를 기록하고 공식적으로 표현 하는 **법적** 문서입니다. 40 | 41 | **연구, 변경 및 배포** 42 | 43 | 오픈 소스 소프트웨어의 기본 구성 요소는 개인이 소프트웨어를 연구하고 자신의 목적에 맞게 변경한 다음 변경 사항을 어떤 목적으로든 다른 사람에게 재배포할 수 있도록 다양한 오픈 소스 라이선스가 부여하는 자유입니다. 변경된 버전에 대한 요구 사항은 사용하는 오픈 소스 라이선스의 유형에 따라 다릅니다. 이에 대한 자세한 내용은 이 과정 시리즈의 이후 모듈에서 제공됩니다. 44 | 45 | **협업적 공개 매너** 46 | 47 | 라이선스가 제공하는 자유로 인해 인기 있는 오픈 소스 소프트웨어를 중심으로 대규모의 다양한 커뮤니티가 형성되어 혁신을 주도하고 기업이 이러한 소프트웨어 프로젝트에 기여하고 이익을 얻을 수 있기 때문에 협업적 공개 매너가 중요합니다. Linux는 그러한 커뮤니티 중 하나의 주요 예이지만 Apache Web Server, Kubernetes 및 OpenStack과 같은 다른 커뮤니티도 많이 있습니다. 48 | 49 | ### 폐쇄 소스 소프트웨어란 무엇입니까? 50 | 51 | 오픈 소스 소프트웨어가 아닌 소프트웨어는 폐쇄 소스 소프트웨어입니다. 다음은 [Wikipedia](https://en.wikipedia.org/wiki/Software_license) 정의를 기반으로 하는 비오픈 소스 소프트웨어에 대한 설명입니다: 52 | 53 | 종종 **독점** 소프트웨어 라고도 하는, **폐쇄형 소스** 소프트웨어는 소프트웨어 게시자 또는 다른 사람이 오픈 소스 소프트웨어에 허용된 것 이상의 지적 권리(일반적으로 소스 코드의 [저작권](https://en.wikipedia.org/wiki/Copyright) 이지만 때로는 특허권도 포함)를 보유하는 비자유 컴퓨터 소프트웨어입니다 . 54 | 55 | 이전과 마찬가지로 이 정의를 약간 풀고 몇 가지 핵심 요소를 살펴보겠습니다.: 56 | 57 | **폐쇄 소스** 58 | 59 | 오픈 소스와 달리 폐쇄 소스 소프트웨어의 사람이 읽을 수 있는 지침은 소프트웨어 작성자가 사용할 수 없습니다. 컴퓨터에 전달되고 설치된 것은 기계가 읽을 수 있는 형식일 뿐입니다. 예를 들어 Microsoft Office와 같은 인기 있는 프로그램은 이러한 방식으로 제공됩니다. 60 | 61 | **무료 아님** 62 | 63 | 여기서 자유롭지 않다는 것은 저자(들)가 프로그램을 연구, 수정 또는 재배포하는 것을 금지하는 오픈 소스 소프트웨어가 아닌 라이선스에 따라 배포한다는 사실을 나타냅니다. 사용료가 있을 수도 있고 없을 수도 있습니다. 64 | 65 | **지적 권리** 66 | 67 | 작성자는 소스 코드뿐만 아니라 프로그램 설계에 사용된 아이디어 및/또는 알고리즘에 대한 액세스 권한을 보유합니다. 68 | 69 | 여기서 또 다른 주요 차이점은 폐쇄 소스 소프트웨어가 일반적으로 외부 커뮤니티 구성원과 협력하지 않는 개발자 팀(일반적으로 기업에서 일하지만 항상 그런 것은 아님)이 설계하고 개발한다는 것입니다(일반적으로 오픈 소스 소프트웨어에서 수행되는 것처럼). 70 | 71 | ### 오픈 표준이란 무엇입니까? 72 | 73 | '오픈 표준'이 무엇인지에 대한 다양한 정의가 있으며 여기에서 그 일부를 통합할 수 있습니다.: 74 | 75 | **오픈 표준** 은 공개적으로 이용 가능하고 로열티가 없으며, '표준'은 모든 이해 당사자가 참여할 수 있고 합의에 따라 운영되는 공식 위원회에서 승인한 기술을 의미합니다. 오픈 표준은 공개적으로 사용 가능하며 협업 및 합의 기반 프로세스를 통해 개발, 승인 및 유지 관리됩니다. 76 | 77 | 또한, **오픈 표준**은 오픈 소스 소프트웨어에서 구현을 준수하는 것을 금지해서는 안 됩니다. 78 | 79 | 여기서도 조금 더 깊이 들어가 보겠습니다: 80 | 81 | **공개적으로 사용 가능** 82 | 83 | 표준은 무료로 대중에게 제공됩니다. 84 | 85 | **로열티 프리** 86 | 87 | 이것은 오픈 표준과 비오픈 표준의 중요한 차이점입니다. 이는 기업으로부터 라이선스를 취득하지 않고도(또는 기업에 비용을 지불하지 않고도) 표준을 활용하여 솔루션을 구축할 수 있는 능력이 보다 폭넓게 채택되는 데 가장 중요합니다. 88 | 89 | **협업 및 합의 기반 프로세스** 90 | 91 | 이것은 이제 오픈 소스에 대한 이전 정의에서 여러분에게 친숙할 것이며, 더 넓은 관점과 다양한 회사와 개인이 광범위하게 채택할 수 있는 최상의 기회를 모두 허용하기 때문에 여기에서도 중요합니다. 또한 때로는 표준을 정의하는 데 시간이 오래 걸립니다. 92 | 93 | **준수 구현** 94 | 95 | 이는 승인된 오픈 소스 라이선스와 오픈 소스의 공식 정의를 모두 유지하는 데 도움이 되는 산업 컨소시엄인 OSI(Open Source Initiative)에서 제시한 특정 정의입니다. OSR(Open Standards Requirement)은 이 정의에 추가하여 표준 자체를 준수하는 오픈 소스 소프트웨어를 구축하는 것을 방해하는 표준의 정의에 어떤 내용도 포함되어서는 안 된다는 점을 추가로 명확히 하고 있습니다. 이를 준수하면 표준을 사용하는 사람들에게 구현을 선택할 때 선택할 수 있는 오픈 소스와 폐쇄 소스 옵션이 모두 있다는 확신을 갖게 됩니다. 96 | 97 | 우리가 매일 의존하는 많은 표준이 있습니다. **TCP/IP** (인터넷 통신의 기본 표준), **HTTP** (월드 와이드 웹 뒤의 프로토콜), **HTML** (웹 페이지 작성자가 콘텐츠 형식 지정에 사용하는 언어 ), **GSM** (세계 대부분의 휴대 전화 통신 표준), **ODF** (다양한 워드 프로세서 간에 문서를 교환하는 데 사용되는 개방형 문서 형식) 및 **PDF** (인쇄용 문서를 생성하는 데 사용되는 휴대용 문서 형식). 98 | 99 | 많은 경우 이러한 표준의 오픈 소스 구현이 있어 많은 개인과 조직이 이러한 기술을 구축하고 발전시키는 데 참여할 수 있습니다. 100 | 101 | **믹싱 및 매칭** 102 | 103 | 오늘날의 기술 환경에서 이 세 가지 요소(오픈 소스, 오픈 표준, 폐쇄 소스 소프트웨어) 중 하나만 단독으로 사용되는 경우는 거의 없습니다. 104 | 105 | 대부분의 경우 Apache Web Server의 HTTP 구현과 같은 오픈 표준의 오픈 소스 구현을 경험하게 되지만 키 관리를 구현하는 암호화 소프트웨어 회사와 같이 오픈 표준을 구현하는 폐쇄 소스 소프트웨어의 인스턴스도 찾을 수 있습니다. 키 관리 상호 운용성 프로토콜(KMIP) 표준으로 많은 공급업체 및 기타 오픈 소스 소프트웨어 간의 상호 운용성을 허용합니다. 106 | 107 | Windows 및 Mac OS X와 ​​같은 폐쇄 소스 운영 체제에서 인기 있는 오픈 소스 Firefox 브라우저를 사용하는 사람들의 경우와 같이 오픈 소스 소프트웨어와 함께 사용되는 폐쇄 소스 소프트웨어도 볼 수 있습니다. Linux와 같은 오픈 소스 운영 체제도 증권 거래소 애플리케이션 및 기타 금융 소프트웨어와 같은 폐쇄 소스 애플리케이션을 실행합니다. 108 | 109 | # 섹션: 오픈 소스 소프트웨어의 짧은 역사 110 | 111 | ## 수업: 소개 112 | 113 | ### 섹션 개요 114 | 115 | 이 섹션에서 우리는 자유 소프트웨어 운동의 뿌리와 오픈 소스 소프트웨어의 후속 탄생에 대한 간략한 개요를 제공할 것입니다. 우리는 실용주의와 이상주의가 어떻게 조직에서 비즈니스 및 기술 전략의 중요한 구성 요소가 되는 오픈 소스로 작용했는지에 대한 논의를 포함할 것입니다. 이 공간에서 열린 표준 플레이의 진화에 대한 짧은 토론도 있을 것입니다. 116 | 117 | ### 학습 목표 118 | 119 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 120 | 121 | * 자유 소프트웨어 운동이 어떻게 오픈 소스를 탄생시켰는지 설명하십시오. 122 | 123 | * 이상주의 대 실용주의 개념이 오픈 소스 채택에 어떤 영향을 미쳤는지 설명하십시오. 124 | 125 | * 이상주의 대 실용주의 개념이 오픈 소스 채택에 어떤 영향을 미쳤는지 설명하십시오. 126 | 127 | ## 수업: 무료 소프트웨어 및 오픈 소스 128 | 129 | ### 길고 유서 깊은 역사 130 | 131 | 소프트웨어의 공유는 컴퓨터 시대의 시작부터 계속되었습니다. 사실, 소프트웨어를 공유하지 않는 것은 예외일 뿐 규칙은 아닙니다. **오픈 소스 소프트웨어(OSS)** 의 개념은 이 용어의 사용보다 오래 전에 사용되었습니다. 소프트웨어 초창기의 자세한 역사를 보려면 [Wikipedia](https://en.wikipedia.org/wiki/History_of_free_and_open-source_software)를 포함하여 확인할 수 있는 많은 리소스가 있지만 여기서는 압축된 버전을 제공합니다. 이 진화의 특정 세부 사항에 대해 많은 의견 불일치가 있지만 기본 일정을 이해하는 것이 중요합니다. 132 | 133 | 컴퓨팅 초창기(1950~1960년대)에 소프트웨어는 주로 초기 컴퓨터 회사에서 일하는 학계와 기업 연구원에 의해 생산되었습니다. 작성하는 것은 어렵고 시간이 많이 걸리며 일반적으로 **public-domain** 의 작품으로 공유됩니다 . 이 작품은 개별 작가나 예술가의 소유가 아닙니다. 누구나 허가 없이 **public-domain** 저작물을 사용할 수 있지만 누구도 소유할 수 없습니다. 소프트웨어를 실행하려면 특수(고가의) 컴퓨터 하드웨어가 필요했기 때문에 소프트웨어는 그 자체로 상품으로 간주되지 않았습니다. 134 | 135 | 1960년대 후반에 컴퓨터 운영 체제와 컴파일러 기술이 다양한 컴퓨터 플랫폼에서 실행되는 효과적인 소프트웨어를 구축하는 것이 덜 번거롭게 되면서 상황이 바뀌기 시작했습니다. 이것은 소프트웨어 전용 회사의 부상으로 직접 이어졌고 1974년 소프트웨어가 저작권의 권리를 획득하면서 소프트웨어가 이 회사들이 보호하기 위해 싸운 중요한 상품이 되기 위해 주사위가 던져졌습니다. 136 | 137 | 1970년대 후반과 1980년대 초반에는 사람이 읽을 수 있는 소스 코드 없이 기계가 읽을 수 있는 코드만 배포하는 추세가 증가했습니다. 1980년대 초, MIT 연구원 Richard Stallman은 GNU 운영 체제(나중에 인기 있는 Linux 커널에 영감을 줌)가 될 것을 작성하는 프로젝트를 시작했습니다. 이 기간 동안 그는 자유 소프트웨어 재단(Free Software Foundation)을 설립하고 자유 소프트웨어 정의([Free Software Definition](https://en.wikipedia.org/wiki/The_Free_Software_Definition)) 를 작성하여 MIT에서 만든 소프트웨어에 대한 통제권을 변경하고 채택한 기업의 이익을 되돌려 받았습니다. 138 | 139 | 자유 소프트웨어 재단의 명성에 대한 다른 주요 주장은 '카피레프트' 개념을 사용하여 자유 소프트웨어를 받는 사용자가 자유 소프트웨어에 대한 변경 사항을 사용할 수 있도록 요구하는 GNU 공중 사용 허가서(GPL)의 생성입니다. Linus Torvalds(리눅스 운영 체제의 창시자)는 1991년 GPL 라이선스가 있는 첫 번째 커널을 출시했습니다. 우리가 이제 알다시피, 그것은 세계 기술의 상당 부분을 위한 기초가 되었습니다. 140 | 141 | 1997년 Eric S. Raymond 는 이전 학계의 해커 커뮤니티와 자유 소프트웨어 원칙에 대한 분석인 The Cathedral & The Bazaar를 출판 했는데, 이는 1998년에 '오픈 소스'라는 용어를 만든 Christine Peterson을 비롯한 여러 업계 및 자유 소프트웨어 개인의 전략 회의로 이어졌습니다. 소프트웨어.' 다음 섹션에서는 이러한 '브랜드' 변경의 이유를 살펴보겠습니다. 142 | 143 | ### 실용주의 대 이상주의 144 | '자유 소프트웨어'와 '오픈 소스 소프트웨어' 사이의 명명 논쟁의 중심에는 영어의 기이함이 있습니다. 특히 '무료'의 두 가지 다른 의미는 다음과 같습니다.: 145 | 146 | * 언론의 자유, 배포의 자유 147 | 148 | * 무료 또는 "무료 맥주"에서 흔히 말하는 무료 149 | 150 | 크리스틴 피터슨(Christine Peterson)과 '오픈 소스' 옹호에 관련된 다른 사람들은 여기에서 무료의 개념을 명확히 하려고 시도했습니다. 소스 코드가 검사, 재배포 및 수정을 위해 공개될 것임을 분명히 했습니다. 더 많은 기업이 이러한 소프트웨어 에코시스템에 참여함에 따라 오픈 소스가 주목을 받았는데, 이는 주로 '자유' 소프트웨어가 '전문적으로' 개발한 코드만큼 가치가 없다는 인식 때문이었습니다. 실제로 양질의 오픈 소스 소프트웨어의 양은 계속 증가할 뿐이며 대부분이 전문적으로 개발되었습니다 151 | 152 | 기업의 참여가 증가하면서 Free Software Foundation 옹호자와 오픈 소스 커뮤니티의 세계관이 분기되었습니다. 특히, 이것은 이상주의 대 실용주의를 중심으로 합니다. 153 | 154 | **이상주의** 155 | 156 | 여기서 "free"는 맥주가 아닌 자유를 의미합니다. 모든 소프트웨어는 기술적인 이유가 아니라 이념적, 윤리적 이유로 열려 있어야 한다는 깊은 믿음이 있습니다. 157 | 158 | **실용주의** 159 | 160 | 여기에서 주요 고려 사항은 더 많은 기여자와 검토자가 참여하는 더 빠르고 더 나은 개발, 더 쉬운 디버깅 등을 포함한 기술적인 고려 사항입니다. 161 | 162 | 보다 이데올로기적인 관점에는 강력한 기술적 요구 사항도 있으며 많은 경우 두 흐름의 목표가 일치한다는 점에 유의하는 것이 중요합니다. 예를 들어: 163 | 164 | * 생명을 구하는 의료 기기(예: 심박 조율기 또는 인슐린 펌프)를 구동하는 소프트웨어는 비밀이어야 합니까? 우리는 그러한 장치를 제어하는 ​​것이 무엇인지 알 권리가 없습니까? 그들이 우리를 죽일 수 있는 외부 공격에 취약하지 않다는 것을 어떻게 알 수 있습니까? 165 | 166 | * 투표 기계에 전원을 공급하는 소프트웨어를 닫아야 합니까? 표로 작성된 결과의 무결성을 존중할 수 있다고 어떻게 확신할 수 있습니까? 이것은 실험 후 실험에서 폐쇄형 소스 투표 기계가 보안 취약점으로 가득 찬 것으로 나타났을 때 특히 사실입니다. 167 | 168 | 불행하게도, 오픈 소스에 대한 이 두 가지 태도 사이의 갈등은 종종 가혹하고 파괴적이었습니다. 끝날 것 같지 않습니다. 그러나 실용주의적 접근 방식은 기업의 인수로 인해 대부분의 경제적 자원을 뒷받침하고 있으며, 더 철학적인 진영은 항상 지지자를 결정한다는 점에 주목하는 것이 중요합니다. 오픈 소스 작업의 대부분은 이 두 극단 사이의 어딘가에서 발생하지만 각각이 가치 있는 경계를 제공하기 위해 존재하는 것이 중요합니다. 169 | 170 | ### 오픈 표준의 진화 171 | 172 | 여러 면에서 표준의 진화는 자유 소프트웨어에서 오픈 소스로의 진화를 반영합니다. 이 경우 폐쇄 표준, *사실상* 표준, 오픈 표준의 세 가지 표준이 발전하기 시작했습니다. 173 | 174 | 비오픈 표준은 공개적으로 사용할 수 없으며 구현자가 제3자에게 로열티를 지불하도록 요구하거나 둘 다입니다. 예를 들어, 4G, Bluetooth 또는 WiFi를 포함하여 일반인이 인식하는 가장 일반적인 무선 표준은 폐쇄형 표준입니다. 이러한 표준에는 액세스 또는 지적 재산권 조건에 의해 제한되는 사양이 있습니다. 175 | 176 | 소프트웨어 시장이 성장하기 시작하고 고객이 해결하는 문제의 종류가 너무 커서 여러 전문 분야가 필요하게 되면서 상호 운용성이 모든 비즈니스의 핵심 요구 사항이 될 것이 분명해졌습니다. 177 | 178 | 고객은 문제를 해결할 수 있는 동급 최고의 솔루션을 제공하는 이기종 시스템을 허용하도록 공급업체에 압력을 가하기 시작했습니다. 이를 가능하게 하기 위해 오픈 표준이 개발되기 시작하여 많은 사람들이 응용 프로그램과 시스템 간에 데이터를 효과적으로 이동하는 방법에 대해 협력할 수 있었습니다. 일부 오픈 표준은 의도적인 표준으로 시작되지 않았습니다. 일부는 광범위한 채택을 통해 *사실상* 표준이 된 오픈 소스 프로젝트로 시작했습니다 . 가장 일반적인 예는 Linux가 세계 상위 500대 슈퍼컴퓨터의 100%를 구동하는 고성능 컴퓨팅과 같은 장치 클래스에 대한 사실상의 표준이 된 Linux 커널입니다. 179 | 180 | 여기에 나열하기에는 너무 많은 오픈 표준이 있지만 [Wikipedia](https://en.wikipedia.org/wiki/Open_standard) 에서 합리적으로 좋은 목록을 찾을 수 있습니다 . 그 목록을 자세히 살펴보면 여러분이 알고 있는 것(TCP/IP, PDF)과 의존하지만 많이 알지 못하는 것(HTML, USB)을 찾을 수 있습니다. 181 | 182 | ### 역사는 항상 일어나고 있다 183 | 184 | 이러한 역사적 배경을 제공하는 주된 이유는 이전에 있었던 일을 알려주는 동시에 소프트웨어 및 기술 산업에서 어떤 것도 고정되어 있지 않다는 것을 상징하기 때문입니다. 자유 소프트웨어의 이상주의적 측면과 실용주의보다 상업적인 가치 사이의 균형에 대한 질문은 항상 있을 것입니다. 185 | 186 | 또한 컴퓨팅의 윤리적 측면과 이것이 라이선스에서 지적 재산 및 협업 모델에 이르기까지 모든 것에 영향을 미치는 방식에 대해 생각하는 움직임이 커지고 있습니다. 187 | 188 | 우리가 오픈 소스와 오픈 표준에서 어디에서 왔는지 이해하면 미래에 어디로 가야 하는지 적절하게 평가할 수 있는 컨텍스트를 얻을 수 있습니다. 189 | 190 | # 섹션: 오픈 소스를 사용하는 이유 191 | 192 | ## 수업: 소개 193 | 194 | ### 섹션 개요 195 | 196 | 이 섹션에서는 오픈 소스의 커뮤니티 및 협업 모델이 엔터프라이즈급 소프트웨어의 지속적이고 효율적인 개발을 보장하는 방법에 대한 개요를 제공합니다. 또한 가치 향상을 위해 오픈 소스와 오픈 표준을 효과적으로 결합할 수 있는 몇 가지 잠재적인 방법에 대해서도 논의할 것입니다. 197 | 198 | ### 학습 목표 199 | 200 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 201 | 202 | * 오픈 소스의 커뮤니티 및 협업 모델을 설명합니다. 203 | 204 | * 오픈 소스가 기업에 가치를 제공하는 확실한 비즈니스 이유를 설명하십시오. 205 | 206 | * 기술 솔루션의 전반적인 가치를 높이기 위해 오픈 소스와 오픈 표준을 결합하는 방법을 설명합니다. 207 | 208 | ## 수업: 오픈 소스 및 표준을 사용해야 하는 이유 209 | 210 | ### 오픈 소스 커뮤니티란 무엇입니까? 211 | 212 | 마법처럼 모든 오픈 소스 개발을 가능하게 하는 신화적인 '오픈 소스 커뮤니티'는 없습니다. 다양한 유형의 문화를 가진 다양한 오픈 소스 커뮤니티가 있습니다. 그러나 커뮤니티 구성은 학계/기업/공유/해커 사고방식에 뿌리를 둔 초기 컴퓨터 시대로 거슬러 올라갑니다. 거의 모든 커뮤니티에는 다음과 같은 주요 특성이 있습니다: 213 | 214 | * 개발 자원의 지리적 분포 215 | 216 | * 분산된 의사 결정 기능 217 | 218 | * 개발 및 의사 결정의 투명성 219 | 220 | * 능력주의 - 지속적인 가치 있는 기여를 통해 영향력을 얻습니다. 221 | 222 | 또한, 대부분의 커뮤니티는 느슨한 수평 구조와 함께 긴밀한 수직 계층 구조를 나타냅니다. 이 구조를 통해 작은 변경 사항(오픈 소스의 공용어)이 위쪽으로 흐르게 하고 상당한 '견제와 균형' 세트를 제공하는 많은 빠른 검토 주기를 거칩니다. 소프트웨어 품질을 보장하는 데 도움이 됩니다. 223 | 224 | 커뮤니티 조직 구조의 예: 225 | 226 | ![image alt text](community-org-structure.png) 227 | 228 | ### 이 모델은 다른 개발 모델과 어떻게 다릅니까? 229 | 230 | 기술 기업 내부의 최신 소프트웨어 개발 팀은 위에 설명된 '애자일' 원칙 중 일부를 공유할 수 있지만 일반적으로 몇 가지 중요한 차이점이 있습니다. 이러한 차이는 좋지도 나쁘지도 않으며 종종 매우 좋은 이유로 존재합니다. 그러나 더 많은 오픈 소스 커뮤니티 참여를 향한 여정을 시작하는 조직에 도전 과제를 제공합니다. 231 | 232 | 다음은 기업 개발 팀과 다른 오픈 소스 소프트웨어 프로젝트의 가장 중요한 몇 가지 사례입니다: 233 | 234 | * 영향력과 위상은 직위나 지위가 전달되지 않습니다. - 능력주의가 그 날을 지배합니다. 235 | 236 | * 소스 코드와 의사 결정 모두의 투명성이 가장 중요합니다. - 부수적인 대화나 결정이 없습니다. 237 | 238 | * 지리적으로 분산된 팀에 대한 지원이 기본 제공됩니다. - 비동기식 커뮤니케이션 및 문화 모드가 표준입니다. 239 | 240 | 일부 조직에서는 제공하는 속도와 유연성을 활용하기 위해 오픈 소스 커뮤니티의 교훈을 자체 내부 노력('내부 소스'로 알려진 관행)에 적용했습니다. 이렇게 하면 업스트림 오픈 소스 생태계에 더 쉽게 참여할 수 있는 필요한 제도적 문화를 구축하는 데 도움이 될 수 있습니다. 241 | 242 | ### 비즈니스 관점 243 | 244 | 이제 커뮤니티 개발 모델이 어떻게 보이는지 약간 다루었으므로 모든 규모의 기업이 실제 문제를 해결하는 데 도움이 되는 가치 있는 기술 도구로 오픈 소스를 선택한 몇 가지 이유를 살펴보겠습니다. 245 | 246 | 기업 내에서 오픈 소스를 사용하면 다음과 같은 이점이 있습니다: 247 | 248 | * 속도 249 | 250 | * 비용 절감 251 | 252 | * 커스터마이징 가능 253 | 254 | * 혁신 255 | 256 | * 보안 257 | 258 | * 비즈니스 이점 259 | 260 | * 라이선스의 유연성 261 | 262 | 다음 몇 섹션에서 이들 각각을 다룰 것입니다. 263 | 264 | ### 오픈 소스는 어떻게 개발을 가속화합니까? 265 | 266 | 오픈 소스 소프트웨어는 소프트웨어 개발 주기를 가속화하는 데 중요한 역할을 하는 것으로 입증되었습니다. 가장 눈에 띄는 예 중 하나는 6-12개월 주기로 주요 신제품이 출시되는 모바일 장치 시장입니다. 오픈 소스는 빠른 진화 제공에 필수적입니다. 267 | 268 | 그렇다면 오픈 소스가 개발 속도를 높이는 방법은 정확히 무엇입니까? 269 | 270 | * 오픈 소스 소프트웨어 획득은 구매 주문, 계약, SOW 또는 라이선스 협상 없이 시작하는 것이 더 빠르고 쉽습니다. 271 | 272 | * 오픈 소스 배포는 일반적으로 훨씬 빠릅니다. 너무 길고 번거로운 상용 설치, 구성 및 구현 주기와 달리 오픈 소스는 `다운로드 후 실행`하는 문화에서 비롯됩니다. 273 | 274 | * 주요 오픈 소스 프로젝트는 수익 중심 관리 대신 커뮤니티 중심 기능으로 더 빠르게 진화하고 있습니다. 오픈 소스의 빠른 의사 결정(종종 [게으른 합의](http://community.apache.org/committers/lazyConsensus.html)의 한 형태)을 통해 프로젝트는 새로운 기능과 수정 사항을 매우 빠르게 통합할 수 있습니다. 275 | 276 | * 광범위한 커뮤니티 테스트를 거치기 때문에 성숙한 오픈 소스의 품질이 더 높은 경우가 많습니다. 실제로 [Forrester Research 연구](https://fossbazaar.org/system/files/OpenSourceForTheNextGenerationOfEnterpriseIT.pdf)에 따르면 소프트웨어 품질은 92%의 경우 기대치를 충족하거나 초과했습니다. 277 | 278 | * 오픈 소스는 소스 코드, 협업 커뮤니티, 인터페이스 및 도구를 사용한 사용자 정의를 지원합니다. 279 | 280 | * 혁신적인 제공 방식을 통해 오픈 소스는 일반적으로 몇 주 또는 몇 개월이 아닌 몇 시간 만에 가동되고 실행됩니다. 281 | 282 | ### 오픈 소스가 더 저렴한 이유는 무엇입니까? 283 | 284 | 오픈 소스 소프트웨어를 사용하면 여러 입증된 방법으로 개발 비용을 크게 줄일 수 있습니다: 285 | 286 | * 최근 [Red Hat 연구](https://www.redhat.com/cms/managed-files/rh-enterprise-open-source-report-detail-f21756-202002-en.pdf)에 따르면 오픈 소스는 상용/폐쇄 소스 솔루션에 비해 총 소유 비용이 30% 더 낮습니다. 287 | 288 | * 오픈 소스를 사용하면 과도한 기능을 피할 수 있습니다. 많은 폐쇄형 소스 제품에는 클라이언트가 거의 사용하지 않거나 필요로 하거나 원하지 않는 기능이 과부하되어 있습니다. 그리고 그들은 종종 번들로 제공되어 어쨌든 지불해야 합니다. 289 | 290 | * 오픈 소스는 공급업체 종속을 방지하고 경쟁을 촉진합니다. 상용 오픈 소스 공급업체가 활용되는 경우에도 응용 프로그램을 변경하지 않고 자유롭게 공급업체를 전환하거나 지원을 중단할 수 있습니다. 291 | 292 | * 오픈 소스는 기술에 대한 독점적인 액세스가 없기 때문에 컨설팅, 교육 및 지원 비용도 지원합니다. 종종 공급업체로부터 다중 소스 지원을 받거나 활기찬 개발자 커뮤니티로부터 지원을 받을 수도 있습니다. 많은 회사에서 커뮤니티에서 개발자를 고용하여 구현을 지원하고 업스트림 프로젝트에 수정 사항을 제공합니다. 293 | 294 | * 활동적인 커뮤니티는 상용 지원 계약보다 더 높은 품질의 지원을 제공하는 경우가 많으며 무료입니다. 295 | 296 | ### 오픈 소스가 더 유연한 이유는 무엇입니까? 297 | 298 | 오픈 소스는 타사 소프트웨어 대안 중 가장 높은 유연성을 제공합니다: 299 | 300 | * 오픈 소스를 사용하면 공급업체, 비용, 구매 구조 또는 재배포 조건에 얽매이지 않습니다. 오픈 소스는 벤더 독립성과 경쟁력 있는 옵션을 가능하게 합니다. 301 | 302 | * 오픈 소스는 배포에 대해 매우 자유로운 계약상 제한이 있는 경우가 많으므로 플랫폼, 사용자 수, 프로세서 수에 대해 최대한의 유연성을 가질 수 있습니다. 303 | 304 | * 소스 코드에 액세스할 수 있으므로 필요한 사용자 지정을 만들 수 있으며 다른 사용자에게 가치가 있는 경우 커뮤니티에서 향후 릴리스에서 이를 지원할 수 있습니다. 305 | 306 | * 오픈 소스 커뮤니티는 특정 사용 사례에 대한 솔루션을 확장하거나 다른 제품과 통합하기 쉽게 하는 사용자 지정을 장려하고 촉진합니다. 307 | 308 | * 건강한 오픈 소스 커뮤니티는 지속적인 지원을 제공하고 개선을 위한 의견과 제안을 장려합니다. 309 | 310 | ### 오픈 소스는 혁신을 어떻게 지원합니까? 311 | 312 | 오픈 소스 소프트웨어는 원래 협업을 통해 개발과 혁신을 촉진하는 방법으로 생각되었습니다. 313 | 314 | 오픈 소스 접근 방식은 혁신에 매우 효과적인 것으로 입증되어 많은 첨단 소프트웨어 기술이 오픈 소스 커뮤니티에 의해 주도되고 있습니다. 예를 들어: 315 | 316 | * 인터넷은 주로 오픈 소스 프로젝트의 대규모 모음으로 개발되었습니다. 317 | 318 | * 소프트웨어 개발 도구 혁신 및 통합은 대부분 오픈 소스 영역입니다. 319 | 320 | * 모바일 통신 분야의 놀라운 혁신 속도는 오픈 소스를 통해서만 가능합니다. Android가 주요 예이지만 Apple의 iOS와 같은 폐쇄 소스 플랫폼도 수백 개의 오픈 소스 소프트웨어 라이브러리 및 구성 요소를 사용하여 대부분 구축됩니다. 321 | 322 | * 인터넷의 나머지 부분과 마찬가지로 소셜 미디어 소프트웨어 플랫폼은 오픈 소스 소프트웨어에서 등장하고 이를 통해 성장했습니다. 323 | 324 | * 과학 컴퓨팅과 대규모 병렬 컴퓨팅의 영역은 거의 독점적으로 오픈 소스 영역입니다. 325 | 326 | 많은 오픈 소스 커뮤니티는 참여를 통해 활용하여 혁신을 가속화할 수 있는 급속한 발전을 보여줍니다. 상향식 능력주의의 오픈 소스 정신은 소유권과 책임을 개발 팀으로 되돌립니다. 327 | 328 | 새로운 소프트웨어 아이디어를 도입하고, 새로운 기능을 테스트하고, 활성 사용자 기반을 확장하는 가장 좋은 방법 중 하나는 오픈 소스 커뮤니티를 이용하는 것입니다. 329 | 330 | 마지막으로 오픈 소스가 가능하게 하는 혁신은 단순한 기술 혁신이 아닙니다. 오픈 소스 라이선스에서 계약상의 제약이 없기 때문에 창의적이고 새로운 사용, 새로운 배포 계획, 유연하고 창의적인 패키징 및 가격 접근 방식, 기타 형태의 비즈니스 및 시장 혁신이 가능합니다. 331 | 332 | ### 오픈 소스 소프트웨어의 보안 이점은 무엇입니까? 333 | 334 | 불행히도 공격자들은 전 세계의 소프트웨어 시스템을 표적으로 삼고 공격하고 있습니다. 오픈 소스 소프트웨어나 폐쇄 소스 소프트웨어 모두 항상 더 안전하지는 않습니다. 보안은 소프트웨어의 설계, 구현, 검증(테스트 포함) 및 배포 방법과 같은 여러 요소에 따라 달라집니다. 335 | 336 | 그러나 오픈 소스 소프트웨어는 폐쇄 소스 소프트웨어에 비해 *잠재적인* 근본적인 보안 이점이 있습니다. 보안 소프트웨어 설계의 핵심 원칙 중 하나는 "개방형 설계"입니다. 즉, 보안 소프트웨어 설계는 모든 사람이 보호 메커니즘이 작동하는 방식을 알고 있다고 가정해야 합니다. 이렇게 하면 전 세계적으로 대규모 피어 리뷰를 통해 보안 취약점을 찾아 소프트웨어가 배포되기 전에 수정할 수 있습니다. 337 | 338 | 물론 가능성이 항상 실현되는 것은 아닙니다. 보안을 유지하려면 오픈 소스 소프트웨어 프로젝트를 보안을 염두에 두고 개발하고 실제로 검토하고 소프트웨어를 배포하기 전에 이러한 문제를 수정해야 합니다. 많은 오픈 소스 소프트웨어 프로젝트는 이미 이러한 잠재적 이점을 활용하기 위한 조치를 취하고 있으며 Linux Foundation은 다양한 오픈 소스 소프트웨어 프로젝트와 협력하여 이러한 이점을 활용할 수 있도록 돕고 있습니다. 339 | 340 | ### 오픈 소스는 어떻게 비즈니스 이점을 제공합니까? 341 | 342 | 위의 모든 요소는 조직의 소프트웨어 경쟁 우위에 추가됩니다. 343 | 344 | * 오늘날과 같이 빠르게 진화하는 시장에서 가장 저렴한 비용으로 가장 빠르게 소프트웨어 솔루션을 지속적으로 생산하는 회사가 승리합니다. 345 | 346 | * 이 시점에서 오픈 소스 소프트웨어는 오픈 소스를 효과적으로 **사용하지 않으면** 조직이 불리한 위치에 놓이게 될 정도로 주류 현상이 되었습니다. 347 | 348 | 리서치 회사 Gartner는 오픈 소스에 대해 다음과 같이 말했습니다: 349 | 350 | "**오픈 소스는 유비쿼터스이며 불가피합니다…** 오픈 소스에 반대하는 정책을 갖는 것은 비현실적이며 **경쟁에서 불리합니다**. 351 | 352 | 최근 [McKinsey & Co. 보고서](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/developer-velocity-how-software-excellence-fuels-business-performance)에 따르면 업계 상위 4분위 기업의 "가장 큰 차별화 요소"는 사용자에서 기여자로 전환한 "오픈 소스 채택"이었습니다. 보고서의 데이터에 따르면 상위 4분위 기업의 오픈 소스 채택은 다른 4분위 기업보다 혁신에 3배의 영향을 미칩니다. 353 | 354 | ### 오픈 소스와 오픈 표준 연결 355 | 356 | 지난 몇 년 동안 표준 세계와 더 나은 협력 방법을 찾으려는 오픈 소스 생태계의 추세가 증가했습니다. 때때로 문제가 있지만(주로 두 그룹의 실행 속도 불일치와 관련하여), 둘 사이의 긴밀한 관계를 계속 옹호해야 하는 충분한 이유가 있습니다. 357 | 358 | 이것이 이미 작동했거나 이미 작동한 프로젝트의 몇 가지 좋은 예가 있습니다.: 359 | 360 | * Linux Foundation의 JDF([Joint Development Foundation](https://www.jointdevelopment.org/)) 노력 - 특히 GraphQL 361 | 362 | * 사이버 위협 데이터 공유를 위한 기존 오픈 표준의 오픈 소스 참조 구현을 제공하는 OASIS Open의 [Open Cybersecurity Alliance](https://opencybersecurityalliance.org/) 363 | 364 | * [IETF](https://www.ietf.org/)의 "거친 합의 및 코드 실행"의 만트라는 OpenDaylight, OPNFV, OpenStack 등과 같은 오픈 소스 프로젝트와 협력하는 많은 오픈 표준으로 이어졌습니다. 365 | 366 | 표준과 오픈 소스는 서로 다른 속도로 움직이고 서로 다른 방식으로 상호 운용성을 위해 노력하지만 오픈 표준의 오픈 소스 구현을 구축할 수 있다는 것은 전통적으로 주로 표준에 의존해 온 고객 공급망에서 더 많은 오픈 소스 사용을 유도하는 데 도움이 됩니다. 예를 들어, 금융 및 NGO. 367 | 368 | 또한 표준을 지원함으로써 오픈 소스 생태계는 폐쇄형 소스 소프트웨어와도 상호 운용할 수 있는 능력을 갖게 되어 기업에 더 많은 선택권과 유연성을 제공합니다. 369 | 370 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /module7/README.md: -------------------------------------------------------------------------------- 1 | # 오픈 소스 프로젝트 생성 개요 2 | 3 | ## 수업: 소개 4 | 5 | ### 섹션 개요 6 | 7 | 이 섹션에서는 새로운 오픈 소스 프로젝트를 만드는 근거와 가치 제안을 살펴보겠습니다. 새로운 오픈 소스 프로젝트를 만들어야 하는 좋은 이유와 나쁜 이유, 그리고 새 프로젝트의 비즈니스 잠재력을 평가하는 방법에 대해 논의하는 데 시간을 할애할 것입니다. 8 | 9 | ### 학습 목표 10 | 11 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 12 | 13 | * 오픈 소스 내부 코드 또는 처음부터 새로운 오픈 소스 프로젝트 생성에 대한 가치 제안 설명 14 | * 소스 코드를 공개해야 하는 이유에 대한 좋은 예와 나쁜 예를 제시하십시오. 15 | * 새로운 오픈 소스 프로젝트의 비즈니스 잠재력을 평가하는 방법 설명 16 | 17 | ## 수업: 어디서부터 시작해야 할까요? 18 | 19 | ### 올바른 질문을 하세요 20 | 21 | 새로운 오픈 소스 프로젝트를 만드는 여정을 시작하기 전에 올바른 질문을 하는 것이 중요합니다. 회사의 고유한 상황에 따라 고려해야 할 몇 가지 추가 특정 질문이 있을 수 있지만 다음 그림은 질문할 내용을 파악하는 데 도움이 되는 좋은 출발점이 될 것입니다. 22 | 23 | ![오픈소싱 프로젝트 전 물어볼 질문](questions-to-ask.png) 24 | 25 | 이 그래픽의 맨 윗줄은 실제로 오픈 소스 프로젝트를 생성하기 위한 가치 제안이 무엇인지 이해하는 문제를 다룹니다. 첫 번째 질문은 불행히도 충분히 자주 묻지 않는 질문입니다. 다른 오픈 소스 프로젝트를 만들어야 하는지 여부를 심각하게 평가해야 합니다. 수천 개의 프로젝트가 존재합니다. 귀하의 코드가 그 자체로 차별화된 가치를 제공할 것입니까, 아니면 확립되고 성공적인 오픈 소스 프로젝트를 훨씬 더 좋게 만드는 것이 더 나을까요? 26 | 27 | 조직에서 오픈 소스 개발 모델(이 과정 시리즈의 이전 섹션에서 다뤘음)을 이해하고 해당 구조로 프로젝트를 구축하는 데 전념하고 있다면 프로젝트를 시작하기로 결정하기 전에 **성공적인 요소를 평가해야 합니다. 사용할 측정항목입니다. 홍보 목적으로 프로젝트를 생성하거나 시작된 오픈 소스 프로젝트 수에 대한 내부 지표를 개선하는 것만으로는 일반적으로 프로젝트가 실패하게 됩니다. 28 | 29 | 두 번째 질문 행은 새로운 오픈 소스 프로젝트에서 가치를 구축할 수 있는 조직과 커뮤니티의 능력에 더 중점을 둡니다. 너무 많은 회사가 내부 재정 및 엔지니어링 투자 없이 방화벽을 넘어 단순히 코드를 던지는 전략을 시도했지만 실패했습니다. 30 | 31 | 시간을 내어 잠재적인 새로운 오픈 소스 프로젝트를 성공적으로 만드는 방법을 고려하십시오. 오픈 소스 프로젝트를 만드는 것이 특정 코드에 적합하지 않다는 결론에 도달해도 괜찮습니다. 오픈 소스 에코시스템에 참여하거나 다른 오픈 소스 프로젝트에 귀하의 기술을 기여할 수 있는 많은 기회가 있습니다. 32 | 33 | ### 오픈 소스는 무엇입니까? 34 | 35 | 업스트림 오픈 소스 커뮤니티에 무엇을 다시 기여할 것인지 결정해야 하는 것과 마찬가지로(이 시리즈의 이전 과정에서), 처음에 공개 상태에서 어떤 코드 또는 기술을 구축할지 또는 어떤 독점 코드를 만들 것인지에 대한 결정' ll 릴리스는 중요한 것입니다. 다음은 이 선택을 고려하는 데 도움이 될 수 있는 몇 가지 기준입니다. 36 | 37 | * 제품의 어떤 부분이 전략적 이점의 원천인지, 그리고 단순히 이러한 부분을 지원하는 부분을 결정합니다. 38 | * 비전략적 부분은 종종 오픈 소스 프로젝트를 만들기 위한 훌륭한 후보입니다. 39 | * 다른 회사도 같은 느낌을 받을 가능성이 높으며 새로운 프로젝트를 유지하고 발전시키는 데 도움이 될 수 있습니다. 40 | 41 | 예: 42 | 43 | * 업계에서 널리 사용되는 파일 시스템 또는 파일 형식 44 | * 연결된 IoT 장치를 위한 네트워크 스택 45 | 46 | 시작할 수 있는 또 다른 장소는 기업이 권위자가 될 필요가 없고 문제 해결을 도울 수 있는 전 세계의 더 많은 기술자 그룹이 있을 수 있는 2차 코딩 프로젝트를 포함합니다. 미션 크리티컬 코드가 아닌 경우 오픈 소스로 사용할 수 있는 좋은 후보입니다. 그러나 회사에서 여전히 적극적으로 사용하고 유지 관리하는 코드여야 합니다. 코드에 대한 상업적 종속성은 버그 수정, 패치 및 새로운 기능에 대한 지속적인 피드백 루프를 가능하게 합니다. 47 | 48 | 49 | ### 오픈 소스 프로젝트를 생성할 때 50 | 51 | 새로운 오픈 소스 프로젝트를 출시하거나 생성하기로 결정하는 것은 상황에 따라 다릅니다. 회사는 먼저 오픈 소스 소프트웨어를 사용하고 기존 프로젝트에 기여하여 일정 수준의 오픈 소스 숙달을 달성해야 합니다(이 시리즈의 이전 과정에서 다루었음). 52 | 53 | 오픈 소스를 사용하는 방법을 이해하면 외부 프로젝트와 개발자를 활용하여 제품을 구축하는 방법을 배울 수 있습니다. 참여하면 오픈 소스 커뮤니티의 관습과 문화에 더 유창해질 수 있습니다. 그러나 오픈 소스에 능숙해지면 자신의 오픈 소스 프로젝트를 시작하기에 가장 좋은 시기는 단순히 "초기" 및 "자주"입니다. 54 | 55 | ![일찍 릴리스 자주 릴리스](release-early.png) 56 | 57 | 이 그래픽은 이 코스워크 시리즈의 _오픈 소스 개발 사례_ 부분에서 다룬 내용에 대한 약간의 알림입니다. 오픈 소스에 다시 기여할 때뿐만 아니라 첫 번째 새로운 오픈 소스 프로젝트를 고려할 때도 중요합니다. 58 | 59 | 첫 번째 오픈 소스 프로젝트를 만들기 전에 모든 것이 절대적으로 완벽할 필요는 없습니다. 프로세스, 법적 검토 등의 측면에서 몇 가지 최소 사항이 있지만(곧 다룰 예정임), 시작하기 위해 코드와 거버넌스 모두에 필요한 최소 사항을 구축하면 더 일찍 참여하고 더 일찍 피드백을 받아 발전할 수 있습니다. 당신의 새로운 프로젝트. 60 | 61 | 첫 번째 프로젝트를 만들기 전에 오픈 소스 프로젝트를 만드는 좋은(그리고 나쁜) 이유에 대해 논의해야 합니다. 62 | 63 | ### 오픈 소스 프로젝트를 만들어야 하는 좋은 이유 64 | 65 | ![오픈 소스 프로젝트를 만들어야 하는 좋은 이유](good-reasons-to-opensource.png) 66 | 67 | 이 그래픽은 오픈 소스 프로젝트를 시작해야 하는 5가지 이유를 보여줍니다. 모두 비즈니스 목표로 돌아가지만 처음 두 가지는 시장에서 고유한 비즈니스 이점을 얻는 것과 관련이 있습니다. 그러나 이러한 '선도자' 비즈니스 이점은 커뮤니티의 나머지 구성원이 귀하가 오픈 소스로 제공한 기술에 익숙해질 때까지 일시적(6-10개월)일 수 있다는 점에 유의하는 것이 중요합니다. 68 | 69 | 세 번째 및 네 번째 항목은 고객의 참여를 유도하고 비오픈 소스 제품의 가치를 구축하는 데 중점을 둡니다. 오픈 소싱 코드에서 가치를 제공하는 것은 결과적으로 제품을 더 좋게 만드는 것임을 기억하십시오. 70 | 71 | 마지막으로, 기술로 스스로를 지원할 수 있는 기술 고객(또는 개발자)이 있는 업계에 있다면 오픈 소스로 선택한 코드에 대해 추가 기술 또는 지원 리소스를 제공할 필요가 없다는 점에서 가치를 실현할 수 있습니다. 72 | 73 | ### 오픈 소스 프로젝트를 만들어야 하는 나쁜 이유 74 | 75 | 올바른 이유로 오픈 소스만큼 중요한 것은 **잘못된** 이유로 오픈 소스 프로젝트를 만들려고 하지 않도록 하는 것입니다. 오픈 소스 생태계는 좋은 의미를 지닌 조직의 실패한 프로젝트로 가득 차 있지만 단순히 코드를 오픈 소싱해야 하거나 새 프로젝트를 만들어야 하는 이유를 충분히 고려하지 않았습니다. 76 | 77 | ![오픈 소스 프로젝트를 만들어야 하는 나쁜 이유](bad-reasons-to-create-opensource.png) 78 | 79 | 다음은 새로운 오픈 소스 프로젝트를 만들어야 하는 나쁜 이유의 몇 가지 예입니다: 80 | 81 | * 구식 소프트웨어 제거 82 | * 투자할 의사가 없을 때 오픈 소스 커뮤니티에서 무료 엔지니어링을 기대합니다. 83 | * 단종 발표에 대한 긍정적인 마케팅 스핀으로 84 | * 프로젝트를 장기적으로 지원할 의도 없이 홍보 또는 마케팅 활동을 얻기 위해 85 | * 내부 성공 지표를 충족하는 수단 86 | 87 | 이 모든 것이 오픈 소스 프로젝트를 만들어야 하는 나쁜 이유가 분명하기를 바랍니다. 하지만 이들 모두의 공통점이 무엇인지 살펴보겠습니다. 내부 초점 및/또는 더 큰 오픈 소스 커뮤니티의 지원 기대입니다. 88 | 89 | 오픈 소스에서 일하는 것은 종종 (기업의 관점에서) '계몽된 자기 이익'으로 설명됩니다. 기업이 반드시 이타적인 이유로 오픈 소스와 함께 일하지 않는다는 것을 모두가 이해하기 때문에 이 경우에 해당합니다. 오픈 소스에서 진행되는 것과 일치하는 비즈니스 가치가 있어야 합니다. 그러나 위에 표시된 이유는 결국 파트너와 경쟁자로 구성된 나머지 오픈 소스 커뮤니티에 대한 불신의 씨앗을 뿌립니다. 90 | 91 | ### 오픈 소스 프로젝트의 비즈니스 잠재력 평가 92 | 93 | 모든 비즈니스 결정과 마찬가지로 오픈 소스 프로젝트를 생성해야 하는 대상, 경우 및 시기를 결정하는 것은 궁극적으로 비즈니스에 제공되는 가치로 돌아갑니다. 이러한 질문을 고려할 때 비즈니스 사례 구축 측면에서 생각하는 것이 가장 좋습니다. 94 | 95 | 먼저 회사에서 코드와 프로젝트의 소유권을 유지하면서 코드를 만들거나 릴리스할 것인지 아니면 프로젝트를 유지 관리하고 관리하기 위해 다른 사람에게 코드를 기여할 것인지 결정해야 합니다. 코드가 이미 존재하는 경우 프로젝트의 모든 코드를 릴리스할지 아니면 일부만 오픈 소스 프로젝트로 릴리스할지에 대한 관련 문제가 있습니다. 96 | 97 | 이러한 결정을 내리려면 뒤로 물러나 코드에 대해 염두에 두고 있는 목표를 결정하는 것이 좋습니다. 이 코드가 조직 외부에서 유용하고 업계에도 변화를 줄 수 있는 코드입니까? 귀사는 조직의 제품 포트폴리오를 지원하기 위해 이 기술에 대해 작업할 파트너(및/또는 경쟁업체)를 유치할 가능성이 있습니까? 98 | 99 | 예를 들어 작업의 핵심이 아닌 응용 프로그램의 일부에 대해 다른 개발자로부터 신선한 통찰력을 얻고 싶을 수 있습니다. 또는 시스템 모니터링 응용 프로그램에서 로그를 감지하기 위해 추가 실제 알고리즘을 찾을 수 있습니다. 전체 제품을 오픈 소스로 공개하는 대신 알고리즘과 관련된 코드만 공개할 수 있습니다. 이를 통해 핵심 비즈니스를 손상시키지 않으면서 다른 사람들의 기여를 얻고 유사한 도움이 필요한 다른 사람들을 도울 수 있습니다. 100 | 101 | 프로젝트를 시작하고 전반적인 제어를 유지하면 감독을 할 수 있고 필요한 것을 구체화하는 데 도움이 되는 기능을 제공하는 동시에 기여하는 개발자에게 작업을 수행할 수 있는 자유와 제어를 제공합니다. 102 | 103 | # 섹션: 새로운 프로젝트 준비 104 | 105 | ## 수업: 소개 106 | 107 | ### 섹션 개요 108 | 109 | 이 섹션에서는 법률, 비즈니스 및 커뮤니티 고려 사항에 대한 논의를 포함하여 새로운 오픈 소스 프로젝트 생성을 준비하는 방법을 살펴봅니다. 또한 성공을 위해 필요한 프로세스, 도구 및 인력 요구 사항에 대해서도 논의합니다. 110 | 111 | ### 학습 목표 112 | 113 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 114 | * 새로운 오픈 소스 프로젝트를 만들기 위한 전반적인 준비 단계를 설명합니다. 115 | * 성공적인 프로젝트 생성을 위해 필요한 프로세스, 고려 사항, 도구 및 요구 사항 이해 116 | 117 | ### 수업: 내부 준비 118 | 119 | ### 경영진 후원자 식별 120 | 121 | 성공적인 오픈 소스 프로젝트를 생성하려면 많은 투자가 필요하므로 조직의 경영진 후원자의 동의를 얻는 것이 **중요합니다**. 후원자가 두 명 이상인 경우 도움이 될 수 있지만 최소한 다음 사항을 제공하고 약속할 수 있는 사람을 목표로 해야 합니다. 122 | 123 | #### 기술 및 커뮤니티 124 | 125 | * 공개적으로 프로젝트에 대한 약속을 지속적으로 재확인 126 | * 성과에 기반한 인정 문화 조성 127 | * 중립성 확보 128 | * 다음 오픈 소스 방법 및 프로세스에 전념 129 | 130 | #### 재정적 131 | 132 | * 내부: 프로젝트 진행을 위한 충분한 개발 자금 지원 133 | * 외부: IT 리소스 및 시스템 관리자에 대한 자금 지원 134 | 135 | ### 리소스 할당 136 | 137 | 이전 페이지에서 언급한 바와 같이 경영진 후원자가 자금을 적절하게 할당하도록 해야 하지만 프로젝트를 성공시키기 위해 적절한 직원 시간을 지시할 수 있어야 합니다. 개발자 시간은 초기에 내부 코드 작업에 소비한 시간과 비슷할 것입니다. 그러나 새로운 커뮤니티의 다른 사람들이 코드베이스에 대한 속도를 높일 수 있도록 개발자가 제공해야 하는 시간, 자료 또는 도움도 고려해야 합니다. 138 | 139 | 또한 경쟁자가 포함될 수 있는 오픈 소스 프로젝트를 만드는 데 관여할 법무팀과 출시 후 프로젝트가 지원과 기여자를 얻을 수 있도록 마케팅 투자에 필요한 리소스도 있습니다. 140 | 141 | 또한 프로젝트를 시작하고 유지 관리하는 데 사용되는 인프라에 대한 예산을 설정해야 합니다. 여기에는 코드가 상주하고 유지 관리되는 GitHub와 같은 프로젝트 호스팅 및 소스 제어 웹 사이트, 버그 해결 및 기타 필요한 도구가 포함됩니다. 142 | 143 | 곧 도구와 인프라에 대해 자세히 다룰 것입니다. 144 | 145 | ### 직원 교육 146 | 147 | 조직에서 오픈 소스 주제(예: 이 과정 시리즈)에 대한 교육을 받았더라도 엔지니어링 팀과 관리자에게 일반적으로 제품 구축 또는 작업 평가에 접근하는 방식과 다를 수 있는 특정 항목을 상기시키는 것이 중요합니다. 148 | 149 | #### 엔지니어용 150 | 151 | * 오픈 소스 개발 방법 및 프로세스 검토 152 | * 회사의 오픈 소스 정책 및 규정 준수 규칙 검토 153 | * 소프트웨어 개발 모델 내에서 오픈 소스 소프트웨어 통합 154 | * 가능한 경우 내부적으로 오픈 소스 모범 사례를 따르십시오. 155 | *보다 일반적인 솔루션을 만드는 데 도움이되는 커뮤니티 사고를 연습하고 장려하십시오. 156 | 157 | #### 관리자용 158 | 159 | * 기존 성능 측정항목이 더 이상 적용되지 않을 수 있음 160 | * 코드가 사용되지 않은 결과만 계산 161 | * 결과에 영향을 미치는 것은 코드를 작성하는 것만큼 유효한 솔루션입니다. 162 | * 관리자가 아닌 개발자를 관리하십시오. 163 | * 당신은 오픈 소스 프로세스를 제어할 수 없습니다 164 | * 직원과 커뮤니티를 위한 학습 곡선이 있습니다. 165 | * 영향력과 존중을 구축하는 데는 시간이 걸립니다(회사의 프로젝트일지라도). 166 | 167 | 168 | ### 수업: 리뷰 169 | 170 | ### 개요 171 | 172 | 일부 청중은 새로운 오픈 소스 프로젝트와 같은 노력을 시작하기 전에 긴 리뷰를 반드시 높이 평가하지는 않지만 법무 팀, 엔지니어링 팀 및 마케팅 팀의 리뷰를 위해 적절하게 시간을 내어 계획하는 것이 중요합니다. 173 | 174 | 가장 자주 놓치는 요소가 균열을 통과하지 않는지 확인하기 위한 간단한 체크리스트 세트가 도움이 될 수 있으므로 이것들이 반드시 고통스러울 필요는 없습니다. 새로운 오픈 소스 프로젝트를 만드는 과정을 시작할 때 이 시간을 사용하면 프로젝트가 종료되고 가시성을 확보한 후 많은 골칫거리를 줄일 수 있습니다. 175 | 176 | 이러한 검토 프로세스를 간소화하는 방법에 대해 다음 섹션에서 몇 가지 모범 사례를 다룰 것입니다. 177 | 178 | ### 법적 검토 179 | 180 | 새 프로젝트에서 발생할 수 있는 최악의 상황 중 하나는 커뮤니티가 코드베이스의 법적 청결성에 대한 불신을 갖는 것입니다. 릴리스하는 코드에 명확한 라이선스와 출처가 있는지 확인하는 것이 중요합니다. 완전한 법적 검토는 기여한 내용이 커뮤니티의 다른 사람들에게 받아들여질 수 있는지 확인하는 데 종종 도움이 됩니다. 181 | 182 | 법적 검토에는 상표 실사 및 등록도 포함되어야 합니다. 프로젝트를 재단에 기여하는 경우(이에 대한 자세한 내용은 나중에 거버넌스 섹션에서) 코드베이스를 오픈 소싱하기 전에 상표 전략에 맞춰져 있는지 확인하십시오. 183 | 184 | 또한 프로젝트에 대한 라이선스를 선택해야 합니다. 라이선스 또는 지적 재산권 요구 사항을 문서화하는 것이 중요합니다. 프로젝트는 일반적으로 아웃바운드 라이선스(예: 다운스트림 사용자가 코드를 받는 라이선스)와 인바운드 기여 메커니즘(예: 프로젝트에 기여하는 프로세스)을 모두 고려해야 합니다. 많은 프로젝트에서 인바운드 기여 메커니즘에 대해 [개발자 인증서](https://developercertificate.org/)(DCO) 승인 프로세스를 사용합니다. 특허 부여에 대한 회사의 명시적인 약속이 필요하거나 나중에 프로젝트에 라이선스를 다시 부여할 수 있는 기능이 필요할 것으로 예상되는 경우 좀 더 일반적인 기여자 라이선스 계약(일반적으로 CLA라고 함)을 살펴보는 것이 좋습니다. 모든 CLA가 동일한 것은 아니므로 이 옵션을 신중하게 고려하십시오. 또한 CLA는 개발자가 서명을 받기 위해 힘든 승인 프로세스를 거쳐야 하는 경우가 많기 때문에 참여를 방해할 수 있습니다. 라이선스 옵션에 대한 자세한 내용은 이 교육 시리즈의 _오픈 소스 규정 준수 프로그램_ 모듈을 참조하십시오. 185 | 186 | 귀하의 프로젝트는 소프트웨어가 아닌 결과물을 생산할 수도 있습니다. 프로젝트에서 문서를 생성하는 경우 문서에 특정 라이선스를 사용해야 하는지 여부를 논의하십시오. 예를 들어, 많은 오픈 소스 프로젝트는 소프트웨어에 대해 오픈 소스 라이선스를 사용하고 문서에 Creative Commons 라이선스를 사용합니다. 또한 일부 프로젝트에서는 다른 사람이 다양한 방식으로 구현할 수 있는 사양을 만들려고 합니다. 이러한 프로젝트는 사양 라이선스를 사용하는 옵션을 고려해야 합니다. 187 | 188 | 각 라이선싱 접근 방식에는 장단점이 있지만 상호 운용 가능하거나 다양한 공급업체 솔루션 간에 이식성을 제공해야 하는 소프트웨어의 경우 특히 문제인 프로젝트 단편화 가능성을 인식해야 합니다. 종종 이 문제는 상용 솔루션이 커뮤니티에서 만든 테스트 또는 일련의 요구 사항을 통과하는 경우 프로젝트 상표의 사용을 허용하는 적합성 프로그램을 만들어 해결됩니다. 이에 대해 미리 생각하면 프로젝트에 대한 법적 검토 및 계획을 알리는 데 도움이 됩니다. 189 | 190 | 요약하면 법적 검토 프로세스의 단계는 다음과 같습니다: 191 | 192 | * 회사의 지적 재산에 대한 오픈 소스의 영향 고려 193 | * 오픈 소스 라이선스에 대한 완전한 규정 준수 보장 194 | * 공개할 소스 코드에 대한 오픈 소스 라이선스를 선택하고 프로젝트의 모든 라이선스 요구 사항을 매우 명확하게 문서화합니다. 195 | * 기여자 동의가 필요한지 결정 196 | * 커뮤니티의 가능한 비 소프트웨어 출력과 문서 및 사양과 같은 적절한 라이선스를 고려합니다. 197 | * 상표 관련 고려 사항 결정 198 | * 적합성 테스트와 같은 생태계 계획에 구축할 추가 요소가 있는지 결정 199 | 200 | ### 기술 검토 201 | 202 | 기술 검토에서는 소스 코드가 다른 내부 코드 또는 개발 방식(사용자 지정 내부 빌드 시스템 포함)에 종속되지 않고 작동할 수 있으며 회사가 오픈 소스 릴리스에 포함할 수 없는 타사 코드가 포함되어 있지 않음을 확인합니다. 203 | 204 | 기술 검토에는 모든 라이선스 및 저작권 고지에 대한 확인이 포함되어야 하며 모든 개인 또는 내부 코드 주석은 삭제되어야 합니다. 단계에는 다음이 포함됩니다: 205 | 206 | * 비공개 구성 요소에 대한 중요한 종속성 제거 207 | * 문서 및 사용 사례 제공 208 | * 내부 주석, 다른 내부 코드에 대한 참조 등을 제거합니다. 209 | * 코딩 스타일이 일관적인지 확인 210 | * 소스 코드 파일의 저작권 고지 업데이트 211 | * 소스 코드 파일에 라이선스 고지 추가 212 | * 코드가 모든 외부 대상 플랫폼에서 컴파일 및 빌드되는지 확인합니다. 213 | * 루트 디렉토리에 라이센스 텍스트를 파일로 추가 214 | 215 | ### 마케팅 검토 216 | 217 | 성공적인 오픈 소스 프로젝트는 코드와 기술의 장점에만 의존할 수 없습니다. 프로젝트를 계속 진행하려면 주의가 필요한 일련의 추가 비즈니스 및 마케팅 단계가 있습니다. 여기에는 프로젝트 홍보, 성공적인 운영 전략 수립, 현실적인 예산 및 프로젝트 브랜딩 제공, 활발한 소셜 미디어 계정 및 장기적인 성공을 뒷받침하는 유용한 도메인 이름 설정이 포함됩니다. 218 | 219 | 마케팅 검토는 브랜딩에 대한 지침을 설정합니다. 이는 시장에서 일관된 메시지를 보장하는 데 도움이 되기 때문에 특히 중요합니다. 마케팅 검토 단계에는 다음이 포함됩니다: 220 | 221 | * 프로젝트 로고, 색 구성표, 웹사이트, 자료 등을 디자인합니다. 222 | * 브랜딩 가이드라인 공식화 223 | * 프로젝트의 소셜 미디어 계정 등록(Twitter, Facebook, LinkedIn 등) 224 | * 프로젝트에 대한 도메인 이름 등록 225 | 226 | 프로젝트 시작 전에 이 마케팅 검토를 수행하면 잠재적인 브랜딩 문제(예: 선호하는 이름에 사용할 수 없는 도메인 이름)가 프로젝트의 성공을 위협하기 전에 처리할 수 있습니다. 마케팅 팀이 이러한(및 기타) 문제를 탐색하는 데 도움이 될 수 있도록 초기에 마케팅 팀을 참여시키십시오. 227 | 228 | 코드를 기여하고, 포럼에 참여하고, 버그 수정을 제공하고, 문제를 보고하기 위해 얼마나 많은 사람들을 프로젝트로 몰고 갈 수 있는지 보는 것은 재미있는 도전이기 때문에 마케팅 팀이 흥분할 것이라는 것을 알게 될 것입니다. 229 | 230 | ### 강의: 거버넌스 및 프로세스 231 | 232 | ### 거버넌스 모델 233 | 234 | 새로운 오픈 소스 프로젝트를 위한 거버넌스 모델이 무엇인지 고려하는 것이 중요합니다. 그러나 거버넌스란 무엇을 의미합니까? 간단히 말해서, 거버넌스는 다음에 대한 결정을 가능하게 하는 프로젝트 주변의 구조입니다: 235 | 236 | * 참가요령 및 요건 237 | * 아키텍처 변경 238 | * 유지 보수 지명 239 | * 분쟁에 대한 최종 중재자 240 | * 참여자 중단 241 | 242 | 다양한 수준의 비즈니스 및/또는 기술 리더십으로 프로젝트를 관리할 수 있는 여러 가지 방법이 있습니다. 리더십에 대해서는 잠시 후에 다루겠지만 다양한 유형의 거버넌스 모델에 대한 자세한 내용은 이 교육 시리즈의 "오픈 소스 프로젝트와 효과적으로 협업" 과정을 참조하십시오. 243 | 244 | ### 리더십 245 | 246 | 진행하기 전에 리더십 역할을 설정하는 것도 중요합니다. 이는 다른 프로젝트에 대해 다른 것을 의미할 수 있습니다. 여러 기업 참여자가 있는 다중 회사 프로젝트를 시작하는 경우 프로젝트에 이사회 또는 기타 관리 그룹과 같은 보다 공식적인 거버넌스가 필요할 수 있습니다. 247 | 248 | 다른 준비에는 단순히 기술적인 관점에서 오픈 소스 프로젝트의 모든 측면을 감독하는 기술 위원회가 필요할 수 있습니다. 위원회의 구성에는 대부분 기술 리더십과 진행 상황 및 프로젝트 요구 사항에 대한 업데이트를 제공하기 위해 경영진에 다시 연락하는 연락 담당자가 포함됩니다. 그런 다음 기술 구성원과 경영진이 적합하다고 생각하는 대로 법무팀을 투입할 수 있습니다. 249 | 250 | 당신의 최고의 건축적 지식인은 물론 코드 기반이 어떻게 작동할지 알고 있는 다른 사람들도 분명히 그곳에 있을 것입니다. 전체적으로 위원회의 구성원은 프로젝트가 어디로 가고 있는지에 대한 비전과 개발자 커뮤니티 내에서 지원을 받게 됩니다. 그들은 당신이 그 과정을 계획하기 위해 테이블에 있기를 원하는 사람들입니다. 251 | 252 | ### 재단 또는 독립 253 | 254 | 새로운 오픈 소스 프로젝트가 생성될 때 자주 제기되는 또 다른 질문은 공급업체 중립적인 비영리 조직에 코드를 기여할 것인지 아니면 자체 프로젝트를 소유하고 실행하여 일부 통제권을 유지할 것인지입니다. 답은 달성하려는 목표에 따라 다릅니다. 업계를 위한 초기 기술을 구축하기 위해 소수의 파트너와 협력하고 있다면 처음부터 비영리 재단을 고려할 필요가 없을 것입니다. 255 | 256 | 그러나 계획하고 있는 것이 산업 전반에 걸쳐 광범위하게 적용될 수 있거나, 산업 전반에 걸쳐 있거나, 작은 노력에서 크고 복잡한 것으로 성장한 경우, 종종 비영리 오픈 소스/공개 표준 컨소시엄을 고려하여 귀하를 호스팅하는 것이 좋습니다. 프로젝트. 프로젝트를 호스팅할 수 있는 진정한 벤더 중립적인 장소를 갖는 것의 가치 외에도, 이러한 기반에는 프로젝트를 성공으로 이끄는 프로세스를 극적으로 간소화할 수 있는 법률, 거버넌스, 마케팅 및 프로젝트 인프라 서비스가 있습니다. 257 | 258 | 선택할 수 있는 많은 기초(및 하위 기초)가 있으며 각각 고유한 가치 제안, 가격 및 서비스 수준을 제공합니다. 이러한 기초의 몇 가지 예는 다음과 같습니다: 259 | 260 | * [아파치 재단](https://www.apache.org/foundation/) 261 | * [이클립스 재단](https://www.eclipse.org/org/foundation/) 262 | * [리눅스 재단](https://www.linuxfoundation.org/) 263 | * [오아시스 오픈](https://www.oasis-open.org/) 264 | 265 | 선택하는 기초는 프로젝트가 속한 전문 분야와 비용, 거버넌스 모델 등과 같은 고려 사항에 따라 다릅니다. 266 | 267 | ### 기술 프로세스 268 | 269 | 시작하기 전에 프로젝트 관리자가 변경 및 개선을 수행할 때 코드의 정기 릴리스를 예약하기 위해 표준 릴리스 프로세스를 만드는 것이 종종 도움이 됩니다. 일정은 개발 커뮤니티와 프로젝트의 비즈니스 측면에 대해 잘 정의되고 가시적인 세부 정보로 설정되어야 합니다. 270 | 271 | 이러한 릴리스의 빈도는 커뮤니티의 기대치에 따라 다릅니다. 프로젝트가 기업 중심이고 매우 강화된 것을 구축하려는 경우 릴리스 일정이 1년에 두 번일 수 있습니다. 프로젝트의 범위가 더 작고 더 민첩하고 프로젝트의 일부를 꺼내려고 하는 경우 매월 또는 매주 코드를 릴리스할 수 있습니다. 일정의 핵심은 커뮤니티가 일정을 지시하고 사용자가 필요로 하고 기대하는 것을 제공하면서 속도의 관점에서 프로젝트를 지원할 수 있는 능력을 이해해야 한다는 것입니다. 커뮤니티에서 릴리스가 너무 빠르거나 너무 느리다는 피드백을 제공하는 경우 프로세스를 살펴보고 일부 조정을 해야 합니다. 여기서 중요한 것은 일관성, 예측 가능성 및 가시성입니다. 272 | 273 | 또한 코드, 패치, 기능 아이디어, 문서 또는 기타 프로젝트 아티팩트를 제출하기 위한 잘 정의된 프로세스가 있어야 합니다. 이 중 일부는 프로젝트 인프라/도구(곧 다루게 될 주제)에서 처리할 수 있지만 기술 프로세스의 일부는 도구가 아니라 워크플로의 기대치 - 예: 코드 제출 방법, 어떤 종류의 코딩 표준을 따를 것인지, 릴리스 주기에서 새 코드가 언제 받아들여질 것인지 - 등입니다. 274 | 275 | ### 강의: 프로젝트 인프라 276 | 277 | ### 개발 도구 278 | 279 | 프로젝트를 시작하기 전에 프로젝트를 위한 저장소를 준비해야 합니다. 이것은 본질적으로 프로젝트를 기여자가 항상 사용할 수 있는 코드 리포지토리를 위한 인프라입니다. 많은 프로젝트에서 잘 알려진 [GitHub](https://github.com/) 또는 [GitLab](https://about.gitlab.com/) 저장소를 사용하거나 [Gerrit](https://www.gerritcodereview.com/)과 같은 도구를 사용하여 자체 저장소를 호스팅합니다. 280 | 281 | 사용할 수 있는 다른 옵션도 많이 있지만 개발자가 프로젝트에 쉽게 참여하고 참여할 수 있도록 하는 것이 유용한 경우가 많다는 것을 기억하십시오. 대부분의 개발자에게 친숙한 도구 플랫폼을 선택하면 프로젝트의 기여와 성장을 가속화하는 데 도움이 됩니다. 282 | 283 | 버그, 문제 및 기능 추적도 프로젝트 인프라 계획의 일부로 포함되어야 합니다. 기고자가 수정해야 할 문제와 유용할 수 있는 새로운 기능에 대한 요청을 보고할 수 있는 쉬운 장소를 제공하고자 합니다. 그런 다음 품질을 보장하기 위해 코드를 스캔하고 확인하는 동안 시스템과 프로젝트의 원활한 흐름을 유지하기 위해 프로젝트의 GitHub 리포지토리의 일부로 포함해야 할 수 있는 자동화된 빌드 및 테스트 시스템 프로세스가 있습니다. 284 | 285 | 이 과정 시리즈의 _Open Source Development Practices_ 모듈을 검토하면 자동화된 테스트 및 지속적인 통합과 같은 것에 대한 자세한 정보를 얻을 수 있습니다. 286 | 287 | ### 웹사이트 288 | 289 | 중요한 단계는 프로젝트에 대해 회사 중립적인 웹 존재를 만드는 것입니다. 오픈 소스 프로젝트 웹사이트를 회사 웹 페이지의 하위 도메인으로 배치하려고 하지 마십시오. 최선의 의도가 있더라도 프로젝트의 중립적인 홈을 시각적으로 구분하는 것이 중요합니다. 웹 페이지는 커뮤니티에서 문서, 코드 다운로드 링크 등을 포함하여 프로젝트에 대한 정보를 찾을 수 있는 장소를 제공합니다. 웹 페이지는 또한 프로젝트의 리더십, 범위, 사용자 및 기여자, 예산, 거버넌스 및 기타 세부 사항에 대한 세부 정보를 제공할 수 있습니다. 중앙 정보 저장소인 귀하의 웹사이트에는 새로운 개발자가 커뮤니티에 가입할 수 있는 매우 명확한 클릭 유도문안/장소가 있어야 합니다. 290 | 291 | ### 커뮤니케이션 도구 292 | 293 | 커뮤니티에서 도움을 요청할 수 있는 커뮤니케이션 채널을 제공하는 것이 중요합니다. 전체 개발 워크플로에 통합할 수 있는 도구를 찾고 싶을 것입니다(예: 지원 요청, 코드 체크인, 오류 로그 및 기타 작업에 대한 알림 수신). 또한 커뮤니티 구성원이 프로젝트에 참여하고 있는 다른 사람들로부터 빠른 답변을 얻을 수 있는 중요한 토론 포럼과 메커니즘을 제공하고 싶을 것입니다. 모두 실시간으로 프로젝트를 진행하는 데 도움이 되는 중요한 커뮤니케이션 수단입니다. 294 | 295 | 고려해야 할 프로젝트 도구 중 하나는 [Slack](https://slack.com/)입니다. 온라인 팀 프로젝트 관리 및 커뮤니케이션 플랫폼은 사용자가 메시지와 파일에 액세스 및 공유하고, 워크플로를 구성하고, 정보 검색을 수행하는 등의 작업을 수행할 수 있는 플랫폼입니다. 그러나 Slack은 독점 도구이며 특정 사용 임계값을 초과하여 유지 관리하는 데 비용이 들 수 있습니다. IRC, [Gitter.im](https://gitter.im/), [Mattermost](https://mattermost.com/), [Rocketchat](https://rocket.chat/) 등과 같은 오픈 소스 옵션이 있습니다. 296 | 297 | 개발자 및 사용자 커뮤니티에 따라 최신 포럼 도구가 필요할 수도 있습니다. [Discourse](https://www.discourse.org/)는 완전 오픈 소스이며 선택적 호스팅도 제공하는 훌륭한 옵션입니다. 통신 시스템을 선택할 때 모든 형태의 종속성, 재정적 비용 및 향후 새 시스템으로의 마이그레이션이 얼마나 쉬운지를 염두에 두십시오. 298 | 299 | 커뮤니티가 성장함에 따라 새로운 커뮤니케이션 채널에 적응할 수 있어야 합니다. 프로젝트가 발전함에 따라 도구 결정에 커뮤니티를 참여시키십시오. 사용자와 개발자는 시간이 지남에 따라 유용하다고 생각하는 다른 도구에 자연스럽게 끌릴 수 있습니다. 300 | 301 | ### 문서 도구 302 | 303 | 문서 관리의 일부 형태는 오픈 소스 프로젝트, 특히 문서 작성 프로세스, 방법 및 기타 텍스트 기반 프로젝트를 더 쉽게 만드는 경우에 종종 유용합니다. 많은 프로젝트에서 GitHub 또는 GitLab의 기본 제공 마크다운 텍스트 도구 기능을 사용하는 것이 편안하지만 다른 프로젝트에서는 Wiki 또는 기타 공유 편집 소프트웨어를 사용하는 것을 선호합니다. 304 | 305 | 잠재적인 Wiki 도구 옵션 목록은 [Wikipedia](https://en.wikipedia.org/wiki/List_of_wiki_software)에서 확인할 수 있습니다. 통신 도구에 적용되는 동일한 주의 사항이 여기에도 적용됩니다. 사용자와 개발자가 다른 플랫폼으로 마이그레이션하기로 결정할 때(그렇지 않은 경우가 아님) 모든 종류의 데이터 또는 도구 종속을 피할 수 있는 방법을 고려하십시오. -won 문서, 자주 묻는 질문 목록 및 방법 내용. 306 | 307 | # 섹션: 성공적인 프로젝트 시작 및 유지 308 | 309 | ## 수업: 소개 310 | 311 | ### 섹션 개요 312 | 313 | 이 섹션에서는 성공적인 오픈 소스 프로젝트 출시에 필요한 최종 단계에 대해 논의하고 프로젝트에 대한 채택 및 기여를 유지하고 장려하는 방법에 대한 몇 가지 추가 정보를 제공합니다. 314 | 315 | ### 학습 목표 316 | 317 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 318 | 319 | * 오픈 소스 프로젝트를 성공적으로 시작하는 데 필요한 마지막 단계를 설명합니다. 320 | * 증가된 프로젝트 채택과 강력한 기여 파이프라인을 허용하는 강력한 커뮤니티 프로세스를 구축하는 방법을 설명합니다. 321 | 322 | 323 | ## 강의: 프로젝트 시작 324 | 325 | ### 최종 코드 검토 326 | 327 | 프로세스의 이 시점에서 시작을 준비하기 위해 소스 코드를 한 번만 마지막으로 통과하는 것이 좋습니다. 앞에서 설명한 프로세스를 따랐다면 큰 부담이 되지는 않겠지만 수정하기 쉬운 항목을 잊지 않도록 하는 것이 매우 도움이 될 수 있습니다. 328 | 329 | 특히, 이 최종 검토의 목표는 법률, 기술 및 마케팅 검토에서 식별된 모든 요구 사항이 완전히 충족되었는지 확인하는 것이어야 합니다. 찾아야 할 몇 가지 예는 다음과 같습니다: 330 | 331 | * 라이선스, 저작자 표시 및 저작권 텍스트가 모두 완전하고 제자리에 있습니다. 332 | * 소스 코드 스캐너는 깨끗한 BOM을 보고합니다. 333 | * 모든 코드 라인은 릴리스에 적합하게 라이선스가 부여됩니다. 334 | * 댓글은 일상적이거나 관련 없는 언어로 삭제됩니다. 335 | * 소스 코드는 내부 프로젝트를 실수로 드러내지 않습니다. 336 | * 소스 코드는 빌드될 만큼 충분히 완전합니다. 337 | * 공개적으로 사용 가능한 도구를 사용하여 소스 코드 빌드 338 | * 파일 및 함수 이름이 변경된 경우 프로젝트 이름을 반영 339 | * MAINTAINERS 파일은 사용하는 경우 최신 상태입니다. 340 | 341 | ### 사전 출시 342 | 343 | 새 프로젝트를 공식적으로 시작하기 전에 조직과 커뮤니티 전체에 최고의 출시 경험을 보장하기 위해 할 수 있는 몇 가지 작업이 있습니다. 성공을 보장하기 위해 할 수 있는 가장 큰 일 중 하나는 출시 전에 임계 질량이 있는지 확인하는 것입니다. 344 | 345 | 새 프로젝트를 발표할 때 함께할 파트너와 고객을 식별해야 합니다. 코드에 익숙해지고 기여할 준비가 될 수 있도록 리포지토리에 대한 미리보기 액세스 권한이 있어야 합니다(또는 이미 기여하고 있음). 346 | 347 | 이것이 초기 오픈 소스 프로젝트 중 하나인 경우 개발자와 함께 빠르게 재검토하여 오픈 소스 커뮤니티에서 다른 사람들과 상호 작용할 것을 예상하여 오픈 소스 개발 방법 및 프로세스를 따르고 있는지 확인하는 것도 나쁘지 않습니다. 귀하의 프로젝트에 기여할 것입니다. 348 | 349 | 모든 프로젝트 인프라가 실행 중인지 확인한 후 내부 개발자가 프로젝트의 커뮤니케이션 도구에 참여하고 질문이나 새로운 기여를 모니터링하기 시작했는지 확인하십시오. 350 | 351 | 이제 중요한 순간을 맞이할 시간입니다! 마지막 남은 코드를 업로드하고 스위치를 전환하여 프로젝트를 전 세계에 라이브로 만들 수 있습니다. 352 | 353 | ### 좋은 오픈 소스 시민의식 354 | 355 | 이제 프로젝트가 시작되었으므로 앞으로 작업의 시작일 뿐입니다. 귀하의 조직이 계속해서 훌륭한 오픈 소스 시민인지 확인하고 다른 사람들이 귀하와 함께 프로젝트에서 함께 작업하도록 권장하는 방식으로 운영되도록 해야 합니다. 다음은 몇 가지 방법입니다: 356 | 357 | * 공개적으로 대화하고 결정하기 358 | * 이는 영업권을 구축하고 결정을 문서화할 때 오버헤드를 줄입니다. 359 | * 이는 신규 참여자의 온보딩 프로세스를 간소화합니다. 360 | * 열린 아카이브를 갖는 것은 참여자가 변경될 때 연속성을 보장합니다. 361 | * 커뮤니티에 귀 기울이기 362 | * 그들의 경험은 특히 통합 및 테스트에서 매우 중요합니다. 363 | * 필요한 것을 확장하는 일반화된 구현을 장려합니다. 364 | * 작업을 수행하는 유일한 회사인 것처럼 리소스를 할당합니다. 365 | * 목표를 설정하고 달성할 수 있는 자원이 있는지 확인 366 | * 이는 레버리지 개발 모델이 적용될 때까지 추진력을 구축합니다. 367 | 368 | 훌륭한 오픈 소스 시민이 되기 위해서는 노력이 필요하며 이타적이지 않습니다. 조직이 오픈 소스 프로젝트를 시작하는 데 투자한 투자에 대해 최상의 수익을 얻는 것은 좋은 비즈니스 관행입니다. 369 | 370 | ## 수업: 프로젝트 유지 관리 371 | 372 | ### 커뮤니티 구축 373 | 374 | 프로젝트가 시작된 후에는 외부 개발자 및 사용자 커뮤니티의 활력을 모니터링하는 것이 필수적입니다. 커뮤니티 구축은 자동으로 이루어지지 않습니다. 프로젝트의 초기 단계에서 추진력을 구축하기 위해 개발자 이벤트를 주최하거나 주요 회의에서 모임을 후원해야 할 수도 있습니다. 프로젝트 거버넌스 및 투명성에 대한 기대치를 관리하고 의무를 이행하는 것도 매우 중요합니다. 375 | 376 | 진행 중인 활동은 다음과 같습니다: 377 | 378 | * 방향 또는 거버넌스에 대한 변경 사항이 명확하게 전달되도록 합니다. 379 | * 다른 유사한 커뮤니티의 모범 사례를 따르십시오. 380 | * 대면 커뮤니티 구축을 위한 기회를 장려하고 제공합니다. 381 | * 적절한 이벤트를 식별하고 커뮤니티에서 토론을 제출하도록 합니다. 382 | * 지역 모임을 고려하십시오 383 | 384 | 다양한 기여자 그룹을 구축함으로써 나중에 시간, 돈 및 기타 자원을 투자하는 데 관심이 있는지 결정하기 위해 작업을 가치 있다고 생각하는 다른 기업 및 조직과 토론하여 프로젝트를 다음 단계로 이동하기로 결정할 수 있습니다. 초기 노력을 확장합니다. 다른 사람들로부터 의견과 자원을 얻음으로써 프로젝트를 확장하고 확장하여 추가 기여자를 위해 더 많은 작업을 수행할 수 있습니다. 385 | 386 | 이러한 성장은 추가 기업이 자신의 개발자가 노력에 참여하도록 하기 위해 더 많은 돈을 기부하고 시작한 노력 뒤에 무게를 두어 작업을 진행하는 데 도움이 되기를 원할 수 있음을 의미합니다. 프로젝트의 중요성과 다른 회사에 미치는 영향에 따라 $10,000 또는 $250,000 이상이 포함될 수 있습니다. 프로젝트가 시작되면 다른 회사가 임무에 도움이 될 경우 작업에 자금을 기부할 수 있습니다. 387 | 388 | 기업과 조직이 해결하려는 기술 문제가 개별 문제보다 더 크다는 사실을 깨닫고 있기 때문에 오늘날에도 이러한 일이 정기적으로 발생합니다. 그 때 기업이 직면한 기술적 문제를 해결하는 데 더 큰 이익을 위해 일하는 벤더 중립적 공동 프로젝트에서 다른 회사와 함께 하는 전략적 가치를 볼 수 있습니다. 389 | 390 | ### 커뮤니티 옹호자 지정 391 | 392 | 새로운 오픈 소스 프로젝트의 성공을 돕기 위해 고용할 수 있는 가장 중요한 역할 중 하나는 커뮤니티 옹호자(커뮤니티 관리자라고도 함)입니다. 이 사람의 역할은 커뮤니티를 성공시키는 데 필요한 모든 일을 하는 것입니다. 393 | 394 | 마케팅, 개발자 옹호, 비즈니스 개발, 위기 관리, 피스메이커 등 다양한 기술이 필요하기 때문에 실행하기 어려운 역할이며 고용하기 어려운 역할이 될 수 있습니다. 찾기 시작하기에 좋은 곳입니다. 이 역할의 누군가는 조직의 내부 개발 또는 마케팅 리소스를 고려하는 것입니다. 또한 기술 작가, 프로그램 관리자 또는 사회학, 심리학 등과 같은 비전통적인 연구 분야와 같은 사람들을 무시하지 마십시오. 395 | 396 | 훌륭한 커뮤니티 옹호자는 아무도 사용하지 않는 기술적으로 성공적인 프로젝트와 배포된 커뮤니티 구축 및 브리징 기술로 인해 비약적으로 성장하는 합리적으로 좋은 기술 프로젝트 간의 차이가 될 수 있습니다. Linux Foundation [TODO Group](https://todogroup.org/)은 커뮤니티 관리 리소스를 식별하는 데 도움이 되는 좋은 장소입니다. 397 | 398 | ### 평가 및 조정 399 | 400 | 모든 새로운 프로젝트 노력과 마찬가지로 자주 평가하고 예상했던 채택 및 기여도가 나타나지 않는 경우 접근 방식을 조정할 준비가 되어 있어야 합니다. 조직의 평판은 새로운 오픈 소스 프로젝트의 성공 여부를 결정짓는 방정식의 일부일 뿐임을 기억하는 것이 중요합니다. 401 | 402 | 커뮤니티에서 피드백을 제공할 때 유연성과 민첩성을 유지하면 협업하고 경청하기에 좋은 장소로 프로젝트의 명성을 높일 수 있습니다. 프로젝트가 시작되면 몇 가지 주요 메트릭을 살펴봐야 합니다: 403 | 404 | * 초기 개발자 기반 외부의 코드 커밋/풀 요청 수 405 | * 배포한 커뮤니케이션 채널에 대한 토론/주제 수 406 | * 제출된 버그 보고서 또는 기능 요청 수 407 | 408 | 또한 부정적인 피드백이라도 커뮤니티가 프로젝트에 참여하고 있다는 것을 기억하는 것이 중요합니다. 투명성과 책임성을 실천하고 우려 사항을 공정하게 해결하려고 노력함으로써 프로젝트는 긍정적인 평판을 얻게 됩니다. 409 | 410 | 이 교육 과정 시리즈 전체에 걸쳐 반복된 격언인 '일찍 릴리스, 자주 릴리스'를 기억하십시오. 새 프로젝트가 첫날에 완벽할 필요는 없지만 이 격언을 염두에 두면 성공적이고 강력한 오픈 소스 노력을 구축하는 데 순조롭게 진행될 것입니다. 411 | -------------------------------------------------------------------------------- /module6/README.md: -------------------------------------------------------------------------------- 1 | # 업스트림 오픈 소스 프로젝트 이해 2 | 3 | ## 수업: 소개 4 | 5 | ### 섹션 개요 6 | 7 | 이 섹션에서는 오픈 소스 프로젝트의 맥락에서 업스트림이 무엇을 의미하는지 설명하고 거버넌스 모델과 기여 전략에 미치는 영향에 대해 논의합니다. 8 | 9 | ### 학습 목표 10 | 11 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 12 | 13 | - 업스트림 오픈 소스 프로젝트가 무엇이며 왜 중요한지 설명 14 | - 성공적인 기여를 위한 몇 가지 일반적인 거버넌스 모델 및 전략 설명 15 | 16 | ## 강의: 업스트림 오픈 소스 소개 17 | 18 | ### 업스트림이란 무엇을 의미합니까? 19 | 20 | 우리는 이미 이 모듈에서 _upstream_이라는 용어를 사용했지만 이것이 의미하는 바는 무엇입니까? 21 | 22 | 다음은 간단한 정의입니다: 23 | 24 | **업스트림 (명사)** 25 | 26 | 파생 상품이 구축되는 원래의 오픈 소스 소프트웨어 프로젝트 27 | 28 | 이 용어는 물과 물이 운반하는 물품이 하류로 떠내려가 물을 받는 사람들에게 이익이 된다는 생각에서 비롯됩니다. 29 | 30 | **업스트림으로 (동사)** 31 | 32 | "업스트림 프로젝트에 변경 사항 푸시"를 간략하게 표현하는 것입니다. 즉, 소스 코드 프로그램에 대한 변경 사항을 해당 프로그램 전용의 원래 프로젝트에 다시 기여하는 것입니다. 33 | 34 | 공급망의 맥락에서 업스트림에 대해 생각하면 다음과 같습니다. 35 | 36 | ![오픈 소스 공급망 유입경로](supply-chain-funnel.png) 37 | 38 | ### 왜 업스트림에 기여해야 합니까? 39 | 40 | 조직에서 자주 묻는 가장 큰 질문은 처음부터 업스트림에 기여하는 이유입니다. 그냥 소비하고 다시 기여하지 않는 것이 더 쉬워 보일 수 있지만 다음을 포함하여 기여 노력을 고려해야 하는 많은 이유가 있습니다: 41 | 42 | - 비공개 코드는 공개 개발에서 고려되지 않습니다. 43 | - 변경 사항을 업스트림에 통합하면 다른 사람들이 변경 사항을 인식하고 이에 대한 계획을 세울 수 있습니다. 44 | - 자신의 코드가 우발적으로 파손될 위험이 감소합니다. - 업스트림 프로젝트와 호환되지 않는 로컬 변경을 수행하는 경우 해당 문제를 수정하는 데 시간과 리소스가 소요됩니다. 45 | - 업스트림 프로젝트에 변경 사항을 통합하면 완제품을 만드는 데 드는 노력이 줄어듭니다. 46 | - 기고된 코드가 검토되고 업스트림 프로젝트에서 필요한 변경 사항에 대해 외부 리소스가 필요할 수 있습니다. 47 | - 기여는 프로젝트를 강화하고 향후 프로젝트 방향에 영향을 줄 수 있는 기회를 제공합니다. 48 | 49 | ### 언제 업스트림에 기여해야 합니까? 50 | 51 | 오픈 소스를 처음 접하는 조직은 종종 업스트림 기여를 시작할 적절한 시기에 어려움을 겪습니다. 다음 지침은 업스트림 기여의 이유/시기에 대한 좋은 개요를 제공합니다: 52 | 53 | - 업스트림 프로젝트와 코드를 동기화하는 데 드는 비용(시간 또는 $)이 혼자 작업하는 것의 편리함을 초과하는 경우 54 | - 타인(고객 포함)이 귀하의 코드를 사용하기를 원할 때 55 | - 코드가 사실상의 표준이 되거나 메인라인 프로젝트의 채택을 유도하려는 경우 56 | - 업스트림 프로젝트를 보완하는 향후 제품에서 특정 코드베이스에 반복적으로 의존할 것으로 예상되는 경우 57 | 58 | ### 예: 업스트림 없이 개발 59 | 60 | 업스트림 프로젝트에 효과적으로 참여하지 않을 경우 발생할 수 있는 일에 대한 더 나은 관점을 제공하기 위해 다음은 그래픽 예입니다: 61 | 62 | ![업스트림 없는 개발](dev-without-upstreaming.png) 63 | 64 | 보시다시피, 예를 들어 필요한 보안 버그나 기능이 릴리스된 경우와 같이 업스트림 오픈 소스 프로젝트의 "메인라인"을 가져와야 할 때 상당히 부담이 될 수 있습니다. 정기적으로 업스트림 프로젝트의 주요 릴리스를 유지한다는 것은 해당 비용을 한 번에 모두 지불하는 것이 아니라 점진적으로 지불한다는 것을 의미합니다. 65 | 66 | ### 예제: 업스트림을 사용한 개발 67 | 68 | 이에 반해 효과적인 업스트림 기여 전략이 있는 개발은 다음과 같습니다: 69 | 70 | ![업스트림 개발](dev-with-upstreaming.png) 71 | 72 | 여기서 주목해야 할 중요한 점은 업스트림에 자주 기여하고 업스트림 프로젝트와 동기화를 더 잘 유지할 때 문제와 통합 문제를 더 빨리 찾을 수 있기 때문에 더 적은 수의 사용자 지정 패치를 적용한다는 것입니다. 73 | 74 | ### 업스트림 거버넌스 모델 75 | 76 | 업스트림 오픈 소스 프로젝트에서 사용하는 거버넌스 모델은 부족하지 않습니다. 중앙 집중화 정도, 하나 또는 소수의 조직 주체에 의한 강한 영향력, 민주적으로 영감을 받은 의사 결정 메커니즘 및 리더십 선택의 존재 여부에 따라 다릅니다. 77 | 78 | 모델의 선택과 그것이 얼마나 잘 실행되는지는 프로젝트의 품질뿐만 아니라 그것이 얼마나 빨리 채택되고 발전하고 개선되고 성공하는지에 지대한 영향을 미칩니다. 모든 사람에게 적용되는 획일적인 모델은 없으며 각 모델에는 옹호자와 비방자가 있습니다. 또한 프로젝트마다 고유한 요구 사항이 다르므로 특정 모델에서 더 잘 충족될 수 있습니다. 79 | 80 | 다음 페이지에서는 가장 자주 사용되는 거버넌스 모델을 다룰 것입니다. 81 | 82 | ### 기업 주도 거버넌스 83 | 84 | 회사 주도 프로젝트는 다음과 같은 특징을 가진 대부분 폐쇄적인 프로세스를 가지고 있습니다: 85 | 86 | - 개발은 하나의 기업 또는 조직의 이해관계에 의해 강력하게 주도됩니다. 87 | - 하나의 엔티티가 소프트웨어 설계, 릴리스를 제어합니다. 88 | - 기여, 패치, 제안 등을 요청하거나 요청하지 않을 수 있습니다. 89 | - 내부토론, 논란, 많이 방영되지 않을 수 있음 90 | - 다음 소프트웨어 릴리스에 무엇이 포함될지 정확히 알려지지 않음 91 | - 출시 시 모든 소프트웨어는 완전히 공개됩니다. 92 | 93 | 예: **Google Android**, **Red Hat Enterprise Linux(RHEL)** 94 | 95 | 당신이 상상할 수 있듯이, 이러한 노력에서 더 많은 업스트림 프로젝트에 기여하는 것 외에는 이러한 프로젝트의 방향에 영향을 미치기가 어려울 수 있습니다. 예를 들어 Linux 커널은 Google Android 및 Red Hat Enterprise Linux의 업스트림이며 거기에서 수용되는 기능( 해당되는 경우)는 Android 및 RHEL에 영향을 미치는 한 가지 방법입니다. 96 | 97 | ### 자비로운 독재자 98 | 99 | 이러한 유형의 거버넌스를 사용하는 프로젝트는 일반적으로 한 명 또는 소수의 핵심 개인의 강력한 리더십을 갖습니다. 또한 다음과 같은 특성이 있습니다: 100 | 101 | - 한 사람이 모든 결정에 가장 큰 영향을 미칩니다. 102 | - 프로젝트의 품질은 자비로운 독재자의 품질에 달려 있습니다. 103 | - 끝없는 토론을 피하고 빠른 진행으로 이어질 수 있습니다. 104 | - 프로젝트가 성장함에 따라 성공은 독재자의 다음 능력에 크게 좌우됩니다. 105 | - 많은 기여자 처리 106 | - 건전하고 확장 가능한 버전 관리 시스템 사용 107 | - 하위 시스템 유지 관리인을 임명하고 작업합니다. 108 | - 자비로운 독재자의 역할은 구조적이지 않고 사회적, 정치적일 수 있음: 포크는 언제든지 발생할 수 있음 109 | - 유지 관리자는 프로젝트가 성숙함에 따라 점점 더 적은 코드를 작성합니다. 110 | 111 | 예: **리눅스 커널** 112 | 113 | ### 이사회 114 | 115 | 이사회 구조의 프로젝트는 다음과 같은 특징이 있습니다: 116 | 117 | - 단체(그룹)가 공개 메일링 리스트에 대한 토론을 수행합니다. 118 | - 디자인, 출시일 등은 일괄적으로 결정 119 | - 누가 기여할 수 있는지, 패치와 새 소프트웨어가 어떻게 받아들여지는지에 대한 결정은 치리회에서 내립니다. 120 | - 지배구조, 조직규칙, 합의 정도 등의 다양한 변화 121 | - 덜 자주 릴리스하는 경향이 있지만 잘 디버깅된 버전 122 | 123 | 예: **FreeBSD**, **데비안** 124 | 125 | 이러한 형태의 거버넌스를 가진 프로젝트는 취미 활동가나 기업 개발자로 구성될 수 있지만 재단/컨소시엄 모델(다음에서 설명)보다 기업의 영향력이 덜한 경향이 있습니다. 126 | 127 | ### 재단/컨소시엄 128 | 129 | 재단 또는 컨소시엄 내의 프로젝트에는 일반적으로 다음과 같은 고유한 특성이 있는 이전에 논의된 거버넌스 모델이 혼합되어 있습니다: 130 | 131 | - 사업/전략적 지배구조 감독위원회/이사회 132 | - 전반적인 사업 및 전략적 방향 제시 133 | - 일반적으로 프로젝트의 기업 후원자로 구성된 회원 134 | - 기술 결정을 위한 별도의 기술 운영 위원회 135 | - 기술 토론을 위한 공개 결정/메일링 리스트 136 | - 기업후원자의 기술자원으로 구성된 리더십 137 | - 기업과 무관한 기술 자원을 임명/의결할 수 있는 능력 138 | - 테스트/승인 주기가 더 긴 정기 릴리스 139 | 140 | 예: **Open Stack**, **Kubernetes**, **Academy Software Foundation** 141 | 142 | 재단 및 오픈 소스 파트너십에 대해서는 향후 교육 모듈에서 더 자세히 설명하겠습니다. 143 | 144 | ### 참여 고려 사항 145 | 146 | 많은 사람들이 위의 거버넌스 모델 중 어느 것이 가장 좋거나 소속 조직이 참여해야 하는지 묻습니다. 각 모델에는 장단점이 있지만 많은 경우, 특히 다음과 같은 경우 어떤 모델에 참여할지 선택하지 못할 수 있습니다. 프로젝트는 제품 또는 비즈니스의 핵심입니다. 147 | 148 | 조직으로서 고려해야 할 가장 큰 것은 필요한 프로젝트에서 사용하는 모델에 효과적으로 참여할 수 있는 적절한 인력(엔지니어링 및 리더십)이 있는지 확인하는 것입니다. 많은 조직이 직면한 가장 큰 문제는 너무 많거나 적은 엔지니어링 또는 관리 리소스로 참여하는 것입니다. 149 | 150 | 조직이 프로젝트에서 필요로 하는 것이 무엇인지 이해합니다. 전략적 입력이 필요한 경우 지속적인 엔지니어링 기여와 금전적 지원 또는 리더십을 제공하는 것이 가장 좋습니다. 당신이 주로 업스트림 기여를 할 필요가 있는 기술의 소비자라면 주로 엔지니어링 중심의 자원 조달 접근 방식을 사용하는 것이 더 효과적일 수 있습니다. 151 | 152 | # 섹션: 효과적인 업스트림 기여 전략 153 | 154 | ## 수업: 소개 155 | 156 | ### 섹션 개요 157 | 158 | 이 섹션에서는 개발 커뮤니티에 참여하는 가장 좋은 방법, 성공 전략 및 피해야 할 행동을 포함하여 업스트림 오픈 소스 프로젝트를 가장 효과적으로 작업하는 방법에 대해 논의합니다. 159 | 160 | ### 학습 목표 161 | 162 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 163 | 164 | - 업스트림 커뮤니티와 효과적으로 협력하는 데 가장 중요한 요소를 설명합니다. 165 | - 성공적인 업스트림 기여를 위한 모범 사례 설명 166 | - 효과적인 업스트림 기여자가 되기 위해 조직에서 처리해야 하는 프로세스와 고려 사항을 이해합니다. 167 | 168 | ### 강의: 업스트림 협업 169 | 170 | ### 기여처 171 | 172 | 업스트림 프로젝트에 기여하는 것이 왜 중요한지 이해한 후, 다음으로 가장 중요한 결정은 기여해야 하는 **위치**를 찾는 것입니다. 모듈 2, 오픈 소스 비즈니스 전략에서 다루었듯이 엔지니어링 및 비즈니스 관점에서 오픈 소스 프로젝트가 귀하에게 중요한 것에 대한 명확한 이해는 이 중요한 결정을 내리는 데 도움이 될 것입니다. 173 | 174 | 일반적으로 조직에 가장 전반적인 가치를 제공하는 것을 기반으로 이러한 기여를 활성화하기 위해 지출해야 하는 엔지니어링 리소스의 양에 따라 오픈 소스 프로젝트와 기여를 평가해야 합니다. 175 | 176 | 몇 가지 중요한 질문과 고려 사항은 다음과 같습니다: 177 | 178 | - **조직 내에서 어떤 오픈 소스 프로젝트를 사용합니까?** 어떤 오픈 소스 프로젝트가 귀하의 비즈니스에 전략적인지 결정하기 위해 전체 조직에서 이미 사용 중인 오픈 소스 프로젝트를 평가하는 데 시간을 할애하십시오. 중요한 비즈니스 인프라(운영), 제품 출시 능력에 영향을 미치는 개발 및 배포 도구, 고객 대면 제품 또는 서비스에 중요한 소프트웨어와 같이 평가에 집중할 수 있는 몇 가지 장소가 있습니다. 179 | - **기여 대상으로 삼아야 하는 프로젝트는 무엇입니까?** 대부분의 조직에서는 많은 오픈 소스 프로젝트를 사용하므로 계획이 가장 중요한 프로젝트에만 초점을 맞추도록 하는 것이 중요합니다. 프로젝트가 대상 목록에 없다고 해서 사람들이 해당 프로젝트에 기여할 수 없다는 의미는 아닙니다. 이는 조직에 중요한 초점이 아님을 의미합니다. 오픈 소스 프로젝트가 비즈니스에 중요하고 고객에게 서비스를 제공하는 능력에 심각한 다운타임이나 중단을 일으킬 가능성이 있는 경우 기여하기에 좋은 후보일 것입니다. 180 | 181 | ### 기여해야 할 사항 182 | 183 | 업스트림 프로젝트에 기여해야 하는 위치 외에 가장 중요한 질문 중 하나는 "**이러한 기여가 왜 중요한가요?**"입니다. 184 | 185 | 시작하고 계획한 모든 훌륭한 일에 대해 이야기하기는 쉽지만 이 작업이 조직에 중요하고 전략적인 이유와 모든 것을 어떻게 활용할 계획인지에 대한 설득력 있는 주장을 포함하는 것을 잊지 마십시오. 전략적 가치에 기여합니다. 186 | 187 | 때때로 기여는 빌드하는 제품을 지원하는 데 중요하고 때로는 전체 업스트림 프로젝트를 강력하고 건전하게 유지하여 다운스트림 작업에서 신뢰할 수 있도록 하는 데 중요합니다. 또한 업스트림 프로젝트의 관점에서 이를 고려해야 합니다. 계획된 기여는 업스트림 프로젝트의 더 넓은 커뮤니티에 가치가 있어야 합니다. 188 | 189 | 조직에 전략적일 수 있지만 자신의 사용 사례에만 유용하고 전체 업스트림 프로젝트 커뮤니티에 일반적으로 적용할 수 없는 기여를 제안하는 나쁜 행동을 피하는 것이 중요합니다. 190 | 191 | ### 참여 방법 192 | 193 | 업스트림 오픈 소스 프로젝트에 기여하는 방법에 대한 기술 프로세스에 대한 훌륭한 리소스가 많이 있지만, 여기서는 조직이 기여하는 방식을 고려할 때 사용할 수 있는 몇 가지 모범 사례에 대해 높은 수준에서 집중해 보겠습니다. 194 | 195 | 기여 여정을 시작할 때 고려해야 할 몇 가지 사항은 다음과 같습니다: 196 | 197 | - "업스트림 우선" 철학 채택 198 | - 항상 메인 브랜치와 다시 병합할 계획 199 | - 업스트림과 병합할 계획이 있는 한 포크와 사이드 브랜치는 괜찮습니다. 200 | - 내부 개발 노력을 업스트림 분기 릴리스 주기에 맞추십시오. 201 | - 업스트림 검토자가 더 잘 이해할 수 있도록 모든 코드를 적절하게 문서화해야 하며, 이는 더 빠른 승인 주기에 기여할 수 있습니다. 202 | - 릴리스를 일찍 따르고 자주 연습하십시오. 거대한 코드 기반을 구축한 다음 업스트림으로 결정하지 마십시오. 디자인, 초기 코드를 공유하고 서로를 기반으로 하는 더 작고 독립적인 패치에서 큰 기여를 제출하십시오. 203 | - 업스트림하지 않기로 선택한 코드 추적: 기회가 있을 때마다 재평가하십시오. 내부에서 유지 관리되는 코드 크기의 증가 추세를 발견하면 이전 결정에 대한 토론과 재평가가 필요합니다. 204 | 205 | ### 효과적인 기여 정책 206 | 207 | 오픈 소스 전략의 일부로 효과적인 규정 준수 정책을 구현하는 것이 중요하지만, 업스트림 기여에 대한 빠른 승인을 위한 가벼운 정책을 설정하는 데 도움이 되도록 법무 및 리더십 팀이 참여하는 것도 중요합니다. 208 | 209 | 이러한 정책은 규칙과 규정이 아니라 사람들이 오픈 소스 프로젝트에 성공적으로 기여할 수 있도록 돕는 데 중점을 두어야 합니다. 사람들이 라이선스나 기밀 문제에 부딪히지 않고 성공적인 기여를 하는 데 필요한 모든 것을 갖추고 있는지 확인하기 위한 지침과 체크리스트가 있다면 도움이 될 수 있습니다. 210 | 211 | 특히 새로운 기여자의 경우, 기여하기 전에 피드백을 얻을 수 있는 안전한 장소로 내부 검토 프로세스를 사용할 수 있도록 하는 데 도움이 될 수 있습니다. 212 | 213 | 대부분의 경우 기여 정책에는 업스트림 프로젝트에서 사용하는 승인된 오픈 소스 라이선스 목록이 미리 정의되어 있으며 개발자와 함께 "샌드박스" 접근 방식을 취합니다. 사전 승인된 라이선스. 214 | 215 | 목표는 업스트림 개발자와의 상호 작용을 촉진하는 프로세스와 오픈 소스의 기업 거버넌스 간의 균형을 맞추는 것입니다. 216 | 217 | ### 직원 채용 고려 사항 218 | 219 | 인력 충원은 성공적인 업스트림 기여에 중요한 요소입니다. 약간의 업스트림 기여를 한 엔지니어링 팀이 있는 경우 조직에 관련 전문 지식이 이미 있을 수 있습니다. 그러나 귀하의 비즈니스에 중요한 업스트림 프로젝트를 살펴보기 시작하면서 지속적인 기여를 할 수 있는 관련 전문 지식이 내부에 있는지 또는 이를 위해 고용해야 하는지 여부를 확인해야 합니다. 220 | 221 | 외부에서 고용해야 하는 경우 기여를 생성할 수 있는 기술을 가진 사람뿐만 아니라 커뮤니티에서 상위 기여를 수용하는 데 능숙한 사람을 찾는 것이 중요합니다. 222 | 223 | 채용을 시드하는 한 가지 방법은 업스트림 프로젝트 커뮤니티에서 주요 개발자와 유지 관리자를 고용하는 것을 고려하는 것입니다. 이러한 사람들은 수요가 높기 때문에 적절한 급여뿐만 아니라 그들이 속한 업스트림 프로젝트에서 계속 작업할 수 있는 엔지니어링 문화를 제공할 준비가 되어 있어야 합니다. 224 | 225 | 목표는 커뮤니티에서 영향력을 발휘할 수 있을 만큼 동료의 인정을 받는 사람들을 찾는 것입니다. 여기에는 일반적으로 도메인 전문성, 오픈 소스 방법론 및 작업 관행의 세 가지 기둥이 있습니다. 또한 기업의 이익과 개인의 이익을 일치시켜야 합니다. 주어진 프로젝트에서 개인의 이익이 기업의 이익과 일치하지 않을 때 선임 오픈 소스 개발자에게 동기를 부여하는 것은 매우 어렵습니다. 예를 들어, Linux 메모리 관리 전문가는 기업 우선순위인 파일 시스템 작업에 관심이 없을 수 있습니다. 따라서 장기적인 관계를 위해서는 관심사에 맞는 짝을 찾는 것이 중요합니다. 226 | 227 | ### 일정/시간 고려 사항 228 | 229 | 업스트림 기여를 위해 프로젝트 일정에 적절한 시간을 제공하는 것이 필수적입니다. 업스트림 기여를 하는 내부 개발자가 있는 경우 이러한 기여를 할 수 있도록 일정에 시간을 투자해야 합니다. 외부 오픈 소스 개발자를 조직에 고용하여 업스트림에서 작업하고 제품에서도 작업하는 경우 일정의 균형을 유지하는 방법도 고려해야 합니다. 230 | 231 | 오픈 소스 개발자를 고용하는 핵심 원칙은 오픈 소스 개발 및 업스트림 활동을 지원하는 것입니다. 또한 전문 분야의 제품 팀을 지원해야 한다는 기대도 있습니다. 그러나 제품 팀이 최대한 제품 개발에 임하도록 하여 오픈 소스 개발자의 시간을 가로채기 위해 영향력을 행사하는 것은 드문 일이 아닙니다. 이런 일이 발생하면 많은 오픈 소스 개발자가 방금 무슨 일이 일어났는지 깨닫기도 전에 업스트림 프로젝트에서 작업할 수 있는 새로운 일자리를 찾아 문을 나서게 될 것입니다. 232 | 233 | 따라서 업스트림 작업과 제품 작업을 분리하여 만들고 유지하는 것이 중요합니다. 즉, 오픈 소스 개발자에게 업스트림 열망과 책임을 충족할 수 있는 보장된 시간을 제공하는 것이 좋습니다. 특히 유지 관리자인 경우에는 더욱 그렇습니다. 제품 구성 요소에서 오픈 소스를 사용하는 주니어 개발자 또는 기타 내부 개발자의 경우 이러한 업스트림 커뮤니티와의 상호 작용은 언어, 의사 소통 및 기술 기술을 향상시킬 것입니다. 234 | 235 | 이러한 업스트림 시간 보장이 없으면 이러한 팀 구성원이 제품 팀의 확장자가 되기 쉽습니다. 결과적으로 업스트림 초점이 제품 개발에 유리하게 건조되어 단기적으로는 도움이 될 수 있지만 궁극적으로 업스트림 커뮤니티에서 조직의 명성을 잃게 되며, 이는 조직에 유익한 영역에서 업스트림 프로젝트를 안내하는 데 도움이 되는 능력에 부정적인 영향을 미칠 수 있습니다. 236 | 237 | ### 교육 고려 사항 238 | 239 | 최고의 외부 오픈 소스 개발자를 고용하더라도 기존 엔지니어링 직원을 위한 교육 기회를 제공하는 것을 고려해야 합니다. 업스트림 커뮤니티와 협력하는 것은 과거에 사용했던 것과는 매우 다른 경험이 될 수 있기 때문입니다. 240 | 241 | 어떤 종류의 교육을 고려해야 합니까? 242 | 243 | - 업스트림 기여를 위한 모범 사례 244 | - 오픈소스, 라이선스, 거버넌스 등에 대한 일반 교육 245 | - 갈등 해결 또는 도전적인 사람들을 다루는 훈련 246 | 247 | 시간이 지남에 따라 노력을 확장하려면 숙련된 오픈 소스 기여자를 새로운 기여자를 위한 멘토로 제공하는 일부 프로그램을 교육 계획에 포함시키십시오. 멘토링은 제품과 관련된 특정 기술 영역에서 오픈 소스 인재를 성장시키는 강력한 방법입니다. 248 | 249 | 회사 외부에서 몇 가지 리소스를 고용하는 것은 쉽지만 이 접근 방식에는 몇 가지 제한 사항이 있습니다. 대안적인 접근 방식은 기술 영역 및 오픈 소스 방법론에 대한 교육을 통해 기존 개발자를 오픈 소스 기여자로 전환하는 것입니다. 그런 다음 이러한 개발자는 멘토와 짝을 이루어 기술을 더욱 확장할 수 있습니다. 250 | 251 | 경험이 풍부한 수석 오픈 소스 개발자가 경험이 부족한 주니어 개발자에게 멘토링을 제공하는 멘토링 프로그램을 설정합니다. 일반적으로 멘토링 프로그램은 3~6개월 동안 진행됩니다. 이 시간 동안 멘토는 멘티의 업무를 감독하고 과제를 할당하고 적절한 결과를 보장해야 합니다. 멘토는 또한 멘티가 생성하는 모든 것에 대한 코드 검토를 수행하고 멘티가 코드를 업스트림 프로젝트에 푸시하기 전에 피드백을 제공합니다. 252 | 253 | 목표는 회사에서 업스트림 프로젝트에 코드를 제공하는 개발자의 수를 늘리고 코드의 품질과 업스트림 프로젝트에 허용되는 코드의 비율을 높여 개인의 효율성을 높이는 것입니다. 일반적으로 주어진 멘토에게 4-5명 이하의 멘티를 배정해야 하며, 코드 리뷰를 보다 효율적으로 수행하려면 멘토와 같은 영역에서 일하는 것이 이상적입니다. 254 | 255 | ### 툴링 고려 사항 256 | 257 | 개발자가 문제 없이 오픈 소스 커뮤니티와 통신하고 작업할 수 있도록 하는 유연한 IT 인프라를 제공하는 것이 중요합니다. 또한 업스트림 커뮤니티에서 외부에서 사용하는 도구와 일치하는 내부 IT 인프라를 설정하는 것을 고려해야 합니다. 이는 내부 팀과 업스트림 프로젝트 커뮤니티 간의 격차를 해소하는 데 도움이 됩니다. 258 | 259 | 이 인프라의 대부분은 조직의 오픈 소스 문화와 함께 자연스럽게 발전하지만 구현의 필요성을 인식하고 계획하는 것이 중요합니다. 오픈 소스 개발에 사용되는 IT 서비스에는 세 가지 기본 도메인이 있습니다: 260 | 261 | - 지식 공유(위키, 공동 편집 플랫폼, 공개 웹사이트) 262 | - 커뮤니케이션 및 문제 해결(메일링 리스트, 포럼, 실시간 채팅) 263 | - 코드 개발 및 배포(코드 저장소 및 버그 추적) 264 | 265 | 오픈 소스 개발을 적절하게 지원하려면 이러한 도구 중 일부 또는 전부를 내부적으로 사용할 수 있어야 합니다. 이는 기존의 전사적 IT 정책과 충돌할 가능성이 있습니다. 그렇다면 이러한 충돌을 해결하고 오픈 소스 개발자가 익숙한 도구를 사용할 수 있도록 하는 것이 중요합니다. 이러한 오픈 소스 관행에는 일반적으로 IT 정책을 제한하는 많은 표준이 없는 IT 인프라가 필요합니다. 266 | 267 | ### 기타 형태의 기여 268 | 269 | 업스트림 커뮤니티에는 코드와 관련이 없을 수 있는 다른 종류의 지원도 필요합니다. 관심 있는 프로젝트의 거버넌스 모델을 살펴보고 해당 프로젝트나 재단에 대한 기업 멤버십 또는 후원 옵션이 있는지 확인하십시오. 이것은 프로젝트의 성공을 돕는 자금을 제공하며, 어떤 경우에는 조직이 자문 역할에 더 많이 참여하거나 프로젝트에 영향을 주는 데 도움이 될 수 있습니다. 270 | 271 | 프로젝트에 직접 자금을 지원하는 것 외에도 관련 컨퍼런스 후원을 고려하십시오. 이것은 당신의 일에 대해 알리고 당신이 채용하고 싶은 사람들을 만나는 데 유용할 수 있습니다. 특히 직원이 있는 로컬 사용자 그룹에 참여하는 것을 간과하지 마십시오. 이러한 지역 그룹을 후원하고 기고자를 보내 강연을 하는 것은 특정 오픈 소스 프로젝트에 열정을 가진 지역 사람들을 모집하는 좋은 방법이 될 수 있습니다. 272 | 273 | ### 업스트림 노력 평가 274 | 275 | 시간, 사람 및 돈에 상당한 투자를 하고 있기 때문에 업스트림 노력을 평가하는 방법을 고려하는 것이 중요합니다. 후원금과 같은 코드가 아닌 기여를 회계 투자와 같은 표준 방식으로 추적할 수 있지만 관심 있는 프로젝트에 대한 기여를 추적하는 데 상당한 생각을 해야 합니다. 276 | 277 | 기여에는 업스트림 코드 개발, 제품 팀 지원, 지식 이전(멘토링, 교육) 및 가시성(출판, 토론)이 포함될 수 있습니다. 278 | 279 | 소스 코드 기여도를 추적하는 데 도움이 되는 몇 가지 툴킷이 있습니다. 예를 들어, The Linux Foundation은 Linux Foundation의 연간 Linux 커널 보고서에 보고되는 데이터를 생성하는 gitdm이라는 도구를 사용합니다. 이는 개별 개발자와 전체 팀 성과를 모두 추적하는 데 사용할 수 있습니다. 개별 개발자는 제출한 패치 수, 패치 수락률(제출된 패치를 수락된 패치로 나눈 값) 및 패치 유형(예: 새로운 기능인 경우, 기존 기능의 개선, 버그 수정, 문서, 등.). 280 | 281 | [GrimoireLab](http://grimoirelab.github.io/)과 같은 다른 도구를 사용하여 추적하려는 메트릭을 차트로 표시하고 시각화할 수도 있습니다. 추적해야 하는 항목의 구체적인 예는 측정항목에 대한 다음 섹션을 참조하세요. 282 | 283 | ## 진행 상황 추적을 위한 지표 284 | 285 | 이러한 오픈 소스 모범 사례를 구현하기 시작하면 원하는 개발 동작을 유도하기 위해 적절한 오픈 소스 메트릭이 필요합니다. 그러나 제품 조직에서 자주 사용되는 기존 메트릭은 오픈 소스 개발의 맥락에서 적용되지 않습니다. 286 | 287 | 예를 들어 변경 집합 또는 코드 줄의 수를 추적하는 것은 오픈 소스 개발 영향에 대한 좋은 지표가 될 수 있습니다. 그러나 오픈 소스 개발자가 커뮤니티의 지원을 위해 로비를 하기 때문에 원하는 기능의 여러 인스턴스가 업스트림에 구현될 수 있습니다. 이 경우 변경 집합 또는 코드 줄의 수는 팀 구성원이 코드를 업스트림으로 가져오고 회사의 다운스트림 유지 관리 노력을 줄이기 위해 제공하는 기술 리더십만큼 중요하지 않습니다. 따라서 추적하는 측정항목은 두 활동을 모두 고려해야 합니다. 288 | 289 | ### 시간 경과에 따른 커밋 및 코드 줄 290 | 291 | 추적해야 할 가장 기본적인 사항 중 하나는 매주, 매월 또는 매년과 같은 특정 기간 동안 변경된 커밋 수와 코드 줄입니다. 292 | 293 | ![시간 경과에 따른 커밋 및 코드 줄](commits-over-time.png) 294 | 295 | ### 프로젝트당 매주 변경된 총 커밋 및 행 수는 메트릭 추적을 시작하기에 좋은 위치입니다. 296 | 297 | 이 데이터를 통해 다양한 내부 개발 팀의 기여를 비교하여 소스 코드 기여가 어디에서 오는지 식별하고 리소스가 적절하게 할당되도록 할 수 있습니다. 298 | 299 | 여기에서 다양한 내부 팀의 누적 기여도, 총 기여도의 백분율, 코드를 업스트림에 커밋하는 데 걸리는 시간을 비교하는 차트를 만들 수 있습니다(다음 차트 참조). 300 | 301 | ![시간 경과에 따른 누적 기여도](cumulative.png) 302 | 303 | **그림 2:** 시간 경과에 따른 누적 기여를 추적하여 내부 팀을 비교하고 특정 오픈 소스 커뮤니티(이 차트에서는 Linux 커널)에 참여를 늘리고 있는 팀을 식별할 수 있습니다. 304 | 305 | ![시간 경과에 따른 총 기여 비율](percent-over-time.png) 306 | 307 | **그림 3:** 회사의 기여도를 시간 경과에 따른 전체 비율로 표시하면 가장 많은 코드를 기여한 팀을 식별할 수 있습니다. 308 | 309 | ![커밋할 시간](time-to-commit.png) 310 | 311 | **그림 4:** 코드 업스트림을 커밋하는 데 걸리는 시간은 개발 효율성을 추적하는 데 유용할 수 있습니다. 이 표와 차트는 다양한 팀이 코드를 업스트림에 기여하는 속도를 보여주고 전체 커뮤니티와 비교합니다. 312 | 313 | 또한 이러한 메트릭을 사용하여 예를 들어 커널 에코시스템에 관련된 다른 회사와 성과를 비교할 수 있습니다(그림 5). 이 경쟁 분석을 통해 프로젝트의 전체 개발자 에코시스템에 대해 더 잘 알 수 있습니다. 314 | 315 | ![기업별 누적 기여도](cumulative-by-company.png) 316 | 317 | **그림 5:** 누적 기여도를 회사별로 정렬하여 귀하의 회사가 다른 회사와 어떻게 비교되는지 확인할 수 있습니다. 318 | 319 | 이러한 메트릭은 강점과 약점이 어디에 있는지에 대한 훨씬 더 나은 아이디어를 제공하고 전반적인 개발 전략을 알려주는 데 도움이 될 수 있습니다. 예를 들어 경쟁업체와 비교하여 자신의 기여도를 추적하면 조직이 시장에서 경쟁업체와 비교하여 제품을 포지셔닝하는 데 도움이 되는 귀중한 정보를 얻을 수 있습니다. 320 | 321 | 최고 기여자가 되는 것은 그 자체가 목표가 아니라 조직의 개발 노력이 참여하는 커뮤니티에서 수용되고 있다는 표시입니다. 322 | 323 | ### 기억해야 할 사항 324 | 325 | 지금까지 업스트림 오픈 소스 프로젝트에서 가장 효과적으로 작업하는 방법에 대해 많은 정보를 제공했습니다. 우리는 이것을 기억해야 할 몇 가지 주요 사항으로 요약하려고 노력할 것입니다: 326 | 327 | 1. 오픈 소스 기여를 안내하는 정책 및 프로세스 수립 328 | 2. 모든 오픈 소스 기여에 대한 승인을 감독할 팀 구성 329 | 3. 귀하의 기술을 가능하게 할 분야에 집중하십시오. 330 | 4. 기여자에게 필요한 IT 인프라 및 도구 제공 331 | 5. 직원에게 기여 모범 사례에 대한 교육 제공 332 | 6. 기여 추적, 영향 측정, 개선 및 커뮤니케이션 333 | 7. 경험이 부족한 개발자를 양성하기 위한 멘토링 프로그램 구축 334 | 8. 기여 가이드라인, 방법, 해야 할 것과 하지 말아야 할 것 제공 335 | 9. 개발자가 오픈 소스 법률 지원에 액세스할 수 있도록 합니다. 336 | 10. 가장 가치 있는 오픈 소스 커뮤니티에서 고용 337 | 11. 항상 각 프로젝트에 특정한 커뮤니티 프로세스 및 관행을 따르십시오. 338 | 12. 당신이 업스트림하는 것이 전체 커뮤니티에 가치가 있고 당신의 제품에만 해당하는 것이 아닌지 항상 고려하십시오. 339 | 340 | # 섹션: 업스트림 개발 관행 341 | 342 | ## 수업: 소개 343 | 344 | ### 섹션 개요 345 | 346 | 이 섹션에서는 이전 섹션에서 논의한 기여 전략을 구현하는 방법에 대한 실용적인 지침을 제공하는 데 도움이 되도록 대부분의 업스트림 프로젝트에서 사용되는 개발 프로세스 및 관행을 더 자세히 살펴보겠습니다. 347 | 348 | ### 학습 목표 349 | 350 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 351 | 352 | - 업스트림 기여 방법에 대한 전체 프로세스 설명 353 | - 더 나은 업스트림 협업을 위해 내부 프로세스를 가장 잘 조정하는 방법 설명 354 | 355 | ## 강의: 프로세스 개요 356 | 357 | ### 시작하기 전에 358 | 359 | 기여해야 할 프로젝트를 확인한 후에는 프로젝트의 내부 작업(이전에 언급한 거버넌스 포함)을 이해하는 데 약간의 시간을 할애하는 것이 도움이 될 것입니다. 시작하는 몇 가지 방법은 다음과 같습니다: 360 | 361 | - 프로젝트 토론(메일링 목록, IRC, Slack, 토론 포럼)을 따라 진행 중인 노력을 이해합니다. 362 | - 핵심 개발자는 누구인가? 363 | - 우선순위가 높은 분야는 무엇입니까? 364 | - 릴리스 주기는 어떻게 작동합니까? 365 | - 현재 해결되지 않은 주요 버그는 무엇입니까 366 | - 최신 안정 및 실험 릴리스로 실험 367 | - 귀하의 관심사와 우선순위가 프로젝트의 관심사와 어떻게 일치하는지 결정하십시오. 368 | - 커뮤니티에서 관심사와 우선 순위를 공유하는 다른 사람들을 찾고 그들과 협력하십시오. 369 | 370 | ### 신호 의도 371 | 372 | ![신호 의도](signal-intent.png) 373 | 374 | 제출할 변경 사항에 대해 커뮤니티와 소통하는 것이 중요합니다. 프로세스는 일반적으로 사용 중인 메커니즘을 통해 커뮤니티에 메시지를 보내는 것으로 시작됩니다. 375 | 376 | 이 공개 토론은 전제 조건이며 유지 관리자가 해결해야 할 필요성과 문제를 인식하는 데 도움이 됩니다. 많은 작업을 수행하기 전에(변경 사항이 거부되기 전에) 유용성과 디자인 고려 사항에 대한 피드백을 수집할 수 있을 뿐만 아니라 작업을 도와줄 다른 사람을 모집하는 데 도움이 될 수 있습니다. 377 | 378 | 변경을 제안할 때 다음과 같은 중요한 사항을 염두에 두십시오. 379 | 380 | - 특정 사용 모델뿐만 아니라 다른 사용자에게도 유용해야 합니다. 381 | - 작은 부분으로 구현되어야 하며 즉각적인 혜택을 제공하는 방식으로 전달되어야 합니다. 382 | - 조직 내에서 구현 및 유지 관리할 준비가 된 리소스의 지원을 받아야 합니다. 383 | 384 | ### 토론 및 근거 385 | 386 | ![토론과 근거](discussion.png) 387 | 388 | 변경 요청이 제출된 후 커뮤니티가 기본 커뮤니케이션에 사용하는 도구에 대해 토론하는 형식이 자주 있습니다. 이때 다른 이해 당사자에게 의견을 제시하고, 피드백을 제공하고, 비판할 수 있는 기회를 제공하며, 유지 관리자에게 프로젝트가 이러한 변경을 수용할 준비가 되었는지 여부에 대해 의견을 말할 기회도 제공합니다. 389 | 390 | 이 단계의 의견은 간단한 승인에서 구현에 대한 자세한 질문에 이르기까지 다양할 수 있습니다. 특히 변경 사항이 프로젝트의 핵심 부분에 위험이 높거나 잠재적으로 방해가 되는 것으로 간주되는 경우에 그렇습니다. 다른 사람들을 어떻게 설득하고 싶은지 생각해보고 이 커뮤니케이션을 처음 보낼 때 보게 될 잠재적인 문제를 해결하는 것이 좋습니다. 391 | 392 | ### 수락 393 | 394 | ![접수](acceptance.png) 395 | 396 | 커뮤니티 토론 후 유지 관리자와 기타 이해 관계자가 동의하면 변경이 수락되고 변경이 프로젝트에 얼마나 전략적인지 확인, 제안된 구현이 괜찮다는 표시, 다음과 같은 일반적인 합의를 포함하여 몇 가지 추가 고려 사항이 논의됩니다. 변경 사항은 프로젝트의 안정성, 보안 또는 전체 기능에 영향을 미치지 않을 것입니다. 397 | 398 | 한 명 이상의 프로젝트 관리자가 일반적으로 이 단계에서 승인 신호를 보냅니다. 399 | 400 | ### 제안된 기여 추적 401 | 402 | ![제안된 기여 추적](tracking.png) 403 | 404 | 변경 사항이 수락되면 추적해야 하며 이는 일반적으로 프로젝트 커뮤니티에서 사용하는 도구에 따라 기능 또는 버그 추적의 일부 형태로 발생합니다. 이 추적 항목은 제안된 내용과 변경 사항으로 승인된 내용에 대한 신뢰할 수 있는 기록으로 간주됩니다. 405 | 406 | 이 단계에서 원래 제출한 개발자는 추적 도구에 자세한 기능 정보를 추가하여 변경 사항이 영향을 미치는 하위 시스템과 전체 구현 계획에 대한 기록이 유지되도록 합니다. 407 | 408 | ### 우선순위 409 | 410 | ![우선순위](prioritization.png) 411 | 412 | 변경 사항을 수락하고 추적한 후에는 프로젝트에 대해 보류 중인 다른 모든 변경 사항과 함께 수락 우선 순위를 지정해야 합니다. 이 시점에서 유지 관리자는 들어오는 변경 사항이 프로젝트의 핵심이고 즉시 필요한 변경 사항과 나중에 수락할 수 있는 변경 사항의 우선 순위를 지정하기 위해 다시 참여합니다. 413 | 414 | 유지 관리자는 일반적으로 종속성 및 향후 릴리스에 대한 전체적인 관점을 가지고 있기 때문에 변경 우선 순위를 지정하고 기능을 올바르게 정렬하기 위해 작업할 수 있습니다. 그러나 변경 사항이 충분히 사소하거나 프로젝트의 핵심 부분에 너무 많은 영향을 미치지 않는 경우 준비가 되자마자 수락할 준비가 되었다는 신호를 보낼 수 있습니다. 415 | 416 | ### 출시 계획 417 | 418 | ![릴리스 기획](release-planning.png) 419 | 420 | 유지 관리자가 들어오는 변경의 우선 순위 지정을 완료하면 변경 요청을 제출한 원래 개발자(전체 커뮤니티뿐만 아니라)에게 변경을 통합할 준비가 되는 시점을 알리기 위해 노력할 것입니다. 이는 유지 관리자와 커뮤니티가 릴리스당 관리 가능한 수의 기능을 계획하는 데 도움이 됩니다. 421 | 422 | 이 단계에서 원래 제출자는 변경 사항이 계획된 특정 향후 릴리스에 대한 알림을 받게 됩니다. 423 | 424 | ### 개발 및 QA 425 | 426 | ![개발 및 QA](development-qa.png) 427 | 428 | 프로세스의 모든 전제 조건이 완료된 후 실제 개발 및 품질 보증이 수행될 수 있습니다. 여기서 개발자와 커뮤니티에서 모집한 기타 리소스가 개입하여 유지 관리자가 설정한 특정 릴리스를 대상으로 새로운 변경 사항을 구현하기 시작합니다. . 429 | 430 | 어떤 이유로 개발에 문제가 발생하거나 할당된 특정 릴리스 창을 만들 수 없는 것처럼 보이면 유지 관리자 및 커뮤니티와 조기에 의사 소통하여 변경 사항에 대한 종속성이 발생할 수 있도록 하는 것이 중요합니다. 향후 릴리스 주기에서 조정됩니다. 431 | 432 | ## 강의: 내부 프로세스 조정 433 | 434 | ### 어디서 시작하나요 435 | 436 | 업스트림 커뮤니티에 변경 사항을 다시 기여할 때 내부 개발 프로세스를 가장 효과적으로 조정하는 방법을 고려하는 것이 중요합니다. 내부 또는 비공개 소스 소프트웨어 제품에 대한 고유한 개발 프로세스가 여전히 있을 수 있지만 업스트림 오픈 소스 프로젝트와 협업할 때 컨텍스트를 전환하고 효과적으로 작업할 수 있는 것은 업스트림 기여뿐만 아니라 오픈 소스를 가장 효과적으로 사용하는 데에도 중요합니다. 프로젝트를 내부 코드에 넣습니다. 437 | 438 | 기여에 대한 설정을 얻으려면 일반적으로 아래에 설명된 프로세스를 따르십시오(이 예는 Github에서 가져온 것이지만 소스 제어 시스템으로 git을 사용하는 모든 시스템으로 일반화할 수 있음). 439 | 440 | ![참여하도록 설정](setup.png) 441 | 442 | 소규모 오픈 소스 프로젝트이거나 조직의 다른 사람들이 사용할 가능성이 낮은 프로젝트인 경우 일반적으로 Github의 포크를 자신의 계정에 남겨둘 수 있지만 조직의 다른 팀에서 사용할 가능성이 있는 경우에는 더 쉬운 유지 관리를 위해 업스트림 프로젝트를 회사 소유 조직으로 분기할 수 있습니다. 443 | 444 | 초기 설정을 완료하면 "풀 요청"을 통해 변경 사항을 푸시하는 일반적인 워크플로는 다음과 같습니다. 445 | 446 | ![풀 리퀘스트](pull-requests.png) 447 | 448 | ### 내부 미러 449 | 450 | 일부 조직, 특히 인터넷에서 오픈 소스 리포지토리의 장기적 가용성에 대해 잠재적인 우려가 있는 조직의 경우 조직 내부에 리포지토리 구조의 추가 계층을 갖는 것이 합리적일 수 있습니다. 예를 들어: 451 | 452 | 453 | 454 | ![내부 미러](internal-mirror.png) 455 | 456 | 또한 일부 조직의 경우 이러한 오픈 소스 프로젝트의 내부 미러를 갖는 "편안한 요소"를 통해 제품에서 오픈 소스 사용에 대한 법적 승인을 더 쉽게 얻을 수 있습니다. 457 | 458 | 안전 계층을 제공하지만 변경 사항을 제안하기 전에 로컬 개발자 저장소에서 내부 미러로 변경 사항을 푸시한 다음 Github의 실제 포크로 푸시해야 하므로 업스트림으로 이동하는 변경 사항에 대한 워크로드도 증가합니다. 당신의 풀 리퀘스트. 459 | 460 | ### 내부 협업 461 | 462 | 내부 미러가 있든 없든 업스트림 프로젝트에 대한 소비 및 기여를 선택하든지 간에 다음을 확인하기 위해 조직 내에서 커뮤니케이션 및 협업 관행을 구축해야 합니다: 463 | 464 | - 업스트림 프로젝트의 승인된 소규모 버전 세트를 작업 중입니다. 465 | - 변경 사항이 중복되거나 내부 팀과 충돌하지 않습니다. 466 | - 업스트림 프로젝트에 제안하는 변경 사항은 회사 전체에서 일관됩니다. 467 | 468 | ### 업스트림 풀 요청 조정 469 | 470 | 업스트림 오픈 소스 프로젝트를 사용하고 잠재적으로 변경할 수 있는 팀이 여러 개인 경우 해당 프로젝트에 대한 변경 사항을 조정하는 작업을 하는 것이 중요합니다. 내부 미러 리포지토리 또는 공공 조직 리포지토리에서 이러한 변경 사항을 모니터링하고 우선 순위를 지정/명확하게 하는 경우 중간 "업스트림" 검토 팀 역할을 담당하는 조직 내부의 내부 "유지 관리 담당자"를 식별하는 데 도움이 됩니다. 471 | 472 | 대규모 엔지니어링 조직에서 업스트림 프로젝트 기여를 효과적으로 조정하는 것은 많은 추가 작업처럼 보일 수 있지만 업스트림 프로젝트를 효과적이고 건전하게 유지하여 신뢰할 수 있고 조직의 명성을 유지하려면 필요합니다. 상류 커뮤니티는 그대로 남아 있습니다. 단일 조직에서 업스트림 프로젝트로 가는 많은 상충되는 변경 사항이 있으면 오픈 소스 커뮤니티에서 조직을 보는 방식에 해로운 영향을 미칠 수 있으며 장기적으로 함께 작업하는 능력에 부정적인 영향을 미칩니다. 473 | -------------------------------------------------------------------------------- /module2/README.md: -------------------------------------------------------------------------------- 1 | # 섹션: 오픈 소스 비즈니스 모델 소개 2 | 3 | ## 수업: 소개 4 | 5 | ### 섹션 개요 6 | 7 | 이 섹션에서는 몇 가지 중요한 오픈 소스 비즈니스 모델의 정의와 이들 간의 비교를 제공합니다. 또한 각 접근 방식의 상대적인 강점과 약점에 대해 논의하고 어떤 비즈니스 시나리오에서 어떤 모델을 사용할 수 있는지 강조할 것입니다. 8 | 9 | ### 학습 목표 10 | 11 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 12 | 13 | - 가장 자주 사용되는 오픈 소스 비즈니스 모델을 정의합니다. 14 | 15 | - 이러한 비즈니스 모델의 차이점과 유사점을 설명하십시오. 16 | 17 | - 어떤 모델이 어떤 비즈니스 시나리오에서 가장 잘 작동하는지 이해합니다. 18 | 19 | ## 강의: 정의 20 | 21 | ### 주요 오픈 소스 비즈니스 모델은 무엇입니까? 22 | 23 | 오픈 소스 비즈니스 모델의 개념을 분할하는 두 가지 방법이 있습니다. 즉, 오픈 소스를 사용하는 회사(대부분의 조직)와 주로 오픈 소스를 생산하는 회사입니다. 먼저 사용 측면을 살펴보자. 24 | 25 | **사용** 26 | 27 | ![오픈소스의 전략적 활용](strategic-use.png) 28 | 29 | 위에서 강조한 최근 Gartner 연구에 따르면 동급 최고의 소프트웨어 및 기술 조직은 고객에게 제품을 제공하기 위해 제품에 사용하는 소프트웨어의 약 80%를 오픈 소스로 사용하고 나머지 20%의 부가가치를 해당 소프트웨어 스택 위에 구축합니다. 이를 통해 제한된 엔지니어링 리소스를 차별화된 가치에 집중하는 동시에 나머지 오픈 소스 생태계와 공통 코드의 개발 비용을 공유할 수 있습니다. 30 | 31 | 오픈 소스 코드를 생산하는 회사는 일반적으로 다음과 같은 유형의 비즈니스 모델에 속합니다(하지만 전략적으로도 오픈 소스를 사용할 가능성도 있음). 32 | 33 | **라이선스** 34 | 35 | 이 모델은 상용 라이선스와 오픈 소스 라이선스 모두에 따른 이중 라이선스 소프트웨어에 의존하며, 일반적으로 고객이 필요한 기능에 따라 제품의 '커뮤니티 에디션'과 '엔터프라이즈 에디션'을 선택할 수 있습니다. 제품. 예를 들어 상용 라이선스와 GNU 공용 라이선스에 따라 라이선스가 부여된 Oracle MySQL 데이터베이스가 있습니다(이후 모듈에서 라이선스에 대해 더 자세히 다룰 예정임). 36 | 37 | **호스팅** 38 | 39 | 이 모델에서 기업은 클라우드 호스팅 SaaS(Software as a Service 모델)에서 오픈 소스 제품을 제공합니다. 이에 대한 주요 예는 강화되고 확장 가능한 엔터프라이즈급 구성으로 오픈 소스 기술을 호스팅하는 Amazon(Amazon Web Services) 및 Google(Google Cloud)과 같은 회사입니다. 40 | 41 | **기술 지원** 42 | 43 | 기업은 종종 오픈 소스가 제공하는 기술 혁신을 활용하기를 원하지만 오픈 소스 제품에서 비즈니스를 운영하는 데 더 관심이 있습니다. 이 경우 기업이 오픈 소스 플랫폼에서 비즈니스 애플리케이션을 실행할 수 있도록 지원, 기술 지침, 전문 서비스 및 교육을 제공하는 RedHat 및 IBM과 같은 회사를 찾습니다. 44 | 45 | **오픈 코어** 46 | 47 | 여기에는 일반적으로 무료 및 오픈 소스인 유능한 핵심 제품이 포함됩니다. 핵심을 중심으로 상업 주체는 기능을 추가하거나 확장하는 폐쇄형 소스 소프트웨어를 제공합니다. 그런 다음 이러한 추가 기능은 상용 소프트웨어로 판매되며 지원 모델과 결합하여 확장에 대한 교육 및 기술 지원을 제공할 수도 있습니다. 48 | 49 | ### 오픈 소스 비즈니스 모델 비교 50 | 51 | 이러한 오픈 소스 비즈니스 모델을 비교할 때, 비즈니스마다 특정 모델을 선택하는 이유가 다르며 위에서 언급한 것처럼 모델이 결합되는 경우(예: Open Core 및 지원)가 있다는 점에 유의하는 것이 중요합니다. 기업이 각 모델을 선택하는 몇 가지 주요 이유는 다음과 같습니다. 52 | 53 | **사용** 54 | 55 | 귀하의 비즈니스에 차별화된 지적 재산이 있지만 비용과 복잡성을 줄여야 하는 경우, 오픈 소스 소프트웨어를 전략적으로 사용하고 해당 오픈 소스 기반 플랫폼 위에 제품 또는 서비스를 구축하면 모든 것을 직접 구축하지 않고도 매력적인 제품을 구축하는 데 활용할 수 있는 공유 혁신에 접근할 수 있습니다. 56 | 57 | **라이선스** 58 | 59 | 이중 라이선스 전략을 사용하면 제품의 '커뮤니티' 버전에 대한 사용 가치와 공유 입력을 얻을 수 있는 기회를 제공하는 동시에 '엔터프라이즈' 버전의 제품을 판매하여 수익을 실현하고 '커뮤니티' 버전. 또한 고객이 '구매하기 전에 사용해 보고' 유료 엔터프라이즈 버전에 대한 액세스를 요구하도록 비즈니스를 성장시킬 수 있는 기능도 제공합니다. 60 | 61 | **호스팅** 62 | 63 | 오픈 소스 프로젝트/제품의 호스팅 솔루션을 제공하면 자체 이익을 위해 코드를 지원하는 인프라를 구축한 기업이 고객에게 동일한 소프트웨어를 서비스로 제공할 수 있습니다. 라이선스 모델과 유사하게 이를 통해 조직은 소프트웨어에 대한 수익을 얻을 수 있으며, 이는 호스팅 인프라에 자금을 지원하고 오픈 소스 프로젝트의 개발을 계속할 수 있게 해줍니다. 64 | 65 | **기술 지원** 66 | 67 | 기술 회사가 사내 전문 지식과 하나 이상의 오픈 소스 프로젝트에 기여한 것으로 명성이 있는 경우 기술 지원 및 교육과 함께 번들로 제공되는 해당 프로젝트의 '강화' 엔터프라이즈 버전을 제공하면 해당 오픈 소스에서 작업을 계속할 수 있습니다. 프로젝트를 통해 고객에게 비즈니스 소프트웨어를 안정적으로 실행할 수 있는 견고한 기반 플랫폼을 제공할 수 있습니다. RedHat Enterprise Linux에서 실행되는 주식 시장은 이 모델의 좋은 예입니다. 68 | 69 | **오픈 코어** 70 | 71 | 이 비즈니스 모델은 매우 잘 작동할 수 있지만 커뮤니티에서 오픈 소스 코드 위에 제공된 폐쇄 소스 확장이 공개 소스 핵심의 일부가 되어야 한다고 생각하는 경우 조직에 대한 평판이 좋지 않을 수도 있습니다. 이 모델은 대기업이 지불할 의향이 있는 부가가치를 제공하는 동시에 개인과 중소기업 모두에게 프로젝트의 무료 커뮤니티 버전이 유용하도록 허용하는 섬세한 균형이 필요합니다. 72 | 73 | # 섹션: 오픈 소스 전략 개발하기 74 | 75 | ## 수업: 소개 76 | 77 | ### 섹션 개요 78 | 79 | 이 섹션에서는 조직의 오픈 소스 전략을 만드는 방법을 보여주고 그렇게 하는 데 필요한 가치와 필요성을 논의한 다음 전략이 오픈 소스 정책의 구현에 미치는 영향에 대한 고려 사항을 논의합니다. 80 | 81 | ### 학습 목표 82 | 83 | 이 섹션이 끝나면 다음을 수행할 수 있습니다. 84 | 85 | - 조직적 오픈소스 전략 수립의 필요성과 가치 설명 86 | 87 | - 조직이 활용할 수 있는 다양한 유형의 전략 설명 88 | 89 | - 전략을 조직적 정책으로 전환하는 데 도움이 되는 단계적 구현 계획을 명확히 합니다. 90 | 91 | ## 강의: 오픈 소스 전략 개요 92 | 93 | ### 오픈 소스 전략이란 무엇입니까? 94 | 95 | 전략은 몇 시간 동안 논의(또는 논쟁)할 수 있는 매우 광범위한 용어이지만 오픈 소스에 대해 이야기할 때는 매우 구체적인 것을 의미합니다: 96 | 97 | - 간결하고 높은 수준의 문서 98 | 99 | - 조직의 비즈니스 목표를 기반으로 100 | 101 | - 비즈니스 목표를 오픈 소스 소프트웨어 사용 및 관리 지침에 매핑 102 | 103 | 전략은 오픈 소스 관련 활동에 참여하는 모든 사람이 이해할 수 있어야 합니다. 향후 오픈소스 정책 및 프로세스에 대한 합의를 위한 참고자료가 됩니다. 지속적으로 이것은 새로운 결정을 내리고 프로그램 동의 및 약속을 수립하기 위한 중요한 도구입니다. 104 | 105 | 많은 조직은 또한 오픈 소스 모범 사례 및 정책을 구현하기 위한 권한을 설정하기 위한 수단으로 오픈 소스 전략을 사용합니다. 106 | 107 | ### 주요 질문 108 | 109 | 실용적인 오픈 소스 전략을 세울 때 세 가지 주요 질문에 답해야 합니다. (처음 두 질문은 어느 순서로든 해결할 수 있습니다.) 110 | 111 | **조직은 어디에서 오픈 소스를 사용하기를 원합니까?** 112 | 113 | 오픈 소스 관리에 대한 모범 사례는 다양한 사용 사례에 따라 상당히 다르기 때문에 이 질문은 매우 중요합니다. 예를 들어, 오픈 소스 도구를 사용하면 내부적으로 위험이 거의 또는 전혀 발생하지 않으며 라이선스 준수 계획이 필요하지 않지만 배포되는 소프트웨어에 오픈 소스를 포함하려면 훨씬 더 많은 고려 사항과 활성화 요소가 필요합니다. 114 | 115 | **오픈 소스를 사용하면 어떤 비즈니스 목표를 달성할 수 있습니까?** 116 | 117 | 우리는 기업이 오픈 소스 소프트웨어를 사용하는 이유에 대해 이미 이야기했습니다. 이들 중 어느 것이 중요한지에 대한 명확성과 동의를 얻으면 다음 단계의 세부 사항에 대한 의사 결정을 크게 촉진할 것입니다. 118 | 119 | **귀하의 조직은 오픈 소스 비즈니스 목표를 달성하기 위해 무엇을 할 것입니까?** 120 | 121 | 이는 오픈 소스 관리 프로그램에 대한 권한을 부여하는 결정입니다. 이상적으로는 수반되는 위험을 효율적으로 관리하면서 오픈 소스를 최대한 활용하기 위한 업계 모범 사례를 반영합니다. 122 | 123 | ## 강의: 오픈 소스 전략의 가치 124 | 125 | ### 오픈 소스 사다리 오르기 126 | 127 | 라이선스에서 커뮤니티 역학, 인재 확보 및 비즈니스 역학에 이르기까지 모든 것을 고려할 때 오픈 소스는 복잡한 주제가 될 수 있습니다. 오픈 소스에서 일반적인 조직의 여정에는 몇 가지 단계가 있습니다. 128 | 129 | ![오픈 소스 사다리 오르기](os-ladder.png) 130 | 131 | 각각을 가져와서 분해해 보겠습니다. 132 | 133 | **사용자** 134 | 135 | 조직의 가장 일반적인 출발점은 상용 제품의 오픈 소스 소프트웨어 사용자입니다. 오픈 소스 구성 요소를 적극적으로 사용하면 차별화 능력이 향상되고 상용 제품을 제공하는 데 소요되는 전체 시간과 비용을 줄일 수 있습니다. 오픈 소스 사용 전략의 필수 구성 요소는 다음과 같습니다: 136 | 137 | - 어떤 오픈 소스 소프트웨어를 사용할지 결정하는 데 도움이 되는 전략적 분류 체계 138 | 139 | - 회사가 오픈 소스 소프트웨어 사용에 대한 모든 의무를 충족하는지 확인합니다. 140 | 141 | - 오픈 소스 사용 평가/승인을 위한 자동화된 워크플로 소프트웨어 배포 142 | 143 | - 모든 오픈 소스 활동에 대한 정보 센터 역할을 하는 오픈 소스 검토 위원회(OSRB; Open Source Review Board) 설립 144 | 145 | - 폐쇄 소스/오픈 소스 소프트웨어의 혼합을 관리하기 위해 엔지니어링, 제품 관리 및 법률 분야의 인력 및 인프라에 대한 추가 투자 창출 146 | 147 | **참여자** 148 | 149 | 회사가 제품 또는 서비스에서 오픈 소스 소프트웨어를 성공적으로 사용하고 나면 오픈 소스 커뮤니티에 참여하도록 전략을 확장할 수 있습니다. 커뮤니티에서 이미 경험 많은 개발자를 고용하지 않은 경우 먼저 커뮤니티와 더 긴밀하게 협력하여 가시성을 높이고 필요한 인재를 유치해야 합니다. 오픈 소스 참여 전략의 필수 구성 요소는 다음과 같습니다: 150 | 151 | - 채팅 서버, 메일링 리스트, 포럼 및 웹사이트와 같은 커뮤니티 커뮤니케이션 플랫폼을 모니터링하여 프로젝트 개발에 대한 정보를 유지합니다. 152 | 153 | - 관련 컨퍼런스 및 밋업에 참석하여 지역사회와의 관계 구축 154 | 155 | - 커뮤니티 내에서 가시성을 향상시키기 위해 프로젝트 이벤트 및 재단 후원 156 | 157 | - 오픈 소스 프로젝트에 참여하고 기여하는 방법에 대한 개발자 교육 158 | 159 | **기여자** 160 | 161 | 회사의 참여가 증가하고 오픈 소스 프로젝트에 코드를 제공하기 시작하면 회사의 요구 사항을 주도하기 위해 대상 프로젝트 및 커뮤니티에 선택적으로 참여해야 합니다. 162 | 163 | 전략적 오픈 소스 프로젝트에 기여하는 것은 코드 기여가 회사의 요구를 충족하는 프로젝트의 미래 기능을 형성하는 데 도움이 될 수 있으므로 조직이 추가 가치를 얻는 데 도움이 될 수 있습니다. 164 | 165 | 오픈 소스 기여 전략의 필수 구성 요소는 다음과 같습니다: 166 | 167 | - 오픈 소스 전략을 이끌고 OSRB를 관리할 스태프 디렉터를 고용합니다. 168 | 169 | - 제품에 중요한 주요 오픈 소스 커뮤니티에 기여자와 커미터를 고용합니다. 170 | 171 | - 오픈 소스 사용 및 기여를 지원하는 오픈 소스 협업 도구 배포 172 | 173 | - 오픈 소스 개발자 리소스 추가 174 | 175 | - 기존 외부 커뮤니티에 참여하기 위해 엔지니어링, 제품 관리 및 법률 분야에 점진적으로 투자 176 | 177 | **리더** 178 | 179 | 오픈 소스 기술의 일부가 비즈니스 또는 제품에 중요하게 되면 해당 프로젝트의 전략 및 기술 방향에 대한 발언권이 필요할 것입니다. 그러나 기존 소프트웨어와 달리 단순히 돈으로 리더십을 '구매'하거나 영향력을 행사할 수는 없습니다. 오픈 소스 프로젝트에서 작업을 수행하는 사람은 방향을 설정하는 데 도움이 되는 사람입니다. 180 | 181 | 오픈 소스 전략 사다리의 마지막 단계는 리더십입니다. 이 시나리오는 기술의 새로운 트렌드를 활용하여 리더십 위치를 확립하기 위해 이전의 모든 시나리오를 기반으로 합니다. 182 | 183 | 기존 오픈 소스 커뮤니티에서 리더십 역할은 프로젝트 구성원과의 신뢰를 구축하고 프로젝트에 대한 높은 수준의 지속적인 기여를 유지함으로써 얻을 수 있습니다. 184 | 185 | 이 시나리오에는 대상 오픈 소스 커뮤니티 및 컨소시엄에 상당한 투자가 필요합니다. 186 | 187 | 리더십 의제를 설정합니다. 오픈 소스 리더십 전략의 필수 구성 요소는 다음과 같습니다: 188 | 189 | - 타겟 오픈 소스 커뮤니티와의 참여 증대 190 | 191 | - 회사의 요구 사항을 주도하기 위해 개방형 표준에 선택적으로 참여 192 | 193 | - 오픈 소스 재단에 참여 194 | 195 | - 오픈 소스 프로젝트, 조직 또는 재단 설립 196 | 197 | - 외부 커뮤니티 및 산업 컨소시엄에서 리더십을 구축하기 위해 주로 엔지니어링, 제품 관리 및 법률 분야에 상당한 투자 198 | 199 | ### 현재와 미래의 요구 사항 고려 200 | 201 | 보시다시피 오픈 소스 전략의 자연스러운 진화는 시간이 지남에 따라 투자를 늘려야 하는 일련의 단계를 기반으로 합니다. 조직에서 수행해야 하는 역할에 대한 결정은 사용하는 모든 오픈 소스 프로젝트 또는 코드베이스에 따라 다릅니다. 202 | 203 | 어떤 경우에는 소규모의 견고하게 유지 관리되는 오픈 소스 프로젝트의 단순한 사용자로 받아들일 수 있지만, 다른 경우에는 오픈 소스 프로젝트가 제품 또는 기술의 핵심 요소가 된다면 적극적인 참여자 및/또는 기여자. 204 | 205 | 오픈 소스 프로젝트가 비즈니스 및 제품의 기본이라면, 특히 조직이 시작하는 데 도움이 된 오픈 소스 프로젝트인 경우 해당 노력의 리더가 되기 위해 노력하는 것이 좋습니다. 206 | 207 | 고려해야 할 또 다른 중요한 요소는 조직이 프로젝트에 참여할 수 있는 수준이 시간이 지남에 따라 변한다는 것입니다. 전략을 수립하는 것은 '한 번만 끝내면 되는' 이벤트가 아닙니다. 정기적인 간격(6개월 - 1년은 일반적인 기간)으로 오픈 소스 전략을 주기적으로 검토하여 비즈니스 또는 경제적 요인에 따라 참여를 조정해야 하는지 여부를 결정할 준비를 하십시오. 208 | 209 | ![시간이 지남에 따라 참여도 증가](involvement-over-time.png) 210 | 211 | ## 강의: 구현 고려 사항 212 | 213 | ### 단계적 구현 214 | 215 | 오픈 소스에는 '일찍 릴리스, 자주 릴리스'라는 문구가 자주 인용됩니다. 코딩의 맥락에서 이것은 시간이 지남에 따라 서로를 기반으로 하는 많은 작은 변경으로 변환되어 모든 변경 사항에 대한 완전하고 쉬운 코드 검토는 물론 제공된 변경 사항이 테스트 및 디버그하기 더 쉽기 때문에 보다 강력한 코드를 허용합니다. 216 | 217 | 오픈 소스 전략을 개발할 때 동일한 모델을 사용할 수 있고 사용해야 합니다. 단기 및 중기 목표와 연결된 기본 전략으로 시작하여 오픈 소스 프로젝트 및 커뮤니티에 참여하기 시작한 다음 조직에 따라 전략(및 개발해야 할 후속 정책)을 조정할 수 있습니다. 오픈 소스 방식으로 더욱 편안하고 자신감을 갖게 됩니다. 218 | 219 | 일반적으로 단계적 접근 방식은 일반적으로 이전에 표시된 사다리 그래픽을 따릅니다: 220 | 221 | - 효과적이고 효율적인 방식으로 오픈 소스를 사용하기 위한 전략(및 정책) 구축 222 | 223 | - 상호작용/질문, 버그 보고 등을 통해 오픈 소스 프로젝트 및 커뮤니티에 참여하기 시작합니다. 224 | 225 | - 처음에는 작은 기여를 하십시오(코드가 아니더라도 - 문서화는 시작하기에 좋은 방법입니다) 226 | 227 | - 오픈 소스 프로젝트에 더 익숙해지고 의존하게 됨에 따라 기여도를 높입니다. 228 | 229 | - '좌석'이 필요한 경우(또는 프로젝트 시작을 도운 경우) 오픈 소스 프로젝트에 지속적이고 가치 있는 기여와 투자를 하십시오. 230 | 231 | ### 전략의 구현 고려 사항 232 | 233 | 다음 섹션에서 오픈 소스 조직 정책 생성에 대해 다루겠지만, 이는 전략을 구현하기 위해 배치할 정책에 대한 전략의 영향을 고려할 수 있는 좋은 기회입니다. 234 | 235 | 당신이 생각해야 할 가장 큰 고려 사항은 시간과 돈입니다. 전략을 실행할 때 얼마나 많은 시간을 사용해야 합니까? 그리고 선택한 전략을 실행하기 위해 얼마나 많은 자원(돈과 직원)을 투입할 준비가 되어 있습니까? 236 | 237 | **시간** 238 | 239 | 기술의 다른 거의 모든 것과 마찬가지로 오픈 소스를 효과적으로 사용하려면 시간 투자가 필요합니다. 이는 인적 자원(직원)의 관점에서뿐만 아니라 사용할 오픈 소스 프로젝트의 릴리스 주기를 효과적으로 이해하고 계획하는 것입니다. 모든 프로젝트에 동일한 릴리스 주기가 있는 것은 아니므로 사용하는 코드 버전과 사용 시기를 결정하기 위해 정책을 적용할 때 이를 인식해야 합니다. 240 | 241 | 다른 모듈에서 보안을 다루고 새로운 오픈 소스 릴리스를 최신 상태로 유지하는 동안 오픈 소스 프로젝트에 대한 사용 및 직원 참여와 관련하여 결정을 내릴 시간 프레임을 고려해야 합니다. 242 | 243 | **돈** 244 | 245 | 오픈 소스 소개 과정에서 우리는 오픈 소스가 라이선스 비용에서 '무료'일 수 있다는 것을 간략하게 다루었지만, 그렇다고 해서 오픈 소스와 관련된 다른 비용이 없다는 것을 의미하지는 않습니다. 246 | 247 | 단순히 효율적이고 전략적으로 사용하거나 특정 표준을 추진하는 것과 상관없이 오픈 소스에 효과적으로 참여하는 것은 주로 인력 영역에서 비용이 듭니다. 대규모 직원으로 시작할 필요는 없지만(나중에 자세히 설명), 소프트웨어 엔지니어와 지원 직원(법률, 비즈니스, 프로젝트 관리)의 측면에서 모두 필요로 하는 사항을 고려해야 합니다. 조직의 오픈 소스 노력을 관리하는 데 도움이 되는 정책을 마련하십시오. 248 | 249 | 시간과 비용 요소를 고려하고 시간이 지남에 따라 합리적인 계획으로 천천히 시작하는 것이 오픈 소스 전략에서 파생된 정책이 장기적으로 성공하도록 하는 가장 좋은 방법입니다. 250 | 251 | ### 전략적 목표의 예 252 | 253 | 다음은 전략 수립 프로세스를 진행하면서 정의할 수 있는 몇 가지 목표의 예입니다. 이것은 완전한 목록이 결코 아닙니다. 조직에는 이 목록이 모두 있거나 이 목록에 포함되지 않은 잠재적으로 다른 목표가 있을 수 있습니다: 254 | 255 | - 기술 리더와의 협업을 통한 혁신 증대 256 | 257 | - 이미 개발 및 테스트된 코드를 사용하여 배포 속도 향상 258 | 259 | - 이미 디버깅된 무료 코드를 사용하여 개발 비용 절감 260 | 261 | - 상용 도구 및 구성 요소에 대한 무료 대안을 사용하여 배포 비용 절감 262 | 263 | - 커뮤니티 유지보수를 활용하여 코드 유지보수 비용 절감 264 | 265 | - 다른 오픈 소스 소프트웨어와의 상호 운용성 제공 266 | 267 | - 파트너 또는 고객의 새로운 기능 생성 촉진 268 | 269 | - 새로운 시장 또는 사실상의 표준 수립 270 | 271 | - 최고의 기술 인재를 채용하고 유지 272 | 273 | ### 취해야 할 조치의 예 274 | 275 | 다음 섹션에서 오픈 소스 정책을 정의하는 방법에 대해 자세히 설명하겠지만 전략을 구축하는 동안 정의한 목표를 지원하기 위해 취할 수 있는 몇 가지 샘플 작업은 다음과 같습니다: 276 | 277 | - 평가 정책 및 획득 프로세스 278 | 279 | - 오픈 소스, 사용 가능한 상용 및 내부 개발 옵션 중에서 잘 선택 280 | 281 | - 귀하의 사용 및 IP 전략과 호환되는 라이선스 조건을 보장합니다. 282 | 283 | - 지원 및 수명 주기 비용 고려 284 | 285 | - 어떤 소프트웨어가 어디에 사용되는지에 대한 정확한 지식을 제공하는 코드 추적 정책 및 프로세스 286 | 287 | - 설정된 정책을 준수하는지 확인하는 감사 프로세스 288 | 289 | - 모든 OSS 라이선스 요구 사항이 일관되게 충족되도록 보장하는 규정 준수 프로세스 290 | 291 | 액션은 오픈 소스 전략에서 "고무가 길을 치는 곳"입니다. 특정 목표를 목표로 하는 것은 오픈 소스 관리 프로그램에 대한 권한을 생성하고 형성합니다. 292 | 293 | 위의 작업은 전체 오픈 소스 관리 프로그램의 가장 기본적인 요소입니다. 그러나 일부 조직에서는 이러한 요소가 모두 필요하지 않을 수 있습니다. 예를 들어, 제품에 오픈 소스를 배포하지 않는 조직은 일반적으로 라이선스 준수 프로세스를 구현할 필요가 없습니다. 일부 조직에서는 소프트웨어 지원 및 유지 관리, 소프트웨어 보안을 보장하기 위한 단계, 오픈 소스 기여 또는 리더십에 대한 목표 또는 경영진 참여에 대한 특정 권한과 같은 다른 조치를 추가합니다. 294 | 295 | 일부 조직은 긴급성 또는 실행 순서를 나타내기 위해 전략 성명서에서 작업의 우선 순위를 지정합니다. 일부 조직에서는 개별 작업에 소유자를 할당하는 것이 유용합니다. 296 | 297 | 오픈 소스 관리 프로그램의 개발이 다음 단계로 이동함에 따라 이러한 행동 지침은 이 전략을 구현하는 정책 및 프로세스에 적용됩니다. 298 | 299 | # 섹션: 오픈 소스 정책 개발 300 | 301 | ## 수업: 소개 302 | 303 | ### 섹션 개요 304 | 305 | 이 섹션에서는 선택한 오픈 소스 전략을 실행하기 위한 프레임워크를 설정하는 오픈 소스 정책을 개발하는 방법에 대해 설명합니다. 이러한 정책의 성공과 조직적 채택에 영향을 미치는 핵심 요소에 특히 중점을 둘 것입니다. 306 | 307 | ### 학습 목표 308 | 309 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 310 | 311 | - 선택한 전략의 실행을 주도하는 오픈 소스 정책을 구현하는 프로세스를 설명합니다. 312 | 313 | - 정책을 정의할 때 고려해야 할 주요 고려 사항 이해 314 | 315 | - 조직에서 광범위한 채택을 장려하는 정책을 가장 잘 설계할 수 있는 방법을 설명합니다. 316 | 317 | - 오픈 소스 정책 개발을 위한 업계 모범 사례의 역할 명시 318 | 319 | ## 강의: 오픈 소스 정책 영역 개요 320 | 321 | ### 내 오픈 소스 정책은 무엇에 중점을 두어야 합니까? 322 | 323 | 오픈 소스의 여정을 시작하는 조직은 때때로 'FUD'(두려움, 불확실성, 의심)의 관점에서 정책을 정의해야 하는 작은 부분에서 수렁에 빠집니다. 향후 모듈에서 오픈 소스 규정 준수와 같은 영역에 대한 더 자세한 내용을 다루게 되지만, 위험 회피뿐만 아니라 보다 효과적인 활용의 관점에서 오픈 소스 정책을 수립할 때 모든 조직이 고려해야 하는 영역에 대한 일반적인 개요를 제공하고자 합니다. 324 | 325 | 또한 가장 먼저 집중해야 하는 정책과 최대 효과를 위해 조직 전체에서 이러한 정책을 사회화하는 방법을 모두 고려할 수 있는 방법을 설명하려고 합니다. 326 | 327 | 이를 위해 먼저 모든 조직의 오픈 소스 정책에 있어야 하는 요소를 제시합니다. 이것이 반드시 완전한 목록은 아니며 특정 비즈니스 상황에 따라 추가 항목이 있을 수 있습니다: 328 | 329 | - **발견** 330 | 331 | - **검토 및 승인** 332 | 333 | - **상업 조달** 334 | 335 | - **코드 관리 및 유지보수** 336 | 337 | - **커뮤니티 상호작용** 338 | 339 | - **규정 준수** 340 | 341 | - **경영진 참여** 342 | 343 | ### 발견 344 | 345 | 오픈 소스 검색 및 평가에서는 팀이 관심 있는 오픈 소스 소프트웨어를 찾는 방법과 위치, 그리고 해당 소프트웨어가 조직의 소프트웨어 포트폴리오에 포함되도록 심사된 기준을 다룹니다. 발견은 성공하거나 실패한 노력이 되어서는 안 됩니다. 올바른 방향과 기준(임시와 비교)으로 시작하면 때때로 어려운 이 프로세스를 간소화하고 향후 문제를 피할 수 있습니다. 346 | 347 | 유용한 오픈 소스를 발견하는 것은 거의 백지 상태에서 시작되지 않습니다. 대부분의 조직은 이미 일부 오픈 소스 소프트웨어를 사용하고 있으며 이 코드는 내부(승인된) 저장소의 기반을 형성할 수 있습니다. 기존 포트폴리오 외부를 볼 때 엔지니어는 창의력을 발휘할 수 있지만 위험을 줄이고 효율성을 높이려면 모범 사례에 따라 상용 공급업체 배포(Red Hat, Google 또는 기타 조직)를 통해 신뢰할 수 있는 소스 집합을 설정해야 합니다. , 또는 Cloud Native Computing Foundation과 같은 소프트웨어 기반을 통해. 348 | 349 | 또한 적절한 오픈 소스 프로젝트 코드 및 버전을 찾고 선택하기 위한 다양한 커뮤니티, 정부 및 상업용 도구가 존재합니다. 예를 들어 OpenHub는 수천 개의 인기 있는 프로젝트에 대한 우수한 메타데이터를 제공하고 Github 자체는 프로젝트 릴리스에 대한 대시보드 정보를 제공합니다. 주요 보안정보는 NIST 취약점 데이터베이스와 오픈소스 취약점 데이터베이스 프로젝트에서 얻을 수 있다. 350 | 351 | 이러한 검색 정책을 개발하는 데 조직의 모든 수준을 참여시키는 것이 중요합니다. 엔지니어에게 추가 설명 없이 특정 내부 저장소를 제외하고는 오픈 소스를 사용할 수 없다고 말하고 의사 결정 프로세스에 참여시키지 않으면 '창의적인' 시도로 이어질 가능성이 높습니다. 나중에 규정 준수를 더 어렵게 만드는 이 정책을 우회합니다. 352 | 353 | ### 검토 및 승인 354 | 355 | 검색 프로세스가 아무리 조심스럽거나 부지런하더라도 오픈 소스 코드가 직면한 실제 테스트는 검토 및 승인 프로세스에서 시작되어야 합니다. 승인 및 검토는 오픈 소스에 수반될 수 있는 보안, 법률 및 운영 위험에 대한 첫 번째 방어선입니다. 356 | 357 | 검색과 마찬가지로 이전에 검증된 코드를 활용하면 이 프로세스의 속도를 높일 수 있으므로 오픈 소스 팀이 아직 수행하지 않은 경우 모범 사례에 따라 승인된 구성 요소 및 버전 목록, 검토 및 승인된 라이선스 유형, 이전에 사용한 평가 근거 생성이 필요합니다. 그리고 결과. 358 | 359 | 명확한 기준을 구축하고(엔지니어에서 프로그램 관리자에 이르기까지 모든 이해 관계자를 포함) 발견 중 문제를 방지하고 검토 속도를 높입니다. 또한 이 프로세스의 속도를 높이고 비용을 절감하며 엔지니어링 팀이 이러한 정책을 준수하도록 더 많은 인센티브를 제공할 수 있는 저위험 승인을 위해 이 정책에서 바로 가기를 구축하는 것을 고려하는 것이 중요합니다. 360 | 361 | ### 상업 조달 362 | 363 | 오픈 소스 코드를 발견하고 통합하는 것을 처음 생각할 때 주로 인터넷을 통해 무료로 획득한 코드를 생각하는 것이 당연합니다. 그러나 상당한 양의 오픈 소스 코드가 상업적 소싱을 통해 조직에 침투합니다. 오픈 소스는 종종 상용 응용 프로그램과 함께 제공되거나 필수적인 부분이며 계약 개발에서 결과물로 자주 찾아옵니다. 364 | 365 | 상업적으로 소싱된 오픈 소스에 수반되는 위험 및 규정 준수 의무는 직접 획득한 오픈 소스와 함께 제공되는 위험 및 준수 의무와 다르지 않습니다. 가장 큰 차이점은 조직에서 오픈 소스 코드를 직접 다운로드하여 다운로드하는 대신 일반적으로 오랜 기간 지속되는 기존 조달 프로세스를 통해 암시적으로, 심지어 조용히 해당 코드를 수신한다는 것입니다. 366 | 367 | 상업적으로 소싱되는 오픈 소스의 경우 업계 모범 사례는 조직의 공급망 및 소싱 담당자와 협력하여 다음에 대한 정책을 수립하고 시행하도록 지시합니다: 368 | 369 | - 타사 코드에 오픈 소스 요소의 존재 보고 370 | 371 | - IP 확인 및 적절한 경우 배상 372 | 373 | - 보고를 보완하기 위한 공급업체 거버넌스 프로그램의 코드 스캔 및 검토(있는 경우) 374 | 375 | - 다운스트림 구성 요소 추적, 릴리스 감사 및 기타 규정 준수 활동과의 문서화 및 통합 376 | 377 | ### 코드 관리 및 유지보수 378 | 379 | "코드 소유권"이라는 개념은 지난 10년 반 동안 오픈 소스로 작업한 수십 개의 회사 관행에서 비롯되었습니다. 가장 높은 수준에서 이 관행은 조직 내에서 오픈 소스 코드에 "얼굴"을 제공하고 코드와 코드를 개발하고 유지 관리하는 커뮤니티에 "가까운" 사람을 제공합니다. 또한 일반적으로 코드 소유권 역할에는 직접 또는 제3자를 통해 해당 코드에 대한 조정 지원이 포함됩니다. 380 | 381 | "소유권"의 필요성은 오픈 소스의 "셀프 서비스" 특성에서 비롯됩니다. 관리 정책은 이러한 구성 요소에 필요한 관리 유형과 코드 소유자의 역할 및 책임을 지정해야 합니다. 382 | 383 | 코드 관리 및 유지 관리와 관련된 기타 작업은 다음과 같습니다: 384 | 385 | - 외부 소스 오픈 소스 아카이빙 386 | 387 | - 공유 및 재사용을 위한 기반으로 내부 사용을 위한 현재 마스터 사본(업데이트, 패치 등 포함) 생성 388 | 389 | - 감사 추적으로 소유권, 승인 및 기타 결정 추적 390 | 391 | 함께 제공되는 지원 모델은 위험과 오버헤드가 적으면서 유연하고 확장 가능하며 지속 가능해야 합니다. 옵션에는 다음이 포함됩니다: 392 | 393 | - 내부 지원(자원이 있는 경우 전문성이 강하고 위험이 낮음) 394 | 395 | - 상업 지원 수집기 396 | 397 | - 기술적으로 복잡한 구성 요소 또는 높은 비즈니스/기술적 위험이 있는 구성 요소를 위한 비즈니스 크리티컬 구성 요소 및/또는 플랫폼에 대한 집중 공급업체 지원 398 | 399 | ### 커뮤니티 상호 작용 400 | 401 | 오픈 소스 소프트웨어는 일반적으로 같은 생각을 가진 개발자 커뮤니티에서 만들고 유지 관리합니다. 이러한 커뮤니티에 참여하면 교육에서 지원, 버그 수정 등에 이르기까지 오픈 소스 소프트웨어를 통합하고 배포하는 조직에 다양한 혜택이 주어집니다. 402 | 403 | 커뮤니티 상호 작용은 이진 결정이 아닙니다. 참여는 대신 연속체입니다. 당신과 당신의 동료들은 OSS의 사용자로서의 소박한 시작부터 지속적인 참여와 리더십에 이르기까지 다양한 활동에 걸쳐 다양한 역할에 참여하도록 선택할 수 있습니다. 참여 수준은 유기적으로 발전할 수 있지만 커뮤니티 상호 작용 수준이 조직의 비즈니스 목표와 일치하고 비용-편익 분석을 기반으로 하는 경우 항상 가장 좋습니다. 404 | 405 | 고려해야 할 몇 가지 상호 작용 수준은 다음과 같습니다: 406 | 407 | 1. 불참(권장하지 않음) 408 | 2. 개인으로 참여 409 | - 회사와의 결속은 불가 410 | 3. 회사를 대신하여 커뮤니티에 참여 411 | 412 | 1. IP 전송 없음 413 | 414 | 2. 요구 사항 또는 버그 수정 기여 415 | 416 | 3. 자체 개발한 바이너리, 라이브러리 등을 전달 417 | 418 | 4. 커뮤니티에 후원 또는 지원 제공 419 | 420 | 5. 기업 IP를 OSS로 공개하고 기업이 관리하는 오픈소스 프로젝트 구축 421 | 422 | ### 규정 준수 423 | 424 | 규정 준수는 오픈 소스 정책 및 오픈 소스 라이선스 조건 준수에 중점을 둡니다. 라이선스 준수는 소프트웨어를 배포하는 조직을 위한 오픈 소스 관리에서 가장 눈에 띄는 부분이며 종종 오픈 소스 프로그램 오피스을 설립하기 위한 추진력을 제공합니다(자세한 내용은 다음 강의 모듈 참조). 425 | 426 | 그러나 규정 준수는 좋은 거버넌스의 "전부" 또는 "완전한 것"이 아닙니다. 아무도 라이센스 준수의 특권을 위해 주로 오픈 소스 소프트웨어를 사용하지 않습니다. 규정 준수는 "경찰 조치"가 아니라 오픈 소스 관리의 다른 차원과 동등하게 취급되어야 합니다. 427 | 428 | 소프트웨어를 배포하지 않는 조직의 경우 소프트웨어 시스템 및 애플리케이션의 보안, 안정성 및 지원 가능성을 보장하기 위해 오픈 소스 정책 및 프로세스를 준수하는지 확인하는 데 규정 준수가 중점을 둡니다. 429 | 430 | 규정 준수 정책은 명시적이고 상세해야 하며 조직 정책과 오픈 소스 라이선스 조건을 모두 준수하기 위한 규칙이 명시되어 있어야 합니다. 규정 준수의 필요성은 수반되는 용어(예: 소스 코드 공개, 속성 등)와 함께 각 릴리스에서 제3자 코드(오픈 소스 포함)를 식별하고 카탈로그화할 수 있는 요구 사항을 강조합니다. 431 | 432 | ### 경영진 참여 433 | 434 | 오픈 소스 관리는 실제로 코드를 만지는 개발자만의 영역이 아닙니다. 또한 지적 재산권(IP) 보호와 관련된 기업 변호사의 권한 하에 있는 것도 아닙니다. 성공적인 오픈 소스 관리는 많은 역할과 분야의 참여를 요구하는 공동 작업입니다. 435 | 436 | 종종 무시되는 참여자 집합 중 하나는 조직의 임원입니다. 경영진은 처음에 오픈 소스 기술을 단순히 기술 구현의 세부 사항으로 생각할 수 있으며 명령 체인을 통해 오픈 소스 관리에 참여하는 것으로 만족할 수 있습니다. 깨달은 경영진은 오픈 소스의 위험/이익 균형과 혁신 및 차별화의 잠재력을 인식하여 오픈 소스 관리 정책과 관련된 주요 결정에 경영진의 참여도를 높일 것입니다. 437 | 438 | 경영진은 다음 정책 영역에서 자신의 역할을 고려하는 것이 중요합니다: 439 | 440 | - 전반적인 오픈소스 정책 수립 및 발전에 참여 441 | 442 | - 오픈소스 검토 및 승인 참여 443 | 444 | - 일반적으로 법률 및 비즈니스 라인을 통해 445 | 446 | - 오픈소스 기여, 프로젝트 후원 등에 관한 고위급 의사결정 참여 447 | 448 | - 오픈소스 활동에 대한 정기 보고서 접수 및 검토 449 | 450 | ## 강의: 정책 구현 고려 사항 451 | 452 | ### 정책 생성의 인적 요소 453 | 454 | 오픈 소스와 관련된 정책 생성에는 조직에서 생성하는 데 사용할 수 있는 기존 HR 또는 기타 정책과 다른 몇 가지 흥미로운 인적 역학이 있습니다. 오픈 소스의 협업 및 '커뮤니티 주도' 특성은 일련의 엄격하거나 형식적인 프로세스보다 작업을 완료하는 데 더 중점을 둡니다. 455 | 456 | 협업은 여기에서 핵심 요소입니다. 이러한 정책을 징벌적이거나 위험을 제거하는 방법으로 엄밀히 고려하기보다는 엔지니어, 프로그램 관리자, 법률 전문가, 심지어 경영진을 포함한 다양한 그룹이 최대한 활용하는 방법에 대해 투명하고 솔직한 토론을 할 수 있는 기회도 고려해야 합니다. 오픈 소스에 대한 조직의 참여. 457 | 458 | 경우에 따라 경영진이 다른 그룹(일반적으로 엔지니어링)과 항상 일치하지 않는 정책에 대한 결정을 내려야 할 수도 있지만 모든 사람에게 정책 생성 방식에 대한 의견을 제공하면 모든 사람이 더 쉽게 규정을 준수하고 정책이 조직에 어떻게 의미가 있는지 확인합니다. 459 | 460 | ### 경제 및 생산성 고려 사항 461 | 462 | 오픈 소스 정책을 작성할 때 고려해야 할 또 다른 요소는 정책 구현이 작업 생산성에 영향을 미치고 따라서 간접적으로 조직에 미치는 경제적 영향입니다. 463 | 464 | 가능한 모든 경우를 포괄하고 방대한 인적 및 기술적 인프라를 필요로 하는 완전히 '방탄' 정책을 구축하는 것은 '가장 안전한' 접근 방식처럼 보일 수 있지만, 이는 소프트웨어 개발을 느리고 다루기 힘들고 불쾌하게 만드는 등 의도하지 않은 결과를 초래할 수 있습니다. 엄격한 정책이 없는 조직은 중요한 소프트웨어 인재를 잃을 위험이 있습니다. 465 | 466 | 또한, 이러한 무거운 정책에 필요한 프로세스 인프라를 구축하는 것은 도구와 상세한 인적 감독 모두에서 경제적인 비용이 듭니다. '완벽한 정책'을 구축하려는 유혹에 맞서 싸우는 가장 좋은 방법은 '일찍 릴리스, 자주 릴리스'라는 자주 반복되는 오픈 소스 만트라를 고려하는 것입니다. 오픈 소스 전략을 구현하는 데 필요한 최소한의 정책 집합을 고려하고 관리 팀과 개발 조직이 오픈 소스 참여의 사다리를 올라감에 따라 이를 기반으로 구축하십시오. 467 | 468 | # 섹션: 오픈 소스 프로그램 오피스 소개 469 | 470 | ## 수업: 소개 471 | 472 | ### 섹션 개요 473 | 474 | 이 섹션에서는 전략을 정의하고, 관련 정책을 구현하고, 조직의 오픈 소스 참여를 안내하는 데 있어 OSPO(Open Source Program Office)가 수행하는 역할에 대해 설명합니다. 이 시리즈의 뒷부분에서 OSPO를 설정하고 실행하는 방법에 대해 더 자세히 다룰 것입니다. 475 | 476 | ### 학습 목표 477 | 478 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 479 | 480 | - 오픈소스 프로그램 사무국의 특성 정의 481 | 482 | - 조직의 오픈 소스 노력을 안내하는 오픈 소스 프로그램 사무소의 역할을 설명합니다. 483 | 484 | - 오픈 소스 프로그램 오피스가 오픈 소스 성공에 대한 메트릭을 정의하는 데 도움이 될 수 있는 몇 가지 방법을 명확히 합니다. 485 | 486 | ## 강의: OSPO(Open Source Program Office) 개요 487 | 488 | ### OSPO란 무엇이며 내 조직에 OSPO가 필요한 이유는 무엇입니까? 489 | 490 | 중앙 오픈 소스 프로그램 오피스는 회사 내에서 오픈 소스를 지원, 육성, 공유, 설명 및 성장하는 지정된 장소입니다. 이러한 오피스가 있으면 기업은 명확한 용어로 오픈 소스 전략을 수립하고 실행할 수 있으며 리더, 개발자, 마케팅 담당자 및 기타 직원에게 운영 내에서 오픈 소스를 성공시키는 데 필요한 도구를 제공할 수 있습니다. 491 | 492 | 전통적인 소프트웨어 개발과 오픈 소스 개발의 가장 큰 차이점 중 하나는 오픈 소스에서 사용되는 고도로 협업적인 특성입니다. 많은 기업에서 오픈 소스 사용에 접근할 때 필요한 철학의 변화는 쉽거나 자연스럽게 오지 않습니다. 493 | 494 | 바로 이 부분에서 오픈 소스 프로그램을 만드는 것이 큰 도움이 될 수 있습니다. 오픈 소스 프로그램 오피스을 만들어 기업은 회사의 장기 사업 계획과 직접적으로 연결되는 방식으로 오픈 소스 사용을 활성화, 간소화 및 구성할 수 있습니다. 오픈 소스 프로그램 오피스는 회사의 오픈 소스 운영 및 구조를 위한 우주의 중심으로 설계되어 필요한 모든 구성 요소를 하나로 모으는 데 도움이 됩니다. 495 | 496 | 여기에는 코드 사용, 배포, 선택, 감사 및 기타 정책 설정, 개발자 교육, 법규 준수 보장, 커뮤니티 참여 촉진 및 구축이 포함될 수 있습니다. 오피스는 또한 회사 내부 및 외부의 모든 오픈 소스에 대한 옹호 및 커뮤니케이션을 제공할 수 있습니다. 497 | 498 | ### OSPO의 역할 499 | 500 | 궁극적으로 잘 조직된 오픈 소스 프로그램 오피스는 전략적 이점을 위해 회사 내부에서 오픈 소스 사용, 기여 및 생성을 촉진할 수 있기 때문에 가치가 있습니다. 501 | 502 | 성공적인 오피스는 개발자와 팀을 지원하는 프로세스를 구축하여 기업의 오픈 소스 사용에 큰 이점을 줄 수 있습니다. 표준 코딩 및 조직적 관행, 프로세스 및 도구 집합을 권장합니다. 동시에 프로그램 오피스는 창의적 개발자가 어쨌든 우회하거나 무시할 수 있는 불필요하고 경직된 프로세스를 피하거나 제거하여 프로젝트의 보안 및 기타 측면을 위협할 수 있습니다. 503 | 504 | 프로그램 오피스의 책임은 다양합니다. 여기에는 다음이 포함됩니다: 505 | 506 | - 사내외 오픈소스 전략을 명확하게 전달 507 | 508 | - 전략 실행을 소유 및 감독 509 | 510 | - 상용 제품 및 서비스에서 오픈 소스의 효과적인 사용 촉진 511 | 512 | - 오픈 소스 커뮤니티에 고품질의 빈번한 코드 릴리스 보장 513 | 514 | - 개발자 커뮤니티에 참여하고 회사가 다른 프로젝트에 효과적으로 기여하는지 확인 515 | 516 | - 조직 내 오픈소스 문화 조성 517 | 518 | - 오픈 소스 라이선스 준수 검토 및 감독 유지 519 | 520 | 모든 회사에서 오픈 소스 프로그램 오피스의 역할은 비즈니스, 제품 및 목표에 따라 맞춤 구성될 것입니다. 모든 산업 또는 단일 산업의 모든 회사에 적용되는 오픈 소스 프로그램을 구축하기 위한 광범위한 템플릿은 없습니다. 그렇게 하면 생성이 어려울 수 있지만 다른 회사에서 교훈을 배우고 조직의 요구 사항에 맞게 통합할 수 있습니다. 521 | 522 | 오픈 소스 프로그램 사무소의 또 다른 핵심 역할은 사업부가 계획에서 오픈 소스를 고려하기 시작할 때 대화에 실체와 사실을 가져와서 고려되는 이유, 결과 및 결과에 대한 완전한 이해가 있도록 하는 것입니다. 목표를 달성하기 위해 필요합니다. 이해 관계자가 결정을 내릴 때 어디서부터 시작하고 무엇을 생각해야 하는지 알 수 있도록 대화를 구성하는 것이 중요한 경우가 많습니다. 523 | 524 | ### 성공 지표 정의에서 OSPO의 역할 525 | 526 | 오픈 소스 프로그램 관리자는 자신의 노력에 대한 투자 수익(ROI)을 입증해야 합니다. OSPO가 조직이 오픈 소스 프로그램, 프로젝트 및 기여를 평가하는 몇 가지 표준 방법을 정의하는 데 어떻게 도움이 되는지 살펴보겠습니다. 527 | 528 | 측정할 대상, 성공을 정의하는 방법, 이 정보를 사용하여 오픈 소스 프로그램 목표를 발전시키고 효율성을 입증하며 지원을 얻는 방법을 배우는 것은 모든 OSPO의 중요한 기능입니다. 529 | 530 | 설정한 목표와 추적하는 지표는 개발자 모집, 개방형 혁신을 통한 새로운 아이디어 및 기술 도입, 시장 출시 기간 단축, 개발 비용 절감, 또는 무수히 많은 다른 이유. 531 | 532 | 고유한 전략에 따라 목표를 설정하고 오픈 소스 전략이 전체 비즈니스 전략과 일치하도록 경영진의 동의를 구하는 것이 중요합니다. OSPO는 조직이 이러한 항목에 대해 전략적으로 생각하는 데 도움이 되는 중립적인 장소를 제공할 수 있습니다. 533 | 534 | 숙련된 OSPO 직원은 일반적으로 메트릭을 작성할 때 다음을 고려합니다. 535 | 536 | - 외부 오픈 소스 프로젝트에 대한 개발자의 참여 및 영향력 수준 537 | 538 | - 오픈 소스 커뮤니티에서 조직의 명성 539 | 540 | - 재능 있는 개발자를 모집하고 유지하는 능력 541 | 542 | - 조직의 자체 오픈 소스 프로젝트 및 개발자가 기여하는 비즈니스 크리티컬 프로젝트의 일반적인 상태 543 | 544 | - 오픈 소스 라이선스 규정 준수를 얼마나 잘 관리하는지 545 | 546 | ### OSPO 생성에 대한 최종 생각 547 | 548 | 효과적인 OSPO를 구축하고 실행하는 데에는 다른 많은 측면이 있습니다. 사실 너무 많아서 이 시리즈의 이후 과정 모듈에서 이에 대한 전용 섹션과 강의를 제공할 것입니다. 현재로서는 가장 중요한 고려 사항은 오픈 소스 참여의 리더십/참여 사다리를 계속 올라가면서 결국에는 어떤 형태의 OSPO가 필요하다는 것입니다. 549 | 550 | 전략 및 정책 정의와 마찬가지로 앞서 인용한 '일찍 출시, 자주 출시'라는 격언을 기억하는 것이 중요합니다. 효과적이기 위해 즉시 수백 명의 직원을 OSPO에 배치할 필요는 없습니다. 조직을 안내하는 데 도움이 될 충분한 경험을 가진 오픈 소스 리더와 그들을 도울 수 있는 소규모 직원으로 시작하는 것이 일반적으로 대부분의 조직에 충분한 시작입니다. 551 | 552 | 잘 작동하는 OSPO는 작은 규모에도 불구하고 효율성을 배가시키는 방식으로 다양한 이해관계자(엔지니어링, 제품 관리, 심지어 경영진까지)를 참여시킵니다. 우리는 차후의 모듈에서 OSPO를 위한 오픈 소스 리더십을 찾고 구축하는 것에 대해 더 많이 이야기할 것입니다. 553 | -------------------------------------------------------------------------------- /module4/README.md: -------------------------------------------------------------------------------- 1 | # 효과적인 오픈소스 개발 및 참여 2 | 3 | ## 수업: 소개 4 | 5 | ### 섹션 개요 6 | 7 | ### 이 섹션에서는 오픈 소스 개발 및 커뮤니티 참여에 사용되는 핵심 개념 및 사례를 살펴보고 기존의 폐쇄 소스 개발과 비교할 것입니다. 8 | 9 | 10 | ### 학습 목표 11 | 12 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 13 | 14 | * 핵심 오픈 소스 관행과 효과적인 오픈 소스 개발 및 커뮤니티 참여에서 수행하는 역할 설명 15 | * 폐쇄 소스 소프트웨어 개발과 비교할 때 이러한 개념의 차이점(및 유사점)을 명확히 합니다. 16 | 17 | ## 강의: 요구 사항 및 설계 18 | 19 | ### 오픈 소스 소프트웨어 개발 요구 사항 20 | 21 | 요구 사항은 모든 형태의 소프트웨어 개발에 대한 핵심 고려 사항이며 오픈 소스도 다르지 않습니다. 그러나 요구 사항 수집의 형태와 기능은 많은 기존 소프트웨어 개발 환경에서 사용되는 '폭포' 요구 사항 프로세스와 크게 다릅니다. 22 | 23 | 일반적인 오픈 소스 개발 모델에 대한 다음과 같은 일반적인 개요를 고려하십시오. 24 | 25 | ![오픈 소스 개발 모델](open-source-development-model.png) 26 | 27 | 이 그래픽에서 볼 수 있듯이 '요구 사항'은 일반적으로 사용자 또는 개발자의 '기능 요청'의 형태로 제공되며 개발의 더 반복적이고 민첩한 특성(자세한 내용은 곧)으로 인해 오래 걸리지 않습니다. , 오픈 소스 소프트웨어 개발을 위한 장기간의 요구 사항 단계. 28 | 29 | 이는 변화하는 요구 사항이나 프로젝트가 운영되는 기술 및 비즈니스 환경에 신속하게 대응할 수 있는 능력을 활용한다는 점에서 고유한 장점이 있습니다. 그러나 프로젝트의 장기 전략적 목표를 관리하는 데 도움이 되는 핵심 오픈 소스 유지 관리자뿐만 아니라 상당한 개발자 규율이 필요합니다. 30 | 31 | 이러한 원칙의 대부분은 [Agile Software Development Methodology](https://en.wikipedia.org/wiki/Agile_software_development)의 일부이며 실제로 많은 유사점이 있습니다. 이후 섹션에서 약간의 차이점에 대해 논의할 것입니다. 32 | 33 | 34 | ### 기존 폐쇄형 소프트웨어 개발의 요구 사항 35 | 36 | 점점 더 많은 소프트웨어 개발이 소프트웨어 설계에 Agile 및/또는 [DevOps](https://en.wikipedia.org/wiki/DevOps) 접근 방식을 채택했지만, 여전히 기존의 폐쇄형 소스 또는 독점 소프트웨어 개발 모델의 상당 부분이 있습니다. 여기에 설명된 것처럼 더 '폭포' 접근 방식을 취합니다. 37 | 38 | ![폭포-모델](waterfall-model.png) 39 | 40 | 이 접근 방식은 문서의 완전성 측면에서 몇 가지 장점이 있지만(예:) 일반적으로 오픈 소스 소프트웨어 프로젝트에서 사용하는 더 반복적이거나 민첩한 접근 방식보다 너무 무겁고 속도가 훨씬 느린 것으로 간주됩니다. 또한 대부분의 오픈 소스 소프트웨어 프로젝트에 존재하는 일반적인 지리적으로 분산된 개발 팀으로 구현하는 것이 일반적으로 더 어렵습니다. 41 | 42 | ### 오픈소스 프로젝트의 특징 43 | 44 | 향후 모듈에서 업스트림 오픈 소스 프로젝트 작업에 대해 더 자세히 다룰 것이지만 이러한 커뮤니티에 참여하기 위한 효과적인 개발 사례를 구축하기 전에 이해해야 하는 대부분의 오픈 소스 프로젝트의 몇 가지 공통된 특성이 있습니다. 45 | 46 | 이것이 완전한 목록은 아니지만 거의 모든 오픈 소스 프로젝트의 몇 가지 핵심 특성은 다음과 같습니다. 47 | 48 | * 지리적으로 분산된 개발 팀 49 | * 투명한 커뮤니케이션 및 개발 관행 50 | * 분산되고 투명하고 열린 의사결정 51 | * 능력주의 문화(일을 하는 사람들이 프로젝트 방향을 이끄는 데 도움이 됨) 52 | * 조직 변화에 대한 회복력 53 | * 자기조직화 54 | * 확장 가능한 프로젝트 개발/관리 모델 55 | * 모든 코드 기여에 대한 동료 검토 56 | 57 | ### 확장 가능한 개발 모델 58 | 59 | 성공적인 오픈 소스 개발 노력의 특징은 사용 가능한 참여의 양에 따라 프로젝트를 효과적으로 확장할 수 있는 능력입니다. 다음은 이를 실현하는 구조의 예입니다. 60 | 61 | ![single-body-of-code](single-body-of-code.png) 62 | 63 | 64 | 소규모 프로젝트에는 일반적으로 단일 관리자와 작은 코드 본문이 있습니다. 릴리스는 일반적으로 엄격하게 예약되지 않으며 '준비가 되면' 발표됩니다. 65 | 66 | ![하위 시스템으로 코드 분할](code-diveded-into-subsystems.png) 67 | 68 | 69 | 프로젝트가 약간 커지기 시작하면 여전히 불규칙한 릴리스 주기가 있지만 코드베이스를 하위 시스템으로 나누기 시작할 수 있습니다. 이 단계에서 그들은 여전히 ​​일반적으로 한 명의 유지 관리자만 가지고 있습니다. 70 | 71 | ![릴리스 기준-더 엄격해짐](release-criteria-become-more-stringent.png) 72 | 73 | 74 | 프로젝트가 중간 규모로 이동함에 따라 일반적으로 단일 유지 관리자가 있지만 릴리스 기준은 정기적으로 예정된 릴리스와 함께 더 엄격해지기 시작할 것입니다. 75 | 76 | ![위임 유지 관리](delegated-maintainership.png) 77 | 78 | 79 | 프로젝트가 중간 규모의 표시를 통과하면 기본 유지 관리자가 더 이상 프로젝트의 모든 단일 하위 시스템을 돌볼 수 없는 위임된 유지 관리에 관심을 갖기 시작합니다. 특정 하위 시스템에 대한 전문성이나 열정을 갖고 있는 신뢰할 수 있는 개발자/기여자가 특정 코드 본문을 보살피도록 임명됩니다. 80 | 81 | ![decicated-maintainers 릴리스](release-overseen-by-decicated-maintainers.png) 82 | 83 | 프로젝트가 '대형' 범주로 전환되면 몇 가지 변경 사항이 있습니다. 하위 시스템의 추가 분할(때로는 훨씬 더 개별적인 부분으로)과 더 자세한 수준의 위임된 유지 관리 및 릴리스가 정기적일 뿐만 아니라 관리자가 감독합니다. Linux 커널의 LTE(Long-term Evolution) 커널 분기와 같은 전용 유지 관리자 집합입니다. 84 | 85 | 이러한 구조 및 개발 모델의 핵심 요소는 서로 다른 프로젝트 하위 시스템에 대한 책임을 하위 시스템의 코드에 대한 최종 책임이 있는 '유지 관리자'에게 위임하여 작동한다는 것입니다. 이를 통해 전체 프로젝트 관리자가 프로젝트의 더 큰 전략 및 아키텍처 그림에 집중할 수 있는 수준의 전문화 및 감독이 가능합니다. 86 | 87 | ### 확장 가능한 프로젝트 예 - Linux 88 | 89 | 성공적인 프로젝트가 이 확장 가능한 개발 모델을 실제로 구현하는 방법의 예로 세계에서 가장 성공적인 오픈 소스 프로젝트 중 하나인 Linux 커널을 고려하십시오. 90 | 91 | ![linux-example](linux-example.png) 92 | 93 | Linus Torvalds는 여전히 프로젝트에 대한 전반적인 영향력을 유지하고 있지만 커널의 일부인 여러 하위 시스템에 대해 분산된 유지 관리자 집합에 크게 의존합니다. 모든 오픈 소스 프로젝트가 이 크기로 성장하거나 이 수준의 제어가 필요한 것은 아니지만, 크고 다양한 기여자 기반에 대해 효과적인 제어를 구현할 수 있는 방법을 고려하는 것은 유익합니다. 94 | 95 | ### 오픈 소스의 디자인 고려 사항 96 | 97 | 이제 몇 가지 오픈 소스 프로젝트 특성과 조직 모델을 살펴보았으므로 오픈 소스 프로젝트 내에서 성공적인 디자인 관행의 몇 가지 핵심 교리를 고려해 보겠습니다. 98 | 99 | 디자인이 오픈 소스 프로젝트 내에서 어떻게 나타나는지, 그리고 그것이 보다 전통적인 소프트웨어 개발과 어떻게 다른지 고려하는 것이 중요합니다. 주요 고려 사항은 세 가지 주요 영역으로 나뉩니다. 100 | 101 | 102 | * **공개된 디자인** 103 | * **기타 모집** 104 | * **승인을 위한 디자인** 105 | 106 | 다음 페이지에서 이에 대해 좀 더 자세히 살펴보겠습니다. 107 | 108 | ### 열린 디자인 109 | 110 | 개방성과 투명성은 오픈 소스 개발의 특징이며 디자인도 다르지 않습니다. 다음은 '공개 설계'에 대한 몇 가지 모범 사례입니다. 111 | 112 | * 프로젝트가 선호하는 커뮤니케이션 플랫폼에서 조기에 자주 커뮤니케이션 113 | * 코드 예제 및 가능한 참조 구현 제공 114 | * 피드백 예상 115 | * 좋은 피드백을 인정하고 기여를 다시 작업하십시오. 116 | * 특히 잠재적 기여자의 질문에 신속하게 응답 117 | * 다른 사람이 작업을 수행할 경우 디자인을 적용할 의사가 있음을 나타냅니다. 118 | * 첫 번째 설계가 모듈화되지 않은 경우에도 모듈화 계획 119 | 120 | 유연성도 여기에서 핵심 요소입니다. 기존의 비공개 소스 프로젝트보다 더 많은 사람이 코드를 평가하고 보고 있다는 사실을 이해하는 것은 최상의 디자인 결정을 내리고 프로젝트에 코드 기여를 승인하는 데 중요합니다. 121 | 122 | 모듈식 접근 방식을 취하는 것(또는 최소한 코드를 모듈식으로 만들 수 있는 방법을 계획하는 것)은 모놀리식 디자인이 더 널리 퍼져 있는 기존 개발 모델과 다를 수 있습니다. 처음부터 모듈화에 대해 생각하는 것은 전체 오픈 소스 프로젝트에 도움이 될 뿐만 아니라 그 자체로 좋은 엔지니어링 관행입니다. 123 | 124 | 125 | ### 기타 모집 126 | 127 | 협업은 오픈 소스 프로젝트에서 게임의 이름이며 일반적인 기업 또는 폐쇄 소스 개발 노력에서 일반적으로 사용되는 것보다 훨씬 더 깊은 방식입니다. 128 | 129 | 오픈 소스에서 도움을 줄 다른 사람을 모집할 때 고려해야 할 몇 가지 사항은 다음과 같습니다. 130 | 131 | * 자신의 가려움을 긁으세요. 다른 사람이 당신을 대신해 긁지 않을 것입니다... 같은 가려움이 없다면 132 | * 개발 부담을 줄이려면 다른 사람을 끌어들이는 코드를 작성하십시오. 133 | * 귀하의 기여 범위가 다른 개발자를 끌어들일 수 있을 만큼 광범위해야 합니다. 134 | * 누군가가 당신의 코드에 관심을 보인다면 반응하고 능동적으로 행동하십시오. 135 | * 경쟁자라고 놀라지 마세요 136 | * 종종 오픈 소스 프로젝트의 기능에서 가장 많은 것을 얻을 수 있는 회사가 동일한 비즈니스 라인에 있습니다. 137 | * 경쟁사 간의 오픈 소스 협업의 풍부한 역사가 있습니다. 138 | 139 | 다른 사람들을 염두에 두고 코드를 디자인하는 것은 보다 좁은 범위의 개발 관행보다 더 많은 시간과 노력이 필요하지만 효과적인 오픈 소스 프로젝트의 기여자 기반의 승수 효과를 목격할 때 결국 가치가 있습니다. 140 | 141 | ### 승인을 위한 디자인 142 | 143 | 지금까지 말한 모든 것을 바탕으로 이 시점에서 오픈 소스 참여의 목표는 디자인과 아이디어를 효과적으로 수용하는 방법을 생각하는 것이어야 합니다. 144 | 145 | 이를 돕기 위해 고려해야 할 사항은 다음과 같습니다. 146 | 147 | * 가능한 가장 작은 부분으로 작성되고 통합되도록 기여를 설계하십시오. 148 | * 패치가 작을수록 유지 관리자가 더 쉽게 통합할 수 있습니다. 149 | * 오픈 소스 프로젝트는 확장성을 촉진하기 때문에 모듈식 접근 방식을 선호합니다. 150 | * 설계 범위를 적절하게 지정하고 필요한 경우 계획을 세분화합니다. 151 | * 더 큰 변경 사항은 구체적인 이정표가 있는 일련의 작은 변경 사항으로 채택될 가능성이 높습니다. 152 | * 컨텍스트를 제공하기 위해 전체 계획을 전달하되, 즉시 보편적인 동의를 기대하지 마십시오. 153 | * 가능한 한 다른 프로젝트 하위 시스템에 방해가 되지 않도록 합니다. 154 | * 핵심 시스템 구성 요소를 변경할 필요가 있다고 생각되면 시작하기 전에 훨씬 더 사전에 의사 소통하고 유지 관리자에게 의견을 요청하십시오. 155 | 156 | 코드를 통합하거나 나중에 유지 관리해야 하는 다른 개발자 또는 유지 관리자의 입장이 된다면 승인을 위한 디자인에 대한 적절한 관점을 제공하는 데 도움이 될 것입니다. 157 | 158 | ## 수업: 의사결정 및 개발 주기 159 | 160 | ### 의사결정 과정 및 커뮤니케이션 기대치 161 | 162 | 새로운 방식으로 디자인하는 것에 대해 생각하는 것 외에도 오픈 소스 프로젝트에서 의사 결정이 내려지고 전달되는 방식을 이해하는 것이 중요합니다. 종종 아래 나열된 원칙은 기존 소프트웨어 개발 방법론에서 약간 벗어난 것입니다. 163 | 164 | * 일반적으로 "하위 시스템 유지 관리자"라고 하는 신뢰할 수 있는 대리인을 지정하여 결정을 분산합니다. 165 | * 신뢰는 과거의 좋은 참여 기록과 작은 문제에 대한 현명한 결정으로 구축됩니다. 166 | * 분산된 특성은 투명성에 대한 추가 초점이 필요합니다. 167 | * 토론은 항상 열린 상태에서 이루어집니다. 168 | * 예: 메일링 리스트, IRC, Slack 등 169 | * 종종 토론 자체가 결과에 대한 문서화된 기록입니다(따라서 아카이브가 중요함). 170 | 171 | 간단히 말해서, 전자 형식의 커뮤니케이션은 오픈 소스 프로젝트에 중요할 뿐만 아니라 일반적으로 직접적인 개발 동료와만 커뮤니케이션할 수 있는 기존 소프트웨어 프로젝트보다 더 많은 토론 빈도와 깊이가 있습니다. 172 | 173 | 이와 다소 다른 방식으로 의사소통하기 위해 자신을 이해하고 준비하는 것이 중요하며 이 교육의 뒷부분에서 이에 접근하는 방법에 대해 더 자세히 다룰 것입니다. 174 | 175 | ### 개발 프로세스 및 케이던스 176 | 177 | 케이던스와 관련하여 오픈 소스 개발 프로세스가 어떻게 작동하는지 더 잘 이해하기 위해 이 교육의 앞부분에 제공된 그래픽을 다시 가져와 보겠습니다. 178 | 179 | ![오픈 소스 개발 모델](open-source-development-model.png) 180 | 181 | 오픈 소스 프로젝트는 '**일찍 릴리스, 자주 릴리스**'라는 만트라에 따라 실행됩니다. 위의 그래픽을 기반으로 하면 이것이 분명해 보일 수 있지만 개발 프로세스와 케이던스, 특히 다음과 같은 요소에 영향을 줍니다. 182 | 183 | * 처음부터 코드의 완성도를 기대하지 마십시오 184 | * 목표를 달성하기에 충분할 때 코드를 제출하십시오. 185 | * 코드 안정화는 커뮤니티 프로세스의 일부입니다. 186 | * 개발자 커뮤니티가 코드를 안내하고 구성하는 데 도움을 줄 수 있습니다. 187 | * 가능한 가장 작은 합리적인 청크로 기능 구현 188 | * 작은 변경은 테스트 및 통합이 더 쉽습니다. 189 | * 코드를 재작업(여러 번 가능)할 ​​수 있도록 준비하십시오. 190 | 191 | 오픈 소스 프로젝트에서 코드 제출/재작업의 주기는 일반적으로 보다 전통적인 소프트웨어 개발 환경에 익숙한 개발자에게 가장 큰 차이점이며 오픈 소스 프로젝트에서 사용되는 더 빠른 속도는 익숙해지는 데 약간의 시간이 걸릴 것입니다. 그러나 이러한 작업 방식에 익숙해지면 이러한 방식으로 작업하는 것이 더 자연스럽고 거의 제2의 천성이 된다는 것을 알게 될 것입니다. 192 | 193 | ## 강의: 대규모 분산 개발 팀과 협력 194 | 195 | ### 커뮤니티 196 | 197 | 이 교육의 이전 섹션에서 오픈 소스 프로젝트 및 해당 커뮤니티와 함께 ​​작업하는 역학이 엄격하게 기업 또는 내부 개발 노력에 익숙할 수 있는 것과 약간 다르다는 것이 분명하기를 바랍니다. 198 | 199 | 커뮤니티의 개념은 이해하기 어렵지 않습니다. 우리 대부분은 커뮤니티에 살고 있으며 일상 생활에서 다양한 수준의 커뮤니티를 경험합니다. 그러나 오픈 소스 프로젝트에 적용할 때 고려해야 할 몇 가지 사항이 있습니다. 200 | 201 | 1. **두 커뮤니티가 완전히 똑같지는 않습니다** 202 | 2. **커뮤니티는 개별 회사에서 작동하지 않습니다** 203 | 204 | Linux 커널 또는 Kubernetes와 같은 잘 알려진 오픈 소스 프로젝트 커뮤니티가 있습니다. 이 커뮤니티에는 몇 가지 유사점은 있지만 일반적으로 시작 방법, 적용되는 거버넌스 모델 및 경험의 결과인 다른 '성격'이 있습니다. 그들의 창립 멤버 중. 205 | 206 | 많은 조직이 현재 오픈 소스에 투자하고 있는 것이 사실이지만(예: Kubernetes는 Google에서 시작함) 오픈 소스 프로젝트 커뮤니티는 개별 회사에서 작동하지 않으므로 조직을 위해 작업을 수행하는 것은 지속적인 기여와 좋은 일을 하고 있습니다(좀 더 자세히 설명하겠습니다). 207 | 208 | 오픈 소스 프로젝트가 조직의 '무료 개발자'가 아니라는 점을 이해하는 것은 매우 중요합니다. 그렇게 가정하면 나중에 문제가 될 수 있습니다. 다음 몇 페이지에서 우리는 오픈 소스 커뮤니티에 참여하기 위한 몇 가지 모범 사례를 제공하고 일부 기본 커뮤니케이션 도구 에티켓이 이러한 대규모 분산 개발 팀과 효과적으로 작업하는 데 도움이 되는 방법을 보여줍니다. 209 | 210 | ### 참여 준비 211 | 212 | 커뮤니티와 직접 작업을 시작하기 전에 올바른 발판을 마련할 수 있는 최상의 접근 방식을 조사하고 준비하는 데 약간의 시간을 들이는 것이 종종 도움이 됩니다. 이 연구의 일부는 귀하(또는 귀하의 조직)가 커뮤니티를 지원하기 위해 무엇을 준비하고 있는지 살펴보는 것입니다. 213 | 214 | **무엇을 제공할지 결정** 215 | 216 | 오픈 소스 프로젝트는 단순한 코드 그 이상입니다. 다음과 같은 분야에 기여할 수 있습니다. 217 | 218 | * 소프트웨어 개발 219 | * 테스트/품질 보증 220 | * 문서 221 | * 사용자 경험/GUI 디자인 222 | * 전도/커뮤니케이션 223 | 224 | 이러한 여러 영역에 대한 전문 지식이 있는 경우 여러 역할에 확실히 기여할 수 있습니다. 225 | 226 | **시간 약속 결정** 227 | 228 | 귀하 및/또는 귀하의 조직이 테이블에 가져올 수 있는 시간 약속의 종류에 대해 현실적이라면 도움이 됩니다. 대부분의 커뮤니티는 공허한 도움 제안보다 완성된 작업을 더 존중하므로 현실적으로 전달할 수 있는 것에 전념하십시오. 229 | 230 | 또한 당신의 헌신은 당신뿐만 아니라 당신이 대표하는 조직에도 반영된다는 것을 기억하십시오. 231 | 232 | ### 커뮤니티 알아보기 233 | 234 | 커뮤니티에 참여하기 위한 계획을 세울 때 그들이 누구이며 어떻게 작동하는지에 대한 몇 가지 중요한 사항을 아는 것이 중요합니다. 235 | 236 | #### 커뮤니티의 커뮤니케이션 방식 이해 237 | 238 | 분명히 커뮤니티의 역학을 이해하는 데 있어 가장 중요한 부분은 커뮤니티가 어디에서 어떻게 의사 소통하는지 이해하는 것입니다. 일부 커뮤니티는 여전히 이메일을 선호합니다. 다른 커뮤니티는 IRC(Internet Relay Chat), Slack, Github 문제, Discord 또는 기타 포럼 도구와 같은 비동기 포럼으로 마이그레이션했습니다. 239 | 240 | 어떤 플랫폼이 사용되고 있는지 파악하는 데 시간을 할애할 뿐만 아니라 어떤 종류의 질문을 받았는지, 어떻게 답변을 받았는지, 어떤 다른 정보 소스(버그 추적기, Wiki 등)가 참조되는지 알아보기 위해 잠시 숨어 있습니다. 커뮤니티의 답변에서. 241 | 242 | 이 조사를 수행하고 커뮤니티에서 질문하기 전에 답변을 찾으려고 노력함으로써 기존 커뮤니티 회원에게 귀하가 훌륭한 커뮤니티 회원이 되는 것에 대해 진지하다는 것을 보여주고 있으며 이는 큰 효과가 있습니다. 243 | 244 | #### 커뮤니티 관리 방식 이해 245 | 246 | 커뮤니케이션 포럼에 숨어서 숙제를 하는 것도 프로젝트를 위한 거버넌스 모델을 이해하는 데 도움이 됩니다. 일부 프로젝트는 명확한 명령/보고서 체인이 있는 계층 구조입니다. 일부 프로젝트에는 더 평평한 조직 모델이 있습니다. 247 | 248 | 거버넌스의 역학을 이해하면 기여 준비를 더 잘할 수 있을 뿐만 아니라 커뮤니티에서 어떤 질문에 대답하는 데 가장 적합한지 알 수 있습니다. 249 | 250 | #### 사람들과 친해지기 251 | 252 | 오픈 소스 프로젝트는 기본적으로 지리적으로 분산된 팀을 활용하지만 기여나 아이디어를 얻는 데 도움이 필요하거나 다른 사람에게 도움을 줄 수 있는 위치에 있는 경우가 많기 때문에 커뮤니티 구성원을 개인적으로 알아가는 것이 중요합니다. 받아들였다. 가능하면 새로운 프로젝트 구성원이 기존 프로젝트 베테랑을 알 수 있도록 많은 프로젝트에서 조직하는 대면 또는 가상 모임에 참여하십시오. 253 | 254 | ### 참여합시다! 255 | 256 | 자, 조사를 마쳤으며 이제 오픈 소스 커뮤니티에 참여할 준비가 되었습니다! 약혼에서 생각해야 하는 네 가지 주요 영역이 있습니다. 257 | 258 | #### 작업 중인 내용 전달 259 | 260 | 커뮤니티를 위해 작업 중인 내용을 '비공개로' 작업하지 마십시오. '일찍 릴리스, 자주 릴리스'의 조언을 기억하십시오. 일반적으로 커뮤니케이션 채널을 확인하여 계획한 일이 이미 완료되었는지 확인하는 것뿐만 아니라 새로운 기능을 구축하거나 버그를 수정하려는 의도를 표시하여 커뮤니티(및 유지 관리자)가 기여를 수락하는 가장 좋은 방법을 계획하는 데 도움이 될 수 있습니다. 커뮤니티는 귀하가 성공하기를 원하므로 귀하가 기여를 준비할 때 도움을 받는 것이 좋습니다. 261 | 262 | #### 사용하는 사람과 자원을 인정 263 | 264 | 오픈 소스 프로젝트에 대한 기여는 대부분 다른 프로젝트의 코드를 포함하고 있습니다. 기여에 사용한 다른 작업/라이브러리/개발을 인정하고 커뮤니티가 전체 프로젝트에 도움이 될 수 있는 이러한 외부 자원도 찾도록 도와주세요. 265 | 266 | #### 커뮤니티에 환원 267 | 268 | 소스 코드의 명백한 기여 외에도 조직에서 하드웨어 선물을 주선하거나(가능한 경우) 팀을 위한 모임을 주선하거나 단순히 새 구성원을 위한 질문에 답하는 데 시간을 보내는 것과 같이 커뮤니티에 되돌릴 수 있는 다른 방법을 고려하십시오. 269 | 270 | 소스 코드는 확실히 중요하지만, 진정으로 성공적인 공개SW 프로젝트는 '코드가 아닌' 기여에서도 번창합니다. 271 | 272 | #### 출구 전략 계획 273 | 274 | 언젠가는 귀하의 조직이 커뮤니티를 종료해야 할 수 있습니다. 커뮤니티에 들어온 것보다 더 나은 상태로 커뮤니티를 떠나도록 노력하십시오. 이를 위해 할 수 있는 몇 가지 간단한 작업은 다음과 같습니다. 275 | 276 | * 후임자 또는 코드를 인수할 사람 식별 277 | * 그 후계자를 나머지 커뮤니티에 소개 278 | * 귀하의 퇴장으로 인해 변경해야 할 사항에 대해 계획할 시간을 가질 수 있도록 가능한 한 빨리 커뮤니티에 알리십시오. 279 | 280 | 커뮤니티를 탈퇴하는 경우에도 귀하의 행동은 귀하 및/또는 귀하의 조직에 반영된다는 점을 기억하십시오. 281 | 282 | ### 커뮤니케이션 에티켓 283 | 284 | 대부분의 프로젝트에서 사용되는 두 가지 주요 커뮤니케이션 도구 유형은 일종의 메시징 시스템(이메일, Slack, IRC 등)과 일종의 문제 또는 버그 추적 소프트웨어(JIRA, Github Issues 등)입니다. 다음은 각 유형의 플랫폼을 효과적으로 사용하기 위한 몇 가지 일반적인 팁입니다. 285 | 286 | #### 메시지 287 | 288 | * 대부분의 메시지/통신은 영어로 되어 있습니다. 289 | * 피드백은 단기/집중 버스트로 올 가능성이 높습니다. 290 | * 개인적으로 코드에 대한 비판을 받아들이지 말고 좋은 제안을 받아들이고 코드를 재작업하십시오. 291 | * 코드를 리뷰하는 경우 코드/아이디어를 비판하되 사람을 비판하지 마십시오. 292 | * 시간대를 알고 즉각적인 응답을 기대하지 마십시오. 293 | * 커뮤니티에서 올바른 방향으로 안내할 수 있도록 질문하는 경우 '작업을 보여주세요' 294 | 295 | #### 버그/이슈 추적 296 | 297 | * 버그 보고서를 간결하지만 철저하게 유지 298 | * 보고하려는 내용이 이미 있는지 확인하려면 버그/문제 시스템을 확인하세요. 299 | * 버그를 유발하는 테스트 코드를 포함하여 관련 정보를 충분히 제공합니다. 300 | * 버그를 수정해야 하는 커뮤니티의 의무는 없음을 이해합니다. 직접 수정해야 할 수도 있다는 사실에 대비하세요. 301 | * 버그를 수정하거나 해결 방법을 찾으면 정보에 대한 관련 업데이트를 제공하십시오. 302 | 303 | ### 기억해야 할 상위 4가지 사항 304 | 305 | 오픈 소스 커뮤니티와 처음 작업을 시작할 때 고려해야 할 사항이 많이 있습니다. 그러나 다음 네 가지 사항을 염두에 둔다면 대부분의 상황을 다룰 수 있을 것입니다. 306 | 307 | #### 커뮤니티 거버넌스 이해 308 | 309 | 각 커뮤니티는 다르지만 모든 '패치'는 전체 전체에 맞아야 합니다. 310 | 311 | #### 커뮤니티 동기 이해 312 | 313 | ![기여자란 무엇인가](what-is-a-contributor.png) 314 | 315 | 성공적인 커뮤니티는 동기 부여된 사람들에 의해 운영되며 항상 돈에 의해 동기 부여되는 것은 아닙니다. 동료 인식과 지위는 종종 오픈 소스에서 강력한 힘입니다. 316 | 317 | #### 커뮤니티는 육성이 필요합니다 318 | 319 | 커뮤니티 참여는 주기입니다. 변화를 예상하고 정기적으로 새 회원을 영입할 수 있도록 준비하십시오. 320 | 321 | #### 겸손하되 담대하라 322 | 323 | 오픈 소스의 리더십은 부여되는 것이 아니라 얻는 것이며, 당신이 일하는 조직과 그들의 평판이 반드시 특정 프로젝트에서 당신에게 영향력을 부여하는 것은 아닙니다. 324 | 325 | 리더십과 통제 사이에는 큰 차이가 있음을 기억하는 것이 중요합니다. 대부분의 오픈 소스 커뮤니티는 프로젝트 방향을 과도하게 제어하려는 시도를 주저하지만 참여자가 주도권을 얻기 전에 가치 있는 기여를 할 것으로 기대합니다. 326 | 327 | ![겸손하지만 담대하게](humble-but-bold.png) 328 | 329 | 대담함과 적극적 참여 사이에서 적절한 균형을 유지하면서 피드백을 받고 코드 기여를 재작업할 만큼 겸손해지면 시간과 연습이 필요하지만 이 균형을 염두에 두는 것은 올바른 방향으로 안내하는 데 도움이 됩니다. 330 | 331 | # 지속적인 통합 및 테스트의 역할 332 | 333 | 334 | ## 수업: 소개 335 | 336 | 337 | ### 섹션 개요 338 | 339 | ### 이 섹션에서는 이 중요한 개념과 관련된 도구, 모범 사례 및 비용을 포함하여 오픈 소스에서 지속적인 통합, 테스트 및 배포의 역할에 대해 논의합니다. 340 | 341 | ### 학습 목표 342 | 343 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 344 | 345 | * 지속적인 통합, 테스트 및 배포 설명 346 | * 이러한 관행을 구현하는 데 사용되는 다양한 도구를 설명합니다. 347 | * 이러한 개념을 구현하는 데 드는 비용과 이점을 명확히 합니다. 348 | 349 | ### 강의: 오픈 소스에서 지속적 통합, 테스트 및 배포의 역할 350 | 351 | ### 왜 지속적 통합인가? 352 | 353 | 옛날 옛적에 대부분의 소프트웨어는 종종 같은 위치에서 자주 연락하는 비교적 작은 개발자 그룹에 의해 작성되었습니다. 책임의 조정 및 분할은 간단한 방식으로 수행될 수 있습니다. 354 | 355 | 개정 관리 시스템 **은 프로젝트에서 작업하는 한 명 이상의 기여자를 수용하기 위해 오래 전에 개발되었습니다. 일반적으로 프로젝트의 마스터 사본을 저장하는 저장소**가 있으며, 한 명 이상의 개발자가 변경한 다음 체크인할 수 있습니다. 356 | 357 | 많은 하위 시스템이 있는 프로젝트의 여러 위치에서 작업하는 개발자가 많으면 상황이 더 복잡해집니다. Linux 커널은 최초의 대규모 분산 개발 프로젝트였으며, 그 창시자인 Linus Torvalds는 분산 개발을 합리화하기 위한 git** **시스템을 발명했습니다. 358 | 359 | 그러나 개정 관리 시스템은 다양한 기여자 그룹이 실제로 함께 작동하는지 확인하는 문제를 해결하지 못합니다. 한 세트의 새로운 코드 또는 버그 수정이 다른 세트와 충돌하지 않습니다. 그것은 테스트를 통해서만 가능합니다. 360 | 361 | 테스트에도 다음과 같은 여러 단계가 필요합니다. 362 | 363 | 364 | * 중복되는 변경 세트를 동시에 적용할 수 있거나 충돌을 일으킬 수 있습니다(**git**과 같은 우수한 개정 제어 시스템은 이 작업의 대부분을 처리할 수 있지만 여전히 사람의 개입이 필요한 경우가 많습니다). 365 | * 모든 변경 사항이 적용되면 프로젝트도 컴파일됩니까? 예를 들어, 한 패치 세트가 다른 패치 세트에 필요한 헤더 파일을 제거할 수 있습니다. 이것은 개정 관리 시스템에 의해 선택되지 않습니다. 366 | * 가능한 모든 대상에서 작동합니까? 이는 다른 하드웨어(예: **x86 대 ARM**) 또는 다른 운영 체제(예: **Linux 대 MacOS 또는 Windows**) 또는 다른 라이브러리, 언어 또는 유틸리티 버전을 의미할 수 있습니다. 367 | * **working**은 무슨 뜻인가요? 자신감을 주기에 충분한 대표적인 워크로드를 실행할 수 있는 중요하지 않은 테스트 제품군이 있습니까? 368 | 369 | **지속적 통합** 기술은 테스트가 너무 자주 수행되어 문제가 오래 지속되지 않도록 하여 분산된 개발자가 같은 페이지를 유지하는 데 도움이 됩니다. 370 | 371 | 프로젝트는 변경 사항을 빠르게 흡수하고 실시간으로(보통 하루에 여러 번) 자동화된 테스트를 실행하여 조화로운지 확인합니다. 일반적으로 프로세스는 다음과 같습니다. 372 | 373 | ![지속적인 통합](continuous-integration.png) 374 | 375 | ### 지속적 배포 및 지속적 배포 376 | 377 | 지속적 전달 및 지속적 배포의 전체 프로세스는 세 가지 개별 단계 또는 단계로 설명할 수 있습니다. 378 | 379 | 1. **지속적인 통합** 380 | 381 | 변경 사항은 가능한 한 자주 메인 브랜치("마스터")에 병합되어야 합니다. 자동화된 빌드** **는 가능한 많은 소프트웨어 및 하드웨어 변형에서 실행됩니다. 갈등은 발생하는 즉시 해결됩니다. 382 | 383 | 2. **지속적인 테스트/배송** 384 | 385 | 릴리스 프로세스가 자동화되고 프로젝트가 빌드 소비자에게 제공될 준비가 되었습니다. 모든 관련 플랫폼에서 철저한 테스트가 수행됩니다. 386 | 387 | 3. **지속적인 배포** 388 | 389 | 제품은 다시 한 번 자동화된 방식으로 고객에게 출시됩니다. 390 | 391 | 이러한 단계 사이의 시간 간격은 가능한 한 0에 가깝습니다. 완벽한 세상에서 개발자 변경 사항은 당일 또는 몇 분 안에 최종 사용자 고객에게 도달할 수 있습니다. 이러한 용어는 다소 다르게 정의될 수 있습니다. 예를 들어 지속적 통합은 전달과 배포를 모두 포함하는 것으로 간주할 수 있습니다. 392 | 393 | ### 지속적인 테스트 394 | 395 | 지속적인 배포 및 배포 주기의 핵심 구성 요소는 오픈 소스 코드 기반에서 자주 실행되는 자동화된 지속적인 테스트입니다. 중첩 테스트 주기의 개념은 지속적인 통합(작은 변경 세트에서 기억)을 통해 통합되는 코드가 철저하게 테스트되고 잠재적인 문제를 쉽게 찾아낼 수 있도록 하는 데 사용됩니다. 예는 다음과 같습니다. 396 | 397 | ![중복 테스트 주기](overlapping-test-cycles.png) 398 | 399 | 오픈 소스 프로젝트의 겹치는 릴리스 주기는 전체 소프트웨어 품질을 더 엄격하게 제어하면서 자주 릴리스할 수 있는 기능을 제공합니다. 400 | 401 | ![중복 릴리스 주기](overlapping-release-cycles.png) 402 | 403 | ### 비용 및 혜택 404 | 405 | 분명히 소프트웨어 개발에서 공짜는 없기 때문에 지속적인 배포 및 배포와 관련된 비용과 이점을 고려하는 것이 중요합니다. 다음은 비용 및 이점의 몇 가지 예입니다. 406 | 407 | #### 비용 408 | 409 | * 변경 사항은 최소한 하루에 한 번, 매우 자주 병합되어야 하므로 개발자에게 부담이 될 수 있습니다. 410 | * 저장소는 기여할 때마다 스크립트 자동화 테스트를 실행하는 지속적 통합 서버**에서 모니터링해야 합니다. 이를 수행하려면 직원을 할당해야 합니다. 411 | * 자동화된 테스트를 수행하고 결과를 보고하고 적절한 조치를 취하려면 스크립트 및 기타 도구를 실행해야 합니다. 이 인프라를 준비하는 데 많은 작업이 필요할 수 있습니다. 412 | 413 | #### 혜택 414 | 415 | * 개발자는 잘못된 경로로 이동하여 수정 가능한 실수를 합성하거나 서로 방해하지 않으며 결국 귀중한 시간을 절약할 수 있습니다. 416 | * 빌드 단계는 완전히 자동화되어 있으며 빌드 테스트가 필요할 때마다 모든 작업이 사전에 완료되었습니다. 417 | * 회귀(작동 중인 제품을 중단시키는 버그)를 최소화할 수 있습니다. 즉, 릴리스된 소프트웨어에는 버그가 더 적어야 합니다. 418 | 419 | 지속적인 통합 파이프라인을 설정하는 것은 쉬운 일이 아니며 제대로 하려면 상당한 경험과 노력이 필요할 수 있습니다. 그러나 “1온스의 예방은 1파운드의 치료 가치가 있습니다.” 작업을 덜 힘들게 만드는 데 도움이 될 수 있는 많은 기존 도구와 서비스가 있습니다. 420 | 421 | ### 도구 422 | 423 | 잘 개발된 지속적 통합 소프트웨어 도구가 많이 있습니다. 이러한 제품에 대한 요약은 [https://www.softwaretestinghelp.com/tools/24-best-continuous-integration-tool/](https://www.softwaretestinghelp.com/tools/24-best-continuous-integration-tool)을 참조하십시오. 이들 중 일부는 무료 도구이고 일부는 그렇지 않습니다. 424 | 425 | 426 | 다음은 가장 자주 사용되는 도구입니다. 427 | 428 | * 젠킨스 - [https://jenkins-ci.org](https://jenkins-ci.org) 429 | * 서클CI - [https://circleci.com/](https://circleci.com/docs/skip-a-build) 430 | * 트래비스 - [https://travis-ci.org/](https://travis-ci.org/) 431 | * Github 무결성 - [http://integrity.github.io/](http://integrity.github.io/) 432 | 433 | 한 가지 명심해야 할 점은 항상 새로운 도구가 개발되고 있으므로 434 | 435 | Google 및/또는 다른 개발자와 지속적 통합을 위해 사용 중인 도구에 대해 논의합니다. 436 | 437 | ### 지속적 전달 재단 438 | 439 | 지속적 배포의 최신 소식을 확인하는 또 다른 방법은 **Linux Foundation**이 2019년 3월에 발표한 프로젝트인 **Continuous Delivery Foundation(CDF)**을 살펴보는 것입니다. CI/CD(지속적 제공 및 통합) 영역에서 중요한 프로젝트의 통합을 위한 벤더 중립적 홈입니다. 440 | 441 | 모범 사례를 수립 및 문서화하고, 지침을 마련하고, 교육을 제공함으로써 목표는 CI/CD 및 DevOps 사례를 전파 및 확산하고 제품 릴리스 프로세스를 개선하는 것입니다. 442 | 443 | **창립 프로젝트**는 다음과 같습니다. 444 | 445 | * **Jenkins**: OSS CI/CD 시스템 446 | * **Jenkins X**: Kubernetes용 Jenkins 447 | * **Spinnaker**: OSS 멀티클라우드 CD 플랫폼 448 | * **Tekton**: CI/CD 구성 요소에 대한 OSS 사양 449 | 450 | 이 재단의 **기술 감독 위원회(TOC; Technical Oversight Committee)**는 기여를 환영하는 개방형 거버넌스 모델을 가지고 있습니다. 451 | 452 | 이 이니셔티브의 창립 멤버는 다음과 같습니다. 453 | 454 | **Alauda, ​​Alibaba, Anchore, Armory.io, Atos, Autodesk, Capital One, CircleCI, CloudBees, DeployHub, GitLab, Google, HSBC, Huawei, IBM, JFrog, Netflix, Puppet, Rancher, Red Hat, SAP, Snyk, 및 SumoLogic**. 455 | 456 | 참여 방법을 확인하거나 https://cd.foundation 에서 재단의 진행 상황을 확인하십시오. 457 | 458 | # 내부적으로 오픈 소스 방법론 적용 459 | 460 | ## 수업: 소개 461 | 462 | ### 섹션 개요 463 | 464 | 이 섹션에서는 '내부 소스'라고 하는 프로세스인 내부 또는 일반적으로 '닫힌' 개발 노력에 오픈 소스 원칙을 적용하는 방법에 대한 정보를 제공합니다. 우리는 이 관행을 구현하는 실질적인 이유와 외부 청중과의 더 나은 오픈 소스 참여를 지원함으로써 조직에 어떻게 도움이 될 수 있는지 다룰 것입니다. 465 | 466 | ### 학습 목표 467 | 468 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 469 | 470 | * 내부 소스가 무엇이며 내부 프로젝트 및 외부 오픈 소스 참여를 개선하는 데 어떻게 유용한지 설명하십시오. 471 | * 조직에서 내부 소스 관행을 구현하기 위해 취할 수 있는 몇 가지 실용적인 단계를 설명하십시오. 472 | 473 | ## 강의: 왜 내부 소스인가? 474 | 475 | ### 내부 소스란 무엇입니까? 476 | 477 | [Wikipedia](https://en.wikipedia.org/wiki/Inner_source)에 따르면 내부 소스는 다음과 같이 정의됩니다. “ 조직 내에서 [오픈 소스](https://en.wikipedia.org/wiki/Open-source_software) [소프트웨어 개발](https://en.wikipedia.org/wiki/Software_development) 모범 사례 및 [오픈 소스와 같은 문화](https://en.wikipedia.org/wiki/Open-source_model). 조직은 여전히 ​​폐쇄 소스[소프트웨어](https://en.wikipedia.org/wiki/Proprietary_software)를 개발할 수 있지만 내부적으로 개발을 개방합니다. 이 용어는 2000년 [Tim O'Reilly](https://en.wikipedia.org/wiki/Tim_O%27Reilly)에 의해 만들어졌습니다.” 478 | 479 | 이 정의의 오픈 소스와 같은 문화 부분을 주목하는 것이 중요합니다. (이 교육에서 설명한 대로) 단순히 오픈 소스 개발 관행을 채택하면 내부적으로 개발 프로세스에 이점을 얻을 수 있지만 Inner Source를 최대한 활용하려면 개발 조직 내에서 보다 개방적이고 투명한 문화를 내부적으로 구축하는 것이 중요합니다(법률, 재무, HR 및 관리와 같은 지원 조직). 480 | 481 | ### 왜 내부 소스인가? 482 | 483 | 내부 소스 원칙이 내부 개발에 적합한 이유는 여러 가지가 있으며 가장 중요한 몇 가지를 아래에 나열하겠습니다: 484 | 485 | **보다 효율적이고 효과적인 개발** 486 | 487 | * 시장 출시 시간 단축 488 | * 소프트웨어 재사용을 통한 개발 비용 절감 489 | 490 | **더 나은 조직 간 협업** 491 | 492 | * 조직 단위 간의 비용 및 위험 공유 493 | * 프로그램 전반에 걸친 정보 교환 494 | 495 | **더 성공적인 소프트웨어 재사용** 496 | 497 | * 컴포넌트 제공자에서 누락된 역량 사용 498 | * 구성 요소 공급자의 구제 499 | 500 | **향상된 지식 공유** 501 | 502 | * 커뮤니티 기반 학습 503 | * 지식의 개방성과 가용성 504 | 505 | **외부 오픈 소스와의 더 나은 참여** 506 | 507 | * 개발자는 내부 개발 방식과 오픈 소스 개발 방식 간에 컨텍스트를 전환할 필요가 없습니다. 508 | * 오픈 소스 개발자 모집/온보딩이 쉬워졌습니다. 509 | 510 | 다음으로 기존 소스 개발 방식과 내부 소스 개발 방식 간의 주요 차이점 중 일부를 다룰 것이며, 이 중 일부는 이 모듈에서 지금까지 다룬 내용을 기반으로 이미 친숙해 보일 것입니다. 또한 조직에서 이러한 관행을 구현하는 방법에 대한 실용적인 팁을 제공하려고 합니다. 511 | 512 | ### 내부 소스의 통신 513 | 514 | 이 모듈의 앞부분에서 다루었듯이 투명한 커뮤니케이션은 오픈 소스 프로젝트의 성공에 매우 중요하며 내부 소스에서도 똑같이 중요합니다. 515 | 516 | 또한 개인 이메일, 대면 회의 및 개인 전화 회의가 대부분의 내부 개발 프로젝트에서 일반적으로 사용되기 때문에 문화적 도전이 가장 큰 영역이기도 합니다. IRC, Slack 및 투명한 포럼과 같은 비동기식 도구를 사용하여 내부 커뮤니케이션 관행을 열면 프로젝트 간 협업을 촉진할 수 있을 뿐만 아니라 조직이 외부 오픈 소스 프로젝트에서 보다 효과적으로 작업할 수 있도록 준비할 수 있습니다. 517 | 518 | 어떤 도구를 선택하든(이메일 별칭이더라도) 사용 가능한 아카이브가 있는지 확인하고 프로젝트 방향에 대한 결정이 공개적으로 논의되어 모든 사람이 액세스할 수 있는 장소에 프로젝트 결정이 기록되도록 하십시오. 519 | 520 | ### 내부 소스에 공개 참여 521 | 522 | 일반적으로 닫힌 저장소의 핵심 팀에서 수행하는 기존의 내부 개발과 달리 내부 소스 프로젝트는 정의에 따라 공개적으로 빌드해야 합니다. 이는 위에서 언급한 바와 같이 개방형 커뮤니케이션뿐만 아니라 개방형 소프트웨어 리포지토리, 게시된 로드맵 및 문서, 쉬운 '진입로' 및 기여를 위한 명확한 거버넌스 모델을 의미합니다. 523 | 524 | 또한 명확하고 투명한 버그 및 문제 추적이 필수입니다. 많은 팀은 핵심 팀에 속하지 않은 개발자와 사용자의 이러한 공개적인 참여를 내부 소스에 대한 가장 어려운 측면이라고 생각합니다. 프로젝트와 코드가 외부 조사에 노출되기 때문입니다. 그러나 이것의 긍정적인 측면은 더 나은 코드, 더 명확한 문서를 작성하고 외부 관점에서 아키텍처를 생각하도록 강요한다는 것입니다. 525 | 526 | ### 내부 소스의 피어 리뷰 527 | 528 | 내부 소스 관행은 핵심 프로젝트 팀의 일부가 아닌 사용자를 참여시키는 것을 의미하므로 동료 검토의 개념이 매우 중요해집니다. 코드 검토 또는 짝 프로그래밍을 설정했을 수도 있지만 '외부' 개발자가 코드를 살펴보는 것은 완전히 다릅니다. 529 | 530 | 그들은 프로젝트의 코드 리뷰에 새로운 관점(그리고 처음에는 많은 질문)을 가져올 것입니다. 그러나 코드를 커밋하기 전에 팀에서 엄격한 검토를 수행할 필요가 없는 새로운 리소스도 제공합니다. 또한 이전에 외부 기여자가 코드 기반에 더 익숙해지고 팀이 코드 기반에 더 익숙해짐에 따라 신뢰의 웹과 아이디어의 교차 수정을 구축하는 데 도움이 됩니다. 531 | 532 | ### 내부 소스의 반복 릴리스 533 | 534 | 우리는 이 모듈에서 오픈 소스의 반복적인 특성과 '일찍 릴리스, 자주 릴리스'라는 만트라를 모두 다루었습니다. 이는 일반적으로 정의된 로드맵과 함께 고정 릴리스 주기를 사용하는 대부분의 내부 개발 노력과 직접적인 대조를 이룹니다. 매우 빠르게 변경합니다. 535 | 536 | 개발에 대한 보다 반복적이거나 민첩한 접근 방식을 활용하고 코드 기반에 대한 작은 변경 사항을 통합함으로써 변화하는 요구 사항에 더 쉽게 적응할 수 있을 뿐만 아니라 프로젝트 아키텍처에서 한 번 성문화된 많은 회귀 또는 값비싼 버그를 방지할 수 있습니다. 수정하기 어렵습니다. 537 | 538 | 지속적인 통합/테스트/배포를 위해 이 교육의 앞부분에서 언급한 사례를 활용하면 내부 소스 프로젝트가 더 효과적으로 작동할 수 있을 뿐만 아니라 개발 팀이 이러한 스타일의 개발을 활용하는 외부 오픈 소스 프로젝트와 함께 작업할 수 있도록 교육할 것입니다. 539 | 540 | ### 내부 소스 인력 충원 541 | 542 | 내부 소스의 인적 자원 측면은 전통적인 계층 구조나 문화가 개발자를 특정 프로젝트에 할당하고 회사 내부의 다른 작업에 기여하는 것을 허용하지 않는 조직에서 때때로 매우 도전적입니다. 543 | 544 | 개발자가 코드베이스의 일부로 사용할 수 있는 조직 내부의 프로젝트에 참여하고 기여하도록 장려하는 방법을 고려하는 것이 중요합니다. 관리 팀이 이러한 종류의 팀 간 협업을 허용하도록 완전히 지원하고 스스로에게 인센티브를 제공하는지 확인하는 것도 중요합니다. 545 | 546 | 물론 여기에는 균형 잡힌 작업이 진행 중입니다. 여기서 개발자는 핵심 프로젝트에 효과적으로 기여해야 하는 동시에 가치 있는 기여를 할 수 있는 관련 프로젝트를 찾아야 합니다. 이러한 이유로 일반적으로 프로젝트 개발자가 공통 인프라 또는 플랫폼 코딩에 기여하도록 하는 것이 가장 좋습니다. 이에 대해서는 조금 더 자세히 설명하겠습니다. 547 | 548 | 이러한 종류의 팀 간 협업을 허용함으로써 얻을 수 있는 한 가지 주요 이점은 엔지니어가 자신의 팀을 넘어 조직에 가치 있는 공헌을 할 수 있다고 느끼는 경우 개발자 지식, 사기 및 유지율이 향상될 수 있다는 것입니다. 549 | 550 | ### 구현 고려 사항 551 | 552 | 내부 소스를 구현하기 위한 모든 제안이 가능하지만 때로는 전통적인 명령 및 통제 계층이 존재하는 조직에서 매우 도전적입니다. 따라서 이미 상당한 상호 의존성이 있을 수 있는 소규모 프로젝트에서 내부 소스 '가장자리' 구현을 시작하는 것이 좋습니다. 553 | 554 | 예를 들어, 기본 라이브러리, 플랫폼 또는 공통 사용자 인터페이스 구성 요소는 일반적으로 이러한 종류의 노력에 적합한 후보이지만 여전히 문화적 변화(구성 요소 팀과 해당 구성 요소를 사용하는 팀 모두에서)와 잠재적인 코드 수정이 모두 필요합니다. - 성공적인 내부 소스를 허용하기 위한 아키텍처/문서화, 정리 등. 555 | 556 | 소규모 프로젝트로 초기 성공을 확보하고 내부 소스 프로그램을 평가하는 '일찍 릴리스, 자주 릴리스'라는 만트라를 따라 진행하면서 변경해야 할 사항을 확인하십시오. 가장 중요한 것은 이 과정이 매우 도움이 되지만 성공적인 열매를 맺는 데 몇 달(몇 년은 아니더라도)이 걸릴 수 있다는 점을 이해하십시오. 계속하십시오! 557 | -------------------------------------------------------------------------------- /module3/README.md: -------------------------------------------------------------------------------- 1 | # 오픈 소스 프로그램 오피스(OSPO) 및 조직 2 | 3 | ## 소개 4 | 5 | ### 섹션 개요 6 | 7 | 이 섹션에서는 OSPO가 무엇을 구성하는지에 대한 정의와 설명을 제공하고 대규모 오픈 소스를 효과적으로 관리하는 데 도움이 되는 이 구성의 역할과 가치에 대한 정보를 제공합니다. 8 | 9 | ### 학습 목표 10 | 11 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 12 | 13 | * OSPO(Open Source Program Office)가 무엇인지 정의 14 | * 조직에서 OSPO의 역할 설명 15 | * OSPO가 기업에 제공하는 가치를 명확히 합니다. 16 | 17 | ## 정의 18 | 19 | ### 오픈 소스 프로그램 오피스란 무엇입니까? 20 | 21 | 위의 소개 텍스트에서 언급했듯이 OSPO(Open Source Program Office)는 조직에서 오픈 소스 작업의 중심 연결점이 되도록 의도되었습니다. 그러나 그 정의는 (의도적으로) 가변성의 여지를 많이 남깁니다. 어떤 사람들은 그것이 가치를 감소시킨다고 말할 수도 있지만, 사실 OSPO가 조직에 따라 다르게 보일 수 있고 다르게 보일 수 있다는 사실은 실제로 장점입니다. 다양한 요구를 해결하기 위해 이 구성을 틀(그리고 자주 변경)할 수 있기 때문입니다. 오픈 소스 여정에 있을 것입니다. 22 | 23 | 예를 들어, 일부 조직에서는 제품 활성화에 필요한 변경 사항을 오픈 소스 프로젝트로 가져오기 위해 조직을 대신하여 작업하는 특정 개발자가 OSPO 내에서 대부분의 업스트림 오픈 소스 작업을 수행합니다. 그러나 일부 조직에서는 이러한 개발자가 분산되어 제품 개발 팀에 포함되어 OSPO 직원의 조언과 교육을 받습니다. 24 | 25 | '일률적으로 적용되는' 모델은 없으며 OSPO는 대규모 리소스 집합이 있는 고도로 중앙 집중화된 것부터 조직 전체의 리소스 교육 및 영향력에 의존하는 작고 분산된 것까지 무엇이든 될 수 있습니다. OSPO가 무엇인지에 대한 훌륭한 개요 리소스는 [github 저장소](https://github.com/todogroup/ospodefinition.org)의 TODO 그룹 작업에서 찾을 수 있습니다. 26 | 27 | ### 기업에서 OSPO의 기능 28 | 29 | 오픈 소스 프로그램 사무국의 주요 기능은 전략적 우위를 위해 기업 내부에서 오픈 소스 사용, 기여 및 생성을 촉진하는 것입니다. 30 | 31 | 프로그램 오피스의 책임은 다양합니다. 여기에는 다음이 포함됩니다: 32 | 33 | * 사내외 오픈소스 전략을 명확하게 전달 34 | * 전략 실행을 소유 및 감독 35 | * 상용 제품 및 서비스에서 오픈 소스의 효과적인 사용 촉진 36 | * 오픈 소스 커뮤니티에 고품질의 빈번한 코드 릴리스 보장 37 | * 개발자 커뮤니티에 참여하고 회사가 다른 프로젝트에 효과적으로 기여하는지 확인 38 | * 조직 내 오픈소스 문화 조성 39 | * 오픈 소스 라이선스 준수 검토 및 감독 유지 40 | 41 | 여기에서 모든 OSPO가 이러한 기능을 모두 갖고 있지 않거나 작업하는 작업을 반드시 균등하게 분배하지 않는다는 점을 반복하는 것이 중요합니다. 프로그램 오피스가 하는 일의 상당 부분은 조직의 비즈니스 요구 사항에 따라 달라집니다. 42 | 43 | 강조해야 할 한 가지는 OSPO가 개발자와 협력하는 것 이상을 수행한다는 것입니다. OSPO는 아래에 언급된 것처럼 지원할 수 있는 다양한 비개발 활동을 가지고 있습니다. 44 | 45 | 출처: TODO 그룹 OSPO 가이드([https://todogroup.org/guides/](https://todogroup.org/guides/)) 46 | 47 | ![OSPO 구조](ospo-structure.png) 48 | 49 | ### OSPO의 가치 50 | 51 | 성공적인 오피스는 개발자와 해당 팀을 지원하는 정책, 프로세스 및 지침을 수립하여 기업의 오픈 소스 사용에 큰 이점을 줄 수 있습니다. 표준 코딩 및 조직적 관행, 프로세스 및 도구 집합을 권장합니다. 동시에 프로그램 오피스는 창의적 개발자가 어쨌든 우회하거나 무시할 수 있는 불필요하고 경직된 프로세스를 피하거나 제거하여 프로젝트의 보안 및 기타 측면을 위협할 수 있습니다. 52 | 53 | 오픈 소스 프로그램 오피스는 사업부가 계획에서 오픈 소스를 고려하기 시작할 때 대화에 실체와 사실을 제공하므로 고려되는 이유, 결과가 무엇인지, 목표를 달성하기 위해 무엇이 필요한지 완전히 이해할 수 있습니다. 오픈 소스 전문가가 대화를 구성하는 데 도움을 줌으로써 이해 관계자는 결정을 내릴 때 어디서부터 시작하고 무엇을 생각할지 알 수 있습니다. 54 | 55 | 프로그램 오피스는 또한 발생하는 문제 또는 요구 사항을 해결하고 이해하기 위해 내부 개발자와 오픈 소스 사용자 커뮤니티 간의 중요한 연락 담당자 역할을 합니다. 프로그램 오피스는 법적 문제를 지원하고 개발자 옹호를 제공하며 회사의 오픈 소스 프로젝트를 기반으로 하는 외부 사용자의 목소리를 낼 수 있습니다. 프로그램 오피스는 또한 해당 정보를 제품 관리 팀을 포함한 회사 내부의 다른 사람들에게 전달하여 조직에 유익한 방식으로 제품을 더욱 발전시키는 데 도움을 줄 수 있습니다. 56 | 57 | # 효과적인 오픈 소스 프로그램 오피스 구축 58 | 59 | ## 소개 60 | 61 | ### 섹션 개요 62 | 63 | 이 섹션에서는 역할, 거버넌스, 프로세스 및 구조에 대한 정보를 포함하여 효과적인 오픈 소스 프로그램 오피스를 만드는 방법을 보여줍니다. 64 | 65 | ### 학습 목표 66 | 67 | 이 섹션이 끝나면 다음을 수행할 수 있습니다: 68 | 69 | * 새로운 OSPO를 구성하는 주요 단계를 설명합니다. 70 | * OSPO의 일부가 될 수 있는 다양한 역할 및 구조 설명 71 | * 거버넌스 및 기타 프로세스를 OSPO에 구축하는 방법을 명확히 합니다. 72 | 73 | ## OSPO 설립 74 | 75 | ### 어디서부터 시작해야 할까요? 76 | 77 | 모든 회사는 다르며 OSPO를 시작하는 데 필요한 요구 사항도 다릅니다. 프로세스는 최고 경영진의 동의를 받아 위에서 아래로 시작할 수 있습니다. 또는 아래에서 위로, 개발자와 오픈 소스 애호가의 주머니가 오픈 소스를 사용해 왔으며 공식화되기를 원하는 곳입니다. 78 | 79 | 법적 문제 및 보안에 대한 지침을 만들고자 하는 열망으로 나타날 수도 있고, 성숙하고 기업 리더의 관심을 끄는 풀뿌리 노력으로 시작할 수도 있습니다. 오픈 소스에 대한 헌신을 심화함으로써 회사를 발전시키고 가치를 추가하는 대의를 옹호하는 진취적인 CEO 또는 CTO와 함께 시작할 수도 있습니다. 80 | 81 | 이러한 종류의 합의와 경영진 지원은 견인력을 얻고 OSPO 시작 프로세스를 진행하는 데 필수적입니다. 오픈 소스 프로그램 오피스 여정을 시작하는 곳은 조직마다 다릅니다. 그러나 다음 페이지에서 고려해야 할 몇 가지 중요한 단계를 다룰 것입니다. 82 | 83 | ### 리더 찾기 84 | 85 | 계획 시작 방법에 관계없이 회사 내에서 신생 프로그램 오피스를 개발하고 운영하는 데 도움이 되는 적합한 리더를 찾는 것이 중요합니다. 최고 후보자는 기존 오픈 소스 프로젝트에서 개발자, 기여자 또는 커미터로 일하면서 기술적인 부분과 함께 오픈 소스 작동 방식에 대한 자세한 이해를 갖게 됩니다. 86 | 87 | 그들은 비즈니스 단위 전반에 걸쳐 전략과 계획을 알리는 데 도움이 되는 비즈니스 통찰력 및 관리 기술과 함께 회사 비즈니스에 대한 폭넓은 이해를 가지고 있어야 합니다. 그리고 다른 사람들에게 열정, 지식, 정보를 전달하고 오픈 소스 이니셔티브가 회사를 어떻게 변화시키고, 변화시키고, 개선할 것인지 이해하도록 도울 수 있도록 사교적이어야 합니다. 88 | 89 | 프로그램 사무국의 책임자는 사람들과 심층 기술에 대해 이야기할 수 있어야 하지만, 주요 업무는 세부적인 논의를 구성하는 데 도움을 주는 것이기 때문에 사용 중인 모든 기술의 안과 밖을 알 필요는 없습니다. 여러 이해 관계자 사이에서 발생합니다. 90 | 91 | ### 작업 정의 92 | 93 | 새로운 프로그램 오피스에 필요한 예산, 인력, 기술 도구 및 시스템도 운영을 확립하는 데 해결해야 할 핵심 문제입니다. 일부 회사는 시간제 관리자로 시작하지만 그 접근 방식을 통해서만 도달할 수 있다는 것을 알게 됩니다. 누군가의 자리를 정규직으로 만드는 것은 프로그램을 신속하게 유지하기 위한 소규모 지원 직원과 함께 프로그램을 시작하기 위한 확실한 단계입니다. 94 | 95 | 잘 정의된 오픈 소스 프로그램 오피스의 예로는 필요한 정책, 프로세스 및 도구를 추진하는 동시에 마찰이 있는 곳에서 마찰을 제거하고 간소화할 수 있는 것을 자동화하는 도구를 사용하고 필요한 작업을 위임하는 만트라를 운영하는 오피스가 있습니다. 달성하기 위해. 정책 및 프로세스를 설정하는 방법에 대한 자세한 내용은 향후 섹션에서 다루겠습니다. 96 | 97 | 프로그램 오피스는 구조화된 정책과 프로세스를 제공해야 하지만 유연성도 유지해야 합니다. 오픈 소스 사용자와 기여자가 도움이 필요할 때 오피스는 컨설팅처럼 운영되어 직원이 업무와 관련된 개인 또는 그룹 비즈니스 결정을 내릴 수 있도록 하는 동시에 지침을 제공합니다. 98 | 99 | ### 피드백 및 바이인 요청 100 | 101 | 오픈 소스 프로그램 오피스를 설립하는 것은 진공 상태에서 수행되어야 하는 일이 아닙니다. 비즈니스에서 중심적인 역할을 하므로 성공적으로 만들려면 기업 내부의 모든 관련 당사자로부터 공개적이고 정직한 입력과 피드백이 필요합니다. 경영진에서 개발자에 이르기까지 모든 사람이 생성에 대해 발언권을 갖도록 하면 광범위한 지원을 제공하는 데 도움이 됩니다. 102 | 103 | 회사가 오픈 소스로 하는 일을 파악하려면 조직이 진정으로 관심을 갖고 있는 핵심 사항에 대해 여러 이해 관계자의 생각이 필요합니다. 초기에 이 피드백을 찾고 OSPO에 대한 롤아웃 계획에 반영하도록 하면 프로그램이 정의하는 데 도움이 되는 프로세스 및 전략을 수용하고 성공하는 데 큰 도움이 될 것입니다. 104 | 105 | ## OSPO 프로그램 구조 정의 106 | 107 | ### OSPO는 어디에 있어야 합니까? 108 | 109 | 그렇다면 오픈 소스 프로그램 오피스는 회사의 조직 구조 내에서 어떻게 그리고 어디에 적합해야 할까요? 엔지니어링 부서에 있어야 합니까? 아니면 법무 부서, CTO 오피스 또는 다른 특정 사업부에 있습니까? 다시 말하지만, 이는 회사의 주요 비즈니스와 오픈 소스 전략에 따라 다릅니다. 110 | 111 | 여기에서 OSPO가 있어야 하는 위치에 대한 '일률적인' 답은 없다는 점을 다시 한 번 강조합니다. 다음 페이지에서는 프로그램 오피스를 위해 가장 자주 선택되는 위치에 대해 논의할 것이지만 이 목록이 완전한 것은 아닙니다. 112 | 113 | ### 법률 그룹의 일원인 OSPO 114 | 115 | 대규모 지적 재산 포트폴리오를 보유한 회사의 경우 오픈 소스 프로그램 오피스가 개발자가 발생하는 문제에 대해 법률 팀과 긴밀하게 협력할 수 있는 법률 오피스에 완벽하게 적합할 수 있음을 의미할 수 있습니다. IP 관련 법적 문제가 발생할 가능성을 항상 우려하기 때문에 하드웨어 회사에 적합할 수 있습니다. 116 | 117 | 그러나 이 접근 방식의 한 가지 문제는 법무 부서의 OSPO가 시간의 상당 부분을 규정 준수 문제에 집중할 수 있다는 것입니다. 장기적으로 조직. 법무 그룹에서 OSPO를 호스팅하기로 결정했다면 그룹 역할의 규정 준수 측면과 오픈 소스 커뮤니티 참여에 대한 보다 진취적이고 전략적인 정책의 균형을 맞출 수 있는 강력한 리더가 필요합니다. 118 | 119 | ### 엔지니어링 OSPO 120 | 121 | 엔지니어링 중심의 회사는 종종 엔지니어링 부서 내에서 오픈 소스 프로그램 오피스를 유지하기로 선택합니다. 이를 통해 개발자가 작업에서 보다 효과적이고 생산적인 작업을 수행하는 데 직접 노력을 집중할 수 있습니다. 122 | 123 | 대부분의 경우 이러한 프로그램 오피스는 CTO 또는 경우에 따라 CIO에게 보고합니다. 강력하고 연결된 제품 세트가 있는 조직에서 오피스는 제품 개발 부사장 또는 엔지니어링 부사장에게 보고할 수 있습니다. 제품 포트폴리오가 서로 다른 회사에서는 일반적으로 OSPO를 CTO 오피스에 두는 것이 가장 좋습니다. OSPO는 모든 엔지니어링 팀을 위한 정책 및 교육 노력을 개발하는 데 가장 폭넓은 관점과 권한을 제공하기 때문입니다. 124 | 125 | 이 접근 방식의 한 가지 단점은 잠재적으로 규정 준수 활동에 덜 집중할 수 있지만(법률 그룹과 함께 OSPO를 호스팅하는 것과 비교할 때) 강력한 리더가 여기에 필요한 균형을 제공할 수 있으며, 이것이 잘 수행되면 개발자가 프로세스가 가볍고 번거롭지 않다고 느끼는 경우 규정 준수를 높일 수 있습니다. 126 | 127 | ### 개발자 관계/마케팅의 일부인 OSPO 128 | 129 | 일부 조직의 경우 오픈 소스 오피스는 오픈 소스를 사용하여 구축한 제품 판매를 목표로 하는 잠재 고객을 유입시키기 위해 오픈 소스를 사용하기 때문에 마케팅 그룹 내에 있습니다. 조직에서 주요 오픈 소스 개발자 및 프로젝트와의 긴밀한 연결이 필요한 경우 개발자 관계와 같은 그룹에서 OSPO를 호스팅하면 이러한 지원을 제공할 수 있습니다. 130 | 131 | 물론 OSPO는 필요에 따라 규정 준수 및 교육 영역에서 필요한 다른 역할을 수행할 수 있어야 합니다. 132 | 133 | ### 구현 고려 사항 134 | 135 | 조직에서 OSPO를 배치할 위치를 결정할 때 고려해야 할 또 다른 중요한 요소는 중앙 집중식 접근 방식과 분산 접근 방식을 계획하는지 여부와 관련이 있습니다. 136 | 137 | 소규모 조직에서는 소비, 협업 및 생성을 위한 모든 워크플로가 중앙 위치에 있는 중앙 집중식 오픈 소스 프로그램 오피스를 갖는 것이 효과적일 수 있습니다. 접근 방식과 규정 준수의 일관성을 최대한 보장하지만 조직이 성장함에 따라 다루기 어려워질 수도 있습니다. 138 | 139 | 중앙 집중식 조직은 조직을 대신하여 업스트림 오픈 소스 프로젝트에 기여할 주요 개발자를 호스트하기도 합니다. 이러한 개발자는 종종 자체적으로 오픈 소스 프로젝트에 기여할 수 있는 교육과 전문 지식이 부족한 제품 팀의 내부 컨설턴트 역할을 합니다. 140 | 141 | 조직이 충분히 커지면 일반적으로 분산 접근 방식이 가장 잘 작동합니다. 개발자와 관리자가 전체 조직 정책과 일치하는 오픈 소스에 대한 제품별 결정을 내릴 수 있도록 교육 및 컨설팅 리소스를 제공하는 데 집중할 수 있기 때문입니다. 이 접근 방식은 또한 조직 전체에 오픈 소스 지식을 전파하고 보다 개방적이고 협력적인 문화를 조성하는 데 도움이 됩니다. 이는 더 큰 오픈 소스 생태계와 협력하는 데 중요한 특성입니다. 142 | 143 | 이 모듈의 뒷부분에서 사례 연구를 공유하여 다른 조직에서 이러한 구조적 결정을 내린 방법에 대한 몇 가지 예를 제공합니다. 144 | 145 | ## 수업: OSPO 역할 146 | 147 | ### 관리 역할 148 | 149 | 오픈 소스 프로그램 오피스를 만들 때 오픈 소스 프로그램 관리자, 회사 법무팀, 엔지니어와 임원으로 구성된 모든 검토 위원회의 역할과 책임을 설정하기 위한 결정이 내려져야 합니다. 또한 OSPO가 성장함에 따라 조직에 가치를 제공하는 추가 역할이 있을 수 있습니다. 다음 몇 페이지에서 이러한 역할에 대해 더 자세히 다룰 것입니다. 150 | 151 | #### 프로그램 관리자 152 | 153 | 최대 효과를 위해 프로그램 관리자는 오픈 소스 활동에 대한 회사의 이익을 직접 감독하고 직접 관리하는 임원급 직책으로 권한을 부여받아야 합니다. 이는 기업 내부에서 오픈 소스 목표와 비전을 향해 나아가는 데 필요한 도구를 제공할 것입니다. 154 | 155 | 일부 회사는 검토 위원회와 유사한 오픈 소스 집행 위원회를 사용하기로 선택합니다. 이러한 그룹은 일반적으로 회사 내 모든 주요 사업부의 고위 리더로 구성되며 정책 변경 및 도입에 대한 이사회 스타일 지침을 제공하고 오픈 소스 프로그램의 우선 순위를 설정하며 조직 행동의 변화를 주도하도록 지원합니다. 156 | 157 | #### 법무 158 | 159 | 회사 내의 다른 모든 기능과 마찬가지로 법무팀은 법률, 오픈 소스 라이선스 계약 및 기타 법적 세부 사항을 준수하도록 오픈 소스 프로그램 오피스 운영에 대해 발언권을 가져야 합니다. 오픈 소스와 관련하여 법무팀은 회사가 내부적으로 코드를 사용하고 수용 가능한 조건으로 프로젝트에 다시 기여할 수 있도록 보장할 책임이 있습니다. 160 | 161 | 규모가 큰 조직은 오픈 소스 프로그램에 자문을 제공할 전담 변호사를 고용하거나 교육하는 것을 고려해야 합니다. 그러나 지식이 풍부한 시간제 직원이나 외부 고문을 사용할 수도 있습니다. 오픈 소스 라이선스 및 IP에 대한 지식과 경험이 풍부한 변호사와 협력하는 것은 상업 계약이나 표준과 관련하여 전문적이고 때로는 당혹스러운 법적 영역이 될 수 있기 때문에 종종 도움이 됩니다. 162 | 163 | #### 준법감시팀 164 | 165 | 오픈 소스 준수 팀은 오픈 소스 라이선스 준수를 보장하는 임무를 맡은 다양한 개인으로 구성된 학제 간 그룹입니다. OSRB(Open Source Review Board)라고 하는 핵심 팀은 엔지니어링 및 제품 팀 대표, 한 명 이상의 법률 고문, 규정 준수 담당자(종종 오픈 소스 프로그램 관리자임)로 구성됩니다. 166 | 167 | 확장된 팀은 규정 준수 노력에 지속적으로 기여하는 여러 부서의 다양한 개인으로 구성됩니다. 여기에는 문서, 공급망, 기업 개발, IT, 현지화 및 OSEC(오픈 소스 집행 위원회)가 포함될 수 있습니다. 그러나 핵심 팀과 달리 확장 팀의 구성원은 OSRB에서 받은 작업에 따라 시간제로만 규정 준수 작업을 수행합니다. 168 | 169 | #### 개발자 관계, 변호 및 전도사 170 | 171 | 오픈 소스 개발자 관계 및 전도자는 특정 프로젝트에 대한 회사의 개발자 커뮤니티 내에서 관심과 열정을 구축하기 위해 일할 수 있기 때문에 신생 오픈 소스 프로그램 오피스에서 중요할 수 있습니다. 전도사들은 종종 컨퍼런스와 기술 행사에 참석하여 청중들이 오픈 소스 커뮤니티와 기업 경험을 공유하면서 어떻게 사용할 수 있고 어떤 도전과 기회를 제공하는지 이해하는 데 도움이 되는 오픈 소스가 무엇인지 설명합니다. 172 | 173 | #### 기타 174 | 175 | 또한 도구 관리자, 교육 관리자, 도구 및 시스템 통합 개발자, 배포 지원 직원 및 구현 프로젝트 리더를 포함하여 오픈 소스 프로그램 오피스의 성공을 위해 다른 직무 역할을 만드는 것이 중요합니다. 예를 들어 도구 관리자는 오픈 소스 프로젝트에서 작업하는 엔지니어에게 필요한 도구를 선택, 제공 및 통합하는 동시에 도구가 기업의 라이선스 및 기타 요구 사항을 충족하는지 확인하는 데 도움이 필요합니다. 176 | 177 | ## OSPO 프로세스 정의 178 | 179 | ### 개요 180 | 181 | OSPO의 구조 및 인력 요구 사항을 해결한 후 다음 단계는 회사의 오픈 소스 전략을 일관되게 구현할 수 있도록 잘 정의된 정책 및 프로세스를 개발하는 것입니다. 182 | 183 | 정책은 회사 전체에서 오픈 소스로 작업하기 위한 요구 사항과 규칙을 제시해야 하며, 일상적으로 규칙을 준수하도록 보장하는 문서화되고 실행 가능한 프로세스를 제시해야 합니다. 184 | 185 | 결정적으로 이러한 프로세스에는 최소한의 오버헤드가 필요하고 기존 오픈 소스 정책 및 프로세스를 검토할 때 반복적으로 제거, 자동화 및 위임하여 절차를 간소화하기 위해 규칙에 대해 지속적으로 질문하고 업데이트해야 합니다. 이는 정책이 적용되는 이유와 사용자를 위해 개선할 수 있는 방법을 묻는 것을 의미합니다. 186 | 187 | 이러한 규칙이 오픈 소스 프로그램 오피스를 위해 신중하게 만들어졌더라도 기업은 비즈니스가 변화하고 오픈 소스 참여가 성숙하고 성장함에 따라 필요에 따라 규칙과 절차를 발전시키고 수정할 준비가 되어 있어야 합니다. 188 | 189 | ### 물어볼 질문 190 | 191 | 오픈 소스 정책 및 프로세스의 초안을 작성할 때 논의해야 하는 많은 주제는 다음과 같습니다: 192 | 193 | * 회사 직원이 오픈 소스 프로젝트에 기여할 수 있는 방법 194 | * 회사가 내부 프로젝트를 오픈 소스로 만들 수 있는 방법 195 | * 회사가 오픈 소스 프로젝트에 대한 외부 기여를 수락하는 방법 196 | * 오픈 소스 출시 준비 방법 197 | * 승인을 받는 방법 198 | * 개발자가 GitHub 및 기타 코드 저장소에서 찾은 오픈 소스 코드를 사용하는 방법 199 | * 오픈 소스 코드를 회사에 가져올 수 있는 방법을 설명하는 절차 및 규칙 200 | * 다른 사람들이 사용 중임을 알 수 있도록 수신 코드를 카탈로그화하는 방법 201 | * 회사 주변에서 같은 생각을 가진 외부 개발자 커뮤니티를 성장시켜 계속해서 번창할 수 있는 방법 202 | * 코드가 언제 오픈 소스로 공개되어야 하는지 또는 지적 재산으로 유지되어야 하는지 결정하는 데 도움이 되는 규칙 203 | 204 | 이러한 질문에 대한 답변은 향후 정책 및 프로세스에 대한 정보를 제공하는 데 도움이 됩니다. 다음 페이지에서 이러한 정책의 몇 가지 예를 다룰 것입니다. 205 | 206 | ### 코드 공개 정책 207 | 208 | OSPO의 중요한 목표는 개발자가 오픈 소스 프로젝트에 성공적으로 기여하고 자신의 프로젝트를 출시하도록 돕는 것입니다. 지침과 체크리스트를 통해 개발자는 라이선스 또는 기밀 문제 없이 코드를 오픈 소스로 릴리스하는 데 필요한 모든 것을 확보할 수 있습니다. 특히 새로운 기여자의 경우, 기여하기 전에 피드백을 얻을 수 있는 안전한 장소로 내부 검토 프로세스를 사용할 수 있도록 하는 데 도움이 될 수 있습니다. 209 | 210 | 조직은 또한 "업스트림 우선" 개발 정책을 채택하기 위해 노력해야 합니다. 먼저 업스트림 오픈 소스 프로젝트에 패치를 제출하고 자체 제품 다운스트림에 패치를 통합하면 각 릴리스 후 리엔지니어링에 막대한 시간과 비용을 소비하는 것을 피할 수 있습니다. 211 | 212 | ### 기여 수락 정책 213 | 214 | 결국 자신만의 오픈 소스 프로젝트를 만들고 중립적인 기반에서 호스팅되지 않는 경우 회사에서 외부 개발자로부터 이러한 프로젝트에 대한 기여를 받는 절차를 만들고 싶을 것입니다. 215 | 216 | 그것은 물론 회사의 오픈 소스 코드를 다른 커뮤니티에 공개하고 다른 개발자가 자신의 프로젝트에 관심을 갖도록 초대하는 이점 중 하나입니다. 공식적으로는 직원이 아니더라도 훌륭한 사람들이 전 세계에서 회사 코드를 작업하도록 하여 회사를 개선하고 기능을 확장할 수 있기 때문입니다. 이러한 종류의 협업은 회사에 중요하며 많은 오픈 소스 프로그램 오피스에서 공통적으로 초점을 맞추고 있습니다. 217 | 218 | ### 입양 촉진 정책 219 | 220 | 당신은 또한 다른 사람들이 그들의 제품과 서비스에서 당신의 코드를 사용하도록 장려하고 싶을 것입니다. 이는 오픈 소스 프로젝트의 성장 및 유지에 도움이 되는 생태계 구축의 핵심입니다. 오픈 소스 사용을 위한 정책은 다양한 혁신적인 형태로 나타날 수 있습니다. 221 | 222 | 예를 들어 RedHat은 대부분의 경우 처음부터 새로 생성된 코드로 오픈 소스를 기본으로 하는 고유한 정책을 가지고 있습니다. 즉, 회사 내에서 각 소프트웨어를 개발할 때 향후에는 오픈 소스로 출시될 예정이라고 가정합니다. 223 | 224 | 이러한 면밀한 조사로 인해 개발자는 오픈 소스를 작성할 때 더 나은 방식으로 구조화하는 경향이 있으며, 작업에서 코드 종속성이 더 적거나 개선된 더 깨끗한 코드를 생성합니다. 225 | 226 | ### 내부 소비 정책 227 | 228 | 기타 필요한 정책에는 팀이 오픈 소스 소프트웨어 사용 및 생성을 위한 신뢰할 수 있는 소스를 찾는 방법과 위치에 대한 규칙, 코드 관리 및 유지 관리 절차 설정에 대한 정책, 프로젝트에 대한 커뮤니티 상호 작용 공식화에 대한 규칙이 포함됩니다. 229 | 230 | 오픈 소스 사용 정책은 제품 기반에 들어가는 모든 소프트웨어(독점, 제3자 또는 오픈 소스)가 감사, 검토 및 승인되었음을 보장합니다. 또한 제품이 고객에게 제공되기 전에 다양한 소프트웨어 구성 요소를 사용하여 발생하는 라이선스 의무를 회사에서 이행할 계획을 가지고 있는지 확인합니다. 231 | 232 | 예를 들어, 정책에 따라 엔지니어가 제품에 오픈 소스 코드를 통합하기 전에 OSRB(오픈 소스 검토 위원회)와 같은 조직의 감사 직원으로부터 승인을 받아야 할 수 있습니다. 또한 제3자로부터 받은 소프트웨어는 포함된 모든 오픈 소스 코드를 식별하기 위해 감사해야 한다고 명시할 수 있으며, 이는 제품이 배송되기 전에 라이선스 의무가 이행될 수 있음을 보장합니다. 233 | 234 | ### 라이선스 준수 정책 235 | 236 | 또한 법률 준수 절차를 공식화 및 확립하고 프로그램에 대한 경영진의 감독을 보장하는 정책이 필요합니다. 237 | 238 | 또한 개발자와 기여자를 위한 절차를 자동화하고 간소화하여 규정 준수 및 코드 테스트 작업의 대부분을 가능하게 하는 소프트웨어 도구를 처리하는 방법을 계획하고 싶을 것입니다. 규정 준수 도구에 대한 자세한 내용은 이 시리즈의 이후 과정 모듈에서 다룹니다. 239 | 240 | 기존 오픈 소스 리소스는 기여자 라이선스 계약(CLA; Contributor License Agreements)에 대한 문서를 포함하여 오픈 소스 프로젝트에 필요한 다른 자료를 찾기 위한 잠재적인 금광이기도 합니다. CLA는 일반적으로 오픈 소스 라이선스에 따른 소프트웨어인 "지적 재산이 회사/프로젝트에 기여한 조건을 정의"하는 데 사용됩니다. CLA를 사용하는 프로젝트는 기여자가 프로젝트에서 수락되기 전에 기여자 및 종종 그들의 회사가 CLA에 서명해야 합니다. CLA 사용 및 서명에 대한 회사의 정책을 결정하는 것은 전체 라이선스 준수 정책을 구축할 때 고려해야 할 중요한 단계입니다. 241 | 242 | ### 마지막 말 243 | 244 | 회사에서 오픈 소스 프로그램 오피스를 만들기로 결정할 때 해야 할 일이 많고 고려해야 할 사항이 많지만 그 가치는 이를 달성하기 위해 들인 노력보다 클 것입니다. 프로그램 오피스 이니셔티브를 추진할 적합한 리더를 찾는 것은 성공을 위한 과정에서 중요한 단계입니다. 245 | 246 | OSPO의 핵심은 실제로 문화 변화 노력이라는 것을 기억하는 것도 중요합니다. 분명히 소프트웨어가 중요한 역할을 하지만 회사의 현재 문화와 오픈 소스에서 가고자 하는 방향을 이해하는 것이 매우 중요합니다. OSPO의 모든 프로세스 및 교육 부분에 대해 대부분의 조직이 가장 크게 깨닫는 것은 이 프로그램과 그 리더가 조직 내에서 실제로 변화를 일으키는 주체라는 것입니다. 247 | 248 | # 추가 정보 및 사례 연구 249 | 250 | ## 소개 251 | 252 | ### 섹션 개요 253 | 254 | 이 섹션에서는 오픈 소스 프로그램 오피스를 구축한 조직의 사례 연구를 제공하고 보다 효과적인 오픈 소스 프로그램 관리를 위해 OSPO를 만드는 과정을 시작할 때 도움이 될 추가 정보에 대한 포인터를 제공합니다. 255 | 256 | ### 학습 목표 257 | 258 | 이 섹션이 끝나면 다음을 수행할 수 있습니다. 259 | 260 | * 여러 오픈 소스 프로그램 오피스 구현 간의 주요 차이점 설명 261 | * 자신의 OSPO 구축에 대한 추가 정보를 보려면 어디로 가야 하는지 알아두십시오. 262 | 263 | ## 사례 연구 264 | 265 | ### 개요 266 | 267 | 앞서 언급했듯이 모든 조직의 오픈 소스 프로그램 오피스는 다를 수 있습니다. 이는 서로 다른 비즈니스 모델의 현실과 각 조직의 현재 오픈 소스 성숙도 및 인식 상태를 반영합니다. 268 | 269 | 합리적으로 광범위한 관점을 제공하기 위해 사례 연구로 세 회사와 OSPO 생성 여정을 선택했습니다. 이 조직들은 오픈 소스로의 여정을 시작하는 다른 사람들에게 도움이 되기를 바라며 이러한 사례 연구를 구축하기 위해 오픈 소스 리더와 관리 팀의 시간을 기꺼이 기부했습니다. 270 | 271 | 사례 연구의 출처: 272 | 273 | * **컴캐스트** 274 | * **마이크로소프트** 275 | * **Salesforce** 276 | 277 | 이 연구에서는 도구, 조직 및 측정항목에 대한 다양한 접근 방식을 볼 수 있습니다. 이 연구는 TODO 그룹(Linux Foundation Initiative)의 후원 하에 수행되었으며 이 모듈의 뒷부분에서 추가 정보에 대한 포인터를 제공합니다. 278 | 279 | ### 컴캐스트 280 | 281 | 오픈 소스에 대한 Comcast의 참여는 시간이 지남에 따라 진화한 점진적인 과정이었습니다. 회사는 결국 두 개의 오픈 소스 프로그램 오피스를 만들었습니다. 하나는 NBC 비즈니스용이고 다른 하나는 이 프로필의 주제인 비즈니스의 케이블 측용입니다. 282 | 283 | Comcast는 최고 소프트웨어 설계자인 Jon Moore가 Apache HTTP에 패치를 기고한 2006년경에 오픈 소스에 기여하기 시작했습니다. 그는 관리 팀에게 패치를 별도로 유지 관리하는 것보다 메인 프로젝트에 통합하는 것이 더 비용 효율적이라는 것을 보여주었습니다. 284 | 285 | Moore는 학제간 팀과 협력하여 법률 및 기술 주제 전문가로 구성된 오픈 소스 자문 위원회를 구성했습니다. 그들은 기여를 검토하고 훌륭한 오픈 소스 관행과 커뮤니티 구축에 중점을 둔 내부 지침을 만들었습니다. 2013년에 이러한 기여를 추적하기 시작했을 때 13개가 있었습니다. 올해에는 거의 10배에 달하는 것을 할 계획입니다. 286 | 287 | *"회사가 오픈 소스 관행을 확립할 때 우리는 오픈 소스에 대해 진지하며 이에 투자하고 싶다는 큰 메시지를 보냅니다."* – Nithya Ruff, Comcast의 Open Source Practice 수석 이사. 288 | 289 | ### 6C의 오픈 소스 프로그램 실습 290 | 291 | 2016년 Comcast는 Ruff를 고용하여 점점 더 중요한 오픈 소스 전략을 이끌었습니다. 이 관행은 질문을 제기하고 직원을 교육하며 인식을 제고하는 조직을 원하는 Comcast 리더십 팀의 최고 수준의 지원을 받았습니다. 292 | 293 | 오픈 소스 프로그램 실무에는 3명의 정규 직원(2020년 6월 기준)이 있으며 법률, 엔지니어링, IT, PR 등의 기능 전문가에게 의존하여 프로그램을 확장할 수 있습니다. 목표는 직원을 지도하고, 안내하고, 조언하고, 추천하고, 컨설턴트로 봉사하는 것입니다. Ruff는 소비, 기여, 규정 준수, 커뮤니케이션, 협업 및 역량 구축과 같은 "6C"로 오픈 소스 관행의 기능을 요약합니다. 294 | 295 | ![컴캐스트 OSPO](comcast-ospo.png) 296 | 297 | 오픈 소스 관행에는 두 가지 주요 목표가 있습니다. 298 | 299 | 1. 사내 사람들이 오픈소스로 작업하기 쉽게 만든다. 오픈 소스의 사용, 오픈 소스에 대한 기여 또는 커뮤니티, 재단 및 조직과의 협업이든, 목표는 법적, 프로세스, 도구, 커뮤니케이션 및 인식 장벽을 제거하는 것입니다. 300 | 301 | 2. 오픈 소스 및 기술 커뮤니티에서 외부에서 볼 수 있습니다. 많은 사람들은 Comcast가 수천 명의 개발자가 있는 기술 회사라는 사실을 모르기 때문에 인지도를 높이고 자신이 하는 일을 공유하고자 합니다. 302 | 303 | ### 오픈 소스 기여 304 | 305 | Comcast는 OpenStack과 같은 기존 오픈 소스 커뮤니티에 크게 기여할 뿐만 아니라 [몇 가지 프로젝트를 오픈 소스화](https://github.com/Comcast)했습니다. [Apache Traffic Control](https://trafficcontrol.incubator.apache.org/)은 Comcast 내에서 시작되었으며 현재 인큐베이션 중인 Apache Software Foundation에 기부되었습니다. 306 | 307 | 그들은 또한 셋톱 박스에 대한 표준을 만드는 데 초점을 맞춘 [RDK 관리 프로젝트](http://rdkcentral.com/)라는 독립 컨소시엄을 설정하는 데 중요한 역할을 했습니다. RDK 소프트웨어는 Yocto 빌드 시스템을 사용하여 반도체 공급업체부터 OEM 및 ISV에 이르기까지 체인의 모든 사람이 일관된 시스템과 구조를 사용하여 셋톱 박스 및 유사 장치용 콘텐츠를 구축할 수 있도록 일관된 계층을 생성합니다. 308 | 309 | Comcast는 인터넷 속도를 측정하는 방법의 측면에서 세상에 투명하기를 원했기 때문에 인터넷 속도 테스트인 [Speed-TestJS 도구](https://github.com/Comcast/Speed-testJS)를 공개했습니다. 속도. 또한 이 프로젝트를 통해 사람들은 도구를 직접 사용하여 Comcast가 약속한 것을 제공하고 있다는 느낌을 받을 수 있습니다. 이것은 개방의 결과로 더 많은 신뢰를 생성할 수 있는 도구의 좋은 예입니다. 310 | 311 | 프로젝트에 기여하는 것 외에도 Comcast는 [Cloud Foundry Foundation](https://www.cloudfoundry.org/membership/) , [Apache Software Foundation](https://www.apache.org/) , [리눅스 재단](https://www.linuxfoundation.org/membership/) , [Yocto 프로젝트](https://www.yoctoproject.org/) , [Linaro](https://www.linaro.org/) , [OpenStack Foundation](https://www.openstack.org/foundation/) , [오픈 네트워크 자동화 플랫폼(ONAP)](https://www.onap.org/) 및 [OpenDaylight](https://www.opendaylight.org/) 같은 여러 단체의 회원사입니다. 312 | 313 | ![컴캐스트 OSPO 외부 협업](oss-foundations.png) 314 | 315 | 이러한 기여를 통해 Comcast는 오픈 소스 커뮤니티에 참여함으로써 얻게 되는 선의의 혜택을 받았습니다. Comcast의 기여는 회사가 새로운 개발자를 모집하는 데에도 도움이 되었습니다. 오늘날 개발자들은 훌륭한 오픈 소스 시민인 회사에서 일하기를 원하며 다양한 커뮤니티에서 Comcast의 기여는 오픈 소스에 대한 헌신에 대해 진지하다는 것을 보여줍니다. 316 | 317 | ### 비즈니스와 연계 318 | 319 | > "관행 확립, 재단 수준에서의 가시적인 참여, 기여도 증가, 리더십 지원 및 회사로서의 도구 지원으로 인해 오픈 소스를 쉽게 수행할 수 있습니다." – Nithya Ruff, Comcast의 Open Source Practice 수석 이사. 320 | 321 | 회사의 오픈 소스 전략이 비즈니스 전략과 밀접하게 일치하는지 확인하는 것이 중요합니다. 오픈 소스 오피스는 회사의 목표를 진정으로 이해하고 오픈 소스 전략에서 이를 가능하게 해야 합니다. 이러한 전략적 연계를 통해 오픈 소스 관행이 Comcast의 광범위한 회사 목표와 연계되어 관행과 회사 전체의 장기적인 성공을 장려할 수 있습니다. 322 | 323 | ### 마이크로소프트 324 | 325 | 마이크로소프트는 이제 오픈 소스 공간에서 인정받는 거대 기업이지만 불과 몇 년 전만 해도 소프트웨어 거물이 그런 역할을 한다는 것은 상상할 수 없는 일처럼 보였습니다. 따라서 많은 사람들은 Microsoft가 독점 소프트웨어 제조업체로 시장 주도권에서 벗어나 오픈 소스로 크게 이동했을 때 놀랐습니다. 이 회사의 스토리는 주목할 만하지만 오픈 소스 여정은 예상보다 갑작스러웠고 예상하지 못했습니다. 326 | 327 | > "인식에도 불구하고 Microsoft는 꽤 오랫동안 오픈 소스를 수행해 왔습니다. 처음에는 여기저기서 실험적인 부분이었지만 약 6년 전인 2011년에 Microsoft Open Technologies라는 단체에서 그 많은 부분에 초점을 맞췄습니다. "라고 Microsoft의 오픈 소스 프로그램 오피스 이사인 Jeff McAffer가 설명했습니다. 328 | 329 | ### 본격적으로 오픈 소스 330 | 331 | 그때부터 마이크로소프트가 오픈 소스로 무엇을 할 수 있는지에 대한 탐색이 본격적으로 시작되었다고 McAffer는 말했습니다. 초기에는 회사에서 오픈 소스로 무엇이든 하는 데 관심이 있는 사람이 있으면 중앙 그룹에 와서 관련 오픈 소스 개발자, 기여자 및 유지 관리자의 도움을 받았습니다. 332 | 333 | 약 3년 전, 상황이 바뀌기 시작했습니다. Microsoft는 회사 전체에 오픈 소스를 보급하기로 결정하고 주요 엔지니어링 그룹에 오픈 소스를 적용했습니다. 334 | 335 | > "이것이 우리가 한 일의 전부였다면 우리가 오픈 소스를 수행하는 방식에 대해 견딜 수 없는 공백을 남겼을 것입니다."라고 McAffer는 말했습니다. “누군가는 정책과 모든 오픈 소스 노력을 조정하는 방법, 사용할 프로세스와 도구, 프로젝트를 추적하는 방법 등에 대해 생각해야 합니다. 그래서 모든 문제를 처리하기 위해 우리는 현재 오픈 소스 프로그램 오피스로 알려진 것을 만들었습니다." 336 | 337 | 초기 오픈 소스 그룹의 기술 인력 중 일부는 새로 구성된 프로그램 오피스로 이동했고 다른 일부는 자신의 작업과 관련된 엔지니어링 그룹에 합류했습니다. 마이크로소프트는 모든 프로젝트와 프로세스가 완전히 사람이 되었는지 확인하기 위해 추가 인력이 필요했고, 따라서 내부 및 외부의 채용 노력이 곧 진행되고 있었습니다. 오늘날 오픈 소스는 Microsoft의 글로벌 작업에서 번창하는 부분입니다. 338 | 339 | ### 비즈니스 및 프로그래매틱 목표 340 | 341 | Microsoft에는 중앙 오픈 소스 전략이나 중앙 승인 기관이 없습니다. 대신 오픈 소스 프로그램 사무국은 회사 전체에서 이러한 논의와 결정을 용이하게 합니다. 팀은 여전히 ​​오픈 소스 참여를 검토해야 하지만 더 로컬에서 수행됩니다. 342 | 343 | > "그들은 자신의 비즈니스를 알고, 기술적 상호 작용이 어떻게 작동하기를 원하는지, 생태계 측면에서 추진하고자 하는 위치, 발생해야 하는 모든 다양한 뉘앙스를 이해합니다."라고 McAffer는 말했습니다. 344 | 345 | > "우리는 이러한 결정과 지시의 대부분을 현지 경영진에게 맡기지만 그러한 결정과 지시에 대해 생각할 수 있는 구조를 그들에게 제공합니다. 우리는 IP를 관리하는 방법과 보안 문제에 대해 수행하는 작업에 대한 중앙 정책을 가지고 있습니다. 우리는 일관성 있고 구체적인 방식으로 매우 간단하게 실행할 수 있도록 이러한 정책을 구현하는 도구와 프로세스를 제공하십시오." 346 | 347 | ### 관리 도구 348 | 349 | Microsoft의 정책은 워크로드를 처리하기 위해 그에 따라 도구가 사용되는 프로세스로 요약됩니다. 한 가지 예는 오픈 소스 릴리스입니다. 정책의 문제로 릴리스는 GitHub에서 이루어집니다. 350 | 351 | > McAffer는 "GitHub에서 우리의 존재를 둘러싸고 많은 도구를 사용하고 있으며 약 100개 조직에서 10,000개 이상의 리포지토리를 관리하고 약 12,000명의 Microsoft 직원이 해당 공간에서 상호 작용합니다."라고 말했습니다. 352 | 353 | > "그것은 다양한 측면을 관리하는 시스템이 정말로 필요한 규모입니다. 예를 들어 사람들이 우리가 실행하는 프로젝트 중 하나에 기여하기를 원할 때 기여자 라이선스 계약 또는 CLA를 관리하는 데 도움이 되는 도구가 필요합니다. 이러한 모든 작업을 위해 우리는 솔루션을 직접 구축하거나 오픈 소스 솔루션으로 전환했습니다." 예를 들어, Microsoft는 CLA 관리를 위해 SAP가 만든 오픈 소스 프로그램인 [CLA Assistant](https://cla-assistant.io/)를 사용합니다. 354 | 355 | > "GitHub 관리 측면에서 우리는 GitHub에서 기업 존재를 관리하는 데 도움이 되는 기존 도구 세트가 없었기 때문에 다른 방향으로 이동했습니다."라고 McAffer는 말했습니다. "그래서 우리는 GitHub에서 오픈 소스로 사용할 수 있는 현재 [오픈 소스 포털](https://github.com/Microsoft/opensource-portal)이라고 하는 것을 만들었습니다." 356 | 357 | 그 요소는 [opensource.microsoft.com](https://opensource.microsoft.com/) 에서 쉽게 볼 수 있지만 Microsoft 직원이 저장소와 팀을 관리하는 내부 측면도 있습니다. 358 | 359 | > "우리는 소스를 공개했으며 다른 회사에서 이를 선택하여 내부적으로 사용하고 있으므로 양방향입니다."라고 McAffer는 설명했습니다. 360 | 361 | GitHub는 많은 상호 작용이 가능한 매우 풍부한 환경입니다. 많은 회사와 마찬가지로 Microsoft는 모든 일이 진행되고 있는지 추적하고 저장소에서 무슨 일이 일어나고 있는지 이해하는 데 어려움을 겪고 있었습니다. 362 | 363 | > "우리는 결국 GHTorrent 프로젝트에 참여하게 되었습니다. 우리는 그들과 꽤 많은 일을 했고 실제로 이제 GHTorrent 프로젝트를 후원하고 있으므로 [GHTorrent.org]에서 볼 수 있는 모든 Azure 리소스에 대한 비용을 지불합니다. http://ghtorrent.org/)"라고 말했다. 364 | 365 | GHTorrent는 Microsoft가 GitHub에서 진행 중인 일을 이해하는 데 도움이 될 뿐만 아니라 자체 프로젝트 측면에서도 내부적으로 이해하도록 도와줍니다. 그럼에도 불구하고 개인 리포지토리 작업 및 관리자 권한이 필요한 팀과 관련된 보다 자세한 데이터를 포함하여 GHTorrent가 설정하지 않은 작업이 있습니다. 366 | 367 | 회사는 결국 [GHCrawler](https://github.com/microsoft/ghcrawler) 라는 또 다른 시스템을 만들었습니다. 이 시스템도 오픈 소스로 제공됩니다. 이 도구는 커밋 수준, 팀 및 권한 변경 사항까지 GitHub의 모든 것을 추적합니다. 그런 다음 해당 데이터는 메트릭 및 추적 분석에 사용되어 얼마나 많은 pull 요청이 들어오는지, 조치를 취하는 속도, 닫거나 병합하는 데 걸리는 시간과 같은 통찰력을 발견합니다. McAffer는 "이는 우리의 존재를 추적하는 방법을 제공합니다. 368 | 369 | ### 오픈 소스 사용 간소화 370 | 371 | 오픈 소스의 사용은 Microsoft에서 완전히 다른 문제이며 다른 프로세스입니다. 회사는 오픈 소스를 무수히 활용하고 있으며, 이를 모두 추적하고 법적 보안 측면을 관리해야 할 필요성이 엄청납니다. 372 | 373 | > "우리는 오픈 소스 사용과 관련된 프로세스와 정책을 단순화하고, 책임 있는 오픈 소스 소비자가 되는 주요 속성을 제대로 이해하고, 올바르게 수행하는 방법을 확인하기 위해 엄청난 양의 작업을 수행했습니다. 라이센스에"라고 McAffer가 말했습니다. 374 | 375 | > "이를 위해 우리는 내부에서 진행 중인 일을 발견, 추적 및 모니터링하고 오픈 소스 사용에 대해 보고하는 많은 도구를 내부적으로 작성했습니다."라고 그는 말했습니다. 이러한 도구는 Microsoft의 엔지니어링 시스템과 긴밀하게 통합되어 있기 때문에 다소 독점적인 경향이 있습니다. 376 | 377 | > "우리는 이를 공개 소스 커뮤니티에서 더 광범위하게 사용할 수 있는 방법을 찾으려고 노력했지만 비즈니스 정책이나 엔지니어링에 여러 면에서 매우 구체적이기 때문에 조금 어려웠습니다. 다른 사람의 시스템과 같지 않을 것입니다."라고 McAffer가 말했습니다. 378 | 379 | Microsoft 오픈 소스 여정은 수년 동안 흥미로운 여정이었고 진정한 오픈 소스 정신에서 우리는 도구에서 코드에 이르기까지 그 과정에서 우리가 배운 것을 모든 사람과 계속 공유할 것입니다. 380 | 381 | ### Salesforce 382 | 383 | Salesforce는 오픈 소스 프로젝트가 소프트웨어 성공에 관심을 갖고 있는 다양한 이해 관계자 커뮤니티가 있을 때 건전한 상태를 유지한다는 것을 일찍부터 배웠습니다. 384 | 385 | [Apache Phoenix](https://phoenix.apache.org/)는 자체 오픈 소스 피닉스 프로젝트로 Salesforce에서 시작되었습니다. 그러나 Salesforce 외부의 사람들도 투자하고 프로젝트가 더 이상 한 회사의 필요와 욕구에 의존하지 않을 때까지는 성공하지 못했습니다. 진정한 커뮤니티 노력의 일환으로 다른 회사의 사람들이 참여하여 '이는 우리에게 유용하고 우리가 기여하고 싶습니다'라고 말했습니다." 최근에 그곳에서 오픈 소스 프로그램을 이끌었던 Salesforce의 소프트웨어 아키텍트 Ian Varley가 말했습니다. 결국, 이 다양한 커뮤니티 덕분에 Apache 프로젝트가 되고 회사 자체 엔지니어가 꿈도 꾸지 못했던 새로운 기능을 통합할 수 있었습니다. 386 | 387 | Salesforce는 프로젝트에 사용하고 참여할 다양한 관심을 육성한다는 이 개념에 계속 초점을 맞춥니다. 동시에 엔지니어링에서 법률, 마케팅 및 PR에 이르기까지 내부 이해 관계자를 오픈 소스 노력과 일치시키는 데 똑같이 집중하고 있습니다. 388 | 389 | ### 오픈 소스 프로그램 목표 390 | 391 | Salesforce는 오픈 소스와 관련하여 많은 우선 순위를 가지고 있습니다. 회사의 오픈 소스 전략은 모든 사람이 일치하도록 유지합니다. 전담 오픈 소스 프로그램 팀은 전략적 지침을 제공하고 오픈 소스의 생성 및 사용을 권장하는 내부 문서를 회사의 엔지니어링 팀에 배포합니다. 이 문서는 오픈 소스 문화의 기초를 제공하고 회사의 리더가 전략 뒤에 완전히 있음을 팀에 확실하게 알립니다. 392 | 393 | 오픈 소스는 점점 더 모든 회사의 거의 모든 소프트웨어 프로젝트의 일부가 되고 있습니다. 오픈 소스로 가질 수 있는 모든 가능한 유형의 비즈니스 모델이 생겨나고 시장에서 손을 댈 것이 당연합니다. 394 | 395 | Salesforce는 SaaS(Software-as-a-Service) 공급업체이며 오픈 소스로 판매하는 최종 고객 대면 제품을 출시하지 않습니다. 대신 엔지니어링 팀은 다른 회사에서 일반적으로 유용하다고 생각할 수 있는 공유 인프라 구성 요소, 라이브러리 및 도구와 고객에게 유용한 샘플 및 SDK를 공개 소싱하는 데 중점을 둡니다. 396 | 397 | ### 오픈 소스 성공 측정 398 | 399 | 회사의 오픈 소스 프로그램의 한 가지 목표는 개발자들 사이에서 명성을 쌓는 것입니다. Varley는 Salesforce 제품을 사용하지 않을 수 있는 엔지니어가 회사의 오픈 소스 프로젝트를 보고 "이 회사는 정말 대단한 일에 관여하고 있습니다."라고 말합니다. 400 | 401 | > "오픈 소스는 (외부 개발자)가 회사 내부에서 진행 중인 훌륭한 엔지니어링을 볼 수 있는 창입니다. 그렇지 않으면 볼 수 없습니다." – Ian Varley, Salesforce의 소프트웨어 설계자. 402 | 403 | 오픈 소스 프로그램은 또한 회사의 자체 오픈 소스 프로젝트 뒤에 있는 커뮤니티를 확장하는 데 중점을 둡니다. 커뮤니티는 소프트웨어를 사용할 뿐만 아니라 기여합니다. 그래서 그들은 패치에 대한 명확한 승인 프로세스, 문서 개선, 건전한 포럼, 환영하고 반응이 빠른 유지 관리자와 같은 프로젝트에 "경로에"를 만드는 데 중점을 둡니다. 404 | 405 | > "박사 학위가 필요하지 않거나 유사한 분야에서 25년 동안 일해 온 사람들이 우리 프로젝트에 참여할 수 있는 방법을 제공했을 때 우리는 성공했습니다. 빠르게 참여할 수 있는 방법이 필요합니다. "라고 발리는 말한다. 406 | 407 | Salesforce는 또한 업계 전반에 걸친 오픈 소스의 성공과 비교하여 자체적인 성공을 측정합니다. 많은 측면에서 오픈 소스가 더 많이 발전할수록 모든 사람이 더 나아집니다. 더 많은 오픈 소스가 업계 전체에서 더 많은 발전을 의미하기 때문입니다. Salesforce가 상용 소프트웨어와 모든 사람이 의존할 수 있는 공유 구성 요소를 구성하는 기준을 높일 수 있다면 업계 전체에 이익이 됩니다. 408 | 409 | ### 아파치 피닉스 410 | 411 | Apache Phoenix는 현재 Apache Software Foundation의 일부인 오픈 소스 빅 데이터 분석 플랫폼입니다. 그러나 Phoenix가 시작했을 때 몇 가지 특정 내부 사용 사례를 위해 구축된 몇 명의 Salesforce 엔지니어 프로젝트에 불과했습니다. 그러나 오래지 않아 이 소규모 팀은 누구나 프로젝트의 혜택을 볼 수 있고 전 세계가 이 프로젝트에 참여하면 속도가 향상될 것이라는 것을 깨달았습니다. 그래서 그들은 그것을 오픈 소스로 만들고 커뮤니티 프로젝트로 전환하기 위해 피치를 만들었습니다. 412 | 413 | 오픈 소스 Phoenix 프로젝트를 만든 첫 해에 Salesforce 엔지니어들은 Phoenix를 발견하고 프로젝트에 참여하기를 원하는 두세 개의 대기업으로부터 기능에 상당한 기여를 하기 시작했습니다. 프로젝트를 외부 사용 및 기여에 개방함으로써 Phoenix 프로젝트는 원래 엔지니어가 스스로 할 수 있었던 것 이상으로 진행되었습니다. 414 | 415 | ### 5가지 핵심 교훈 416 | 417 | Salesforce에서 오픈 소스를 관리한 4년의 경험을 되돌아보면 Varley는 자체 오픈 소스 프로그램을 이제 막 시작하려는 회사를 위한 5가지 핵심 교훈을 제공합니다. 418 | 419 | * 내부적으로 오픈 소스의 사용과 생성을 강력하게 권장하는 전사적 정책을 만듭니다. 420 | * 커뮤니티는 내부적으로 달성할 수 있는 것 이상으로 프로젝트를 발전시킬 수 있음을 인식합니다. 421 | * 다양한 유형의 이해 관계자로부터 오픈 소스 프로그램에 대한 의견을 구하십시오. 예를 들어, 엔지니어가 유일한 이해관계자가 되어서는 안 됩니다. 예를 들어 법무팀과 경영진도 직접 참여해야 합니다. 422 | * 훌륭한 설정 문서와 건전한 포럼을 통해 오픈 소스 프로젝트에 대한 좋은 "경사로"에 집중하십시오. 423 | * 오픈 소스의 성공은 업계 전체의 성공과 모든 곳에서 더 나은 제품을 주도할 수 있음을 인식합니다. 424 | 425 | ### 추가 리소스 426 | 427 | 이 모듈은 조직이 자체 오픈 소스 프로그램 오피스를 만드는 데 도움이 되는 다양한 정보를 다루었지만 이 과정에서 완전히 다룰 수 있는 것보다 더 세부적이고 미묘한 차이가 있습니다. 따라서 사례 연구를 보거나 이 주제에 대한 추가 정보를 얻는 데 사용할 수 있는 몇 가지 추가 리소스가 포함되어 있습니다. 428 | 429 | * TODO 그룹: [https://todogroup.org/](https://todogroup.org/) 430 | 431 | * 오픈 소스 프로그램 오피스는 무엇을 합니까? (Red Hat 블로그): [https://www.redhat.com/en/blog/what-does-open-source-program-office-do](https://www.redhat.com/en/blog/what-does-open-source-program-office-do) 432 | 433 | * Google이 새로운 종류의 오픈 소스 프로그램 오피스(Opensource.com)을 만든 방법: [https://opensource.com/business/16/9/google-open-source-program-office](https://opensource.com/business/16/9/google-open-source-program-office) 434 | 435 | * 오픈 소스 프로그램 오피스가 있습니다. 이제 무엇을 합니까? (비터지아 블로그): [https://blog.bitergia.com/2019/03/05/ive-got-an-open-source-program-office-now-what/](https://blog.bitergia.com/2019/03/05/ive-got-an-open-source-program-office-now-what/) 436 | --------------------------------------------------------------------------------