현재 위치

홈 ›› Forums ›› 이슈 ›› 토론, 토의

오픈소스의 소스 변경 기준

hwiorb의 이미지
글쓴이: hwiorb / 작성시간: 토, 2012/04/28 - 12:50오전

1. Patch는 소스의 수정이 프로그램의 철학을 바꾸지 않는 것.
2. Fork하는 것은 소스의 수정이 프로그램의 철학이 바뀐 것.
(제 개인적인 단어 의미 정의 입니다. 맞는지 모르겠군요)

소스의 기능의 추가를 위해서는 기존 소스의 내부 변경이 불가피한 상황이 있습니다.
어떤 프로그램이 마음에 들어, 재미삼아 소스 수정을 하는 중인데,
필요한 기능이 프로그램의 중요 부분을 걷어내고 다시 짜야 (할지도 모르게) 되는 경우...
실제론 필요 없는 걱정일지도 모르겠습니다만, 어떻게 (선택) 해야 할지 모르겠습니다.

오픈 소스이기 때문에, 주류 소스에 반영될것을 경우를 감안해서
(힘들어도) 최대한 기존 소스의 변경없이 구현하며 가는데 좋은걸까요(-> Patch)
기존 소스를 최대한 수정해서 필요한 기능을 구현하는게 보다 나은걸까요(-> Fork)

회사에서 쓰는 거라면야, 마음가는대로 효과적인 쪽으로 짜면 그만이지만,
과연 오픈 소스쪽에서는 어떻게 해야 되는 것인지 개인적으로 생각이 정리가 되었으면 해서
여러분의 의견과 선택의 기준을 듣고 싶습니다.

Forums: 
토론, 토의
Stand Alone Complex의 이미지

글쓴이: Stand Alone Complex / 작성시간: 토, 2012/04/28 - 1:19오전

자신의 수정 방향이 해당 오픈 소스 프로젝트의 목표와 같은 방향이라면 수정된 사항을 Patch 형태로 제작 후 해당 프로젝트 개발자에게 제공하는 것이 가장 좋은 선택이라고 생각합니다.
개발자가 Patch를 받아주지 않거나, 목표가 매우 다르거나 하는 심각한 문제가 없는 한 될 수 있으면 Fork 하는 것은 말리고 싶습니다.

RET ;My life :P

hwiorb의 이미지

글쓴이: hwiorb / 작성시간: 수, 2012/05/02 - 3:03오후

네, 개인적으로도 Fork는 할 생각이 없습니다.
그런데, "Patch의 범주를 넘어설때가 있는 것 같아서"가 문제가 되서 그렇죠.

예를 들자면,

1. 어떤 기능을 추가하려고 보니, 의존성으로 인하여 기존 소스를 다 뜯어고쳐야 함.
 
2. 이것 저것 추가/변경하다보니 기존 소스의 외형을 찾아보기 힘듦.

1번의 예는 특수한 경우입니다. 겉에서는 하나의 기능이지만,
실제로 추가되고 염두되어야 할것이 여럿이라서, 2번의 형태로
발전하게 되는 경우입니다.

이것 저것 생각해본바, 항상 괜찮은 선택은 Patch로 국한되어지는것 같습니다.

ps. 커미터가 아니기 때문에(그래서 Patch가 주기적으로 반영될수 없죠), 이것 저것 나름대로
수정해버린 프로그램의 패치가 추후에 받아들여질지가 나름대로 또 의문입니다 :)

nil.

둘러보기