오픈 소스의 미래

• 우리 COO이자 공동창업자인 Anne이 독일 식품회사 Delinero의 CEO였을때 소송을 당했음. 공급업체가 제공한 라즈베리 잼을 "Himbeermarmelade"라고 표기했는데, 독일에서는 마멀레이드가 최소 20%의 감귤류를 포함해야만 "마멀레이드"라고 표기할 수 있는 'Konfitürenverordnung(잼 규정)'이 있었기 때문
• 이는 일반적으로 사용되는 단어의 의미와는 상반되는 규정이었지만, 소수의 이해관계자들이 오래 전에 만든 법이기에 따라야만 했음
• 현재의 "오픈 소스"도 이와 유사한 상태라고 볼 수 있음. OSI가 Konfitürenverordnung처럼 일반적인 용법과는 달리 진화한 용어를 여전히 엄격하게 규제하고 있음
• 하지만 어떻게 하면 건설적인 방향으로 나아갈 수 있을까?

"오픈 소스"를 하지 않는 방법

• GitButler가 클라이언트 코드를 "Fair Sourcing"하여 OSI 승인되지 않은 라이선스로 공개했을 때, 어떻게 발표할지 고민했음
• 대부분의 사람들은 "오픈 소스"를 "GitHub에 공개된 것"과 동일시하고, 또한 GPL/카피레프트 라이선스의 다소 위험한 의미로 인해 사람들은 어떤 라이선스가 적용되는지 확인하는 데 매우 익숙함
• 그렇다고 "Source Avaialable'd" 같은 모호한 말은 쓰고 싶지 않았고, 혼동을 피하기 위해 "오픈"이라는 말을 사용했지만, 공격을 받았음
• 소수의 목소리 큰 사람들이 이 용어를 보호하고 구체화하려 한다는 것을 깨달음
• "오픈 소스"는 "클로즈드 소스"의 논리적 부정이 아님. GitHub에 공개되고 참여하는 것과 OSI가 자체 규제하는 "오픈 소스"의 기술적 10가지 정의 사이에는 대중적 이해의 격차가 존재함

오픈 소스의 간략한 역사

• 1950-60년대 초기 컴퓨팅 시대에는 소프트웨어가 하드웨어에 묶여 있어 별도로 구분할 필요가 없었고, 하드웨어 회사들이 자유롭게 배포했음
• 1970-80년대 하드웨어가 상품화되면서 소프트웨어만의 가치가 생겼고, IBM, AT&T 등 대기업들이 비용을 들여 만든 소스 코드의 접근을 제한하기 시작함
• 이에 Richard Stallman 등이 기업의 이해관계로부터 보호되는 자체 OS와 도구들을 만들기 시작했고, GPL 등 상호주의적 라이선스로 IBM, AT&T가 그들의 것을 사용하면 모두 자유 소프트웨어로 만들도록 강제했음

  "우리가 당신의 장난감으로 놀 수 없으면, 당신도 우리 장난감으로 놀 수 없습니다."

  • 그들은 이 운동을 "자유 소프트웨어"라고 명명하고 Emacs와 GNU 컴파일러 시스템과 같은 많은 놀라운 도구를 만들었음. 이는 오늘날에도 대부분의 현대 컴퓨팅의 기본 도구임
  • 자유 소프트웨어 운동의 근본적인 초점은 사용자가 소프트웨어를 실행, 복사, 배포, 연구, 변경 및 개선 할 수 있는 자유를 보장하는 것이었음. 그 당시 그들을 둘러싼 기업 이익에 의해 그들에게서 빼앗긴 자유
• 1990년대 초 Linus Torvalds의 리눅스 커널로 완전한 OS를 갖추게 되었고, LAMP 스택 등 자유 소프트웨어 생태계가 성장하며 기업들도 사용하고 의존하게 됨
• 1997년 Eric Raymond가 자유 소프트웨어 개발 모델이 폐쇄형보다 우월하다는 에세이 "성당과 시장"을 발표했고, 이는 Netscape가 Navigator Suite의 소스 코드를 공개하는 것을 정당화하는 데 인용 됨
  • 넷스케이프가 소스 코드를 공개하기로 결정했을 때, 팔로알토에서 열린 전략 세션에서 레이몬드와 몇몇 저명한 Linux 및 자유 소프트웨어 개발자들은 "오픈 소스"라는 새로운 용어를 만들어 사용하기로 합의

  "회의 참석자들은 넷스케이프가 코드를 공개하도록 동기를 부여한 실용적이고 비즈니스적인 근거가 잠재적인 소프트웨어 사용자 및 개발자와 소통하고 커뮤니티에 참여하여 소스 코드를 만들고 개선하도록 설득할 수 있는 가치 있는 방법이라고 믿었습니다. 회의 참석자들은 또한 이러한 접근 방식을 식별하고 철학적, 정치적으로 초점을 맞춘 “자유 소프트웨어”라는 라벨과 구별할 수 있는 단일 라벨이 있으면 유용할 것이라고 믿었습니다."

• 중요한 것은 "자유 소프트웨어"와 "오픈 소스" 사이에는 실질적인 법적 또는 실용적인 차이가 없다는 것
  • 대부분의 라이선스는 두 정의 모두에서 호환되고 인정됨
  • "오픈 소스"는 넷스케이프와 같은 더 많은 회사가 전문 소스 코드의 개방을 수용하도록 하기 위한 스톨만과 그의 운동의 정치적인 목표와 소프트웨어 개방의 실용성을 분리하기 위해 비즈니스 친화적으로 브랜드를 변경한 것일 뿐
• 또는 자유 소프트웨어쪽 사람들이 얘기했듯이

  "오픈소스는 개발 방법론이고 자유 소프트웨어는 사회 운동입니다."

오픈 소스와 GitHub 시대

• "오픈 소스"라는 문구의 정의와 마케팅은 1998년, 지금으로부터 25년 이상 전이었음. 그렇다면 컴퓨팅의 지난 25년 동안 오픈 소스와 소프트웨어 개발 분야에서 무슨 일이 일어났을까?
• 특히 지난 10년간 GitHub와 GitHub 스타일의 소프트웨어 개발이 오픈 소스에 엄청난 영향을 미쳤음
• 1998년에는 기업들에게 오픈 소프트웨어를 받아들이도록 설득하려 했지만, 현재는 거의 모든 오픈 소스 소프트웨어를 기업이 작성하거나 후원함
• 가장 큰 변화 중 하나는 "개발 워크플로우의 표준화", 특히 GitHub에 의해 주도됨
• 이전에는 오픈 소프트웨어 프로젝트와 기업의 프로젝트 사이에 큰 차이가 있었지만 이제는 거의 차이가 없음
  • 모두가 Git을 사용
  • 거의 모든 사람이 풀 리퀘스트(또는 병합 요청, 또는 이 기능을 복제한 다른 ​​방법)를 사용
  • 대부분의 팀은 GitHub Flow ( Trunk 기반 개발 , Gitlab Flow 등) 의 어떤 형태를 사용
• 이제 저장소의 공개 여부만이 유일한 차이점임. 25년 전에는 프로세스에 많은 마찰이 있었지만 이제는 오픈 소스화하는 데 거의 프로세스 변화가 필요하지 않음

오픈 소스의 다음 단계는 무엇인가

• 거의 모든 기업이 오픈 소스 소프트웨어를 사용하고 생산하게 되면서 오픈 소스 (자유 소프트웨어) 운동이 성공한 것일까?
• 오픈 소스 세계에는 현재 두 가지 큰 문제가 있음. "개발자 지속 가능성"과 "상용 오픈 소스가 Viable한가"

개발자 지속 가능성 문제

• 오픈 소스에 크게 의존하게 되면서 지속 가능성과 유지 보수 문제가 발생하고 있음. XZ Utils 백도어 악용 사건이 최근 유명한 사례
• 거의 모든 유지 관리자가 소진과 괴롭힘으로 어려움을 겪고 있음. 오픈 소스 소프트웨어를 작성하고 유지 관리하면서 돈을 버는 것은 거의 불가능함
• 대부분의 오픈 소스 개발자와 유지 관리자는 이제 대기업의 후원을 받고 있음
  • Linux, Git, Ruby, React 등을 살펴보면 중요한 오픈 소스 프로젝트의 대부분 기여자는 GitHub, Microsoft, Red Hat 등 기업 후원자가 전문적으로 고용함.
• 개발자가 XZ Utils와 같은 프로젝트를 유지 관리하면서 제대로 된 생계를 꾸리기는 어려움
  • 한 회사가 개발자에게 지불하는 대신, 수천 개의 회사가 전문 유지 관리자에게 작은 금액을 지불하는 것이 이상적일 것
• 주요 문제는 현재 이를 할 수 있는 좋은 방법이 없다는 것
  • GitHub Sponsors, Thanks.dev, Liberapay, Tidelift 등 유망한 이니셔티브가 있지만, 기업이 기부할 수 있는 적절한 인센티브 문제는 아직 해결하지 못함
• Sentry는 OSS Pledge 라는 새로운 이니셔티브를 추진해 왔으며 , GitButler는 10월에 출시되면 참여할 계획
• 하지만 이와 같은 방식이 오픈 소스 생태계에서 개발자의 지속 가능성이라는 크고 점차 커지는 문제를 해결할 수 있을지는 아직 알 수 없음

상용 오픈 소스의 문제

• 개발자들은 오랫동안 오픈 소스와 오픈 커뮤니티를 사랑하며 자랐고, 회사와 프로젝트를 시작할 때 기본적으로 오픈하길 원함
  • 그러나 개별 유지 관리자와 마찬가지로 오픈 소스에도 기업의 지속 가능성 문제가 있음
• Elasticsearch와 Redis의 사례에서 볼 수 있듯이, 전문적으로 소프트웨어를 개발하는 데 시간과 돈을 투자할 때 Amazon 등 대기업이 자신들의 작업물을 이용해 직접 경쟁하는 위험이 있음
• 많은 전문 제작자들은 소프트웨어에 투자하고 나중에 그것이 자신들에게 불리하게 사용되지 않도록 하고 싶어함
  • 이는 라이선싱에 창의적이 되거나 소스 코드를 폐쇄하는 것을 의미함
• 나는 Fair Source 운동이 이 증가하는 문제에 대한 훌륭하고 필요한 해결책이라고 믿으며, 지난 몇 년 동안 점점 더 많은 문제와 혼란을 야기한 오픈 소스 생태계의 격차를 메꾼다고 생각
  • 이는 대부분 허용되고, 소스를 사용할 수 있으며, GitHub 커뮤니티가 참여하는 전문 프로젝트를 가리키는 새로운 용어로, 이전에 비공개로 진행되던 프로젝트가 더 많이 공개되도록 장려하기 위해 절실히 필요한 솔루션이라고 생각

협업의 미래

• 오픈 소스의 미래는 그저 "Open Source" 그리고 OSI의 10가지 Konfitürenverordnung만이 아님
• 모두에게 가능하고 가치있는 Open Source, 안전한 투자를 위해 필요한 Fair Source, 중요한 기초 오픈 라이브러리와 프로젝트에 대한 대규모 공동 펀딩의 조합임
• 중요한 오픈 소스 라이브러리 유지 관리를 지속 가능하게 만들어야 하고, 지속 가능한 상용 소스 사용 가능 라이선스 클래스를 수용하고 정상화해야 함
• 가능한 한 모든 것을 허용하는 OSI 라이선스로 오픈 소스화해야 하며, 무엇보다 폐쇄형 소스를 과거의 일로 만들어야 함
• 지금 당신이 할 수 있는 일은
  • 폐쇄형 소프트웨어를 Fair Source로 만들고
  • 오픈 소스에 의존한다면 OSS Pledge에 동참하는 것