오픈 소스 프로젝트가 제품에서 사용하기에 충분히 성숙한 지 아는 방법은 무엇입니까?

15

직장에서 제품에 포함시키고 싶은 오픈 소스 프로젝트가 있습니다. 우리는 스스로 할 대역폭이나 주제 전문 지식이 없습니다. Google에서 검색하여 찾았습니다. 나는 프로젝트를 이용하는 "주요 선수들"을 모른다. 그러나 나는 내가 본 것에 매우 고무되어있다.

이제 joe-blow의 오픈 소스 프로젝트를 사용하여 노출되는 위험 정도에 대해 약간 걱정하고 있습니다. 나에게 95 %가 걸리면 나머지 5 %는 쉽게 추가하거나 수정할 수 있습니다. 아마도 사소하지 않습니다.

사람들이 오픈 소스 프로젝트가 제품에 사용하기에 충분히 성숙한 지 어떻게 판단합니까?

이것은 취미 프로젝트가 아니므로 안정성, 유지 보수성 등이 가장 중요합니다.

open-source

— jglouie
소스

당신은 확실하지 않습니다. Windows가 충분히 성숙 되었습니까? 그것을 테스트하고 개발자에게 연락을 시도하십시오-개인 연락처 (이메일?)는 그들이 만든 프로젝트의 온전함 / 성숙도에 대해 많은 것을 말할 수 있습니다.

— SChepurin

3

중요한 것은 요구 사항에 맞는지 여부입니다. 그렇다면 간단하게 사용하십시오. 그것이 "성숙하지 않다"(의 정의가 논쟁의 여지가 없다면), 코드 / 토론 / docs / community / bugs / xyz에 기여하여 그것을 성숙시킬 수있다.

— treecoder

1

실제 제품에 새 라이브러리를 포함시키기 전에 정말 좋은 단위 테스트를 작성하십시오.

— Jim In Texas

@greengit : 대안이 더 잘 맞지 않는 한 모든 요구 사항을 충족시킬 필요조차 없습니다.

— Jan Hudec

17

프로젝트가 내 요구 사항에 맞는 경우 사용하는 기준 :

사람들이 도움을 줄 수있는 활동적인 커뮤니티가 있습니까?
라이센스가 내 개발에 적합합니까?
제품이 아직 개발 중입니까?
일반적으로 사용되는 프레임 워크입니까?
제품에 대한 리뷰 / 블로그 게시물 / 등을 찾을 수 있습니까?

4 & 5는 귀하의 틈새 프로젝트에 실제로 도움이되지 않습니다.

가장 중요한 것은 요구 사항을 충족시키는 것입니까? 그렇게 생각한다면 다음으로 할 일은 프로젝트를 테스트하기 위해 하네스를 만들고 원하는 작업을 수행 할 수 있는지 확인하는 것입니다. 이를 통해 API (라이브러리 인 경우)와 작동 방식에 대한 느낌을 얻을 수 있습니다.

하루가 끝날 무렵, 귀하가하는 일의 90 %를 수행하는 오픈 소스가있는 경우이를 포크하고 추가 기능을 추가하여 커뮤니티에 반환하십시오. 나는 상업 프로젝트를하기 전에 이것을했다.

— 샘
소스

6

완료된 95 %는 남은 95 % 만

— 남았다는

6

프레임 워크의 경우 일반적으로 미리 작성된 많은 모듈과 큰 커뮤니티가있는 크고 성숙한 프레임 워크 만 사용합니다. 일반적으로, 하나의 프레임 워크를 다른 프레임 워크보다 선택하면 실제로 자신의 코드에 소비해야하는 작업량을 크게 줄일 수 없으며, 일부 프레임 워크는 더 아름다운 코드를 장려 할 수 있고, 다른 프레임 워크는 특정 작업을 쉽게 수행 할 수 있지만 일반적으로 총 개발 노력과 거의 차이가 없습니다. 그러나 널리 사용되는 프레임 워크에는 활용할 수있는 미리 작성된 모듈이 더 많기 때문에 일반적으로 훨씬 더 많은 시간과 노력을 절약 할 수 있습니다.
작은 비 프레임 워크 라이브러리의 경우 일반적으로 많은 문제없이 필요한 경우 직접 수정할 수 있으므로 일반적으로 커뮤니티를 추가 보너스로 고려하는 것이 좋습니다. 대부분의 소규모 도서관은 한 사람 만 관리하지만 자신을 구축하는 것보다 낫습니다. 그러나 대규모 도서관의 경우, 자신을 쉽게 변경할 수 없기 때문에 성숙하고 활동적인 커뮤니티 및 문서화가 필수적입니다.
라이센스는 필수입니다. 1 인 라이브러리의 경우 라이브러리를 수정해야 할 가능성이 있으므로 동의하면 해당 라이센스로 라이센스를 부여해야합니다.

소규모 도서관의 경우, 항상 포크해야하고 프로젝트가 이미 중단되었다고 가정해야합니다. 특히 프로젝트가 Github 또는 BitBucket에서 호스팅되는 경우 다른 사람들의 프로젝트를 어리석게 쉽게 만들 수 있기 때문에 문제가되지 않습니다. 소규모 도서관의 경우, 원래 관리자가 사라지거나 원하지 않는 장소로 프로젝트 방향을 잡을 계획 인 경우 항상 프로젝트 유지 관리를 직접 맡을 수 있습니다.

나는 프로젝트 활동에 대해 덜 염려합니다. "완벽 성"에 대한 감각을 얻은 성숙한 라이브러리는 일반적으로 버그 수정 만하면되므로 활동 속도가 느려집니다. 프로젝트 활동은 라이브러리가 적극적으로 발전하고있는 대상을 포함하는 경우에만 중요합니다. 예를 들어 외부 서비스의 래퍼는 외부 서비스가 발전함에 따라 지속적으로 업데이트되어야하므로 적극적인 개발이 필수적이지만 수학 라이브러리는 많이 필요하지 않습니다. 필요한 모든 기능을 갖춘 새로운 개발.

더 큰 라이브러리의 경우 상황이 더 어려워집니다. 인수는 훨씬 더 복잡합니다. 운 좋게도 더 큰 라이브러리는 일반적으로 더 성숙하기 때문에 빠르게 이동하지 않습니다.

@Sam이 그의 답변에서 말했듯이 오픈 소스 라이브러리를 평가할 때 가장 중요한 것은 요구 사항에 얼마나 부합하는지 동의합니다. 라이센스 문제가 정리되면 오픈 소스 라이브러리를 사용하는 것은 실수가 거의 없습니다.

— 거짓말 라이언
소스

3

프로젝트의 버그 추적기를 살펴보십시오. 많은 다른 사람들이 제출 한 많은 티켓과 다양한 사람들로부터 온 응답이 보이면 좋은 징조입니다. 더 많은 버그 티켓 == 더 큰 사용자 커뮤니티 == 더 많은 프로덕션 사용 준비가 될 것입니다.

— 칼 포겔
소스

2

그것이 프로젝트가 어떤 용량으로 사용되고 있는지를 확실히 확인할 수있는 방법이지만, 프로젝트가 프로덕션 시스템에 충분히 신뢰할 수 있는지를 알기 위해서는 단순히 버그 티켓 수보다 더 많은 맥락이 필요합니다. 예를 들어, 대부분의 버그 티켓이 한동안 열려 있고 여전히 해결되지 않은 경우,이를 비즈니스 핵심 시스템에 통합하고 싶지 않습니다.

— Derek

실제로, 대부분의 티켓조차도 한동안 열려 있고 해결되지 않으면 괜찮습니다. 이것은 소프트웨어 자체에 대한 것보다 사용자 기반의 규모와 참여를 나타내는 것일 수 있습니다. 해당 주제에 대한 자세한 내용은 여기 : rants.org/2010/01/bugs-users-and-tech-debt .

— Karl Fogel

1

뉴스는 좋지 않지만 그것이 틀렸다는 것을 의미하지는 않습니다. 당신은 모른다.

프로덕션 환경에서 유사한 구현이 있었다면 실현 가능성이 있지만 "주요 플레이어"가 프로젝트를 사용하지 않는다고 말한 것입니다.

사내에서 개발했다면 알겠지만, 말했듯이 자원이 없습니다.

알고 싶어하는 것이 합리적이지만 ... 그렇지 않습니다.

이 답변이 도움이 되길 바랍니다. 의존하고 있지만 통제하지 않는 기술에 대한 플러그를 뽑을 계획이 있어야합니다.

— 윌슨
소스

1

질문은 다르게 넣어야합니다. 당신이 정말로 요구하는 것은 이 오픈 소스 프로젝트를 사용하여 제품을 개발하는 가장 좋은 방법입니까?

여기에는 반드시 해당 오픈 소스 프로젝트뿐만 아니라 다른 옵션도 포함됩니다. 다른 옵션이 모든 것을 직접 작성하는 경우 프로젝트를 수정할 수있을만큼 코드를 이해할 수 있다면 프로젝트를 사용하는 것이 좋습니다.

물론 다른 질문은 프로젝트가 실행 가능한지 여부에 달려 있습니다. 즉, 오픈 소스 코드를 통해 원하는 기능을 수정하거나 완료해야하는 위험을 포함한 노력을 추정해야합니다. 프로젝트가 널리 사용되지 않으면 해당 코드를 검토해야합니다.

— 얀 후덱
소스