소스 코드 가용성 비용은 누가 부담해야 하는가?

Zine의 11개 의존성이 GitHub·Codeberg·Forgejo에 흩어져 있어 호스트 장애가 새 빌드 실패로 이어지며, 문제의 본질은 호스팅 기술보다 가용성 비용의 부담 주체에 있음 포크와 벤더링은 소비자도 보존 비용을 나누게 하지만 복사본을 자동으로 발견하거나 미러로 활용하기 어렵고, 중앙 패키지 저장소는 높은 가용성 비용을 기업 후원과 자원봉사에 의존함 Radicle은 관심 있는 저장소를 각 노드가 시드하는 P2P 네트워크로, Issues와 Patches까지 Git 객체로 저장해 제작자·사용자·의존 프로젝트가 필요에 따라 가용성 비용을 분담할 수 있음 Radicle의 RID는 특정 호스트가 아닌 암호학적으로 식별된 저장소를 가리키지만, Zig의 무의존성 원칙을 지키려면 직접 연결보다 HTTP 지원 노드와 미러 기능을 결합하는 편이 현실적임 Codeberg는 기부자가 비용과 정책을 결정하는 중앙형 비영리 모델이고 Tangled는 투자자와 atproto 인프라에 의존하는 연합형 모델인 반면, Radicle은 노드별 시드 정책과 중복 자원을 활용해 고가용성을 더 비용 효율적으로 달성할 가능성이 있음 포크와 벤더링이 해결하는 문제 정적 사이트 생성기 Zine은 GitHub, Codeberg, 자체 호스팅 Forgejo에 있는 11개 의존성을 사용함 GitHub나 Codeberg가 중단되면 새로운 빌드가 실패함 자체 호스팅 Forgejo는 가동 시간이 더 좋지만 영구 폐쇄되어 프로젝트를 계속 깨뜨릴 위험이 더 큼 포크는 Zine과 모든 의존성을 같은 호스트로 옮겨, 주 프로젝트를 복제할 수 있으면 의존성도 복제할 수 있게 함 간접 의존성까지 모두 포크해야 함 중간 의존성이 자체 포크를 참조하도록 수정해야 함 의존성 변경을 업스트림에 보내거나 커밋을 체리픽할 때는 벤더링보다 편리함 벤더링은 모든 의존성 소스를 프로젝트 저장소에 커밋해 한 번의 복제로 전체 소스를 얻도록 함 Zig 0.17.0-dev의 전역 캐시는 패키지를 압축 아카이브로 보관하고, 프로젝트의 zig-pkg/에는 사용 중인 의존성의 압축 해제 파일을 둠 zig-pkg/를 버전 관리에 추가하면 손쉽게 벤더링할 수 있으며, 벤더링하지 않을 때는 .gitignore에 넣는 방식이 권장됨 중앙 패키지 인덱스인 npmjs.com이나 crates.io는 소스를 자체 복사본으로 보관해 포크에 가까운 기능을 제공함 그러나 소스 가용성을 패키지 관리에만 묶음 목표...