본문으로 이동

오픈 소스 소프트웨어

위키백과, 우리 모두의 백과사전.
시나몬 데스크톱 환경을 실행 중인 데비안 리눅스의 스크린샷. 파이어폭스(미디어위키를 사용하는 위키백과에 접속 중), 리브레오피스 라이터, Vim, VLC 및 Nemo 파일 관리자가 실행되고 있으며, 이들은 모두 오픈 소스 소프트웨어이다.

오픈 소스 소프트웨어(Open-source software, OSS)는 저작권 보유자가 사용자에게 모든 사람과 어떤 목적으로든 소프트웨어 및 해당 소스 코드를 사용, 연구, 변경 및 배포할 수 있는 권한을 부여하는 라이선스 하에 배포되는 컴퓨터 소프트웨어이다.[1][2] 통상 간략하게 오픈 소스라고 말하기도 하며 대한민국의 공공기관에서는 공개 소프트웨어라는 표현을 사용한다.[3][4] (단, 저작권위원회에서는 오픈소스SW를 사용한다.[5]) 오픈 소스 소프트웨어는 협력적이고 공개적인 방식으로 개발될 수 있다. 오픈 소스 소프트웨어는 개방형 협업의 두드러진 사례로, 능력을 갖춘 사용자라면 누구나 개발에 온라인으로 참여할 수 있어 잠재적 기여자 수가 무한하다. 코드를 검사할 수 있는 능력은 소프트웨어에 대한 대중의 신뢰를 용이하게 한다.[6]

오픈 소스 소프트웨어 개발은 단일 기업의 시각을 넘어서는 다양한 관점을 가져올 수 있다. 2024년 추산에 따르면 기업에 대한 오픈 소스 소프트웨어의 가치는 8조 8천억 달러에 달하며, 오픈 소스 소프트웨어를 사용하지 않을 경우 기업들은 현재보다 3.5배 더 많은 비용을 지출해야 할 것으로 분석되었다.[7]

오픈 소스 코드는 학습용으로 사용될 수 있으며, 능력을 갖춘 최종 사용자가 사용자 스크립트나 커스텀 스타일 시트를 통해 웹사이트를 변경하는 것과 유사한 방식으로 자신의 필요에 맞게 소프트웨어를 조정할 수 있게 해준다. 또한 이러한 수정 사항을 비슷한 선호도를 가진 사용자들을 위해 포크로 공개하거나, 풀 리퀘스트를 통해 개선 사항을 직접 제출할 수도 있다.

정의

[편집]
오픈 소스 이니셔티브의 로고

오픈 소스 이니셔티브(OSI)의 정의는 여러 국가 정부에서 표준 또는 데 팍토 정의로 국제적으로 인정받고 있다.[8] OSI는 특정 소프트웨어 라이선스가 오픈 소스인지 판단하기 위해 오픈 소스의 정의를 사용한다. 이 정의는 주로 브루스 페렌스가 작성하고 수정한 데비안 자유 소프트웨어 지침을 기반으로 한다.[9][10][11] 페렌스는 나중에야 널리 알려진 자유 소프트웨어 재단(FSF)의 "네 가지 자유"를 기반으로 글을 작성하지 않았다.[12]

페렌스의 정의에 따르면, 오픈 소스는 소스 코드를 일반 대중에게 공개하고 코드의 사용 및 수정에 대한 제한이 완화되었거나 존재하지 않는 광범위한 소프트웨어 라이선스이다. 소프트웨어의 빠른 진화를 가능하게 하기 위해 모든 조직이나 사용자에 의한 사용 또는 배포에 매우 적은 제한을 두는 것이 오픈 소스의 명시적인 "특징"이다.[13]

펠러 등(2005)에 따르면, "자유 소프트웨어"와 "오픈 소스 소프트웨어"라는 용어는 "사용자가 적절하다고 판단하는 방식으로" 소프트웨어를 사용, 수정 및 재배포할 수 있도록 허용하는 조건으로 배포되는 모든 "소프트웨어 제품"에 적용되어야 하며, "나열된 활동에 참여하는 것에 대해 소프트웨어 저작자에게 로열티나 수수료를 지불할 것을 요구하지 않아야 한다."[14]

처음에는 이를 수용했음에도 불구하고,[15] FSF의 리처드 스톨먼은 현재 그들이 "자유 소프트웨어"라고 부르는 것에 "오픈 소스"라는 용어가 적용되는 것을 단호히 반대한다. 그는 두 용어가 "거의 동일한 범주의 소프트웨어"를 설명한다는 점에는 동의하지만, 두 용어를 동일시하는 것은 부정확하고 오해의 소지가 있다고 생각한다.[16] 스톨먼은 또한 소프트웨어 자유에 대한 FSF의 이상주의적 표준을 타협함으로써 자유와 공동체라는 자유 소프트웨어의 이상이 위협받을 것을 우려하여 오픈 소스 이니셔티브의 공언된 실용주의에 반대한다.[17] FSF는 자유 소프트웨어를 오픈 소스 소프트웨어의 부분집합으로 간주하며, 리처드 스톨먼은 예를 들어 DRM 소프트웨어가 오픈 소스로 개발될 수 있지만, 그것이 사용자에게 자유를 주지 않고 오히려 제한하기 때문에 자유 소프트웨어의 자격은 없다고 설명했다.[16]

오픈 소스 소프트웨어 개발

[편집]

개발 모델

[편집]

1997년 에세이 성당과 시장에서 오픈 소스의 영향력 있는 기여자인 에릭 S. 레이먼드는 시장(bazaar) 모델로 알려진 OSS 개발 모델을 제안한다. 레이먼드는 전통적인 방법론에 의한 소프트웨어 개발을 개인이나 소규모 그룹에 의한 신중하고 고립된 작업인 성당 건설에 비유한다. 그는 모든 소프트웨어가 서로 다른 의제와 접근 방식을 가진 시장 스타일을 사용하여 개발되어야 한다고 제안한다.[18]

그가 성당 모델이라고 부른 전통적인 개발 모델에서는 개발이 중앙 집중식으로 이루어진다. 역할이 명확하게 정의되어 있다. 설계에 전념하는 사람들(설계자), 프로젝트 관리를 책임지는 사람들, 구현을 책임지는 사람들이 역할에 포함된다. 전통적인 소프트웨어 공학은 성당 모델을 따른다.[18]

그러나 시장 모델은 다르다. 이 모델에서는 역할이 명확하게 정의되지 않는다.[18] 시장 모델을 사용하여 개발된 소프트웨어의 몇 가지 제안된 특징은 다음과 같은 패턴을 보여야 한다.[19]

  • 사용자를 공동 개발자로 대우해야 함: 사용자는 공동 개발자처럼 대우받으므로 소프트웨어의 소스 코드에 접근할 수 있어야 한다. 또한 사용자는 소프트웨어에 대한 추가 기능 제출, 코드 수정, 버그 보고, 문서화 등에 참여하도록 권장된다. 공동 개발자가 많아질수록 소프트웨어가 진화하는 속도가 빨라진다. 리누스의 법칙에 따르면 충분한 눈이 있다면 모든 버그는 쉽게 발견된다. 이는 많은 사용자가 소스 코드를 본다면 결국 모든 버그를 찾아내고 수정 방법을 제안할 것임을 의미한다. 일부 사용자는 고급 프로그래밍 기술을 가지고 있으며, 더 나아가 각 사용자의 컴퓨터는 추가적인 테스트 환경을 제공한다. 이 새로운 테스트 환경은 새로운 버그를 찾아 수정할 수 있는 능력을 제공한다.[19]
  • 초기 릴리스: 공동 개발자를 조기에 찾을 수 있는 가능성을 높이기 위해 소프트웨어의 첫 번째 버전은 가능한 한 빨리 출시되어야 한다.[19]
  • 잦은 통합: 프로젝트 생명 주기 마지막에 대량의 버그를 수정하는 오버헤드를 피하기 위해 코드 변경 사항은 가능한 한 자주 통합(공유 코드 베이스로 병합)되어야 한다.[19][20] 일부 오픈 소스 프로젝트는 통합이 자동으로 수행되는 나이틀리 빌드를 운영한다.[19]
  • 여러 버전: 소프트웨어에는 적어도 두 개의 버전이 있어야 한다. 기능은 더 많지만 버그가 더 많은 버전과 기능은 적지만 더 안정적인 버전이 있어야 한다. 버그가 있는 버전(개발 버전이라고도 함)은 최신 기능을 즉시 사용하고 싶어 하며 아직 철저히 테스트되지 않은 코드를 사용하는 위험을 감수할 의향이 있는 사용자를 위한 것이다.[19] 그러면 사용자는 공동 개발자로서 역할을 수행하며 버그를 보고하고 수정을 제공할 수 있다.[19][21]
  • 높은 모듈화: 소프트웨어의 일반적인 구조는 독립적인 구성 요소에 대한 병렬 개발이 가능하도록 모듈식이어야 한다.[19]
  • 동적 의사결정 구조: 변화하는 사용자 요구 사항 및 기타 요인에 따라 전략적 결정을 내리는 공식적 또는 비공식적인 의사결정 구조가 필요하다. 이는 익스트림 프로그래밍과 비교된다.[19]

오픈 소스 개발 프로세스는 개발자가 새로운 기능을 추가할지 또는 프로젝트의 버그를 수정해야 할지 고려하는 요구 사항 도출에서 시작된다. 이는 버그 추적 시스템이나 메일링 리스트, 프로젝트 페이지와 같은 경로를 통해 OSS 커뮤니티와 소통함으로써 확립된다. 다음으로 OSS 개발자는 작업을 선택하거나 할당받아 솔루션을 식별한다. OSS에서는 솔루션에 대한 여러 가지 경로가 있는 경우가 많기 때문에 신중한 고려와 때로는 동료 평가를 통해 최선의 솔루션을 선택해야 한다. 그런 다음 개발자는 코드를 개발하고 커밋하기 시작한다. 코드는 동료들에 의해 테스트되고 검토된다. 개발자는 지속적 통합의 피드백을 통해 코드를 수정하고 발전시킬 수 있다. 리더십과 커뮤니티가 프로젝트 전체에 만족하면 부분적으로 출시될 수 있으며 사용자 지침이 문서화될 수 있다. 프로젝트가 출시될 준비가 되면 심각한 버그 수정이나 보안 수리만 이루어지는 동결 상태가 된다. 마지막으로 프로젝트가 완전히 출시되며 사소한 버그 수정을 통해서만 변경된다.[21]

장점

[편집]

표준의 오픈 소스 구현은 해당 표준의 채택과 장기적인 생존 가능성을 높일 수 있다.[22] 기여자들이 개발 과정과 최종 결과물에 대해 더 큰 참여 의식과 소유감을 느끼기 때문에 개발자의 충성도를 높이는 경우가 많다.[23]

게다가 OSS에는 마케팅 및 물류 서비스에 대한 낮은 비용이 소요된다.[24] OSS는 상업용 제품을 포함한 회사의 이미지를 홍보하는 도구가 될 수 있다.[25] OSS 개발 방식은 신뢰할 수 있고 고품질의 소프트웨어를 빠르고 저렴하게 생산하는 데 도움이 되었다.[24]

오픈 소스 개발은 혁신을 가속화하고 사회적 가치를 창출할 수 있는 잠재력을 제공한다. 예를 들어 프랑스에서는 정부가 자유 오픈 소스 소프트웨어를 선호하도록 장려하는 정책을 통해 연간 OSS 기여가 약 60만 건으로 증가했으며, 오픈 소스 소프트웨어의 양과 질을 높여 사회적 가치를 창출했다. 이 정책은 또한 기술 스타트업이 최대 18% 증가하고 IT 분야 종사자 수가 14% 증가하는 결과를 가져온 것으로 추산된다.[26]

OSS는 수천 명의 독립적인 프로그래머가 소프트웨어의 버그를 테스트하고 수정할 때 매우 높은 신뢰성을 가질 수 있다.[19] 오픈 소스는 원래 그것을 만든 회사나 저작자에게 의존하지 않는다. 회사가 실패하더라도 코드는 계속 존재하며 사용자에 의해 개발된다.[27]

OSS는 모듈식 시스템을 통해 프로그래머가 커스텀 인터페이스를 구축하거나 새로운 기능을 추가할 수 있기 때문에 유연하며, 대규모의 서로 다른 프로그래머들 간의 협업 결과물이기 때문에 혁신적이다.[19] 다양한 관점, 기업의 목표, 개인의 목적이 섞이면서 혁신이 가속화된다.[28]

나아가 자유 소프트웨어는 순수하게 기술적인 요구 사항에 따라 개발될 수 있다. 이는 종종 소프트웨어의 품질을 떨어뜨리는 상업적 압박에 대해 생각할 필요가 없음을 의미한다. 상업적 압박은 전통적인 소프트웨어 개발자가 보안 요구 사항보다 고객의 요구 사항에 더 많은 주의를 기울이게 만드는데, 이러한 보안 기능은 고객에게 어느 정도 보이지 않기 때문이다.[29]

개발 도구

[편집]

오픈 소스 소프트웨어 개발에서 도구는 제품 개발과 개발 프로세스 자체를 지원하는 데 사용된다.[21]

중앙 집중식 버전 관리 시스템(CVCS) 및 분산 버전 관리 시스템(DVCS)과 같은 버전 관리 시스템은 협업을 촉진하기 위해 소프트웨어 프로젝트의 소스 코드 파일과 해당 파일에 대한 변경 사항을 관리하는 데 도움이 되는 도구이며, 종종 오픈 소스이다. CVCS는 중앙 저장소를 중심으로 중앙 집중화되어 있는 반면, DVCS는 분산되어 있으며 모든 사용자에 대해 로컬 저장소를 갖는다. Concurrent Versions System(CVS)와 이후의 서브버전(SVN)은 CVCS의 예이며, Git은 DVCS이자 가장 널리 사용되는 버전 관리 소프트웨어이다.[30] 저장소는 깃허브나 깃랩과 같은 소스 코드 호스팅 시설에서 호스팅되고 공개된다.[31]

오픈 소스 프로젝트는 오픈 소스 소프트웨어 개발을 조직하기 위해 이슈 추적기와 같은 유틸리티를 사용한다. 일반적으로 사용되는 버그 추적 시스템으로는 버그질라와 레드마인이 있다.[21]

메일링 리스트 및 IRC와 같은 도구는 개발자 간의 조정 및 버그 토론 수단을 제공한다. 프로젝트 웹 페이지, 위키 페이지, 로드맵 목록 및 뉴스그룹은 최종 사용자에게 초점을 맞춘 프로젝트 정보를 배포할 수 있게 한다.[21]

참여 기회

[편집]

기여하기

[편집]

OSS 참여자의 기본 역할은 프로젝트의 실행을 제어하는 중심부의 리더십부터 시작하여 여러 카테고리로 나뉠 수 있다. 다음은 다른 기여자들을 안내할 수 있는 프로젝트 내 풍부한 경험과 권한을 가진 핵심 기여자들이다. 비핵심 기여자들은 경험과 권한은 적지만 정기적으로 기여하며 프로젝트 개발에 필수적이다. 새로운 기여자는 가장 경험이 적지만 멘토링과 지도를 통해 정기 기여자가 될 수 있다.[32]

오픈 소스 소프트웨어에 기여하는 몇 가지 가능한 방법에는 프로그래밍, 유지보수, 사용자 인터페이스 디자인 및 테스트, 웹 디자인, 버그 분류, 접근성 디자인 및 테스트, UX 디자인, 코드 테스트, 애플리케이션 보안 검토 및 테스트와 같은 역할이 포함된다. 그러나 코딩 기술이 없어도 OSS 프로젝트에 기여할 수 있는 여러 방법이 있다. 예를 들어, 문서 작성 및 편집, 번역, 프로젝트 관리, 행사 조직 및 조정, 마케팅, 배포 관리, 커뮤니티 관리, 홍보 및 대외 협력과 같은 덜 기술적인 참여 방식이 있다.[32]

자금 지원은 개인과 조직이 오픈 소스 프로젝트에 기여하기 위해 선택하는 또 다른 방법이다. Open Collective와 같은 그룹은 개인이 자신이 좋아하는 프로젝트를 지원하기 위해 매달 기부할 수 있는 수단을 제공한다.[33] Sovereign Tech Fund와 같은 조직은 독일 정부가 사용하는 도구를 지원하는 데 수백만 달러를 기여할 수 있다.[34] 미국 국립과학재단은 오픈 소스 혁신을 지원하기 위해 POSE(Pathways to Enable Open-Source Ecosystems) 프로그램을 설립했다.[35]

산업계 참여

[편집]

산업계의 오픈 소스 소프트웨어 채택은 시간이 지남에 따라 증가하고 있다.[36] OSS는 제공되는 이점 덕분에 전기 통신, 항공우주, 의료, 미디어 및 엔터테인먼트와 같은 여러 산업 분야에서 인기가 있다.[37] OSS의 채택은 대규모 조직에서 더 가능성이 높으며 회사의 IT 사용량, 운영 효율성 및 직원의 생산성에 따라 달라진다.[36]

산업계는 백오피스 기능, 판매 지원, 연구 및 개발, 소프트웨어 기능, 빠른 배포, 플랫폼 간의 이식성 및 상업적 라이선스 관리 회피를 위해 OSS를 사용할 가능성이 높다. 또한 컴퓨터 하드웨어 및 소유 비용의 절감도 중요한 이점이다.[36]

주요 조직

[편집]

자유-오픈 소스 소프트웨어 운동의 개발과 확장에 기여하는 조직은 전 세계에 존재한다. 이러한 조직은 기술 교육 및 전파와 같은 목표에 전념하고 있다. 오픈 소스 이니셔티브의 전 부사장이 나열한 바에 따르면, 미국의 일부 조직에는 자유 소프트웨어 재단, 소프트웨어 자유 단체, 오픈 소스 이니셔티브 및 공익을 위한 소프트웨어 재단이 포함된다. 유럽 내에서는 자유 소프트웨어 재단 유럽, 오픈 소스 프로젝트 EU(OSP) 및 OpenForum Europe(OFE)이 주목할 만한 조직이다. 호주의 한 조직은 Linux Australia이며 아시아에는 Open Source Asia와 FOSSAsia가 있다. 아프리카를 위한 자유 오픈 소스 소프트웨어(FOSSFA)와 OpenAfrica는 아프리카 조직이며 중앙 및 남아시아에는 FLISOL 및 페루 자유 소프트웨어 사용자 그룹(GRUP de usuarios de software libre Peru)과 같은 조직이 있다. 이 외에도 오픈 소스 소프트웨어의 발전에 전념하는 더 많은 조직이 존재한다.[32]

법적 및 경제적 이슈

[편집]

라이선스

[편집]

FOSS 제품은 일반적으로 두 가지 유형의 라이선스로 제공된다. 퍼미시브 라이선스와 카피레프트 라이선스이다. 이 두 유형의 라이선스는 더 많은 사용자에게 소프트웨어 접근을 허용하고 각 라이선스에 고유한 규칙이 있는 특정 라이선스 조건에 명시된 대로 2차적저작물 생성을 허용한다는 점에서 사유 라이선스와 다르다. 퍼미시브 라이선스는 소프트웨어 수령자가 배포 시 동일한 라이선스를 사용할 필요 없이 저작자의 저작권을 구현할 수 있도록 허용한다. 이러한 유형의 라이선스 예로는 BSD, MIT 및 아파치 라이선스가 있다. 카피레프트 라이선스는 수령자가 저작물 배포의 최소한 일부에 대해 동일한 라이선스를 사용할 것을 요구한다는 점에서 다르다. 강한 카피레프트 라이선스는 모든 2차적저작물이 동일한 라이선스를 사용할 것을 요구하는 반면, 약한 카피레프트 라이선스는 특정 조건 하에서만 동일한 라이선스 사용을 요구한다. 이러한 유형의 라이선스 예로는 GNU 라이선스 제품군, MPL 및 EPL 라이선스가 있다. 이 두 라이선스 범주의 유사점은 저작권에 대한 광범위한 권한을 부여하고, 수령자가 저작권 고지를 보존할 것을 요구하며, 코드와 함께 라이선스 사본이 수령자에게 제공되어야 한다는 점이다.[38]

오픈 소스 소프트웨어에 대한 중요한 법적 선례 하나는 2008년 Jacobson v Katzer 사건에서 수정 사항의 속성 및 식별을 포함한 아티스틱 라이선스 조건을 집행했을 때 만들어졌다. 이 판결은 라이선스 조건이 준수되지 않았을 때 저작권법에 따른 집행을 공고히 했다. 아티스틱 라이선스가 다른 오픈 소스 소프트웨어 라이선스와 유사하기 때문에, 이 판결은 널리 적용되는 선례를 만들었다.[38]

자유 소프트웨어 사용권 / 오픈 소스 사용권의 예로는 아파치 라이선스, BSD 허가서, GNU 일반 공중 사용 허가서, GNU 약소 일반 공중 사용 허가서, MIT 허가서, 이클립스 공용 허가서 및 모질라 공용 허가서가 있다.[38]

법적 이슈

[편집]

소프트웨어가 제품인지 서비스인지, 무엇이 수정으로 간주될 수 있는지, 계약 대 라이선스를 통한 거버넌스, 소유권 및 사용 권한과 같이 오픈 소스 소프트웨어에 큰 영향을 미치는 소프트웨어 규제 내에는 여러 회색 지대가 존재한다. 이러한 문제에 대한 진전이 있었지만, 종종 더 많은 질문으로 이어지기도 한다. 규제의 이러한 불확실성의 존재는 기술 관련 산업 전체에 부정적인 영향을 미친다.[38]

소프트웨어 전체의 법적 역사 내에서, 이를 특허법, 저작권법 하의 지식 재산권으로 보호할지 아니면 독특한 규제를 수립할지에 대해 많은 논쟁이 있었다. 궁극적으로 저작권법이 표준이 되었으며 컴퓨터 프로그램은 일종의 어문 저작물로 간주되었고, 몇 가지 독특한 규제가 가미되었다.[38]

소프트웨어는 일반적으로 소스 코드와 목적 파일로 간주되며 둘 다 보호 가능하지만, 이 정의에는 법적 다양성이 존재한다. 일부 관할권에서는 자체적인 목적을 위해 이 개념화를 확장하거나 축소하려고 시도한다. 예를 들어 유럽 사법 재판소는 프로그램의 기능, 프로그래밍 언어 또는 데이터 파일의 형식을 포함하지 않는 것으로 컴퓨터 프로그램을 정의한다. 소프트웨어의 다양한 측면에 대한 보호를 제한함으로써 법은 소프트웨어 사용에 대한 오픈 소스적 접근 방식을 선호한다. 특히 미국은 대부분의 오픈 소스 라이선스가 그곳에서 시작된 만큼 소프트웨어에 대해 개방적인 접근 방식을 취하고 있다. 그러나 이는 이러한 라이선스 내에서의 특허권에 대한 집중을 증가시켰고, 지식 재산권 보호의 다른 형태를 선호하는 OSS 커뮤니티로부터 반발을 불러일으켰다.[38]

또 다른 이슈로는 1996년 세계 지식 재산권 기구(WIPO) 조약에서 국제적으로 법적 인정 및 보호를 받은 기술적 보호 조치(TPM)와 디지털 권리 관리(DRM) 기술이 있다. 오픈 소스 소프트웨어 지지자들은 이러한 기술이 저작권법을 넘어서 최종 사용자를 제약할 수 있기 때문에 싫어했다. 유럽은 이러한 불만에 대응하여 TPM을 법적 통제 하에 두었으며, 이는 OSS 지지자들에게 승리를 의미했다.[38]

경제적/비즈니스적 함의

[편집]
오픈 소스 및 공공 데이터 지향 게임 잼인 Free Knowledge Game Jam 2015 참가자들

오픈 소스 커뮤니티에서는 생산된 소프트웨어를 소유하는 대신 생산자가 진화하는 소프트웨어의 개발을 소유한다. 이러한 방식으로 소프트웨어의 미래는 열려 있으며, OSS 내에서 소유권이나 지식 재산권을 설정하기 어렵게 만든다. 라이선싱 및 브랜딩은 다른 사람들이 이를 도용하는 것을 방지하여 공공재로서의 지위를 유지할 수 있다. 오픈 소스 소프트웨어는 모든 사람이 사용할 수 있고 한 사람이 다운로드해도 다른 사람에게 가치가 줄어들지 않으므로 공공재로 간주될 수 있다. 오픈 소스 소프트웨어는 자원을 소모하는 대신 사용되고 기여될수록 더 가치 있게 된다는 점에서 독특하다. 이는 평판에 대한 투자 및 네트워크 효과와 같은 개념으로 설명된다.[39]

오픈 소스 소프트웨어의 경제 모델은 개발자가 프로젝트에 노동을 기여하여 공익을 창출하는 것으로 설명될 수 있다. 개발자는 향상된 평판이나 프로젝트의 가치와 같이 인지된 혜택이나 비용을 바탕으로 프로젝트를 선택한다. 개발자의 동기는 매우 다양한 곳과 이유에서 올 수 있지만, 중요한 점은 돈이 유일하거나 심지어 가장 중요한 인센티브가 아니라는 것이다.[39]

경제 이론은 주로 희소 자원의 소비에 초점을 맞추기 때문에 OSS 역학은 이해하기 어려울 수 있다. OSS에서 생산자는 프로젝트에 기여한 보상을 거둠으로써 소비자가 된다. 예를 들어, 개발자는 OSS 프로젝트에 대한 성공적인 기여로 동료들로부터 높은 평가를 받게 된다. OSS의 사회적 혜택과 상호 작용은 경제 모델에서 설명하기 어렵다. 또한 기술의 혁신은 끊임없이 변화하는 가치 논의와 전망을 만들어내어 경제 모델이 사회적 행동을 예측할 수 없게 만든다.[39]

비록 OSS가 경제 모델에서 이론적으로 도전적이지만, 시간, 돈, 기술 및 기여를 포함하는 자원이 필요한 지속 가능한 사회 활동으로 설명 가능하다. 많은 개발자들이 대학 및 정부와 같은 조직에서 지원하는 기술을 사용해 왔지만, 이들 조직 역시 OSS가 수행한 작업으로부터 혜택을 입는다. OSS가 성장함에 따라 OSS와 사유 시스템을 포함하는 하이브리드 시스템이 더 보편화되고 있다.[39]

2000년대 중반을 지나며 점점 더 많은 기술 기업들이 OSS를 사용하기 시작했다. 예를 들어 델은 리눅스가 이미 설치된 컴퓨터를 판매하기 시작했다. 마이크로소프트 자체도 이전의 OSS 운동에 대한 적대감에도 불구하고 리눅스 기반 운영체제를 출시했다. 이러한 발전에도 불구하고 이들 기업은 특정 목적으로만 OSS를 사용하는 경향이 있어, OSS가 기업들에 의해 이용만 당하고 아무것도 돌려받지 못하고 있다는 우려를 낳고 있다.[27]

정부의 활용

[편집]

많은 정부가 제공되는 다양한 이점 때문에 오픈 소스 소프트웨어를 도입하고 장려하는 데 관심이 있다. 예를 들어 영국 정부는 2004년에 오픈 소스 및 개방형 표준을 장려하는 정책을 발표했으며, 2009년에 이를 재확인했다. "정부는 사유 소프트웨어와 함께 오픈 소스 솔루션을 능동적이고 공정하게 고려할 것이다."[40] 그러나 고려해야 할 이슈는 사이버 보안이다. 우발적인 취약점도 가능하지만, 외부 요원에 의한 공격도 가능하다. 이러한 우려 때문에 소프트웨어 거버넌스에 기여하려는 정부의 관심이 더 두드러지고 있다. 그러나 이는 이슈의 대략적인 흐름일 뿐이며, 각 국가는 오픈 소스 소프트웨어 및 그 구현 목표와 관련하여 저마다의 구체적이고 정치화된 상호 작용을 가지고 있다. 예를 들어 미국은 중국이나 러시아와 같은 국가에서 오픈 소스 소프트웨어 활동이 증가하는 것을 위협으로 인식하여 오픈 소스 소프트웨어 구현과 관련하여 국가안전보장에 초점을 맞추었으며, 국방부는 OSS 사용을 위한 여러 기준을 고려하고 있다. 이러한 기준에는 신뢰할 수 있는 소스로부터 제공되고 유지 관리되는지, 계속 유지 관리될 것인지, 소프트웨어 내 하위 구성 요소에 대한 의존성이 있는지, 구성 요소의 보안 및 무결성, 그리고 외국 정부의 영향력이 포함된다.[41]

정부의 오픈 소스와 관련된 또 다른 이슈는 운영체제, 반도체, 클라우드, 인공지능과 같은 기술에 대한 투자이다. 이러한 기술들은 모두 글로벌 협력에 영향을 미치며, 다시 보안 문제와 정치적 결과를 야기한다. 많은 국가들이 이러한 파트너십에서 기술 혁신과 기술 의존성 사이의 균형을 맞춰야 한다. 예를 들어, 중국의 오픈 소스 의존 기업인 화웨이가 2019년에 구글의 안드로이드 시스템 사용을 차단당한 후, 그들은 자체적인 대안 운영체제인 Harmony OS를 만들기 시작했다.[41]

독일은 최근 그들이 사용하는 소프트웨어의 거버넌스와 유지보수를 지원하기 위해 Sovereign Tech Fund를 설립했다.

오픈 소프트웨어 운동

[편집]

역사

[편집]

컴퓨팅 초기, 특히 1950년대와 1960년대에는 프로그래머와 개발자가 서로 배우고 분야를 발전시키기 위해 소프트웨어를 공유하는 것이 일반적이었다. 유닉스와 같은 초기 시스템은 사용자에게 소스 코드에 대한 접근 권한을 제공하여 협업과 수정을 허용하기도 했다. 그러나 1970년대와 1980년대에 상용 소프트웨어 산업이 부상하면서 사유 모델이 지배적이 됨에 따라 이러한 개방적 공유 문화는 쇠퇴하기 시작했다. 이러한 변화에도 불구하고 학술 및 연구 기관은 협력적인 소프트웨어 개발 관행을 계속 장려했다.[42]

이에 대응하여 오픈 소스 운동은 널리 해커 또는 해커 문화라고 불리는 숙련된 프로그래머 애호가들의 작업을 통해 탄생했다.[43] 이러한 열성 팬 중 한 명인 리처드 스톨먼은 자유 소프트웨어 운동의 원동력이었으며, 이는 나중에 오픈 소스 운동을 가능하게 했다. 1984년에 그는 소스 코드를 공유하고 개선하는 것을 막는 사유 소프트웨어에 의해 자신의 연구소 프로그래머 문화가 억압받자 자유 운영체제인 GNU를 만들기 위해 MIT에서 사임했다. GNU는 유닉스와 호환되었는데, 이는 프로그래머 애호가들이 그 작동 방식에 여전히 익숙할 것임을 의미했다. 그러나 스톨먼이 선택한 자유 소프트웨어라는 명칭에 대해 약간의 혼란이 있다는 것이 곧 분명해졌는데, 그는 이를 가격이 아닌 자유를 의미하는 것으로 설명했다. 그는 나중에 이 자유의 개념을 네 가지 핵심 자유로 확장했다. GNU를 통해 다른 사람의 소스 코드를 통합하고 커뮤니티의 버그 수정 및 새로운 기능에 대한 코드 제안을 받는 오픈 소스 규범이 나타났다. 1985년에 스톨먼은 소프트웨어의 변화를 장려하고 GNU 작성을 돕기 위해 자유 소프트웨어 재단(FSF)을 설립했다. 자신의 작업이 사유 소프트웨어에 사용되는 것을 방지하기 위해 스톨먼은 누구나 자신의 작업을 사용할 수 있지만 특정 조건 하에서만 가능하도록 하는 카피레프트 개념을 만들었다. 이를 위해 그는 1989년에 GNU 일반 공중 사용 허가서(GNU GPL)를 만들었고, 이는 1991년에 업데이트되었다.[20] 1991년, GNU에는 커널이 없었기 때문에 리누스 토르발스가 작성한 리눅스 커널과 결합되었다.[44] 이 운영체제는 현재 보통 리눅스라고 불린다.[20] 이 시기 내내 버클리 소프트웨어 배포판, TeX 및 X 윈도 시스템과 같이 사유 소프트웨어의 도덕성뿐만 아니라 자유 소프트웨어의 개념이 무엇이며 무엇이어야 하는지에 대해 서로 다른 생각을 가진 많은 다른 자유 소프트웨어 프로젝트와 라이선스가 존재했다.[45]

자유 소프트웨어가 발전함에 따라 자유 소프트웨어 재단은 자유 소프트웨어의 아이디어와 인지된 이점을 상용 소프트웨어 산업에 도입할 방법을 찾기 시작했다. FSF의 사회적 활동주의는 기업들에 매력적이지 않으며, 소프트웨어 소스 코드를 공유하고 협업하는 비즈니스 잠재력을 강조하기 위해 자유 소프트웨어 운동을 재브랜딩할 방법이 필요하다는 결론이 내려졌다.[45] 오픈 소스라는 용어는 1998년 자유 소프트웨어 지지자 모임에서 크리스틴 피터슨에 의해 제안되었다. 그룹의 많은 이들이 자유 소프트웨어라는 이름이 초보자에게 혼란을 주고 산업계의 관심을 저해한다고 느꼈으며, 오픈 소스라는 새로운 지칭을 기꺼이 받아들여 오픈 소스 이니셔티브(OSI)를 창설하고 오픈 소스 소프트웨어가 무엇인지에 대한 OSI 정의를 만들었다.[20] 오픈 소스 이니셔티브(OSI)의 정의는 이제 여러 국가 정부에서 표준 또는 데 팍토 정의로 국제적으로 인정받고 있다.[44] 이 정의는 주로 브루스 페렌스가 작성하고 수정한 데비안 자유 소프트웨어 지침을 기반으로 했다.[46] OSI 정의는 사유 소프트웨어의 포함을 허용하고 라이선싱에 더 많은 자유를 허용한다는 점에서 자유 소프트웨어의 정의와 달랐다. 스톨먼과 같은 일부 사람들은 사유 소프트웨어에 대해 강한 도덕적 입장을 취하기 때문에 결과적으로 원래의 자유 소프트웨어 개념에 더 동의하지만, 소프트웨어 운영 측면에서는 두 운동 사이에 많은 겹치는 부분이 있다.[20]

오픈 소스 이니셔티브가 새로운 용어의 사용을 장려하고 그것이 준수하는 원칙을 전파하려고 노력하는 동안, 상용 소프트웨어 벤더들은 자유롭게 배포되는 소프트웨어와 애플리케이션의 소스 코드에 대한 보편적인 접근 개념에 점점 더 위협을 느끼게 되었으며, 2001년에 마이크로소프트의 한 임원은 오픈 소스를 지식 재산권 파괴자라고 불렀다. 그러나 자유-오픈 소스 소프트웨어(FOSS)가 역사적으로 주류 민간 소프트웨어 개발 밖에서 역할을 수행해 온 반면, 마이크로소프트만큼 큰 회사들도 인터넷에서 공식적인 오픈 소스 입지를 구축하기 시작했다. IBM, 오라클, 스테이트 팜은 오늘날의 경쟁적인 오픈 소스 시장에서 중요한 공적 지분을 가진 회사 중 일부일 뿐이며, 이는 FOSS 개발과 관련된 기업 철학의 중대한 변화를 나타낸다.[47]

미래

[편집]

오픈 소스 소프트웨어 커뮤니티, 그리고 연장선상의 자유 소프트웨어 커뮤니티의 미래는 그 가치가 무엇인지에 대해 혼란스럽지는 않더라도 성공적으로 자리 잡았다. 예를 들어, 안드로이드와 우분투는 2000년대 초반에 존재했던 기술 혁신의 변두리에서 오픈 소스 소프트웨어가 부상하여 두각을 나타낸 성공의 이정표이다. 그러나 커뮤니티의 일부 사람들은 구글과 파트너들에 의한 안드로이드의 OSS 중심성 경시, 포킹을 허용하여 안드로이드 내 협업 기회 상실을 초래한 아파치 라이선스 사용, 우분투에서 자유보다 편의를 우선시한 점, 그리고 마케팅 목적으로 사용자를 추적하는 우분투 내 기능 등의 문제로 인해 이들을 OSS의 대표 사례로서 실패작으로 간주하기도 한다.[27]

OSS의 사용은 비즈니스에서 더 일반적이 되었으며, 기업의 78%가 운영의 전부 또는 일부를 FOSS로 실행한다고 보고했다. OSS의 인기는 한때 OSS를 비난했던 마이크로소프트가 시스템에 그 사용을 포함할 정도로 높아졌다. 그러나 이러한 성공은 OSS가 무엇인지, 무엇이어야 하는지, 그리고 보호가 필요하다면 무엇을 해야 하는지 등의 질문에 커뮤니티가 답해야 하는 미래를 결정할 우려를 낳았다. 대체로 자유 오픈 소스 혁명은 시장에서 인지된 평형 상태로 둔화되었지만, 그것이 끝났다는 것을 의미하지는 않으며 미래를 결정하기 위해 많은 이론적 논의가 이루어져야 한다.[27]

다른 소프트웨어 라이선싱/개발 모델과의 비교

[편집]

소스 비공개 / 사유 소프트웨어

[편집]

오픈 소스 소프트웨어는 공개적으로 사용 가능하고 라이선스 비용이 없으며 라이선스 사양에 따라 수정 및 배포가 허용된다는 점에서 사유 소프트웨어와 다르다. 이 모든 것은 사유 소프트웨어의 목표인 OSS 제품에 대한 독점을 방지하기 위해 작동한다. 사유 소프트웨어는 고객의 선택을 해당 소프트웨어 사용을 고수하거나 업그레이드하거나 다른 소프트웨어로 전환하는 것으로 제한하여, 고객이 금전적 비용에 의해 소프트웨어 선호도에 영향을 받도록 강요한다. 사유 소프트웨어 벤더의 이상적인 시나리오는 고객이 이러한 비용 때문에 소프트웨어를 전환하지 않거나 전환할 수 없어 해당 벤더로부터 제품을 계속 구매하는 벤더 록인이다.[48]

사유 소프트웨어 내에서 버그 수정은 벤더에 의해서만 제공될 수 있고, 플랫폼을 옮기려면 다른 구매가 필요하며 제품의 존재는 언제든지 중단할 수 있는 벤더에 달려 있다.[43] 또한 사유 소프트웨어는 소스 코드를 제공하지 않으며 사용자에 의해 변경될 수 없다. 비즈니스의 경우, 제품을 필요에 맞게 전문화할 수 없고 접근하거나 변경할 수 없는 숨겨진 위협이나 정보 유출이 소프트웨어 내에 있을 수 있기 때문에 이는 보안 위험과 좌절의 원인이 될 수 있다.[20]

자유 소프트웨어

[편집]

OSI의 정의에 따르면, 오픈 소스는 소스 코드를 일반 대중에게 공개하고 코드의 사용 및 수정에 대한 제한이 완화되었거나 존재하지 않는 광범위한 소프트웨어 라이선스이다. 소프트웨어의 빠른 진화를 가능하게 하기 위해 모든 조직이나 사용자에 의한 사용 또는 배포에 매우 적은 제한을 두는 것이 오픈 소스의 명시적인 특징이다.[49]

자유 소프트웨어 운동의 리더이자 자유 소프트웨어 재단 회원인 리처드 스톨먼은 그들이 자유 소프트웨어라고 부르는 것에 오픈 소스라는 용어가 적용되는 것에 반대한다. 그는 두 용어가 거의 동일한 범주의 소프트웨어를 설명한다는 점에는 동의하지만, 두 용어를 동일시하는 것은 부정확하고 오해의 소지가 있다고 생각한다.[16] 그는 주된 차이점이 하나의 용어를 다른 용어보다 선택함으로써 다른 사람들에게 자신의 목표가 개발(오픈 소스)인지 아니면 사회적 입장(자유 소프트웨어)인지 알릴 수 있다는 점이라고 믿는다.[50] 그럼에도 불구하고 오픈 소스 소프트웨어와 자유 소프트웨어 사이에는 상당한 중복이 존재한다.[16] 스톨먼은 또한 소프트웨어 자유에 대한 FSF의 이상주의적 표준을 타협함으로써 자유와 공동체라는 자유 소프트웨어의 이상이 위협받을 것을 우려하여 오픈 소스 이니셔티브의 공언된 실용주의에 반대한다.[50] FSF는 자유 소프트웨어를 오픈 소스 소프트웨어의 부분집합으로 간주하며, 리처드 스톨먼은 예를 들어 DRM 소프트웨어가 사용자를 제한함에도 불구하고 오픈 소스로 개발될 수 있으며, 따라서 자유 소프트웨어의 자격은 없다고 설명했다.[16]

FSF는 오픈 소스라는 용어가 소스의 단순한 가용성을 사용, 수정 및 재배포할 수 있는 자유와 혼동하게 만드는 다른 종류의 모호성을 조장한다고 말했다.[16] 반면, 자유 소프트웨어라는 용어는 'free'라는 단어의 모호성 때문에 비즈니스 채택에 저해되는 것으로 간주되었고, 해당 용어의 역사적인 모호한 사용 때문에 비판을 받았다.[50]

개발자들은 결과적으로 자유 소프트웨어이기도 한 오픈 소스 소프트웨어를 설명하기 위해 자유-오픈 소스 소프트웨어(FOSS) 또는 Free/Libre and Open Source Software (FLOSS)라는 대체 용어를 사용해 왔다.[32]

소스 입수 가능 소프트웨어

[편집]

소프트웨어는 읽을 수 있는 코드인 소스 코드와 함께 배포될 수 있다. 이 소스 코드를 볼 수 있을 때 소프트웨어는 소스 입수 가능 소프트웨어이다. 그러나 소스 입수 가능 또는 FOSS가 되기 위해 소스 코드가 모든 사람에게 공개될 필요는 없으며, 해당 소프트웨어의 사용자에게만 공개되면 된다. 모든 FOSS 소프트웨어는 오픈 소스의 정의에 의해 요구되는 사항이기 때문에 소스 입수 가능하지만, 모든 소스 입수 가능 소프트웨어가 FOSS인 것은 아니다. 예를 들어, 소스 코드가 공개되어 있더라도 소프트웨어가 수정이나 재배포 허용과 같은 오픈 소스 정의의 다른 측면을 충족하지 못한다면 해당 소프트웨어는 FOSS가 아니다.[51]

오픈 소스화

[편집]

소프트웨어 기업 내 최근 트렌드는 오픈 소스 라이선스 하에 공개함으로써 이전의 사유 소프트웨어를 오픈 소스 소프트웨어로 전환하는 오픈 소스화(open-sourcing)이다.[52][53] 이를 수행한 기업의 예로는 구글, 마이크로소프트 및 애플이 있다.[52] 또한 오픈 소스화는 오픈 소스 소프트웨어를 프로그래밍하거나 오픈 소스 소프트웨어를 설치하는 것을 의미할 수도 있다.[53] 오픈 소스화는 새로운 관점과 문제 해결 능력을 가진 더 많은 외부 기여자를 끌어들이는 등 여러 면에서 유익할 수 있다. 오픈 소스화의 단점으로는 기본 코드를 쉽게 이해할 수 있게 만들고, 새로운 개발자를 위한 소통 채널을 구축하고, 새로운 개발자가 쉽게 참여할 수 있도록 문서를 만드는 등 새로운 커뮤니티를 유지하기 위해 수행해야 하는 작업이 포함된다. 그러나 여러 오픈 소스화된 프로젝트를 검토한 결과, 새로 오픈 소스화된 프로젝트가 많은 신규 참여자를 끌어들이지만, 상당수는 곧 프로젝트를 떠날 가능성이 높고 그들의 포크 또한 영향력이 없을 가능성이 높은 것으로 나타났다.[52]

기타

[편집]

오픈 소스와 일부 유사성을 공유할 수 있는 다른 개념으로는 셰어웨어, 퍼블릭 도메인 소프트웨어, 프리웨어, 그리고 소스 코드는 제공하지 않지만 자유롭게 사용할 수 있는 소프트웨어 뷰어/리더가 있다. 그러나 이들은 소스 코드에 대한 접근성, 라이선싱, 저작권 및 비용 면에서 오픈 소스 소프트웨어와 다르다.[20]

사회 및 문화

[편집]

인구 통계

[편집]

국제적으로 협업할 수 있음에도 불구하고, 오픈 소스 소프트웨어 기여자들은 주로 실리콘 밸리와 같이 주로 내부에서 협업하는 대규모 클러스터에 위치한 것으로 나타났다. 이 현상의 가능한 원인은 OSS 기여자 인구 통계가 주로 소프트웨어 분야에서 일하며, 이는 OSS 지리적 위치가 해당 분산과 밀접하게 관련되어 있고 직장 및 사회 연결망을 통해 협업이 장려될 수 있기 때문일 수 있다.[54] 코드 채택은 이러한 사회적 네트워크 클러스터 내의 지위에 영향을 받을 수 있으며, 위치에 기반한 코드 채택에서 불공정한 선입견을 만들 수 있다.[55] 국제적 협업의 장벽에는 언어적 또는 문화적 차이도 포함된다.[56] 나아가 각 국가는 인도를 제외하고 자국 기여자의 코드에 대해 더 높은 채택률을 보이는 것으로 나타났으며, 이는 문화적으로 유사한 협력자에 대한 편향을 나타낸다.[56]

2021년에 오픈 소스 소프트웨어 기여도가 가장 높은 국가는 미국, 중국, 독일, 인도, 영국 순이었다.[54] 2021년 연구에 따른 인구 대비 OSS 개발자가 가장 많은 국가는 아이슬란드, 스위스, 노르웨이, 스웨덴, 핀란드 순이었으며, 2008년 SourceForge의 추정 기여자 수가 가장 많은 국가는 미국, 독일, 영국, 캐나다, 프랑스였다.[54][56] OSS 개발자의 분포와 기여에 대한 여러 연구가 수행되었지만, 이는 여전히 여러 가지 방식으로 측정될 수 있는 개방된 분야이다. 예를 들어, 정보 통신 기술 참여, 인구, 부 및 인터넷 접근 비율이 OSS 기여와 상관관계가 있는 것으로 나타났다.[56]

성별 다양성이 팀 생산성을 향상시키는 것으로 밝혀졌음에도 불구하고, 여성은 자신의 성별이 식별 가능할 때 오픈 소스 소프트웨어 프로젝트에 기여하는 동안 여전히 편견에 직면한다.[57] 2002년에 국제 오픈 소스 소프트웨어 개발자 중 여성은 1.5%에 불과했던 반면, 여성은 기술 산업 역할의 28%를 차지하여 소프트웨어 분야에서 낮은 대표성을 보여주었다.[58] OSS 기여에 전제 조건이 없음에도 불구하고, 이러한 성별 편향은 성별이 중요하지 않아야 하며 코드의 품질만이 코드 채택의 유일한 고려 사항이어야 한다는 기여자들의 공통된 믿음 때문에 계속 존재할 수 있으며, 이는 커뮤니티가 여성 대표성의 시스템적 불균형을 다루는 것을 방해한다.[43] 그러나 2005년부터 2021년까지 계산된 전 세계 여성 OSS 참여 수치는 9.8%이며 대부분이 최근 기여자들로, 이는 여성 참여가 증가하고 있음을 시사한다.[59]

동기

[편집]

OSS 커뮤니티에 기여하는 데에는 많은 동기가 있다. 우선, 코딩 및 기타 기술 관련 능력과 같은 여러 기술을 배우고 연습할 기회일 뿐만 아니라 소통과 협업과 같은 기본 기술, 그리고 이슈 추적 시스템이나 버전 관리와 같이 기술 관련 분야에서 탁월하기 위해 필요한 실무 기술을 배울 기회이다. 교실이나 직장을 통해 배우는 대신 OSS에 기여하며 배우는 것은 참여자가 자신의 속도에 맞춰 배우고 관심 있는 분야를 따를 수 있게 해준다. OSS에 기여할 때 기여자는 현재 산업의 모범 사례, 기술 및 트렌드를 배울 수 있으며 테크 분야 내에서 OSS가 점점 인기를 얻음에 따라 차세대 큰 혁신에 기여할 기회도 얻게 된다. 보수 없이 OSS에 기여하는 것은 해고될 위협이 없음을 의미하지만, 평판에는 타격을 입을 수 있다. 반면에 OSS에 기여하는 큰 동기는 자신의 공개 포트폴리오를 키우면서 얻는 평판이다.[32]

불균형

[편집]

프로그래밍이 원래 여성 직업으로 여겨졌음에도 불구하고 컴퓨팅 분야에는 여전히 큰 격차가 남아 있다.[60] 테크 산업의 여성들이 원치 않는 남성의 관심과 괴롭힘을 받거나 기술 지식에 있어 여성스럽지 못하다는 것에 대한 불안감에 직면함에 따라 사회 정체성은 큰 우려 사항이 되는 경향이 있으며, 이는 자신감에 큰 영향을 미친다.[43] 일부 남성 테크 참여자들은 여성이 문화 내에 어울리는 것이 불가능하다고 믿는다는 것을 분명히 하며, 여성과 테크 산업 내 그들의 위치에 대한 불안감을 심화시킨다. 또한 오픈 소스 소프트웨어와 같은 자발적 기여 환경에서도 여성과 남성이 OSS 기여에서 동일한 생산성을 보임에도 불구하고 여성은 수동 테스트나 문서화와 같은 프로젝트의 덜 기술적인 측면을 수행하게 되는 경향이 있다. 명시적인 편향에는 더 긴 피드백 시간, 더 정밀한 코드 조사 및 낮은 코드 채택률이 포함된다.[57] 특히 오픈 소스 소프트웨어 커뮤니티에서 여성들은 성적으로 불쾌한 언어가 흔하며 여성으로서의 정체성이 OSS 기여자로서보다 더 많은 관심을 받는다고 보고한다. 편향은 성별이 중요하지 않아야 한다는 믿음 때문에 다루기 어려우며, 대부분의 기여자들은 여성이 특별 대우를 받는 것이 불공평하고 성공은 기술에 달려 있어야 한다고 느껴 포용성을 높이기 위한 어떠한 변화도 막고 있다.[43]

채택 및 응용

[편집]

주요 프로젝트

[편집]

오픈 소스 소프트웨어 프로젝트는 종종 자원봉사자일 수 있는 프로그래머 네트워크에 의해 구축 및 유지 관리되며, 상용 제품뿐만 아니라 자유 제품에서도 널리 사용된다.[61]

  • 유닉스: 유닉스는 AT&T에 의해 개발된 운영체제로, 개발자들이 유닉스 코드 없이 운영체제를 만들려고 시도하면서 자유 및 오픈 소스 소프트웨어 혁명이 시작되었다는 점에서 오픈 소스 소프트웨어의 전구체 역할을 했다. 유닉스는 소프트웨어의 상업화 이전이자 오픈 소스 소프트웨어의 개념이 필요하기 전인 1960년대에 만들어졌기 때문에 진정한 오픈 소스 소프트웨어 프로젝트로 간주되지 않았다. 이는 1980년대 중반에 상업화되기 전 연구 프로젝트로 시작되었다. 상업화 이전에는 글로벌 사용자의 분산된 협업, 롤링 릴리스 및 사유 소프트웨어에 대한 혐오라는 커뮤니티 문화를 포함하여 오늘날 자유 및 오픈 소스 소프트웨어 혁명이 견지하는 많은 이상을 대표했다.[27]
  • BSD: 버클리 소프트웨어 배포판(BSD)은 기능을 늘리기 위해 유닉스 코드와 버클리 연구소의 코드를 혼합하여 1978년에 시작된 유닉스의 변종 운영체제이다. BSD는 기능 향상에 집중했기 때문에 가장 큰 혁신 사항을 메인 유닉스 운영체제와 공개적으로 공유했다. 이는 오늘날 FOSS의 핵심 특징인 자유로운 공공 코드 공유의 한 예이다. 1980년대에 유닉스가 상업화되면서 사유 소프트웨어를 지지하지 않는 개발자나 커뮤니티 구성원들은 BSD에 집중하여 유닉스 코드를 전혀 포함하지 않는 운영체제로 만들기 시작했다. BSD의 마지막 버전은 1995년에 출시되었다.[27]
  • GNU: GNU는 1984년 리처드 스톨먼에 의해 만들어진 자유 운영체제로, 그 이름은 Gnu's Not Unix(GNU는 유닉스가 아니다)를 의미한다. 아이디어는 누구나 사용할 수 있고 프로그래머들이 서로 코드를 자유롭게 공유할 수 있게 해주는 유닉스 대안 운영체제를 만드는 것이었다. 그러나 GNU의 목표는 유닉스를 대체하는 것뿐만 아니라 더 많은 기술적 능력을 가진 우수한 버전을 만드는 것이었다. 이는 자유 및 오픈 소스 소프트웨어 혁명의 철학적 신념이 진정으로 정의되기 전에 출시되었다. 저명한 FOSS 프로그래머인 리처드 스톨먼에 의해 만들어졌기 때문에 GNU는 FOSS 활동주의와 깊게 연관되었으며, GNU의 가장 큰 성과 중 하나는 개발자들이 법적으로 공유하고 수정할 수 있는 소프트웨어를 출시할 수 있게 해준 GNU 일반 공중 사용 허가서(GPL)의 창안이었다.[27]
  • 리눅스: 리눅스는 1991년 리누스 토르발스에 의해 소개된 운영체제 커널이다. 리눅스는 영리 운영 서비스인 미닉스보다 더 나은 버전을 만드는 데서 영감을 얻었다. 그것이 완전히 무료였고 분산되어 있었다는 점에서 당시 다른 해커들이 생산하던 것과는 근본적으로 달랐다. 나중에 리눅스는 GPL 라이선스 하에 놓여 사람들이 리눅스로 돈을 벌 수 있게 되었고 리눅스를 FOSS 커뮤니티로 가져왔다.[27]
  • 아파치: 아파치는 NCSA HTTPd 코드 베이스에 대한 불만으로 인해 일군의 개발자들이 자신들만의 웹 서버를 출시하며 1995년에 협업으로 시작되었다. 아파치라는 이름은 그들이 이 코드 베이스에 적용한 여러 패치(patch)들 때문에 사용되었다. 출시된 지 1년 만에 전 세계를 선도하는 웹 서버가 되었다. 곧 아파치는 자체 라이선스를 내놓았고, 이는 더 넓은 FOSS 커뮤니티에 불협화음을 일으켰지만 궁극적으로 성공적인 것으로 증명되었다. 아파치 라이선스는 허가된 구성원들이 소스 코드에 직접 접근할 수 있도록 허용했는데, 이는 GNU와 리눅스의 접근 방식과는 눈에 띄는 차이점이었다.[27]

소프트웨어 외 용도로의 확장

[편집]

원래 오픈 소스라는 용어는 소프트웨어의 소스 코드에만 적용되었지만, 현재는 모든 인간이 사용할 수 있도록 기술을 분산시키려는 운동인 오픈 소스 에콜로지(open-source ecology)와 같은 많은 다른 영역에도 적용되고 있다.[16][62] 그러나 이는 일부만 겹치는 다르고 상충되는 원칙을 가진 다른 영역에 잘못 적용되는 경우가 많다.[43]

오픈 소스 소프트웨어의 기반이 되는 동일한 원칙은 오픈 소스, 오픈 콘텐츠 및 개방형 협업과 같은 많은 다른 벤처에서도 찾아볼 수 있다.[63][6]

이 "문화" 또는 이데올로기는 상업 기업에서 전형적으로 사용되는 것과 같은 보다 중앙 집중화된 개발 모델과 대조적으로, 서로 다른 의제, 접근 방식 및 우선순위의 동시 입력을 촉진하기 위해 원칙이 보다 일반적으로 적용된다는 관점을 취한다.[18]

가치

[편집]

90% 이상의 기업이 자사의 사유 소프트웨어의 구성 요소로 오픈 소스 소프트웨어를 사용한다.[64] 오픈 소스 소프트웨어를 사용하거나 기존 오픈 소스 소프트웨어를 개선하기 위해 오픈 소스 프로젝트에 참여하기로 하는 결정은 대개 실용적인 비즈니스 결정이다.[65][66] 사유 소프트웨어가 오픈 소스 대안과 직접 경쟁할 때, 연구 결과는 해당 사유 제품의 가격과 품질에 미치는 경쟁 효과에 대해 상충되는 결과를 발견했다.[67]

수십 년 동안 일부 회사들은 엔터프라이즈 사용자를 위해 오픈 소스 소프트웨어 제품의 서비스를 제공하는 것을 비즈니스 모델로 삼아왔다. 이러한 회사들은 오픈 소스 소프트웨어 제품을 제어하며, 라이선싱이나 사용에 대해 비용을 청구하는 대신 개선, 통합 및 기타 서비스에 대해 비용을 청구한다.[68] 오픈 소스 구성 요소를 기반으로 하는 서비스형 소프트웨어(SaaS) 제품이 점점 더 보편화되고 있다.[69]

오픈 소스 소프트웨어는 투명성을 높이고 과학적 결과의 검증 및 수용을 돕기 때문에 과학적 응용 분야에서 선호된다.[70]

같이 보기

[편집]

각주

[편집]
  1. ↑ St. Laurent, Andrew M. (2008). 《Understanding Open Source and Free Software Licensing》. O'Reilly Media. 4쪽. ISBN 978-0-596-55395-1. 2023년 4월 22일에 원본 문서에서 보존된 문서. 2023년 3월 21일에 확인함.
  2. ↑ Corbly, James Edward (2014년 9월 25일). 《The Free Software Alternative: Freeware, Open Source Software, and Libraries》. 《Information Technology and Libraries》 33. 65쪽. doi:10.6017/ital.v33i3.5105. ISSN 2163-5226. 2021년 5월 1일에 원본 문서에서 보존된 문서. 2021년 4월 28일에 확인함.
  3. ↑ “공개SW 개요”. 2022년 10월 21일에 확인함.
  4. ↑ “TTA정보통신용어사전”. 2022년 10월 21일에 확인함.
  5. ↑ “오픈소스SW 라이선스 종합 정보 시스템”. 2022년 10월 21일에 확인함.
  6. 1 2 Levine, Sheen S.; Prietula, Michael J. (2013년 12월 30일). 《Open Collaboration for Innovation: Principles and Performance》. 《Organization Science》 25. 1414–1433쪽. arXiv:1406.7541. doi:10.1287/orsc.2013.0872. ISSN 1047-7039. S2CID 6583883.
  7. ↑ Hoffmann, Manuel; Nagle, Frank; Zhou, Yanuo (2024). 《The Value of Open Source Software》. 《SSRN Electronic Journal》. doi:10.2139/ssrn.4693148. ISSN 1556-5068.
  8. ↑ “International Authority & Recognition”. Opensource.org. 2015년 4월 21일. 2019년 7월 23일에 원본 문서에서 보존된 문서. 2017년 12월 7일에 확인함.
  9. ↑ Perens, Bruce. Open Sources: Voices from the Open Source Revolution 보관됨 15 9월 2014 - 웨이백 머신. O'Reilly Media. 1999.
  10. ↑ Dibona, Chris; Ockman, Sam (January 1999). 《The Open Source Definition by Bruce Perens》. O'Reilly. ISBN 978-1-56592-582-3.
  11. ↑ “The Open Source Definition”. 2006년 7월 7일. 2013년 10월 15일에 원본 문서에서 보존된 문서. 2008년 8월 24일에 확인함., The Open Source Definition according to the Open Source Initiative
  12. ↑ “How Many Open Source Licenses Do You Need? – Slashdot”. 《News.slashdot.org》. 2009년 2월 16일. 2013년 7월 17일에 원본 문서에서 보존된 문서. 2012년 3월 25일에 확인함.
  13. ↑ Open Source Initiative (2006년 7월 24일). “The Open Source Definition (Annotated)”. 《opensource.org》. 2021년 5월 5일에 원본 문서에서 보존된 문서. 2016년 7월 22일에 확인함.
  14. ↑ Feller, Joseph; Fitzgerald, Brian; Hissam, Scott; Lakhani, Karim R. (2005). 〈Introduction〉. 《Perspectives on Free and Open Source Software》. Cambridge, MA: The MIT Press. xvii쪽. ISBN 0-262-06246-1.
  15. ↑ Tiemann, Michael. “History of the OSI”. Open Source Initiative. 2006년 9월 24일에 원본 문서에서 보존된 문서. 2014년 5월 13일에 확인함.
  16. 1 2 3 4 5 6 7 Stallman, Richard (2007). “Why Open Source Misses the Point of Free Software”.
  17. ↑ Stallman, Richard (2007년 6월 19일). “Why "Free Software" is better than "Open Source"”. 《Philosophy of the GNU Project》. Free Software Foundation. 2021년 3월 27일에 원본 문서에서 보존된 문서. 2007년 7월 23일에 확인함.
  18. 1 2 3 4 Raymond, Eric (2005). 《The Cathedral and the Bazaar (originally published in Volume 3, Number 3, March 1998)》. 《First Monday》. doi:10.5210/fm.v0i0.1472. ISSN 1396-0466.
  19. 1 2 3 4 5 6 7 8 9 10 11 Robles, Gregorio (2006). 〈Empirical Software Engineering Research on Free/Libre/Open Source Software〉. 《2006 22nd IEEE International Conference on Software Maintenance》. 347–350쪽. doi:10.1109/icsm.2006.25. ISBN 0-7695-2354-4. S2CID 6583883.
  20. 1 2 3 4 5 6 7 Napoleao, Bianca M.; Petrillo, Fabio; Halle, Sylvain (2020). 〈Open Source Software Development Process: A Systematic Review〉. 《2020 IEEE 24th International Enterprise Distributed Object Computing Conference (EDOC)》. IEEE. 135–144쪽. arXiv:2008.05015. doi:10.1109/EDOC49727.2020.00025. ISBN 978-1-7281-6473-1.
  21. 1 2 3 4 5 Napoleao, Bianca M.; Petrillo, Fabio; Halle, Sylvain (2020). 〈Open Source Software Development Process: A Systematic Review〉. 《2020 IEEE 24th International Enterprise Distributed Object Computing Conference (EDOC)》. IEEE. 135–144쪽. arXiv:2008.05015. doi:10.1109/EDOC49727.2020.00025. ISBN 978-1-7281-6473-1.
  22. ↑ US Department of Defense. “Open Source Software FAQ”. 《Chief Information Officer》. 2016년 8월 28일에 원본 문서에서 보존된 문서. 2016년 7월 22일에 확인함.
  23. ↑ Sharma, Srinarayan; Vijayan Sugumaran; Balaji Rajagopalan (2002). 《A framework for creating hybrid-open source software communities》 (PDF). 《Information Systems Journal》 12. 7–25쪽. doi:10.1046/j.1365-2575.2002.00116.x. S2CID 5815589. 2008년 10월 30일에 원본 문서 (PDF)에서 보존된 문서. 2008년 9월 8일에 확인함.
  24. 1 2 Reynolds, Carl; Jeremy Wyatt (February 2011). 《Open Source, Open Standards, and Health Care Information Systems》. 《Journal of Medical Internet Research》 13. e24쪽. doi:10.2196/jmir.1521. PMC 3221346. PMID 21447469.
  25. ↑ Landry, John; Rajiv Gupta (September 2000). 《Profiting from Open Source》. 《하버드 비즈니스 리뷰》. doi:10.1225/F00503 (년 이후로 접속 불가 2025-07-12).
  26. ↑ Nagle, Frank (2019년 3월 3일). 《Government Technology Policy, Social Value, and National Competitiveness》 (PDF) (영어). 《Information Systems Journal》 12. doi:10.2139/ssrn.3355486. S2CID 85509685. SSRN 3355486.
  27. 1 2 3 4 5 6 7 8 9 Tozzi, Christopher (2017). 《For Fun and Profit: A History of the Free and Open Source Software Revolution》. United States: MIT Press. ISBN 978-0-262-34118-9.
  28. ↑ Plotkin, Hal (December 1998). 《What (and Why) you should know about open-source software》. 《Harvard Management Update》. 8–9쪽.
  29. ↑ Payne, Christian (February 2002). 《On the Security of Open Source Software》. 《Information Systems Journal》 12. 61–78쪽. doi:10.1046/j.1365-2575.2002.00118.x. S2CID 8123076.
  30. ↑ Shirey, Russell G. (2015년 3월 1일). “Git as an Encrypted Distributed Version Control System” (PDF). 《Defense Technical Information Center》. 38쪽. 2025년 9월 5일에 확인함.
  31. ↑ Zolkifli, Nazatul Nurlisa; Ngah, Amir; Deraman, Aziz (2018). 《Version Control System: A Review》 (영어). 《Procedia Computer Science》 135. 408–415쪽. doi:10.1016/j.procs.2018.08.191.
  32. 1 2 3 4 5 Brasseur, V. M. (2018). 《Forge your future with open source: build your skills, build your network, build the future of technology》. The pragmatic programmers. Raleigh, North Carolina: The Pragmatic Bookshelf. ISBN 978-1-68050-301-2.
  33. ↑ “Open Source” (영어). 《Open Collective》. 2022년 10월 20일. 2024년 5월 28일에 확인함.
  34. ↑ “Technologies” (영어). 《Sovereign Tech Fund》. 2024년 5월 28일에 확인함.
  35. ↑ “NSF invests over $26 million in open-source projects | NSF - National Science Foundation” (영어). 《new.nsf.gov》. 2023년 10월 25일. 2024년 5월 28일에 확인함.
  36. 1 2 3 Spinellis, Diomidis; Giannikas, Vaggelis (2012). 《Organizational adoption of open source software》 (영어). 《Journal of Systems and Software》 85. 666–682쪽. doi:10.1016/j.jss.2011.09.037.
  37. ↑ Zhang, Yiming; Malhotra, Baljeet; Chen, Cheng (2018). 〈Industry-Wide Analysis of Open Source Security〉. 《2018 16th Annual Conference on Privacy, Security and Trust (PST)》. IEEE. 1–10쪽. doi:10.1109/PST.2018.8514185. ISBN 978-1-5386-7493-2. S2CID 53234981.
  38. 1 2 3 4 5 6 7 Brock, Amanda (2023). 《Open Source Law, Policy and Practice》 2판. UK: Oxford University Press. ISBN 978-0-19-886234-5.
  39. 1 2 3 4 Wynants, M., & Cornelis, J. (Eds.). (2005). How open is the future? : Economic, social and cultural scenarios inspired by free and open-source software. ASP.
  40. ↑ Cabinet Office, All about Open Source: An Introduction to Open Source Software for Government IT, Version 2.0, page 8, published in April 2012, accessed on 1 October 2025
  41. 1 2 Pannier, Alice (2022). 《Software Power: The Economic and Geopolitical Implications of Open Source Software》. Études de l'Ifri. ISBN 979-10-373-0641-8.
  42. ↑ Maracke, Catharina (2019). 《Free and Open Source Software and FRAND-based patent licenses: How to mediate between Standard Essential Patent and Free and Open Source Software》 (영어). 《The Journal of World Intellectual Property》 22. 78–102쪽. doi:10.1111/jwip.12114. ISSN 1422-2213.
  43. 1 2 3 4 5 6 Bretthauer, David (2001). 《Open Source Software: A History》. 《Information Technology and Libraries》 21.
  44. 1 2 “International Authority & Recognition” (미국 영어). 《Open Source Initiative》. 2015년 4월 21일. 2023년 12월 18일에 확인함.
  45. 1 2 Fogel, Karl (2006). 《Producing open source software: how to run a successful free software project》 1. Aufl., [Nachdr.]판. Beijing Köln: O'Reilly. ISBN 978-0-596-00759-1.
  46. ↑ Kelty, Christopher (2008). 《Two Bits: The Cultural Significance of Free Software》. Duke University Press. ISBN 978-0-8223-8900-2.
  47. ↑ Miller, Keith W.; Voas, Jeffrey; Costello, Tom (2010). 《Free and Open Source Software》. 《IT Professional》 12. 14–16쪽. Bibcode:2010ITPro..12f..14M. doi:10.1109/mitp.2010.147. ISSN 1520-9202. S2CID 265508713.
  48. ↑ Zhu, Kevin Xiaoguo; Zhou, Zach Zhizhong (2012). 《Research Note —Lock-In Strategy in Software Competition: Open-Source Software vs. Proprietary Software》 (영어). 《Information Systems Research》 23. 536–545쪽. doi:10.1287/isre.1110.0358. ISSN 1047-7047.
  49. ↑ “The Open Source Definition (Annotated)” (미국 영어). 《Open Source Initiative》. 2006년 7월 24일. 2023년 12월 18일에 확인함.
  50. 1 2 3 Stallman, Richard M.; Gay, Joshua (2002). 《Free software, free society》. Boston (Mass.): Free software foundation. ISBN 978-1-882114-98-6.
  51. ↑ Fortunato, Laura; Galassi, Mark (2021년 5월 17일). 《The case for free and open source software in research and scholarship》 (영어). 《Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences》 379. Bibcode:2021RSPTA.37900079F. doi:10.1098/rsta.2020.0079. ISSN 1364-503X. OSTI 1836982. PMID 33775148. S2CID 232387092.
  52. 1 2 3 Pinto, Gustavo; Steinmacher, Igor; Dias, Luiz Felipe; Gerosa, Marco (2018). 《On the challenges of open-sourcing proprietary software projects》 (영어). 《Empirical Software Engineering》 23. 3221–3247쪽. doi:10.1007/s10664-018-9609-6. ISSN 1382-3256. S2CID 254467440.
  53. 1 2 Ågerfalk; Fitzgerald (2008). 《Outsourcing to an Unknown Workforce: Exploring Opensurcing as a Global Sourcing Strategy》. 《MIS Quarterly》 32. 385쪽. doi:10.2307/25148845. ISSN 0276-7783. JSTOR 25148845.
  54. 1 2 3 Wachs, Johannes; Nitecki, Mariusz; Schueller, William; Polleres, Axel (March 2002). 《The Geography of Open Source Software: Evidence from GitHub》 (영어). 《Technological Forecasting and Social Change》 176. arXiv:2107.03200. doi:10.1016/j.techfore.2022.121478.
  55. ↑ Rastogi, Ayushi; Nagappan, Nachiappan; Gousios, Georgios; van der Hoek, André (2018년 10월 11일). 〈Relationship between geographical location and evaluation of developer contributions in github〉 (영어). 《Proceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement》. ACM. 1–8쪽. doi:10.1145/3239235.3240504. ISBN 978-1-4503-5823-1. S2CID 215822439.
  56. 1 2 3 4 Gonzalez-Barahona, Jesus M.; Robles, Gregorio; Andradas-Izquierdo, Roberto; Ghosh, Rishab Aiyer (August 2008). 《Geographic origin of libre software developers》 (영어). 《Information Economics and Policy》 20. 356–363쪽. doi:10.1016/j.infoecopol.2008.07.001.
  57. 1 2 Bosu, Amiangshu; Sultana, Kazi Zakia (2019). 〈Diversity and Inclusion in Open Source Software (OSS) Projects: Where do We Stand?〉. 《2019 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)》. IEEE. 1–11쪽. doi:10.1109/ESEM.2019.8870179. ISBN 978-1-7281-2968-6. S2CID 197640269.
  58. ↑ Nafus, Dawn (June 2012). 《'Patches don't have gender': What is not open in open source software》 (영어). 《New Media & Society》 14. 669–683쪽. doi:10.1177/1461444811422887. ISSN 1461-4448. S2CID 206727320.
  59. ↑ Trinkenreich, Bianca; Wiese, Igor; Sarma, Anita; Gerosa, Marco; Steinmacher, Igor (2022년 10월 31일). 《Women's Participation in Open Source Software: A Survey of the Literature》 (영어). 《ACM Transactions on Software Engineering and Methodology》 31. 1–37쪽. arXiv:2105.08777. doi:10.1145/3510460. ISSN 1049-331X. S2CID 234778104.
  60. ↑ Albusays, Khaled; Bjorn, Pernille; Dabbish, Laura; Ford, Denae; Murphy-Hill, Emerson; Serebrenik, Alexander; Storey, Margaret-Anne (April 2021). 《The Diversity Crisis in Software Development》. 《IEEE Software》 38. 19–25쪽. Bibcode:2021ISoft..38b..19A. doi:10.1109/MS.2020.3045817. ISSN 0740-7459.
  61. ↑ Popp, Karl Michael 편집 (2020). 《Best practices for commercial use of open source software: business models, processes and tools for managing open source software》. Synomic Academy. Norderstedt: BoD – Books on Demand. ISBN 978-3-7386-1909-6.
  62. ↑ Powers, Stephanie M.; Hampton, Stephanie E. (2019). 《Open science, reproducibility, and transparency in ecology》 (영어). 《Ecological Applications》 29. e01822쪽. Bibcode:2019EcoAp..29E1822P. doi:10.1002/eap.1822. ISSN 1051-0761. PMID 30362295.
  63. ↑ Cheliotis, Giorgos (2009). 《From open source to open content: Organization, licensing and decision processes in open cultural production》. 《Decision Support Systems》 47. 229–244쪽. doi:10.1016/j.dss.2009.02.006. ISSN 0167-9236.
  64. ↑ Butler et al. 2022, 1쪽.
  65. ↑ Butler et al. 2022, 11152쪽.
  66. ↑ Davila 2015, 7쪽.
  67. ↑ Zhou & Choudhary 2022, 731쪽.
  68. ↑ August et al. 2021, 1–2쪽.
  69. ↑ August et al. 2021, 1쪽.
  70. ↑ Morin et al. 2012, Compatibility, Proliferation, Fragmentation, and Directionality.

외부 링크

[편집]
원본 주소 "https://ko.wikipedia.org/w/index.php?title=오픈_소스_소프트웨어&oldid=41481824"