"오픈 소스, 패치 제출"에 대한 정식 레토르트는 무엇입니까? [닫은]

제품, 특히 오픈 소스에서 일부 기능을 제안 할 때의 위험은 "왜하지 않습니까?"라는 응답을 얻을 수 있다는 것입니다.

그것은 유효하며 직접 변경할 수있는 것이 좋습니다. 그러나 프로그래머가 다른 프로그래머 인 경우에도 사용자의 목소리에 귀를 기울이면 제품이 개선되는 경우가 많습니다. 또한 이러한 변경 작업을 효율적으로 수행하는 방법에는 이미 프로젝트를 진행하면서 아이디어를 취하고 구현 한 사람이 포함될 수 있습니다.

소프트웨어 개발 문제를 나타내는 데 사용되는 몇 가지 일반적인 용어가 있습니다. 예를 들어 Bikeshedding . 본질적으로 다음과 같이 사용되는 일반적인 용어가 있습니까? "예, 저는 폐쇄 된 소스라도 전 세계 어디에서나 바꿀 수 있다는 것을 알고 있습니다. 실제로 쉽게 변경하거나 일반적으로 가능성을 논의하기에 적합한 다른 코더에게 유용한 관찰 결과입니다. "

[ps (며칠 후)- "패치 제출"은 종종 유머로 말하며 적절한 재치있는 답변을 찾고 있습니다.]

어려운 점이 있습니다. 사용자가 직접 또는 간접적으로 제품에 대한 비용을 지불하지 않기 때문에 기능 구현을 요청할 수 없습니다. 마치 제품을 주문한 이해 관계자 나 직거래 고객이 아니며 상업용 제품의 최종 사용자도 아닙니다.

이 존재는 말했다 올바른 답이 아니다 "패치 제출". 공손하지 않습니다. 정확하지 않습니다. 오픈 소스 제품의 경우에도 마찬가지입니다. "패치 제출"은 다음과 같은 짧은 버전입니다.

"우리는 당신이 우리의 제품을 좋아하는지 아닌지 상관하지 않습니다. 원한다면 가서 수정하십시오. 그러나 당신의 고객 요청으로 우리를 귀찮게하지 마십시오."

패치를 제출하는 것은 어떻습니까?

글쎄, 쉽지 않습니다. 그렇게하려면 :

• 오픈 소스 프로젝트에 사용 된 언어를 알아야합니다.

• 버전 제어에서 소스 코드를로드하여 수정할 수 있어야합니다.

• 런타임 라이브러리 및 빌드 도구를 포함하여 올바른 빌드 종속성 버전이 모두 설치되어 있어야합니다.

• 이 소스 코드를 컴파일 할 수 있어야합니다 . 일부 경우에는 그렇게 명확하지 않습니다. 특히, 거대한 프로젝트에서 컴파일하고 482 개의 오류와 수천 개의 경고를 표시하는 데 몇 시간이 걸리는 경우 이러한 오류의 원인을 찾아 보는 것이 용기가있을 수 있습니다.

• 프로젝트 수행 방식 , 사용하는 코딩 스타일, 단위 테스트 실행 방법 등을 잘 이해해야합니다. 프로젝트 에 적절한 문서가없는 경우 (종종 오픈 소스 프로젝트의 경우) ), 정말 어려울 수 있습니다.

• 프로젝트와 프로젝트에 적극적으로 참여하는 개발자의 습관에 적응해야합니다. 예를 들어 .NET Framework 4를 매일 사용하지만 프로젝트에서 .NET Framework 2.0을 사용하는 경우 LINQ, 코드 계약 또는 최신 버전의 프레임 워크의 수천 가지 새로운 기능을 사용할 수 없습니다.

• 패치는 반드시 수락해야합니다 (커뮤니티와 공유 할 의도없이 자신 만 변경하지 않는 한).

귀하의 의도가 프로젝트에 적극적으로 참여하려는 경우, 모든 일을하고 시간을 투자 할 수 있습니다. 반면에 성가신 사소한 버그 또는 누락 된 간단한 기능이 있거나 프로젝트를 연구하는 데 며칠, 몇 주 또는 몇 달을 보낸다면 몇 분 안에 작업을 수행하는 것이 마음에 들지 않으면 불합리합니다.

그렇다면 "오픈 소스이고 패치를 제출하십시오"라는 정식 레토르트가 있습니까? 나는 그렇게 생각하지 않습니다. 상대방에게 그녀가 무례하다고 설명하거나 이야기를 그만두십시오.

정식 레토르트는 패치를 제출하는 것입니다.

이것은 개발자가 합리적인 기간 내에 무언가를 할 것이라고 생각하지 않을 때 표준 답변이지만 반복적으로 제기되었습니다.

그것이 반복적으로 제기 될 때 가장 불공평하지만, 가장 최근에 언급 한 사람은 그것을 알지 못하고 바로 "우리는 패치를 받고 있습니다"라는 메시지를받습니다. 이 경우 관리자는 토론에 질려 있지만 사용자는 새로운 주제라고 생각합니다. 어쨌든, 즉시 "패치 찍기"를 받으면 개인적으로 가져 가서는 안되지만 문제에 대한 자세한 내용은 아카이브 및 버그 추적기를 읽어보십시오.

반복적으로 요청을 직접 제기하는 경우 "패치 찍기"는 잠재적으로 덜 정중 한 대안에 비해 상대적으로 예의 바른 솔직을 의도합니다 ...

물론 아무에게도 설명하지 않고 "패치 찍기"라고 말하는 무례한 관리자가 있지만, 나는 그것이 소수라고 말합니다.

많은 사용자가있는 오픈 소스 프로젝트를 유지 관리 한 경우 관리자가 얻을 수있는 것보다 100 배 더 많은 요청이 있으며 이러한 요청 중 많은 수가 요청자에게 중요하지만 엄청나게 어려울 것입니다. 다른 많은 사용자를 방해하거나 프로젝트와 코드베이스에 대한 전반적인 이해로만 볼 수있는 다른 결함이있을 수 있습니다. 또는 때로는 판단 요청이있을뿐 아니라 모든 사람이 계속해서 논쟁하는 데 너무 많은 시간이 걸립니다.

오픈 소스가 아닌 대부분의 회사는 개발자에게 전혀 액세스 권한을 부여하지 않으며 고객 지원 센터에서 조용히 처리하거나 정중하지만 허위 이야기를 얻습니다. 따라서 오픈 소스에는 최소한 몇 가지 옵션이 있습니다 (기능을 코딩하기 위해 누군가에게 지불하십시오). 개발자가 무례 할 수는 있지만 최소한 정답을 제공합니다. 차라리 "로드맵에 있습니다 ... [2 년 후] ... 여전히 로드맵에 있습니다."여러 벤더로부터받은 것입니다.

그래서 레토르트가 없다고 생각합니다. 어쩌면 오픈 소스 관리자가 너무 바빠서 어쩌면 바보 일 수도 있지만 어쨌든 그들은 힘든 일을하고 누가 마지막 말을했는지 논쟁하지 않아도됩니다. 당신이 할 수있는 최선의 방법은 어떤 방식 으로든 기여하고 건설적으로 노력하는 것입니다.

코드가 아닐 수도 있지만 가능한 많은 분석 및 문서화 사용자 시나리오가있을 수 있습니다. 그놈 창 관리자를 유지하면서 많은 사람들이 모든 사용자를 고려하여 전 세계적으로 문제를 분석하고 문제 와 장단점, 그리고 전 세계적 관점에서 일어날 일을 적어 두는 것이 도움이되었을 것입니다 .

(대신, 평범한 것은 그들이 유일하게 중요한 사용자 였고 트레이드 오프가 없었던 것처럼 화염을 시작하는 것이 었습니다. 그리고 그것은 훌륭하고 데이터 포인트였으며 종종 공손하게 머물거나 결국 문제를 해결했습니다 .. 타오르는 것은 어떤 일도 더 빨리 일어나게하지 않으며 단지 감정을 문제로 혼동시키고 모든 시간을 낭비합니다.)

이 응답을받는 이유는 관리자가 바보가 아니기 때문에 자신 의 기능에 대해 작업하는 사람들 의 가치 제안을 적절히 확신하지 못했기 때문입니다 .

최선의 대응은 지역 사회 전체에 기능의 가치에 대한 대화를 시작하여 그들이 마음을 바꾸도록 설득 할 수 있는지 확인하는 것입니다. 그들이 옳을 수도 있고 당신보다 자신의 공동체의 필요에 대해 더 많이 알고있을 수도 있지만, 다시는 그렇지 않을 수도 있습니다.

이 기능이 당신에게만 가치가 있고 지역 사회에 가치가 없거나 거의 가치가 없다면, 나는 돈이 훌륭한 동기 부여 자라는 것을 알지만 그들의 태도에 대해 불평하는 것은 아닙니다.

"오픈 소스, 패치 제출"에 대한 정식 레토르트는 무엇입니까?

차이를 만들 수있는 합리적인 레토르트가 없습니다. 자원 봉사자들에게 의도가없는 일을하도록 설득하는 것은 시간 낭비입니다.

옵션은 다음과 같습니다.

• 응답이 제안하는 것을하십시오. 즉, 기능을 구현하고 패치로 제출하십시오. 그것은 "뭔가를 돌려주는 것"이라고합니다.

• 실제 돈을 위해이 기능을 기꺼이 구현할 사람을 찾으십시오. 프로젝트 자체 (예 : 후원을위한 대가로), 프로젝트와 관련된 사람 또는 임의의 "임대용 코더"일 수 있습니다.

• 대체 제품을 찾으십시오.

"유용한"제안을했을 때이 응답을 받았다면, 그의 신발을 신었을 때 어떻게 응답했는지 생각해보십시오. 예를 들어, 제안이 가치 있고 / 잘 생각하고 / 알기 어려운 / 그 밖의 것이 아니라 장기 토론에 참여할 시간이나 인내심이 없다고 생각한다면 어떻게 대답 하시겠습니까?

나는 오랫동안 운영되는 오픈 소스 OS 프로젝트에 참여해 왔으며, 가장 성가신 것은 "땅콩 갤러리"에 앉아 "더 나은"일을하는 것에 대한 제안을하는 사람들입니다.

• 불완전하거나 이해할 수 없거나 완전히 무의미한 경우
• 객관적으로 낮은 성공 가능성을 가진 시도되지 않은 아이디어입니다.
• 구현하기 위해 많은 노력이 필요합니다.
• 프로젝트의 명시된 목표에 반합니다.

종종 최선의 대응은 프로젝트에 참여하도록 사람에게 뾰족하게 도전하는 것입니다. 그리고 그들이 "들어 올리거나 닥 치기"위해 힌트를 얻길 바랍니다. 불행히도, 가장 성가신 사람들은 힌트조차 얻지 못합니다.

물론 그러한 사람들에 대한 다른 반응은 전혀 반응하지 않거나 완전히 무시하는 것입니다.

귀하와 해당 프로그래머가 동일하고 코드베이스 및 언어에 대해 거의 동일하게 알고 있고 지적하고있는이 특정 사항과 관련된 다른 모든 사항을 알고 있으면 응답이 합리적입니다.

당신은 평등하지 않거나 (아마 아마 그것을했을 것입니다) 적절한 레토르트를 제안 할 것입니다 :

"가능한 한 빨리 그리고 좋은 일을 할 수있는 방법이 없기 때문에 처음부터 도와달라고 부탁했습니다."

나는 "오, 그래, 오랜 시간을 보냈고 정말 잘하는 일이 너무나 간단해서 누구나 거리에서 들어 와서 좋은 일을 할 수있다" 나는 "할 수 있습니다.

정식 레토르트는 프로젝트를 포크하는 것입니다.

"패치 제출"에 대한 정식 답변은 다음과 같습니다.

"필요한 기술, 경험 또는 시간이 없으므로 맥주 케이스를 제공 할 수있는 사람에게 맥주를 배송 할 수있는 곳을 알려주세요."

종합적인 테스트 사례를 제출하십시오 .

"그렇게하면 포함시킬 것"이 "아니오"보다 훨씬 낫습니다.

어떤 이유로 든 작업을 수행 할 수없는 경우 상황을 프로젝트 관리자에게 개인적으로 설명하십시오.

사용하려는 오픈 소스 프로젝트에 어떤 방식 으로든 기여하지 않으려는 경우 대신 상용 지원 또는 다른 상용 제품을 찾고 있어야합니다.

"응답 감사합니다."

때문에:

• 가격이 0이면 수요 (기능 요청)가 공급 (상기 기능을 구현하는 데 사용 가능한 코더)을 초과합니다.
• 무료로 제공되는 모든 것에 걸치면 IMHO 클래스가 부족합니다.
• 이것이 FOSS의 요점입니다. 사람들은 돌 수프에 영양을 공급하기 위해 자신의 야채와 고기를 가져옵니다. 내가 무언가를 기여할 수 없다면, 나는 전혀 먹을 수 있다는 것에 감사해야하고, 더 잘 먹지 않는다고 불평하지 않아야합니다.

아무 말도 할 필요가 없습니다. 개발자가 응답했다는 사실은 이미 문제가 있음을 알았으며 (적어도 일부) 사용자에게 고통을 초래한다는 것을 나타내는 것으로 충분합니다.

하루가 끝나면 개발자가 원하지 않는 경우 개발자가 당신을 위해 일하도록 설득 할 수는 없습니다.

훌륭한 오픈 소스 프로젝트에는 버그 / 기능 요청 시스템이있어 사용자가 버그 / 기능을 제출하고 다른 사람들이 그에 대해 투표 할 수 있으므로 관리자가 커뮤니티 전체에 중요한 것을 식별 할 수 있습니다. 그러나 기능을 사용하는 가장 빠른 방법은 패치를 제출하는 것입니다. 시대 ... 그 주위에 방법이 없습니다.

개인적으로 저는 "이것은 알려진 문제이지만 불행히도 곧 해결 될 문제는 아닙니다. 개발자는 다른 문제에 대해 작업하고 있습니다. 현재 ETA가 없습니다"라고 대답합니다.

"패치 제출"응답은 여러 가지 사항을 가정하므로 매우 무례합니다.

1. 프로그램의 모든 사용자는 프로그래머이거나 모든 버그 리포터는 프로그래머입니다.
2. 모든 프로그래머는 프로그램의 언어를 알고 있습니다.
3. 모든 프로그래머는 모든 종류의 프로그램이 가질 수있는 모든 종류의 문제에 대해 알고 있습니다.
4. 모든 프로그래머는 오픈 소스 프로젝트를 수행 할 자유 시간이 있습니다.

"패치 제출"응답 메이커가 위의 모든 사항을 알고 있다고 가정하더라도 "내 시간의 X 시간은 일어나고있는 시간의 시간보다 더 큰 가치가 있습니다. 문제를 빠르게 해결하기 위해

일반적으로 문제가 있거나 버그를 제출할 때 개발자로부터 무례한 응답을 받으면 해당 프로그램의 사용을 중단합니다. 예를 들어 "지원"포럼에서받은 응답이 너무 무례했기 때문에 더 이상 uTorrent (오픈 소스는 아니지만 요점은 남아 있음)를 사용하지 않습니다. Bug Reports 포럼에있는 문제를 제출했습니다. 스레드는 스레드에서 비슷하지만 다른 문제에 대해 다른 스레드에 대한 링크와 함께 즉시 잠겼습니다 (물론 잠겨 있음). 그동안 일반 토론 포럼에서 누군가가 문제에 대한 해결책을 찾았는지 묻는 스레드를 열었습니다. 그 스레드를 저장하고 돌아가서 첫 번째 스레드가 잠 겼음을 확인하는 데 걸리는 시간에 General의 스레드가 잠기고 포럼 계정이 방해되는 행동을 금지했습니다. 나는 uTorrent를 제거하고 그 이후로 돌아 오지 않았습니다.

"패치 제출"에 답하는 것은 무례한 IMO이지만 여전히 ... 심지어 심각한 일을 위해 오픈 소스 소프트웨어를 사용하는 경우, 필요할 경우이를 처리 할 준비가되어 있어야합니다.

다음은 Jeremias Maerki (Apache FOP 명성)의 게시물 을 기반으로 합니다 .

무언가가 효과가 없다면 몇 가지 옵션이 있습니다.

• 이것은 오픈 소스입니다 : 직접 고칠 수 있습니다.
• 스스로 고칠 수 없다면, 자유 시간이 있고 구현하기가 재미있을 때까지 기다릴 수 있습니다.
• 그런 일이 일어나지 않으면 다른 사람을 찾아 고용 할 수 있습니다.

"패치 제출"답변의 매우 유효한 정식 버전이라고 생각합니다.

이것을 볼 때마다 나는 즉시 대체 제품을 찾기 시작합니다. 나에게 이것은 관리자가 사용자에 대해 신경 쓰지 않거나 (프로젝트가 어디에서나 사용되는 경우 나쁘다) 프로젝트에 대한 관심을 잃어 버렸다는 위험한 신호입니다. 이 두 가지 모두 일반적으로 개발자가 프로젝트 진행을 거부함에 따라 프로젝트가 곧 죽거나 정체 상태에 시달릴 것임을 의미합니다.

(이러한 종류의 응답으로 가장 먼저보고되는 버그 보고서는 아닙니다. 일반적인 추세를 살펴 봐야합니다. 대부분의 버그 보고서가 이러한 종류의 응답으로 끝나는 경우이 조언을 따르십시오. 단지 몇 가지, 프로젝트 목표에 맞지 않거나 특정 용도로 사용되는 기능 요청 일 가능성이 높습니다)

@MainMa가 말했듯이 새로운 프로젝트에 기여하는 것은 매우 어렵다. 대부분의 개발자는 몇 달 / 몇 년 동안 프로젝트를 진행하면서 이것을 이해하지 못하며 이해가됩니다. 이것은 때때로 정직한 실수 일 수 있습니다.

나는 때때로 무료 소프트웨어가 맥주처럼 무료이거나, 연설에서나 무료로 당신이 지불하는 것을 얻을 때 무료라고 농담합니다.

나는 농담으로 말하지만 (많은 OSS를 사용하는 회사에서 일하고 있지만) 진실이 있다고 생각합니다. 상업적 수준의 지원을 원한다면 상용 소프트웨어를 적절한 지원 계약으로 사용하거나 개방형 소스 소프트웨어 솔루션을 통해 해당 수준의 지원을 제공 할 수 있습니다 (보통 비용을 지불하는 사람을 통해 지원하지만 잠재적으로 개발 리소스를 사용하거나 할당하여 조직을 통해).

"패치 제출"은 화를 내고 있지만 OSS에 대한 내용을 강조하고 있으며, OSS가 모든 상황에서 모든 사람에게 적합하지 않다는 것을 상기시켜야합니다. 사내, 지역 사회를 위해 또는 지역 사회를 통해 지불).

우리는 종종 맥주처럼 무료이지만 말로는 아닌 소프트웨어 (비공개 프리웨어)에 대해 생각합니다. 아마도 이것은 우리가 소프트웨어를 언론이 아닌 맥주가 아닌 무료로 생각해야하는 경우 일 것 입니다.

잘 관리 된 대안으로 전환하십시오.

잘 관리 된 오픈 소스 프로젝트에 대한 나의 경험에 따르면, 잘 정의 된 버그 보고서 또는 기능 요청을 만들면 구현 가능성이 매우 높습니다.

"한 번에 한 가지 작업 만 할 수 있지만 한 번에 많은 작업에 대해 불평 할 수 있습니다. 두 기능이 모두 유용하다고 생각합니다." - 와이 콤비 네이터에 akkartik .

프로젝트와 함께 작업하면서 릴리즈와 지원을 제공 할 때 개발자와 사용자 간의 무언의 암시 적 지원 계약이 시작된다고 생각합니다. 개발자는 요청시 기능 추가를 포함하여 사용자를 위해 코드베이스를 지원해야 함을 암시했습니다.

"패치 제출"은 기본적으로 사용자들에게 손가락을주고 있습니다. 상황에 맞습니다. 때로는 구현하기에 너무 많은 노력이 필요하며 때로는 기존 프로젝트를 망가 뜨리거나 유료 크레아 티 즘염 또는 기타 여러 가지 원인이 발생할 수 있습니다. 그러나 궁극적으로 그것은 "하지 말고 당신을 조이십시오"라고 말합니다. 내 마음에 어느 정도는 그 무언의 계약을 어기는 것입니다.

몇 가지 방법이 있습니다.

• 기능 제안 및 투표. 그러나 이것은 시간이 걸립니다.

• 패치를 만들기 위해 필요한 회사에서 고용하십시오. 분명히 이것이 가장 좋은 솔루션이지만 업그레이드하려는 오픈 소스 소프트웨어를 만드는 사람과 협력 할 준비를하십시오.

• 기능이 처음에 구현되지 않은 이유를 찾는 것도 중요합니다. 종종이 기능은 소프트웨어 프로젝트에서 벗어난 것입니다. 팀은이 기능을 원하지 않거나 필요하다고 느끼지 않거나 무언가를하는 것이 좋은 방법이 아니라고 생각합니다. 이 경우 프로젝트를 포크하여 직접 만들어야합니다.

• 원하는 것을하는 독점 소프트웨어를 사용하십시오.

• OOP 소프트웨어는 종종 기능 통합 프로세스를 용이하게합니다.

• 메일 링리스트, irc 또는 포럼에서 프로그래머를 화나게 할뿐 아니라 OSS 지지자에게 탄약을 줄 것입니다.

것입니다 당신이 말할 수있는 건 아무것도 없다 있도록 그를 그렇게는. 결국, 왜 그는해야합니까? 한 사용자의 소원 때문에? 이유가 충분하지 않습니다.

그러나 합리적인 수의 사용자를 모을 수 있고 합리적인 이유를 제시 할 수 있다면 ( "나는 그것을 원한다"는 합리적인 이유가 아닙니다.) 왜이 기능이 유용한 지, 일반적으로 당신과 다른 사람들에게 유용 할 수 있다면 그는 단지 마음을 바꿀 수 있습니다. .

그러나 고려해야 할 특별한 경우도 있습니다. 그 dev. 앱을 개발하는 데 지쳐서 천천히 포기하고 (다른 일을해야 함), 그는 천천히 기능 요청을 무효화합니다. frm이 그에게 코드를 공개하도록 설득하려고 노력하는 것 외에도이 경우 위의 내용과 관련하여 실제로 할 수있는 일은 없습니다.

특히 오픈 소스 프로젝트는 새로운 기능이 공식 릴리스에 적용되지 않더라도 특정 기능 개발에 대한 바운티 나 자금 지원에 우호적입니다.

또한 오픈 소스 게시의 기본 아이디어 중 하나는 모든 사람이 자신의 공헌을 할 권리와 책임을 갖도록하는 것입니다.

비공개 소스를 사용하면 가장 좋은 리소스는 원하는 솔루션과 같은 솔루션을 원하는 사용자 기반에서 통계적으로 중요한 그룹을 수집하는 것입니다.

내 경험에 따르면이 요청은 일반적으로 사용자 요청이 프로젝트의 목표에 맞지 않으면 제공됩니다. 사람들이 자신에게 제안한 모든 것을 구현할 것이라고 생각할 때 발생합니다. 무료, 오픈 소스 및 위대하고 행복한 미래.

'패치 제출'은 비교적 무례한 반응입니다. 물론 피해야합니다. 특히이 간결하고 예리한 형식에는 거의 같은 메시지를 표현하는 방법이 많이 있습니다. 예를 들어 사용자에게 '초대'를 요청하면 직접 구현할 시간이 없습니다). 그러나 현재로서는 '내 시간을 낭비하지 말라'는 것이 분명하다. 따라서 그것에 대해 할 수있는 일이 많지 않으며 '정식적인'반응도 없습니다.

내가 생각할 수있는 가장 좋은 대답은 실제로 패치를 제시하는 것입니다 . 패치가 작동한다고 가정하면 아이디어가 완전히 비현실적이지 않다는 것이 적어도 입증되었습니다. 일반적으로 이는 프로젝트 담당자가 제안을 다시 고려할 것임을 의미합니다.

"패치 제출"은 프로젝트의 목표에 맞지 않는 아이디어를위한 합법적 인 도구입니다. 장기적으로는 아이디어가 짜증나거나 의도 한 범위를 벗어난 무언가에 프로젝트를 사용하려고 시도하는 것이 더 나을지 모르지만 "이봐 요. 요청한 것이 너무 사소한 것 같다면 왜 그렇지 않습니까?" "기존의 코드베이스에 맞추려고" "언제나 적절합니다.

사소하고 프로젝트의 의도 된 사용자가 실제로 사용하는 경우 버그 보고서를 제출하고 문제를 명확하게 설명하고 재현 단계를 제공하며 현재 야간 빌드를 사용하고 있음을 나타내며 그대로 두십시오.

수많은 사용자에게 도움이되는 사소한 단순한 변화처럼 보일 수있는 것은 실제로 당신 외에는 아무도 사용하지 않을 엉덩이에 큰 고통이 될 수 있습니다. 이것이 "패치 제출"에 대한 가장 좋은 경우입니다.

그의 시스템은 우주, 스펙에 대한 그의 해석은 신의 말씀, 그리고 모든 것이 있다는 것을 한 트랙으로 생각하는 악명 높은 glibc 관리자와 같은 사례를 겪었을 수도 있습니다. 다른 사람들이 얼마나 선호하는지

RentACoder / ELance / etc와 같은 사이트에서 기능을 구현하기위한 프로젝트를 생성하고 원래 오픈 소스 프로젝트 포럼에 게시하는 것이 좋습니다. 저자를 포함한 오픈 소스 프로젝트의 모든 프로그래머는 이제 귀하의 요청을 고려할 재정적 인센티브를 갖습니다.

나는 실제로이 질문에 대답하기 위해 가입했습니다.

레토르트가 필요합니까? 이 응답은 일반적으로 개발자가 문제에 대해 알고 있지만 중요하다고 생각하지 않을 때 사용됩니다.

나는 당신에게 실제적인 예를 줄 것입니다. 우분투는 systray 지원을 중단했지만 (앱을 흰색으로 나열하면 해결할 수 있음) 새로운 앱 표시기를 추가했습니다. jupiter와 같은 일부 응용 프로그램은 systray 지원에 의존하므로 개발자는 app-indicator 지원을 추가하는 대신 workaournd에 대해 알려주므로 개발자에게 app-indicator suppory를 추가하도록 요청했습니다 . 그들이 이것을 구현하지 않기로 선택한 이유를 묻습니다. 이 있었다

libra1ry에 대한 지원을 구축하는 데 시간을 투자하는 데 관심이 없습니다. 돈이 많은 사람이 Linux 배포판에서 제대로 작동 할 수있는 응용 프로그램 기능을 블랙리스트에 표시하여 단순히 요구하기 때문에 절대 사용하지 않을 것입니다.

그것이 진정한 기술적 문제라면, 아마도 조치를 취할 것이지만 이것은 순전히 정치적인 행동이므로 그렇게 생각하지 않습니다.

아니요, 화이트리스트에 추가하겠습니다.

그럴 수 있지. 개발자는 기능을 구현하지 않을 이유가 있지만 패치를 기꺼이 받아들입니다. 이것은 실제로 무례하고 공격적이지 않으므로 레토르트가 필요하지 않았습니다.

결론 : 정식 레토르트는 패치를 제출하는 것이지만 레토르트가 필요없는 경우

원하는 기능에 대한 현상금을 시작하십시오.

또는 마케팅이 귀하의 기대와 맞지 않다는 것을 알게되면 원하는 것을 정확하게하고 지원 담당자를 남용하는 제품을 구입하십시오.

내가 생각할 수있는 가장 좋은 것은 "당신이 빨아"입니다.

죄송하지만이 방법은별로 도움이되지 않지만 사용자가 완전히 망친 불행한 상황 중 하나라고 생각합니다. 개발자의 양심에 대한 잔인한 정직한 호소는 마지막 도랑 노력입니다.

문제를 해결하기 위해 " 기침 "을 제공 할 수는 있지만, 버그 수정으로 인해 수익성이 높아지지 않아야하므로, 이러한 관행이 일반적으로 이루어지면 업계에서 무결성을 완전히 상실하게 될 것이라고 우려합니다. "무료"또는 상용 소프트웨어.