오픈소스 프로젝트의 성공을 결정하는 요소는 무엇입니까?[닫은]
https://stackoverflow.com/questions/80997
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
우리는 일련의 비공개 소스 애플리케이션과 라이브러리를 보유하고 있으며 이를 위해 소스 코드를 공개하는 것이 합리적이라고 생각합니다.
지금까지 우리를 가로막고 있던 것은 공개하기 전에 코드 베이스를 정리하고 소스를 문서화하는 데 필요한 노력이었습니다.
우리는 프로젝트가 성공할 합리적인 가능성이 있는 경우에만 소스를 공개하고 싶습니다.기여자가 있습니다.우리는 이 코드가 대규모 개발자들에게 흥미로울 것이라고 확신합니다.
어떤 요인, 프로젝트의 "흥미성"과 "유용성"을 제외하고, 오픈소스 프로젝트의 성공 여부를 결정짓는가?
예:
- 코드의 청결성
- 소스 코드 주석의 가용성
- 전체 또는 부분적으로 문서화된 API
- 라이센스 선택(GPL 대LGPL 대BSD 등...)
- 공개 저장소 선택
- 공개 웹사이트에 대한 투자
해결책
코드의 성공을 좌우하는 몇 가지 요소가 있습니다.이 모든 것은 채택 가능성이 조금이라도 달성되어야 합니다.
- 시장 - 오픈소스 프로젝트에는 시장이 있어야 합니다.귀하의 프로젝트가 우주의 오렌지 주스기라면, 귀하가 큰 성공을 거둘 수 있을지 의문입니다.귀하의 프로젝트가 사용자와 개발자 사이에서 큰 폭으로 채택되도록 해야 합니다.다른 기업에서도 이를 채택하게 하면 성공할 확률이 두 배로 높아집니다.
- 문서화 - 앞서 언급했듯이 문서화가 핵심입니다.이 문서에는 주석 처리된 코드, 아키텍처 결정 및 API 노트가 포함되어 있습니다.문서에 버그나 소프트웨어에 대한 버그가 포함되어 있어도 괜찮습니다.투명성이 핵심이라는 것을 기억하세요.
- 자유 - 당신의 코드가 "자유"가 되도록 허용해야 합니다. 즉, 맥주처럼 말하는 것이 자유롭다는 뜻은 아닙니다.당신의 시장이 다른 기업을 위한 라이브러리가 되고 있다는 느낌이 든다면 BSD 라이센스가 최적입니다.귀하의 소프트웨어가 데스크탑에서 실행될 예정이라면 GPL을 선택하십시오.
- 투명성 - 투명한 환경에서 소프트웨어를 작성해야 합니다.오픈소스로 전환하면 숨겨진 비밀은 없습니다.자신이 하는 모든 일과 하고 있는 일을 설명해야 합니다.이것은 다른 누구보다도 개발자를 화나게 할 것입니다
- 개발자 커뮤니티 - 강력한 개발자 커뮤니티가 필요합니다.이는 존재해야 합니다.사용자 중 약 5%만이 프로젝트에 다시 기여합니다.누군가가 1 년 동안 릴리스가 없다는 것을 알게된다면, 그들은 "와우,이 소프트웨어는 완성된다"고 생각하지 않을 것이라고 생각합니다. 비용이 드는 것을 의미하더라도 개발자의 작업을 계속하십시오.
- 통신 - 커뮤니티가 통신할 수 있는지 확인해야 합니다.버그를 신고하고, 해결 방법을 논의하고, 패치를 게시할 수 있어야 합니다.피드백이 없으면 프로젝트를 오픈소스화하는 것은 의미가 없습니다.
- 가용성 - 변호사를 화나게 하더라도 코드를 쉽게 얻을 수 있도록 만드는 것이 필요합니다.프로젝트를 다운로드하고 활용하기 쉬운지 확인해야 합니다.이를 위해 사용자가 18개의 잔소리 화면을 뛰어넘고 계약서에 서명하는 것을 원하지 않습니다.간단하고 깔끔하게 만들어야 해요
다른 팁
내 생각에 가장 중요한 요소는 프로젝트를 사용하는 사용자의 수입니다.그렇지 않으면 정말 잘 작성되고, 유용하고, 잘 문서화되어 서버에 앉아 별로 많은 일을 하지 않는 것들일 뿐입니다...
기여자를 확보하려면 먼저 사용자가 필요하고 그 다음에는 불완전성이 필요합니다.당신은 "이것은 시원합니다. 그러나 나는 그것이 이것을 가지고 있거나 이런 식으로 달랐으면 좋겠다"고 트리거해야합니다. 명백한 기능이없는 경우 사용자가 추가하는 데 기여할 가능성이 매우 높습니다.
가장 중요한 것은 프로그램이 좋다는 것이다.좋지 않으면 아무도 사용하지 않을 것이다.닭고기와 계란이 뒤바뀌고 그것이 좋아질 때까지 사람들이 그것을 당연하게 여기기를 바랄 수는 없습니다.
물론 "좋다"는 것은 단지 "상당수의 사람들에게 다른 어떤 실용적인 옵션보다 낫다"는 의미일 뿐입니다. 이는 그것이 엄밀히 최고라는 것을 의미하는 것이 아니라 많은 사람들에게 다른 어떤 실용적인 옵션보다 더 좋게 만드는 몇 가지 기능을 가지고 있다는 의미일 뿐입니다. 다른 옵션.가끔 프로그램이 가지다 다른 곳에서는 이에 상응하는 것이 없으며, 이 경우 이와 관련하여 요구 사항이 거의 없습니다.
프로그램이 좋으면 사람들은 그것을 사용하게 됩니다.분명히, 사용자들 사이에 시장이 있어야 합니다. 아무도 원하지 않는 일을 하는 좋은 프로그램은 아무리 잘 설계되었더라도 실제로는 좋지 않습니다.마케팅에 대해 어떤 주장을 할 수도 있지만, 정말 좋은 제품은 어느 정도까지는 스스로 마케팅하는 경향이 있습니다.좋지 않은 것을 홍보하는 것은 훨씬 어렵습니다. 따라서 제품을 홍보하는 것이 아니라 제품 자체가 최우선 순위가 되어야 한다는 점은 분명합니다.
그렇다면 진짜 질문은 어떻게 하면 좋게 만들 수 있느냐는 것입니다.이에 대한 답은 헌신적이고 숙련된 개발팀입니다.한 사람이 스스로 좋은 제품을 만드는 경우는 거의 없습니다.그들이 다른 개발자보다 훨씬 뛰어나더라도 다양한 관점은 프로젝트에 매우 유용한 영향을 미칩니다.이것이 바로 기업 후원자를 갖는 것이 매우 유용한 이유입니다. 이는 다른 개발자(기업의)가 문제에 대해 자신의 의견을 제시할 수 있도록 하는 것입니다.이는 프로그램 개발에 커뮤니티에서 일반적으로 사용할 수 없는 상당한 전문 지식이 필요한 경우에 특히 유용합니다.
물론 이 모든 것은 경험에서 말하는 것입니다.저는 가장 인기 있는 비디오 인코더 중 하나인 x264(현재 가장 활동적인 개발자)의 주요 개발자 중 한 명입니다.우리는 두 명의 주요 개발자, 패치를 제공하는 커뮤니티의 다양한 소규모 개발자, Joost(속도 제어 알고리즘을 유지 관리하는 Gabriel Bouvigne), Avail Media(때때로 계약으로 일하며 현재 계약으로 코더를 고용하고 있는)의 기업 후원을 보유하고 있습니다. MBAFF 인터레이스 지원 추가) 및 때때로 팝업되는 몇 가지 다른 기능도 있습니다.
좋은 개발자 한 명이 프로젝트를 만드는 것이 아니라 많은 좋은 개발자가 프로젝트를 만듭니다.그리고 이것의 최종 결과는 대부분의 상업용 경쟁사, 하드웨어 또는 소프트웨어, 심지어 막대한 개발 예산을 가진 경쟁사보다 더 빠르고 훨씬 더 나은 품질로 비디오를 인코딩하는 프로그램입니다.
이러한 문제를 살펴보면서 온라인 버전을 확인하는 데 관심이 있을 수 있습니다. UC Berkeley 오픈소스 강좌, 디지털 정보의 오픈 소스 개발 및 배포:기술적, 경제적, 사회적, 법적 관점.Mitch Kapur(Lotus 창립자)와 로스쿨 교수인 Paula Samuelson이 공동으로 가르쳤습니다.출퇴근 시간이 길어서 작년에 iPod에 강좌 오디오를 넣었습니다. 그들은 매우 광범위한(분명히 학술적인) 관점에서 무엇이 효과가 있고 무엇이 효과가 없는지, 왜 그런지에 대해 많은 이야기를 나눴습니다.
이 주제에 관한 책이 저술되었습니다.실제로 여기에서 무료 책을 찾을 수 있습니다. 오픈소스 소프트웨어 제작
사실 '프로젝트를 어떻게 운영하느냐'가 답인 것 같아요.
모든 예가 중요합니다. 하지만 핵심은 개발자 간의 상호 작용을 관리하는 방법, 패치 등을 처리/수락하는 방법, '책임자' 및 해당 책임을 처리하는 방법 등입니다.
Perl에서 Class::DBI 및 DBIx::Class 개발 관리를 비교하고 대조해 보세요(이력은 추적하기 어렵지 않습니다!).
저는 오늘 밤 성공적인 오픈 소스 프로젝트와 실패한 오픈 소스 프로젝트의 유용성 측면에 대한 훌륭한 게시물을 읽었습니다.
발췌:
오픈 소스 소프트웨어/무료 소프트웨어(이하 "OSS")의 유용성 부족을 놓고 논쟁을 벌이면서 많은 대역폭이 낭비되었습니다.현재 블로그, 포럼, Slashdot 댓글 스레드에서 논쟁이 계속되고 있습니다.어떤 사람들은 나쁜 유용성이 전체 OSS 세계의 고질적이라고 말하는 반면, 다른 사람들은 OSS 유용성은 훌륭하지만 진짜 문제는 모든 프로그램이 Microsoft를 복제할 것이라고 기대하는 폐쇄적인 사용자들이라고 말합니다.어떤 사람들은 UI 문제가 일시적인 성장통이라고 주장하는 반면, 다른 사람들은 OSS 개발 모델이 체계적으로 나쁜 UI를 만들어낸다고 말합니다.어떤 사람들은 GPL이 사용하기 어려운 소프트웨어에 간접적으로 보상을 한다고 주장하기도 합니다.(참고로 저는 동의하지 않습니다.)
그냥 오픈소스로 만드세요.아마도 아직 아무도 기여를 시작하지 않을 것입니다.그러나 최소한 보도 자료에 귀하의 제품이 GPL 등이라는 내용을 쓸 수는 있습니다.
첫 번째 단계는 사람들이 그것을 사용하기 시작한다는 것입니다.
그리고 아마도 사용자가 익숙해지면 기여를 시작할 것입니다.
지금까지는 모두의 답변이 좋았지만 한 가지 빠진 것이 있는데 그것은 좋은 감독입니다.일종의 프로젝트 관리가 없는 것보다 오픈 소스 프로젝트를 더 빨리 죽이는 것은 없습니다.사람들에게 무엇을 해야 하는지 알려주는 것이 아니라 유치하고 싶은 개발자를 위해 구조와 작업을 추가하는 것뿐입니다.
체계적이지 않은 프로젝트는 빠르게 무너집니다.그냥 놓아두고 날아가는 것을 지켜보는 새가 아닙니다.
