오픈 소스 소프트웨어 출시가 너무 빠름 [폐쇄]

오픈 소스 소프트웨어를 너무 빨리 출시하는 도덕적 책임은 무엇입니까? 예를 들어, 완전히 테스트되지 않은 완제품에 가깝습니다.

프로그래머의 기대는 무엇입니까? 완전히 테스트 될 때까지 기다리거나 오픈 소스로 릴리즈 한 다음 추가 개발, 테스트 및 발전을 계속 하시겠습니까?

문제는 소프트웨어가 오픈 소스이며 소비자에게 문제를 일으킬 수 있다는 것입니다.

이것이 근거없는 두려움입니까?

반대로 오픈 소스 소프트웨어를 최대한 빨리 릴리스해야한다고 생각합니다. 그것에 대해 "너무 빨리"는 없습니다 (그러나 컴파일해야합니다).

^{또는 최소한 공식적으로 릴리스 하지 않고 소스 코드를 매우 빠르고 지속적으로 게시하십시오 (예 : github 을 자주 푸시 ) .}

그러나 알파 또는 베타 단계로 플래그를 지정하고 가능한 경우 (예 : README또는 TODO파일 및 일부 블로그 등) 누락되거나 테스트되지 않았거나 모양이 나쁜 것을 말할 수 있습니다 . 또한 그러한 정보를 전달 하기 위해 버전 번호 를 사용해야합니다 .

무료 소프트웨어를 사용하면 누군가가 소스 코드를 들여다보고 작은 패치를 제안하는 것이 가장 좋습니다. 이것이 소프트웨어를 무료로 만드는 이유입니다!

^{그러므로, 당신은 당신의 무료 소프트웨어에 대한 일상적인 작업을 보여 주어야합니다! 패치가 최신 소프트웨어 소스 코드와 함께 작동하지 않거나 복제 본인 경우 외부 기고자들이 화나게됩니다.}

당신이 두려워해야 할 것은 아무도 당신의 소프트웨어에 관심을 가지지 않고 그것에 기여하지 않는다는 것입니다. 자유 소프트웨어에 대한 외부 관심을 끄는 것 (특히 외부 기고자를 유치하는 것)은 긴 여정입니다.

TL; DR :

조기 출시. 종종 출시.

개인 일화 :

작업중인 프로젝트에 정말 흥분했습니다. 정말 신나게. 나는 흥분된 밤에 잠을 잘 수 없었다. 그래서 나는 공동 개발자가 원하는 것보다 빨리 v1.0을 발표하도록 추진했습니다.

끔찍했다. 예상대로 작동하지 않았습니다. 모든 차례에 버그가 있었지만 우리는 버그를 기록하고 수정했습니다. 우리는 심지어 얼리 어답터가 발견하지 못한 버그를 제출하도록했습니다. 1-2 주 후에 많은 문제를 해결 한 새로운 릴리스를 출시 한 후 새로운 기능을 구축했습니다.

일찍 릴리스하는 것이 우리가 할 수있는 가장 좋은 일이었습니다. 실제 사용자 앞에 제품을 배치했습니다. 이 노출 된 버그를 수행하면 프로젝트를 발견하거나 개선 할 수 있습니다. 또한 얼리 어답터들에게 우리가이 프로젝트에 대해 진지하다는 것을 알 렸습니다. 더 많은 릴리스와 활발한 개발이있을 것입니다.

그래도 다른 방법으로는 쉽게 사라질 수 있습니다. 우리는 그 버그 보고서를 무시했을 수 있습니다. 또는 우리는 빨리 반응하지 못했습니다. 몇 주가 아닌 v1.1을 출시하는 데 3 개월이 걸렸다면 다른 이야기 였을 것입니다.

폐쇄 소스 소프트웨어와 동일합니다. 의사 소통이 중요합니다.

사용자에게 소프트웨어 상태와 다운로드 가능한 이유를 알려줍니다.

소프트웨어는 전체 테스트 여부에 관계없이 항상 고객 문제를 유발합니다. 대부분의 고객은이 사실을 받아들이고 일부 고객은 절대 받아들이지 않습니다. 그러나 소프트웨어가 합리적으로 예상 할 수있는 것보다 더 많은 문제를 야기 할 경우 고객에게 위험을 알리는 도덕적 의무가 있습니다. 정보는 간단한 형식 ( "Alpha / Beta / EarlyAccess"레이블) *이어야하며 세부 정보 : 알려진 문제, 해결 방법 및 특별 고려 사항 (예 : 데이터가 손상 될 수있는 경우)의 목록입니다.

* 일부 대형 소프트웨어 회사는 사용자가 "베타"를 소프트웨어가 탄탄한 상태로 생각하도록 교육을 받았으므로 소프트웨어가 "베타"라고 알려주는 것만으로는 충분하지 않습니다.

도덕적 책임은 없습니다. 아무도 당신의 반 구운 소프트웨어를 사용하도록 강요 당하지 않습니다.

걱정해야 할 유일한 것은 당신의 신뢰성입니다.

내 경험은 달성해야 할 균형이 있다는 것입니다.

지금은 내가 작성한 코드를 사용하는 매우 흥미로운 FOSS 프로젝트로 보이는 것을 제작하는 개발자와 함께 (질문을 보지 않고 개발 제안을 제공한다는 의미에서) 작업하고 있습니다. 공개 릴리스는 설계 변경을 실현하여 프로젝트를 장기적으로 개선하는 데 반복적으로 지연되었지만 이미 작성되었으며 이미 "작동 중"인 코드를 상당 부분 다시 작성해야합니다. 내 견해로는, 보여줄만한 일이 생기 자마자 작동하지만 불완전한 릴리스가 이루어졌으며, 변화에 대한 아이디어 (및 실제 패치)는이 프로젝트에 관심이있는보다 광범위한 커뮤니티에서 나왔을 수 있기 때문에 오히려 가속화되었습니다. 문제는 한 번에 하나씩 천천히 개발자가 자신을 생각하고 자신과 커뮤니티의 다른 관심있는 멤버의 디자인 피드백을 요구할 때. 그래서이 관점에서 저는 "일찍 릴리스, 자주 릴리스"에 대한 옹호자입니다.

반면에 저품질 릴리스는 새로운 프로젝트가 시작되기 전에 나빠 보이게 만들 수 있습니다. 내가 본 몇 가지 함정은 다음과 같습니다.

• 인터페이스 정의는 있지만 코드는없는 골격 트리.
• 개발자 이외의 사람을 위해 성공적으로 컴파일되지 않는 코드.
• 프로그램을 빌드 / 실행하는 방법에 대한 지침이 없습니다.
• 작동 할 것으로 예상되는 측면에 대한 문서가 없습니다.
• 프로그램의 기능에 대한 명확한 설명.
• 유용성에 대한 설명이 부족합니다.

마지막으로, 나는 다음과 같은 것을 생각하고 있습니다.

• hello-world 타입 프로그램을 컴파일 / 실행할 수없는 컴파일러 / 통역사.
• 최소한 어떤 종류의 샘플 프로그램을 실행할 수 없거나 무언가를하고 있다는 것을 증명할 수없는 에뮬레이터.
• 수정되지 않은 이미지를로드하고 다시 저장하는 것 외에는 아무것도 할 수없는 이미지 처리 도구입니다.
• 타이틀 화면 만있는 게임.

이러한 종류의 문제는 작업 코드가 부족하다는 것에 대해 매우 개방적이지 않으면 흔들리지 않는 "증기 류"이미지에 적합합니다.

마지막으로, 버전 번호를 이해하십시오. 사용자가 충돌하지 않고 기대하는 것을 수행 할 때까지 프로젝트를 "1.0"이라고 부르지 마십시오. 나는 초기 공개 릴리스를 위해 "0.5"주위의 버전 번호를 사용하고 거기에서 나가는 것에 대해 항상 운이 좋았지 만 "0.1"또는 "0.10"과 같은 것들도 의미가 있습니다.

자유 소프트웨어를 공개하면 부정적인 결과를 초래할 수 있습니다. 일부 사양은 일반인에게 배포 된 모든 구현이 처음 게시 될 때 사양을 완전히 준수해야한다는 조건하에 일반인에게 라이센스가 부여됩니다. 게시자는 사양에 따라 진행중인 구현을 배포하는 것을 법적으로 금지합니다. 사양 게시자의 특정 협상 라이센스가 없으면 모든 테스트를 통과 할 때까지 다른 사람과 라이센스를 공유해야합니다. 이것은 스펙의 구현에 대해 "성당 모델"(Eric S. Raymond라고 함)을 강제합니다.

이러한 라이센스에 따른 한 가지 사양은 Java 언어 사양 입니다. 이 제한은 JVM과 호환되는 가상 머신 개발자에게는 적용되지만 다행히 JVM에서 실행되는 애플리케이션 개발자에게는 적용되지 않습니다.

Liu Qihao & Ciaran O'Riordan 의 기사 " Microsoft의 '오픈 소스'.NET에 대한 4 가지 교묘 한 세부 사항 " 에서는 CLR의 불완전한 구현을 유사한 방식으로 제외하기 위해 .NET 라이브러리 및 런타임 구성 요소 에 대한 Microsoft 특허 약속을 해석 할 수 있다고 언급했습니다. . 그러나 다시 CLR에서 실행되는 응용 프로그램에는 적용되지 않습니다.