작은 오픈 소스 프로젝트의 원시 소스가 컴파일되고 사용 준비가 된 라이브러리 (이 경우에는 jar 파일, 플랫폼에 독립적)보다 자주 다운로드된다는 사실을 알고 놀랐습니다. 그 뒤에있는 이유가 무엇인지 궁금하네요? 신뢰의 부족? 호기심? 사용자 정의 설정으로 컴파일 하시겠습니까? 디버깅 소스를 첨부 하시겠습니까?프로젝트가 오픈 소스 인 경우 출처를 살펴보기가 어렵습니까?
개인적으로 나는 무언가가 작동하지 않거나 그것이 어떻게 작동하는지 이해하지 못한다면 대개 소스를 다운로드하고 보는 것을 귀찮게하지 않습니다.
첫 번째 이유는 응용 프로그램을 사용자 정의하기위한 것입니다.
또한 코드를 다운로드하고 코드 작동 방식을 보지 않고 바로 사용할 수있는 좋은 방법은 아닙니다. 코드에서 배울 점이 있습니다.
또한 프로젝트의 전체 기능이 필요하지 않을 수도 있습니다. 프로젝트가 너무 크고 일부 기능 만 사용해야하는 경우에는 프로젝트를 필요에 따라 다듬어서 사용하는 것이 좋습니다.
두 번째 요점은 일반적으로는 합리적이지만 많은 사람들이 SQLite 소스 코드를 실제로 읽었다는 것을 상상할 수 없습니다. 매우 복잡합니다. – sharptooth
매우 복잡한 프로젝트의 경우 귀하의 요지가 유효 할 수 있습니다. – rahul
가장 큰 이유는 컴파일러 설정입니다. 호환되지 않는 일부 설정으로 컴파일 된 정적 라이브러리를 연결하여 발생하는 고통의 양을 상상할 수 없습니다. 확인 된 설정으로 직접 컴파일하면 삶이 크게 단순 해집니다. 게다가 기존 정적 라이브러리가 필요하지 않은 더 나은 컴파일러를 변경하기로 결정한 경우 - 새 컴파일러 2에서 컴파일됩니다.
2 가지 이유는 사람들이 내부에서 어떤 작업을하는지보고 싶어 할 수 있다는 것입니다. 예를 들어 상용 폐쇄 소스 프로젝트에서 동일하거나 유사한 기능을 원하며 바이러스 성 라이센스로 인해 코드를 빌릴 수 없습니다. 그러나 그들은 그것이 어떻게 작동하고 영감을 얻었는지 알 수 있습니다. 왜 소스를 다운로드하고 읽어야하는지.
다른 사람들이 특정 작업을 어떻게 구현했는지 알기 위해 소스를 다운로드하는 경우가 있습니다. 다른 사람들 소스 코드를 읽고 이해하는 것이 더 나은 프로그래머가되는 좋은 방법입니다.
상대적으로 많은 다운로드 수의 경우, 귀하의 도서관은 Linux 배포판과 같은 다른 프로젝트에 포함되어 있습니까? 이러한 프로젝트는 대개 소스에서 다운로드하여 빌드하므로 제대로 패키지 할 수 있습니다.
다운로드 수가 많지 않다는 것만 제외하면 컴파일 된 버전보다 높습니다. – serg
좋아요, 비교적 다운로드 수가 많음 :-) –
내 회사에서 장기간 관심을 보이는 모든 소프트웨어에 대해 품질 평가를 위해 출처를 검토합니다. 그 뒤에 대한 근거는 잘못 작성된 소프트웨어는 일반적으로 사용 및 유지가 안 좋고 따라서 장기적으로 비즈니스 위험이된다는 것입니다.
ERP 시스템과 같은 대부분의 상용 소프트웨어를 사용하는 경우에도 소스를 확인하는 데 아무런 문제가 없습니다. COTS (MS Office)에서만 소스를 확보하기가 어렵습니다.
나는 또한 모든 채용 결정에 대해 출처를 확인합니다.
많은 소스 다운로드를 보는 다른 이유는 FreeBSD Ports과 같은 자동화 된 빌드 시스템이 자동으로 다운로드되고 컴파일 될 수 있기 때문입니다.
불량으로 인해 거부 한 프로젝트의 예를 보는 것이 흥미로 웠습니다. 품질. – serg
나는 라이브러리를 다운로드하고 자신을 컴파일했지만 실제로 코드를 살펴 보지 않았습니다. 라이브러리를 사용하면 변경 사항을 적용하고 소스를 확보 할 수 있다는 것을 알고있는 것이 좋습니다. 방대한 라이브러리 일 경우 때때로 파일 하나 또는 두 개만을 가져 왔고 큰 라이브러리의 단일 기능 만 필요합니다.
나는 프로그램의 작동 방식을 배우기 위해 소스를보고있다.
오픈 소스 소프트웨어 (예 : 오픈 소스 CRM)는 설명서의 부족으로 유명해 보일 수 있습니다. 그것이 어떻게 작동하는지 알아내는 유일한 방법은 그것으로 실험하는 것입니다. 실험이 실패하더라도 IDE를 실행하고 소스를 읽을 시간입니다 !!
아마도 답은 실망 스럽겠지만 소스 다운로드 수가 비교적 많으면 응용 프로그램이 Gentoo, FreeBSD 또는 MacPorts와 같은 포트 기반 패키지에 패키지되어있는 것을 의미 할 수 있습니다.이 패키지는 모든 패키지가 로컬 컴퓨터에서 다운로드되고 컴파일되는 동안 설치.
프레임 워크 인 경우 항상 소스를 다운로드합니다. 디버깅에 사용하고 특정 상황을 어떻게 구현했는지 확인합니다. 독립 실행 형 응용 프로그램 인 경우 일반적으로 문제가 있거나 응용 프로그램이 고유 한 작업을 수행하지 않는 한 원본을 보지 않습니다.
아멘. 소스는 종종 최고의 API 문서입니다. – gustafc
바이너리가 jar라고 말하면 응용 프로그램이 아닌 Java 라이브러리 인 것처럼 들립니다. 개발자는 종종 소스를 사용하여 IDE에 포함시켜 라이브러리에서 디버그하고 특정 기능을 조회합니다. 또한 많은 개발자들이 소스를 빌드 프로세스에 포함시켜 종속성도 컴파일합니다. 그것은 설명 일 수 있습니다.
몇 가지 이유가있을 수 : 인해 트로이 목마 이진 다운로드의
불신 등
코드의 품질을 확인하는 방법을 이미 구현 한 것이
을 살펴보면 :)
이 라이브러리이므로 포괄적 인 문서에 대한 필요성은 독립형 응용 프로그램보다 훨씬 높습니다. 종종 가끔씩 문서에서 제외 된 특정 사항을 파악하기 위해 라이브러리 코드를 찾는 경우가 종종 있습니다. 특정 기능의 시간/공간 복잡성.
우리는 상용 응용 프로그램을 위해 일부 오픈 소스 패키지를 사용합니다. 나는 항상 소스에서 다운로드하고 빌드한다.
미래에 우리의 호스팅 플랫폼 변경, 그것은 미리 컴파일 된 바이너리가없는 뭔가 변경 될 수 있습니다 경우. 새로운 플랫폼에서 같은 패키지/버전 을 사용하고 싶습니다. 패키지가 휴면 이동 또는 가 지원되지 않는 될 경우
, 나는 변화를 적용하거나 절대적으로 필요한 경우 해결할 수 되고 싶어요. 뭔가 서버 (메모리 누수, CPU 스파이크, 등)에 잘못가는 경우
, 나는 의 소스로 패키지를 에 로깅 또는 계측 코드를 추가 식별하거나 제거 할 수 있도록하려면 문제.
나는 물론 단지 자신을 위해 대답 할 수 있지만, 내가 (나는 보통의 경우 프로젝트를 신뢰 가정) 바이너리를 다운로드하고 사용자가 디버깅 할 때 내가 소스를 다운로드하는 거의하지 않습니다. 그러나 나는 그들과 함께 끝났다고 생각할 때 소스를 지우는 경향이 있습니다. 그리고 당신이 정말로 완료되지 않았기 때문에 나중에 소스를 다시 다운로드해야하므로 소스 다운로드가 더 높아질 수 있습니다.
컴파일보다 다운로드가 많다는 것을 어떻게 알 수 있습니까? –
나는 소스를위한 카운터와 컴파일 된 jar의 카운터를 가진 두 개의 다운로드 링크를 가지고있다. – serg