당신은 현재 두 가지 상황 중 하나에 있으실 것입니다. 팀이 정제된 사유적 도구와 열린 소스 스택을 선택해야 하는 상황, 또는 이미 열린 소스만 사용하고 더 어려운 질문에 대한 명확한 대답이 필요합니다: 언제 이익이 증명되고, 언제 팀의 책임이 옮겨지는지.
그것이 핵심적인 대화입니다. 대부분의 기사에서는 열린 소스를 이익이 좋은 목록으로 단순화합니다: 낮은 비용, 더 많은 유연성, 더 나은 보안, 큰 커뮤니티. 모두 사실일 수 있습니다. 그러나 실제 운영 환경에서 자동으로 사실이 아닙니다.
For teams shipping Capacitor or Electron apps, the gap between theory and practice gets even more obvious. You’re not just picking a library. You’re choosing how fast you can fix bugs, how much control you keep over your release process, how dependent you become on vendors, and who owns the hard parts when something breaks on Friday night.
목차
- 최고의 팀이 열린 소스를 선택하는 이유
- 실제 운영 환경에서 소스 접근이 어떻게 바뀌는지
- 세계적인 кух대 beats closed recipe book
- 개방형 소스에서 보안을 강화하는 방법
- 제조업체에 의존하는 비용을 줄이기
- 제조업체에 의존하는 것을 운영 환경에서 개방형 소스로 대체하는 방법
- 개방형 소스를 전략적 이점으로 만드는 방법
왜 최고의 팀이 개방형 소스를 선택하는가
개방형 소스를 PROCUREMENT 단축법으로만 보지 마라. 누군가는 0 달러 라이선스를 보고, 제조업체의 견적과 비교하고, 결정을 주로 금전적인 문제로만 생각한다. 강력한 팀은 그렇게 생각하지 않는다. 그들은 개방형 소스를 사용하기 때문에 빠르게 빌드, 적응, 복구할 수 있기 때문이다.
비즈니스 가치는 단 한 팀의 소프트웨어 비용보다 더 큽니다. 하버드 비즈니스 학교 연구원들은 널리 사용되는 오픈 소스 소프트웨어의 수요 측면 대체 가치를 2.59조 달러에서 13.18조 달러로 추정했습니다. 대량으로 사용되는 오픈 소스 소프트웨어의 수요 측면 대체 가치 2.59조 달러에서 13.18조 달러 13.18조 달러그리고 글로벌 프로그래머 사용을 고려할 때 8.8조 달러로 조정됩니다. 8.8조 달러 하버드 비즈니스 학교 연구 논문그것이 오픈 소스 이점의 숨겨진 엔진입니다. 팀이 승리하는 것은 "__CAPGO_KEEP_0__이 무료" 때문이 아닙니다. 승리는 엔지니어를 재배치하는 비용을 중단하는 것입니다.).
That’s the hidden engine behind many open source advantages. Teams don’t win because code is “free.” They win because they stop paying engineers to reinvent plumbing.
모바일 제품을 개발하는 경우 이 점은 어디서나 중요합니다. 인증 흐름, 로컬 스토리지 wrapper, 네이티브 브리지, 빌드 도구, 업데이트 인프라, 로깅 헬퍼, UI 컴포넌트, 테스트 러너 등 모든 것이 제품에 특화된 __CAPGO_KEEP_0__을 작성하기 전에 존재합니다.
오픈 소스는 code 대신 시간을 구매하는 것을 허용합니다. 소프트웨어에서 가장 가치 있는 거래가 종종 이렇습니다.
code은 소프트웨어입니다.
실용적인 규칙: 공유 인프라에 대해 오픈 소스를 사용하세요. 고객이 실제로 인지하는 부분에 대한 커스터마이즈 엔지니어링 노력을 투자하세요.
이것도 오픈 소스가 현대 스택의 프레임워크부터 패키지 관리자까지 배포 도구까지 전반적으로 나타나는 이유입니다. 최고의 팀은 개발자의 선호도라고 생각하지 않습니다. 비즈니스에서 차별화된 부분에 집중하기 위해 예산과 주의를 집중하는 방법으로 생각합니다.
실제로 그 모델이 어떻게 작동하는지에 대한 지구력 있는 관점을 원한다면 Capgo가 쓴 오픈 소스 소프트웨어와 팀이 그것을 선택하는 이유 모바일 팀이 이동성과 운영 제어를 모두 필요로 할 때 유용한 동반자입니다.
기술적 유연성과 제어를 해제하는 방법
proprietary 소프트웨어는 종종 폐쇄된 엔진입니다. 키를 돌려도 기어를 열 수 없습니다. 오픈 소스는 거의 작동하는 패키지를 의존하는 앱이 있는 경우에 특히나 아픈 곳이 됩니다.
오픈 소스는 종합 도구와 더 가깝습니다. 움직이는 부분을 검사할 수 있고 하나가 실패하면 교체할 수 있고 도로가 바뀌면 기계를 적응할 수 있습니다.
핵심적인 기술적 이점은 source-code 접근성팀은 code을 검사, 수정 및 재배포할 수 있으며, 이는 직접 커스터마이즈하고 빠른 버그 수정을 위해 벤더 제어 업데이트 주기를 기다리지 않고 가능하게 합니다. Texas A&M International University의 오픈 소스 소프트웨어의 IT 역할에 대한 논의 (code의 오픈 소스 소프트웨어 소스 접근성).
실제 프로젝트에서 소스 접근의 변화
실제 프로젝트에서 소스 접근은 위험의 모양을 바꿉니다.
만약 플러그인이 하나의 안드로이드 버전에서만 깨지면 실제 구현을 디버깅할 수 있습니다. 만약 라이브러리가 온보딩 플로우에 거의 맞으면 에지 케이스를 패치할 수 있습니다. 만약 API wrapper가 플랫폼 변경에 뒤쳐지면 팀은 유지보수자가 먼저 움직이는 것보다 먼저 움직일 수 있습니다.
그것은 모든 팀이 모든 것을 포크해야 한다는 뜻이 아닙니다. 대부분의 팀은 그렇게 shouldn't해야 합니다. 하지만 __CAPGO_KEEP_0__을 포크할 수 있다는 사실이 중요합니다. 그것은 의존성과 의존성의 차이입니다. 이것을 생각하는 유용한 방법은 다음과 같습니다: 닫힌 도구의 경우
계획은 '벤더에게 물어보세요'입니다.
- 오픈 도구의 경우__CAPGO_KEEP_0__
- __CAPGO_KEEP_0__개발자들은 '점검, 수정, 배포'라는 계획을 만들 수 있습니다.
개발 매니저에게는 이 옵션은 차단 위험을 줄여주고, 제품 매니저에게는 로드맵 의무를 보호해주며, 주니어 개발자에게는 학습 경로를 제공합니다. 구현은 숨겨져 있지 않고, 지원 티켓 뒤에 숨겨져 있지 않기 때문입니다.
앱 팀에서 이게 중요합니다.
Capacitor와 Electron 팀은 통합 경계에서 이 이점을 빠르게 느낍니다. 웹 code은 네이티브 동작과 일치합니다. 브라우저 가정과 장치 제약이 충돌합니다. 빌드 스크립트, 플러그인, 런타임 권한, 업데이트 흐름 모두 상호 작용합니다.
이것이 오픈 소스가 얻는 이점입니다. 동작을 추적할 수 있고, 업스트림 리뷰를 기다리면서 플러그인을 수정할 수 있고, 원래 프로젝트가 멈추더라도 원본 프로젝트의 개인 fork를 유지할 수 있습니다.
라이선스 조항은 여전히 중요합니다. 팀은 의존성의 기초가 된 후에 수정, 재배포, 또는 임베드할 수 있는지 이해해야 합니다. Capgo의 오픈 소스 라이선스 기초 개요는 팀이 그 명확성을 원치 않고, 모든 엔지니어를 법률 자문으로 만들지 않으려는 팀에게는 실용적인 시작점입니다. 커뮤니티 파워로 혁신을 가속화합니다.
싱글 벤더 팀은 환경을 테스트할 수 있는 수, 기능을 우선순위로 지정할 수 있는 수, 에지 케이스를 처리할 수 있는 수에 제한이 있습니다. 건강한 오픈 소스 프로젝트는 더 많은 사람들이 요리, 맛보기, 오류를 수정하는 바쁜 전문 요리사 кух대로 작동합니다. 한 요리는 강력한 메뉴를 생산할 수 있지만, 전 세계적인 кух장은 레시피를 지속적으로 개선합니다.
__CAPGO_KEEP_0__의 오픈 소스 라이선스 기초 개요는
IBM은 조직들이 오픈 소스를 선택하는 이유로 큰 커뮤니티 지원이라고 언급했습니다.그리고 이 협력 모델은 소프트웨어를 공유된 개선 시스템으로 바꾸어 많은 기여자들이 버그를 고치고 기능을 추가할 수 있게 합니다.).
IBM은 오픈 소스에 대해 무엇이며 조직들이 왜 이를 사용하는지에 대해 설명했습니다.
세계적인 주방은 폐쇄된 레시피 책보다 낫다.
이 패턴은 성숙한 프레임워크와 플러그인 생태계에서 볼 수 있습니다. 한 팀은 특정 장치 구성에 버그를 보고합니다. 다른 팀은 코어 유지자가 사용하지 않는 워크플로에 대한 지원을 추가합니다. alguien else는 문서를 개선합니다. 왜냐하면 그들은 다음 주에 신입 개발자가 마주하게 될 같은 날카로운 모서리를 마주했기 때문입니다.
Good open source doesn’t just give you code. It gives you a public memory of how other teams solved the same problem.
좋은 오픈 소스는 GitHub을 제공하는 것만이 아닙니다. 그것은 다른 팀이 같은 문제를 해결한 방법에 대한 공공의 기억을 제공합니다.
그것은 공공의 기억이 사람들이 인정하는 것보다 더 중요합니다. __CAPGO_KEEP_0__ 이슈, 예시 레포지토리, 토론, 블로그 게시물은 온보딩 저항을 줄여 팀이 매번 처음부터 시작하지 않도록 합니다.
커뮤니티의 이익은 프로젝트가 활발한 유지보수자와 사용자들이 기여하기 위해 충분히 관심을 기울이고 있는 경우 가장 강력합니다. 그것은 code 기여, 이슈 정리, 문서 개선, wrapper, 시작 템플릿, 또는 통합 가이드와 같은 다양한 형태로 나타날 수 있습니다.
소프트웨어 외에 분산 기여 모델의 작동 방식을 이해하고 싶은 팀이 있다면, 창작자들을 위한 가장 좋은 크라우드 소싱 플랫폼에 대한 개요는 유용한 대안입니다. 프로젝트의 개선은 참여자들이 공유된 결과에 노력을 투자하는 이유가 있는 경우에만 이루어집니다. 앱 팀에게는 커뮤니티 참여가 실용적이지요, 이념적이지 않습니다:
버그 리포트는 향후 업그레이드에 도움이 됩니다:
- 명확한 복제 단계가 종종 사례를 더 빠르게 해결하는 비공개 불만보다 이슈를 해결합니다. 문서 기여는 반복적인 지원 부하를 줄입니다:
- 만약 팀이 설정 세부 사항을 역공학적으로 복원해야 한다면, 다음 팀도 마찬가지일 것입니다. 작은 pull 요청은 영향력을 쌓습니다:
- 프로젝트는 건강을 유지하는 데 도움이 되는 사용자를 인정합니다. 오픈 소스 도구에 의존하는 스택이 있다면, 기여를 엔지니어링 하이진으로 다루어야 합니다. 팀이 수정, 문서, 또는 예제를 공개하면 종종 의존하는 생태계에서 더 많은 가치를 얻습니다. __CAPGO_KEEP_0__의
If your stack depends on open tools, it’s worth treating contribution as part of engineering hygiene, not charity. Teams that publish fixes, docs, or examples tend to get more value back from the ecosystems they rely on. Capgo’s contributing guide 실천하는 동일한 실제적인 접근 방식을 반영합니다.
투명성으로 보안 강화
소프트웨어에서 가장 느슨한 논쟁 중 하나는 공개 code가 불안전하다고 주장하는 것입니다. 공격자는 또한 바이너리를 역행할 수 있고, 동작을 검사할 수 있고, 미사용 설정을 악용할 수 있고,陈舊한 의존성을 대상으로 할 수 있습니다. 숨겨진 code은 위험을 제거하지 않습니다. 그것은 누구에게도 검사할 수 있는 것을 바꿉니다.
전문가들이 프로젝트를 효과적으로 관리할 때 투명성이 보안을 향상시키는 더 강력한 버전의 공개 소스 보안 논쟁은 유용합니다.
Kiuwan이 요약한 연구는 이 구별을 명확하게 합니다. 공개 소스가 보안을 향상시키는지는 유지 관리 구조와 기여자 보상에 따라 달라집니다. '많은 눈'의 아이디어는 기여자가 생태계에서 이익을 얻을 때 가장 잘 작동합니다. 공개 소스는 기본적으로 "많은 눈"이 보안을 향상시키는다는 것은 아닙니다. 기여자 보상과 유지 관리 구조가 가장 중요합니다. Kiuwan이 공개 소스 보안 이점과 관리에 대한 설명투명성이 도움이 되지만 관리가 결정합니다.).
공개된 저장소가 약한 유지 관리를 하더라도 보안 전략이 아닙니다. 그것은 그냥 위험한 것을 투명하게 만듭니다.
__CAPGO_KEEP_0__
소스 의존성 평가 시, 투명성의 슬로건을 넘어 더 어려운 질문을 묻는 것이 중요합니다:
- 이 프로젝트를 유지 관리하는 사람들은 누구인가?
- 변경 사항을 신중하게 검토하는가?
- 보안 문제를 책임 있게 논의하는가?
- 프로젝트는 지속적인 관리를 보여주고 있는가, 아니면 활동이 폭발하고 나서 침묵을 지키는가?
성숙한 오픈 소스 프로젝트는 더 쉽게 감사할 수 있다. 팀은 직접 code 경로를 검사하고 앱 내부에서 실행되는 것을 이해할 수 있다. 규제 팀에게 유용한데, 벤더의 주장만으로 내부 검토가 충분하지 않기 때문이다.
투명성도 책임을 부여한다. 패치가 존재하고 팀이 적용하지 않았다면, 소스에 대한 가용성에 실패한 것이 아니다. 프로세스 때문이다.
투명성을 잘 사용하는 방법
제품 팀에게는 보안 이점이 오는 것은 오픈 소스를 운영 관리와 Pairing하는 것이다.
간단한 모델을 사용하라:
- 가져온 의존성을 감사하라. 튜토리얼이 패키지를 추가하라고 한 이유로 패키지를 추가하지 마라.
- 활발한 프로젝트를 선호하세요. 죽은 저장소는 침묵적인 노출을 생성합니다.
- 업데이트 책임을 추적하세요. 팀 중 alguien이 의존성 검토를 소유해야 합니다.
- 어셈블리된 앱을 테스트하세요. 안전한 라이브러리가 불안전한 릴리스 프로세스 내에 있더라도 여전히 노출됩니다.
SaaS 및 모바일 팀이 외부 테스트 관점이 필요한 경우, 의존성 위생과 함께 애플리케이션 수준 보안 검증이 어디에 위치하는지 설명하는 실용적인 설명서를 찾고자 한다면 SaaS 보안 테스트 애플리케이션 수준 보안 검증이 의존성 위생과 어디에 위치하는지 설명하는 실용적인 설명서를 찾고자 한다면
보안 takeaway: 오픈 소스는 검사하고 패치를 할 권리를 제공합니다. 판단을 외주하는 것은 아닙니다.
그 distinction은 Capacitor 및 Electron 앱에 중요합니다. 공격 표면은 자바스크립트 패키지, 네이티브 플러그인, 업데이트 채널, 저장소层, 백엔드 API로 구성됩니다. 투명성은 chain을 검사하는 데 도움이 됩니다. Governance은 chain이 신뢰할 수 있는지 결정합니다.
Vendor Lock-In을 줄이고 총 비용을 줄이기 위해
Vendor Lock-In은 비싼 인쇄기만큼 비싸지 않게 인쇄기를 구매하는 것과 비슷합니다. 초기 비용은 관리가 가능해 보입니다. 그러나 장기적인 의존성은 비용이 드는 곳입니다.
이것이 오픈 소스 이점이 팀이 협상력을, 이주 옵션, 또는 타이밍을 제어할 때 중요해지는 이유입니다. code를 검사할 수 있고, 자체 호스팅, fork, 또는 지원層을 교체할 수 있다면 옵션이 있습니다. 옵션은 전략적입니다.
라이선스 비용은 총 비용이 아닙니다.
이것이 오픈 소스에 대한 나쁜 조언이 무너지는 곳입니다. 사람들이
무료 라고 말할 때, 라이선스 비용이 없다는 것을 의미합니다. 이것은 같은 statement가 아닙니다.오픈 소스는 비용을 shift, 비용을 제거하지는 않습니다.라이선스가 무료일 수 있지만, 조직은 전문 직원을 필요로 하며, 내부 전문 지식을 필요로 하며, 지속적인 유지 보수를 통해 효과적으로 보안, 통합, 운영을 해야 합니다. 이는 오픈 소스와 비영리 소프트웨어 간의 단순한 비교에서 큰 결함입니다.).
이것이 오픈 소스와 비영리 소프트웨어 간의 비용과 소유권의 총 비용에 대한 Nebius입니다.
- 따라서 TCO는 최소 4개의 버킷을 포함해야 합니다. 구매:
- 구현: 설치, 통합, 내부 도구, 마이그레이션 작업.
- 운영: 패치, 모니터링, 업그레이드, 인시던트 대응.
- 인력 비용: 시스템을 잘 이해하는 엔지니어들이 시스템을 소유할 수 있는 엔지니어들.
잠금은 예산 문제입니다.
반대의 경우도 사실입니다. 사유 도구는 종종 판매자가 패키징, 지원 및 정제된 워크플로우를 처리하도록 함으로써 근시안적인 작업 부하를 줄입니다. 이는 작은 팀이나 고준수 환경에 적합한 거래일 수 있습니다.
그러나 잠금은 청구서에 표시되지 않은 경우에도 비용이 있습니다. 로드맵 변경이 판매자의 우선 순위 뒤에 막히거나, 지원 대기열이 крит적 인 수정을 막거나, 마이그레이션 이 τόσο 고통스럽게 느껴질 때 "다시 갱신" 하는 것이 시스템을 되찾는 것보다 저렴한 경우가 있습니다.
운영 도구 비교를 하는 팀에게는 무료 syslog 서버 선택 가이드 이것은 "무료" 옵션들이 설정 부하, 유지 보수 기대치 및 환경에 적합한지 평가하는 시야로 평가해야 하는 경우의 예입니다.
모바일 릴리스 인프라에 대해서도 동일한 논리가 적용됩니다. 오픈 소스 기반은 가용성을 제공합니다. 서비스 레이어는 운영적 고통을 제거하는 경우에만 비용을 지불할 가치가 있습니다. 그게 Capgo가 오픈 소스 vs 사유 앱 업데이트 솔루션에 대한 토론의 실용적인 프레임입니다. 오픈 소스 vs 사유 앱 업데이트 솔루션.
운영 환경에서 오픈 소스를 운영화하는 방법
오픈 소스는 릴리스 PIPELINE에 들어가면 철학이 아닌 운영 문제가 됩니다. 그때부터 우리는 무엇을 신뢰하고, 어떻게 평가하고, 그리고 채택 후 누구에게 소유권을 넘길 것인지에 대한 문제가 됩니다.
팀은 일반적으로 두 가지 방법으로 문제를 겪습니다. 첫 번째는 패키지가 인기 있는 경우에 의존성을 너무 쉽게 승인하는 것입니다. 두 번째는 nobody가 반복 가능한 검토 프로세스를 갖고 있지 않아 유용한 도구를 거부하는 것입니다. 짧은 체크리스트는 두 가지 문제를 모두 해결할 수 있습니다.
오픈 소스 컴포넌트 평가 체크리스트
| 기준 | 체크할 내용 | 주의 |
|---|---|---|
| 라이선스 적합성 | 앱, 배포 모델, 그리고 고객 의무에 맞는 라이선스가 있는지 | 팀은 라이선스가 무엇을 허용하는지 설명할 수 없습니다. |
| 유지관리자 건강 | 최근 커밋, 이슈 정리, 릴리즈 노트, 명확한 소유권 | 장기간의 침묵 또는 비응답의 중요 이슈 |
| 커뮤니티 품질 | 유용한 토론, 문서, 재현 가능한 버그 리포트, 예시 | 활동이 존재하지만 대부분의 경우 해결되지 않은 혼란 |
| 통합 노력 | 자연적인 호환성, 빌드 단계, 플러그인 설정, 업그레이드 복잡도 | 설정은 누구도 소유하고 싶지 않은 취약한 워크아라운드가 필요하다 |
| 보안 태세 | 공개 정보 습관, 패치 반응성, 의존성 청결 | 알려진 이슈가 유지관리자 반응 없이 남아 있다 |
| 포크 위험 | 포크가 필요할 때 임시 포크를 유지하거나 패치할 수 있는지 여부 | 코드베이스가 너무 불투명하여 포킹이 현실적이지 않다 |
| 관측 가능성 | 로그, 오류 표면, 프로덕션에서 디버그 가능성 | 실패는 무성음이고 추적하기 어렵다 |
| 이탈 경로 | 이후에 교체하기 어렵다 | 의존성이 깊게 내장되어 추상화가 없다 |
웹 라이브러리, 네이티브 플러그인, 자체 호스팅 서비스 및 릴리스 도구에 잘 작동하는 테이블
팀은 오픈 소스 컴포넌트를 동일한 방법으로 인프라 벤더를 승인해야 한다. alguien이 흥분의 감각이 사라진 후에 소유권을 소유해야 한다.
실용적인 Capacitor 및 Electron 워크플로우
실제 앱 스택으로 그것을 넣어보세요.
Capacitor 팀은 프레임워크 자체를 시작으로 파일, 인증, 장치 API, 로컬 알림, 분석, 또는 앱 내 동작을 위한 커뮤니티 플러그인을 추가합니다. 그 모델은 합리적입니다. 프레임워크는 안정적인 브릿지를 제공하고 에코 시스템은 제품별 결함을 채웁니다.
업데이트와 운영 제어에서 고통은 일반적으로 나중에 나타납니다. 자바스크립트, CSS, 콘텐츠 및 웹 자산은 원시 바이너리 릴리스보다 훨씬 더 빠르게 변경됩니다. 앱 스토어 리뷰 사이클은 그 속도와 일치하지 않습니다. UI 결함이 프로덕션에 도입되면, 완전한 원시 릴리스 경로를 기다리는 것은 시간과 지원 부하가 비싼 것입니다.
Capacitor 에코 시스템에서, Capgo Capacitor
code
그것은 오픈 소스 업데이터 플러그인과 클라우드 서비스를 제공합니다. 그것은 signed 웹 번들을 배송하고, 런칭 시 업데이트를 적용하고, __CAPGO_KEEP_0__ 앱에 대한 롤백 보호를 제공합니다.
- 그것은 혼합된 접근법입니다. __CAPGO_KEEP_0__ 경로를 유지하고 싶지만, 모든 운영 부분을 수동으로 빌드하지 않으려면 유용합니다. 정확한 워크플로우는 다음과 같습니다:
- 의존성을 자신의 인터페이스 뒤로 감싸세요: 세 번째 파티 API가 앱에 미치는 영향을 확인하지 않도록 하세요.
- 채널을 통해 스테이지 업데이트를 진행합니다: 내부 또는 베타 그룹에서 광범위한 론칭 전에 테스트합니다.
- 롤백이 간단해야 합니다: 업데이트가 시작 또는 핵심 흐름에 피해를 주면, 그 것을 되돌리는 것이 지루해야 합니다.
- 문서 소유권을 문서화합니다: 모든 기초 패키지는 리뷰를 담당하는 팀 또는 개인이 있어야 합니다.
어느 날에는 일부 팀이 완전한 인프라 제어도 원할 수 있습니다. 그 경우에, Capgo의 자체 호스팅 Capgo 구성을 위한 안내서가 관련이 될 수 있습니다. self-hosted Capgo setup 큰 교훈은 간단합니다. 개방 소스는 운영에 지루한 습관과 유연성을 결합할 때 프로덕션에서 가장 잘 작동합니다: 버전 관리, 리뷰 게이트, 릴리스 채널, 롤백 계획, 명확한 소유권.
개방 소스를 전략적 이점으로 만드는 방법
강력한 개방 소스 이점은 격리된 이익이 아닙니다. 그들은 서로를 강화합니다.
Capgo의 자체 호스팅 __CAPGO_KEEP_0__ 구성을 위한 안내서
제어는 의존성을 배달에 방해하지 않도록 하기 때문에 중요합니다. 커뮤니티는 의존하는 도구를 개선하는 사람들의 수를 확장하기 때문에 중요합니다. 투명성은 감사, 패치, 이해하기 쉬운 시스템을 만들기 때문에 중요합니다. 비용은 라이선스 비용을 피하는 것이 도움이 되지만浪費, LOCK-IN, 중복된 엔지니어링 노력을 피하는 것이 일반적으로 더 큰 이익을 얻는 곳입니다.
팀은 오픈 소스를 카테고리처럼 다루지 않고 능력으로 다루면 오픈 소스에서 가장 많은 이점을 얻을 수 있습니다. 모든 프로젝트를 채택해야 하는 것은 아닙니다. 모든 무료 도구는 운영 비용이 적지 않습니다. 모든 코드베이스가 안전하지 않습니다. 그러나 팀이 구성 요소를 신중히 평가하고 discipline로 운영할 때, 오픈 소스는 이점을 포기하지 않고 더 빠르게 움직일 수 있는 방법이 됩니다.
제품 매니저에게는 벤더 결정에 묶여있는 로드맵의 병목 현상을 줄이는 것이 중요합니다. 엔지니어에게는 디버깅, 확장, 복구에 더 많은 공간이 필요합니다. 모바일 및 데스크톱 앱을 배달하는 회사에게는 배달 프로세스가 자신의 우선순위를 반영할 수 있습니다.
오픈 소스는 책임의 부재가 아닙니다. 오픈 소스는 올바른 책임을 소유할 수 있는 옵션입니다.
Capacitor 또는 Electron 앱을 배달하는 팀이 웹 업데이트에 대한 더 많은 제어를 원하면서도 오픈 소스 기반을 포기하지 않으면서 Capgo 열거할 가치가 있습니다. 이 업데이터 플러그인은 관리되는 배포, 롤아웃 제어, 롤백 지원 및 릴리스 관찰성을 제공하여 빠르게 움직일 수 있는 팀이 업데이트 경로를 이해할 수 있도록 합니다.
