developerWorks에 처음 로그인하면 developerWorks프로파일이 생성됩니다.귀하의 프로파일에서 동의하신 내용이 공개되지만 이 사항은 언제든지 변경 가능합니다. 귀하의 성명(숨김으로 체크되어 있어도 표시됩니다)과 디스플레이 이름은 게시한 컨텐츠나 사이트 엑세스시 표시됩니다.

모든 정보가 안전하게 전송되었습니다.

처음 developerWorks에 로그인할 때 프로파일이 작성되므로, 이를 위해 디스플레이 이름을 선택해야 합니다. 선택하신 디스플레이 이름은 developerWorks에 게시한 컨텐츠에 표시됩니다.

3글자 이상 31글자 이하의 길이로 사용 가능합니다. dW커뮤니티 내에서는 보안상 이메일주소를 제외한 다른 이름을 지정하셔야 합니다.

모든 정보가 안전하게 전송되었습니다.

My developerWorks：

나의 통지：

로그아웃

언어 선택：

오픈 소스의 재조명

오픈 소스 소프트웨어는 더 이상 알파 긱스(기술선도자)만을 위한 것이 아님

Brett McLaughlin, 필자 겸 편집자, O'Reilly Media Inc.

Brett McLaughlin은 로고(작은 삼각형이 기억나는가?) 프로그래밍 언어 시절부터 컴퓨터로 작업을 해왔다. 최근에 McLaughlin은 자바와 XML 공동체를 통틀어 가장 잘 알려진 저자이자 프로그래머 중 한 명이 되었다. McLaughlin는 넥스텔 커뮤니케이션에서 일하며, 복잡한 엔터프라이즈 시스템을 구현하고 있다. 루트리스 테크놀로지에서는 응용 프로그램 서버를 실제로 작성했다. 가장 최근에는 오라일리 미디어에서 집필과 편집을 맡고 있다. McLaughlin이 선보일 책인 Head Rush Ajax는 수상 경력이 풍부하고 창의력으로 뭉친 Head First 시리즈를 Ajax에 접목한 내용이다. McLaughlin이 가장 최근에 쓴 책인 Java 1.5 Tiger: A Developer's Notebook은 최신 자바 기술을 다루는 책이다. McLaughlin이 쓴 고전적인 Java and XML은 자바 언어에서 XML 기술을 활용하는 모범 답안으로 남아있다.

요약： 비용을 절감해야 하지만 당신은 관리자가 아니라 소프트웨어 개발자 또는 고급 사용자이거나 급여를 지급할 수 있을 정도의 수익을 유지해야 하는 누군가일 뿐입니다. 이러한 상황은 오픈 소스 소프트웨어 솔루션을 당신의 환경에 도입하기 위한 이상적인 상황입니다. 이것이 앞으로 3주 동안 makefile을 프로그래밍하거나 작성하는 방법을 배워야 한다는 얘기처럼 들릴 수 있지만 그렇지는 않습니다. 작업 환경에서 오픈 소스를 사용하여 유연하고 유용하게 효율성을 높이는 방법을 살펴봅니다.

여기에 태그 달기!

원문 게재일: 2010 년 4 월 20 일
번역 게재일: 2010 년 6 월 01 일
난이도: 중급
영어로: 보기
PDF: A4 and Letter Get Adobe® Reader®
페이지뷰： 3948 회
의견：

2010년의 오픈 소스

이 기사를 무시하기 전에, 먼저 이 기사는 오픈 소스 연합에 관한 기사가 아니라는 것을 알아둔다. 굳이 말하자면 이 기사에서는 이러한 풍부한 연두교서 접근 방식에 수반되는 미신을 없애려고 한다. 여기서 염두에 두어야 할 것은 오픈 소스는 더 이상 전부 아니면 아무것도 없다는 식으로 선택할 수 없다는 점이다. 달리 말하면 이 기사에서는 Windows®를 버리고 GNU Linux®를 설치하거나 Adobe와 Apple을 저주하라고는 하지 않는다.

이 기사에서는 겸손하게 오픈 소스 소프트웨어가 일부 문제점의 서브세트에 대한 솔루션이며 당신이 가지고 있는 문제점 중 일부가 해당 서브세트에 있을 가능성이 높다는 확인을 심어주려고 노력한다. 따라서 당신이 Internet Explorer®와 관련된 브라우저 문제를 가지고 있거나 적절한 코드 IDE(Integrated Development Environment)를 찾고 있거나 PhotoShop에 비용을 지불하는 데 지쳤거나 단지 실시간에 근접한 지원 시스템을 원하는지에 관계없이 오픈 소스는 소프트웨어 스택의 일부로 적합하다.

하이브리드 접근 방식이 거의 언제나 최상의 방법임

순전히 철학적인 이유로 인해 오픈 소스에 관심을 가지지 않는다고 가정해 보자. 이는 오픈 소스 접근 방식을 이해하지 못하고 있다는 것을 말하려고 하는 것이 아니라 단순히 직면하고 있는 소프트웨어 문제에 대한 대체 솔루션을 찾기 위한 현실적인 관심을 가지고 있다는 것을 말하는 것이다. 당신은 "오픈 소스만" 사용하지는 않을 것이라고 가정한다. 따라서 당신에게는 "클로즈드 소스"인 소프트웨어가 있을 것이다(대다수의 소프트웨어가 클로즈드 소스일 수도 있음). 이는 소프트웨어가 상용이거나 소프트웨어의 소스 코드에 당신이 액세스할 수 없음을 의미한다. 여기에는 아무 문제가 없다. 오픈 소스 소프트웨어와 오픈 소스가 아닌 소프트웨어를 혼합하는 형식이 잘못되었음을 제시하는 내용은 어디에도 없다.

실제로 오픈 소스에 대한 하이브리드 접근 방식은 최적의 옵션이다. 이 접근 방식을 이용하면 현재 환경에서 문제가 되는 부분을 하나 또는 두 가지 찾게 된다. 예를 들어, Windows에서 Internet Explorer가 문제를 일으킨다고 가정해 보자. 이때 Firefox로 전환하면 이것이 바로 오픈 소스에 대한 하이브리드 접근 방식이다. (Firefox는 오픈 소스 소프트웨어를 기반으로 빌드되었다.) Windows와 같은 상용 소프트웨어를 Firefox와 같은 오픈 소스 소프트웨어와 혼용하고 있는 것이다. 당신은 이들 중 하나에 전적으로 의존하지 않고 두 가지 모두를 최대한 활용한다.

오픈 소스 소프트웨어와 오픈 소스가 아닌 소프트웨어 사이의 균형은 전적으로 당신이 결정한다. Firefox 이외의 소프트웨어는 사용하지 않을 수도 있다. 그것으로도 충분하다. 한편으로는 거의 전부 오픈 소스 소프트웨어를 사용하는 Sterling Ball이 주창하는 Ernie Ball 접근 방식(참고자료에서 참조된 CNET에 대한 Ernie Ball의 사례에 대한 링크 참조)으로 마음이 기울 수 있다. 둘 중 하나를 사용하든 둘 사이에 위치한 방식을 사용하든 당신의 필요에 따라 선택하며 그것이 바로 적절한 방식이다.

오픈 소스는 개발자만을 위한 것이 아님

10년 가까이 오픈 소스 프로젝트에 대해 작업해 온 개발자로서 필자는 많은 오픈 소스 커뮤니티가 폐쇄되거나 상업화된 것을 잘 알고 있다. 8개월 전에 누군가가 물어 본 사용자 목록에 대해 질문하면 "아카이브를 확인해 봐, 애송아!"라는 말만 들을 것이다. 기능에 대한 요청을 제출하면 "불평 그만하고 직접 수정해. 그건 오픈 소스야."라는 핀잔만 받을 것이다. 이러한 것들은 오픈 소스에 대한 매우 무례하고 개발자 중심적인 접근 방식이다.

고맙게도 이러한 유형의 성격을 가진 대부분의 프로젝트는 사라졌거나 극적으로 변경되었다. 조금이라도 예의를 갖춘 개발자들은 이러한 행동에 반발하거나 프로젝트를 떠나기까지 했다. 2010년 현재는 대부분의 오픈 소스 프로젝트가 유익한 개발자들이 관리하는 강력한 사용자 목록을 가지고 있을 뿐만 아니라 실제로 Facebook, Twitter 및 LinkedIn을 보조 통신 채널로 통합한다. 버그 추적 시스템은 프로젝트의 일반적인 항목이므로 비난받을 걱정 없이 기능 요청 또는 버그를 제출할 수 있다. 이러한 보고서는 프로젝트를 개선시키기 때문에 실제로 우수한 프로젝트에서는 이러한 보고서를 환영한다.

예를 들어, XML 프로세서 및 변환기인 Xalan-J에는 그림 1과 같이 문제점 처리 방법에 대해 자세하게 설명하는 확장 페이지가 있다.

그림 1. Xalan-J는 문제점 보고 방법에 대해 자세하게 설명하는 잘 구성된 페이지를 제공함
웹 페이지를 통해 쉽게 버그를 제출하는 방법을 보여 주는 스크린샷

지시사항만 제공되는 것이 아니라 언급한 사용자 목록도 제공된다. 이 페이지에서는 당신의 버그 수정을 옹호하지만 Xerces-J는 본래 매우 낮은 수준의 코드 프로젝트라는 점을 알고 있어야 한다. 그럼에도 여기에서는 모든 기능을 갖춘 우수한 버그 보고 API인 JIRA를 사용하여 버그를 제출하는 방법에 대한 정보를 제공한다(그림 2 참조). 즉, 생소한 텍스트 전용 UI와 복잡한 지시사항은 다루지 않는다. 버그 보고 및 기능 요청은 문서화되어 사용자가 쉽게 따라할 수 있다.

그림 2. JIRA는 강력한 버그 보고 기능을 제공하며 이 기능은 사용자가 자유롭게 액세스할 수 있음
JIRA가 알려진 버그와 수정된 버그 모두에 대해 보고하는 방법을 보여 주는 스크린샷

커뮤니티는 유익함

결국 여기서 설명한 유형의 상호작용은 확실하게 커뮤니티라고 부를 수 있는 것이 무엇인지에 대한 의문을 제기한다. 단순히 지원을 요청하거나 버그 보고서를 제출한 후 다시 사용자 목록에 전념할 수 있지만 이것은 전형적인 방식이 아니다. 소프트웨어 프로젝트의 메일 목록에 등록하는 대부분의 사용자는 배회하게 된다. 이들은 동일한 문제 영역에서 작업하고 있거나 다른 영역에서 비슷한 문제에 직면하고 있는 다른 사용자를 찾는다.

단순해 보이고 지나치게 이상적이라고도 할 수 있지만 커뮤니티는 이러한 이메일 목록과 지원 사이트를 구성한다. 당신은 소프트웨어 문제와 관련하여 당신에게 조언을 해 주거나 당신이 조언을 할 수 있는 사람들을 찾을 것이다. 이전에 언급한 Ernie Ball에 대한 기사로 다시 돌아가서, Sterling Ball의 오픈 소스에 대한 경험은 비즈니스를 개선하는 것 이상의 역할을 했다. 비슷한 상황에 있는 다른 사람들에게 매우 현실적인 문제에 대처하고 이러한 문제를 극복하는 방법을 알려주고 싶다는 의지를 가지게 만들엇다. 그 결과 다른 많은 회사에서 Sterling의 솔루션과 Ernie Ball의 솔루션 변형을 사용하려고 하고 있다.

오픈 소스 소프트웨어는 이러한 유형의 공동 이니셔티브를 불러온다. 공개된 이메일 목록의 본질 때문인지 아니면 소프트웨어가 공개된 상태에서 신속하게 발전하는 본성 때문인지 관계없이 상호작용이 촉진된다. 특히 영리 기업 조차도 자신의 이익을 위해 상호작용에 심각하게 반대하지는 않는다. 하지만 오픈 소스 소프트웨어를 사용하는 경우에는 이러한 상호작용이 상호작용을 더 촉진하고 사용자 간 상호작용을 특히 더 촉진한다. 이것이 오픈 소스의 의미 있는 혜택이다.

위로

오픈 소스 소프트웨어는 공개되어 있음

필자는 책, 기사의 섹션 등의 제목을 멋지게 지으려고 하지는 않지만 여기서 꼭 해야할 말은 오픈 소스에서 "오픈"이라는 단어는 중복되거나 중요하지 않은 단어가 아니라는 점이다. 관리자가 있고 회사의 관심사가 있다고 가정해 보면 이 기사의 첫 번째 섹션에서는 자세한 설명을 제공했어야 한다.

하지만 당신이 IBM® developerWorks에서 활동하고 있기 때문에 필자는 당신이 적어도 개발자의 자세를 지니고 있다는 또다른 가정을 한다. 당신은 원하는 만큼 많은 코드를 접하지 않을 수도 있지만 여전히 개발자처럼 생각한다. 이것은 적절한 자세이다. 솔직히 이 부분이 오픈 소스의 장점이 빛을 발하는 부분이기도 하다. 하이브리드 접근 방식와 커뮤니티의 수준을 넘어서면 당신은 좀 더 기술적인 부분에 관심을 가지게 되고 오픈 소스가 이러한 관심의 대부분을 매우 적절하게 충족시킨다.

자체 문서화는 시대에 뒤쳐졌지만 유용함

먼저 안 좋은 소식은 개발자는 코드를 문서화하지 않기로 유명하다는 것이다. 즉, Xalan-J 또는 Firefox나 Sourceforge.net과 관련하여 좋아하는 프로젝트를 자세히 살펴보려고 할 때 항상 매우 적절한 문서를 찾지는 못한다(이러한 모든 프로젝트에 대한 링크는 참고자료 섹션에 있음). "구문 분석기 초기화"와 같은 거의 도움이 되지 않는 레이블이 지정된 initParser()라는 메소드에 대해 들은 적이 있다. 이 메소드는 거의 도움이 되지 않는다.

하지만 프로젝트와 프로젝트의 코드 기반이 성숙할수록 문서화되는 경향이 높다. 수년 동안 다뤄온 JDOM 프로젝트를 살펴보자(참고자료 참조). JDOM은 SAX 또는 DOM보다 더 사용자에게 친숙한 구문 분석을 위한 오픈 소스 API이다. 실제로 NASA와 Sun Microsystems(현재는 Oracle)의 많은 사용자가 JDOM을 사용하고 있다. 여기에는 제대로 문서화된 API도 일정 부분 기여했다. 예를 들어, Listing 1에서는 Element 인터페이스에 있는 하나의 메소드에 대한 코드만 보여 준다.



Listing 1. JDOM 내부 문서의 샘플
  /**  * This protected
                constructor is provided in order to support an Element  * subclass that
                wants full control over variable initialization. It  * intentionally
                leaves all instance variables null, allowing a lightweight  * subclass
                implementation. The subclass is responsible for ensuring all the  * get
                and set methods on Element behave as documented.  * <p>  * When
                implementing an Element subclass which doesn't require full control  *
                over variable initialization, be aware that simply calling super() (or  *
                letting the compiler add the implicit super() call) will not initialize  *
                the instance variables which will cause many of the methods to throw a  *
                NullPointerException. Therefore, the constructor for these subclasses  *
                should call one of the public constructors so variable initialization is
                * handled automatically.  */
 protected Element() { }

개발자에게는 이것이 매우 유용하다. 혼동되지도 않고 이 클래스를 사용하면 훨씬 편리해 진다. 물론 대부분의 언어(Java™ 언어 포함)로 이 유형의 코드 레벨 문서를 더 유용한 항목으로 변환할 수 있다. 그림 3에서는 위의 코드 문서에서 직접 생성된 Element 인터페이스의 JavaDoc을 보여 준다.

그림 3. JavaDoc은 코드 레벨 문서의 시각적 표시임
이 문서는 코드의 주석에서 자동 생성됨

커뮤니티의 규모가 크면 지원 인원의 규모도 큼

코드 레벨 문서라는 아이디어를 구체화한다. 먼저, 개발자가 문서를 작성한다. 그런 다음 프로젝트의 다른 참여자가 해당 코드에 대해 상호작용하고 세분화하거나 원래 개발자가 문서를 세분화하게 한다. 그러면 문서가 개선된다.

그런 다음 사용자가 코드에 대한 상호작용을 시작한다. 이러한 사용자 중 일부는 문제점을 찾아 보고하고 이러한 문제의 수정을 지원하기도 한다. 문서가 증가한다.

사용자 기반이 증가할수록 다른 문제가 발생한다. 이러한 사용자 중 몇몇은 세부사항을 매우 중요하게 여기는 A 유형(필자도 이러한 유형의 사용자 중 한 명임)이 된다. 이러한 사용자는 코드 기반을 자세히 조사하여 문서를 향상시킨다. 본능적으로 이들은 이렇게 할 수 밖에 없다. 따라서 이러한 사용자 중 일부는 코드의 기능을 변경하지는 않더라도 문서는 개선한다.

이 프로세스를 모두 완료하는 동안 사용자 커뮤니티는 지원 커뮤니티가 된다. 증가하는 이해 당사자 그룹에 의해 답변이 채워진다. 이러한 이해 당사자 중 다수는 무료로 봉사하거나 원래 소스 코드 기반과 관계도 없다. 예를 들어, 초보자를 위한 Eclipse 프로젝트의 포럼을 확인해 보자(참고자료 참조). 이 포럼은 오픈 소스 개발 환경이다. 다양한 게시물을 스크롤해 보면 Eclipse.org 이메일이 없는 사용자가 제공한 답변 수와 답변의 상세함에 놀라게 된다. 이들은 몰래 숨어 있는 IBM 직원이 아니다. 당신은 오픈 소스 커뮤니티가 얼마나 빠르게 지원 커뮤니티로 변하는지 확인할 수 있다. 이 소프트웨어는 상용 소프트웨어가 아닌데도 말이다.

실제로 Microsoft에 직접 메일을 보낼 수 있는가?

이 부분은 다소 공격적이라는 것을 인정한다. 하지만 이 문제는 실제로 존재하는 문제이다. 기업의 규모가 커질수록 수준 높은 지원을 받는 것이 어려워진다. Excel® 또는 Mac OS X에 대한 당신의 문제와 관련된 개인적인 이메일을 받을 수 있다고 마지막으로 생각한 적이 언제인가? 종종 그런 일이 발생하기도 하지만 상당 부분 PR에 대한 것이며 이는 일반적인 경우가 아니다. 확실히 지원 컨트랙트를 구매할 수 있지만 문의 전화를 했을 때 누가 응답할 것인지는 주사위를 굴리는 것과 같다.

명확하게 말하면 필자와 당신은 상당한 지원 경험을 얻었다. 필자는 사람들에게 필자가 등록 기간이 만료되어 도움을 제공할 수 없다는 것을 무시하게 했다. 필자는 기간이 만료된지 얼마 되지 않은 시기에는 이메일로 자세한 설명을 제공받았다. 필자는 후속 처리를 위한 전화만 받았을 뿐이다. 영리 회사가 많은 지원을 받을 수 없다는 것을 나타내는 내용은 없다.

추가로 다수의 오픈 소스 소프트웨어 프로젝트에는 프로젝트에 대한 지원을 제공할 수 있을 정도로 성장한 기업이 있다. 이러한 기업을 이용하는 사람도 있지만 이용하지 않는 사람도 있다. 따라서 클로즈드 소스 환경과 마찬가지로 오픈 소스 환경에서도 지원이 "상업적으로" 제공될 수 있다. 고정 관념은 도움이 되지 않으며 당신과 당신의 입장을 공유하는 사용자를 어리석은 사람으로 만들기도 한다.

하지만 여기에 설명된 내용을 살펴보면 더 이상 댓가를 받는 선택된 몇몇 개인만이 지원을 제공할 수 있는 것은 아니다. 코드 문서에서도 지원을 제공한다. 이러한 문서를 읽으면 많은 지식을 얻을 수 있고 많은 경우 자립할 수 있는 수준까지 이른다. 사용자 그룹은 더 큰 지원 커뮤니티를 형성한다. 결국 필자는 FAQ의 내용이 얼마나 충실하고 자세한지에 관계없이 FAQ를 직업적으로 관리하는 사용자보다 더 훌륭한 조언을 제공하기 위해 현재 필자가 가지고 있는 버그를 밤새도록 추적한 사용자에게 더 의지한다.

위로

오픈 소스 소프트웨어는 반복됨

반복은 많은 곳에 사용되는 용어이다. 반복은 소프트웨어 개발에서 특히 눈에 띈다. 오픈 소스 소프트웨어에서 반복이라는 용어는 소프트웨어가 자주 릴리스되는 경향을 언급한다. 사실 조기에 릴리스된 후 자주 릴리스되는 것이 오픈 소스 소프트웨어의 핵심 아이디어이다. 따라서 주요 릴리스 사이에 15개 또는 20개의 릴리스가 있을 수 있다(2.0, 2.1, 2.1.1, 2.1.2, 2.2 등이 있고 최종적으로 3.0이 있음).

상용 소프트웨어가 반복되지 않는다는 것은 아니다. 하지만 이러한 반복은 일반적이고 공통적인 사용자 기반에서 숨겨지는 경우가 많다. 자주 업데이트되지만 Windows 및 Mac OS X와 같은 소프트웨어도 최소화된 창이나 화면의 맨 아래에서 드러나지 않는 슬라이드 인 및 슬라이드 아웃을 사용하여 해당 업데이트를 표시한다. 이유는 무엇인가? 대부분의 상용 소프트웨어에서는 개정을 통해 오류를 정정하기 때문이다. 개정사항이 많을수록 더 많은 오류를 정정해야 한다.

오픈 소스 소프트웨어를 사용하면 그 반대의 경우가 발생한다. 코드가 공개되어 있기 때문에 오류가 있으면 모든 사용자가 해당 오류를 알고 있다. JDOM, Xalan-J, Eclipse 또는 Firefox의 사용자 목록에 등록하기만 하면 된다. 버그는 감춰져 있지 않다. 원하는 프로젝트에 해당하는 JIRA에 로그온하면 해당 오류를 수정하는 빈번한 릴리스와 개정사항을 확인할 수 있다. 숨겨야 할 내용은 없다. 이러한 빈번한 릴리스를 통해 사용자인 당신은 혜택을 받을 수 있다.

기능 요청을 제어하는 것은 당신임

소프트웨어가 자주 릴리스되고 "숨겨진" 실제 버그가 없는 경우에는 지속적으로 발전하는 코드 기반을 가지게 된다. 그 결과 기능 업그레이드가 편리해진다. 이미 한 달에 한 번 이상 릴리스하고 있는 경우 단순히 버그만 수정하지 않고 소프트웨어에 기능을 추가하지 않도록 하려면 어떻게 해야 하는가?

이제 이 내용에 대해 살펴보자. 사용자 커뮤니티는 지원 커뮤니티로서 버그를 찾아서 수정한다. 개발자도 사용자이기 때문에 사용자와 함께 활동한다. 그렇다면 기술 요청은 누가 제어하는가? 어딘가에 있는 관리자가? 이사회에서? 프로젝트 관리자가? 어느 정도 관련되어 있을 수는 있어도 이들 모두 아니다. 바로 당신이 제어한다. 당신이 바로 사용자이고 당신이 바로 주주이다.

결국 빈번한 릴리스는 빈번한 개선을 의미한다. 버그 수정은 개선사항이기도 하고 기능 업그레이드이기도 하다. 개발은 공개되어 있기 때문에 당신은 많은 영향을 미칠 수 있다. 필자가 공동으로 작성했고 오랫동안 활동한 JDOM에서는 대부분의 주요 소프트웨어 변경이 사용자의 요청에 대한 응답으로서 수행되었다. 더욱 인터페이스 중심적인 지원을 제공하는 버전으로의 이동은 프로젝트와 "공식적인" 관계가 없는 사용자가 이끌었다. 이러한 사용자는 단순히 참여하기만 했다. Eclipse는 주로 코드 기반의 새로운 사용자를 생각하는 똑똑한 프로그래머에 의해 좌지우지된다.

오픈 소스 소프트웨어는 당신에게 맞춰짐

결국 오픈 소스 소프트웨어를 오랫동안 사용해 온 사용자들이 해당 소프트웨어를 그들의 필요에 맞추는 원동력이다. 당신은 나서지도 않고 메일 목록에 참여한 적도 없었고 품질을 유일한 기준으로 생각한다. 이것이 Ernie Ball에게 많은 의욕을 불러 일으켰다. 한편으로 당신의 참여는 소프트웨어에 대한 제어를 확보하는 것을 의미한다. 이 기능은 당신이 의견을 교환하도록 요청하며 당신은 자체 기능을 추가할 수도 있다.

동시에 당신은 자신을 소프트웨어에 맞추고 있다. 이것은 잘못된 것이 아니다. 빈번한 사용과 오픈 소스가 제공하는 코드 기반에 대한 이해를 통해 소프트웨어가 가장 잘 수행하는 사항에 당신의 작업 방식을 맞출 수 있다. 소프트웨어의 내부 작업에 대한 지식이 증가(사용자 목록에 참여하고 코드를 지원하면 자연적으로 증가됨)할수록 소프트웨어의 사용을 최적화하는 의사결정을 내린다는 것을 알게 된다. 당신은 장점이 무엇이고 장점이 제대로 수행되는 위치가 어디며 문제가 있는 위치가 어디인지 알고 있다. 결과적으로는 해당 지식을 활용하여 더 나은 결과를 가져온다.

위로

결론

오늘날 오픈 소스에 대한 대부분의 기사는 종교적인 공허한 외침이거나 기껏해야 실용성에 중점을 둔 기사들이지만 그 내면에는 아직도 열정이 남아 있다. 수년 동안 오픈 소스 옹호자들은 철학적인 논쟁을 통해 자신의 주장을 뒷받침해 왔다. 옹호자들은 사용자보다 전향자를 원하는 것 같다. 이것은 개발자가 아닌 사용자뿐만 아니라 오픈 소스에 신경을 쓸 여유가 없는 다수의 프로그래머에게도 중대한 갈림길이다.

하지만 이러한 모호성이 오픈 소스 소프트웨어의 진정한 장점이다. "대부분의 경우에는 오픈 소스를 사용하지 말라!"고 하기 보다는 좀 더 부드럽게 말하자면 오픈 소스 소프트웨어를 사용하면 비용을 절감하여 기능을 개선할 수 있는 경우도 있다. 언급했듯이 Firefox는 대부분의 일반 사용자에게 가장 눈에 띄는 예이다. 오픈 소스 아젠다를 가지고 있기 때문에 Firefox를 설치하는 사용자는 거의 없다. Firefox는 다른 모든 브라우저보다 많은 플러그인이 결합되어 있는 매우 유용한 브라우저이다. 왜냐고? 왜냐하면 이 소프트웨어는 활동적이고 활기가 넘치는 커뮤니티의 지원을 받기 때문이다.

하이브리드 환경에서 오픈 소스 소프트웨어를 고려할 때 가장 좋은 논거는 IBM 자체에 있다. (알다시피 이 기사는 IBM 사이트에 게재된다. 하지만 그 내용은 진실이다.) IBM은 상용 오퍼링의 수지를 맞추려고 애쓰고 있고 기부에서 Apache, Eclipse 등에 이르기까지 상당한 오픈 소스 소프트웨어 목록을 여전히 가지고 있다. 해당되는 경우에는 오픈 소스를 사용하는 이 접근 방식을 추천한다.

Gimp를 좋아하지 않을 수 있고 PhotoShop이 가장 확실한 방법일 수 있다. 데스크탑과 iPhone에서 Safari를 통해 동기화된 책갈피가 실제로 최적의 솔루션일 수 있다. 그것으로도 충분하다. 단기적인 시각으로 분개하여 오픈 소스 소프트웨어의 다른 모든 부분을 내버리지만 않으면 된다. (이 문장은 설명하는 조치만큼이나 과도하게 극적인 것처럼 보인다.) 빠른 업그레이드 주기와 최신 기능이 필요한 경우에는 오픈 소스 대체 소프트웨어를 찾아라. 1년에 수십 만 달러의 비용을 지출하지 않고 지원을 받아야 하는 경우에는 특정 영역에서 오픈 소스가 제공하는 사항을 확인하라. 그리고 어떤 경우든 통지를 수신하라. 좋은 정보를 바탕으로 좋은 선택을 하라. 그러면 모두가 만족할 것이다. 그리고 어떤 오픈 소스 오퍼링을 선택(및 거절)했는지와 그 이유를 우리에게 알려라. 온라인에서 만나자.

참고자료

교육

상용에서 오픈 소스로 전환된 가장 유명한 사례 중 하나는 Ernie Ball(CNET.com)의 사례이다.
Eclipse 포럼에서 활동 중인 오픈 소스 커뮤니티를 살펴보자.
developerWorks 팟캐스트에서 소프트웨어 개발자의 흥미로운 인터뷰와 토론을 확인할 수 있다.
developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
Twitter의 developerWorks 페이지를 살펴보자.
IBM 오픈 소스 개발자에게 유익한 컨퍼런스, 기술 박람회, 웹 캐스트 및 기타 행사를 확인하고 참여하자.
오픈 소스 기술을 활용하여 개발 작업을 수행하고 이러한 기술을 IBM 제품과 함께 사용하는 데 도움이 되는 사용법 정보, 도구 및 프로젝트 업데이트와 IBM에서 가장 인기있는 기사 및 튜토리얼을 developerWorks 오픈 소스 영역에서 확인할 수 있다.
My developerWorks 커뮤니티는 다양한 주제를 다루는 일반적인 커뮤니티로 성공적으로 운영되고 있다.
무료로 제공되는 developerWorks On demand demos를 통해 IBM 및 오픈 소스 기술에 대해 배우고 제품 기능을 익히자.

제품 및 기술 얻기

Eclipse는 우수한 IDE 중 하나이며 확장 가능한 플러그인 아키텍처를 가지고 있다. 무엇보다도 Eclipse는 완전히 오픈 소스이다.
Xalan-J는 모든 오픈 소스 구문 분석기와 도구를 기반으로 빌드된 오픈 소스 XML 프로세서이다.
JDOM은 기존의 API에 대한 실망으로 인해 빌드된 오픈 소스 구문 분석기 API이다. 그 자체로 대부분 오픈 소스이며 손상되어 있기 때문에 수정된다.
가장 뛰어난 웹 브라우저이며 신뢰할 수 있는 오픈 소스 소프트웨어를 확인하는 최적의 시작점인 Mozilla Firefox를 살펴보자.
DVD로 제공되거나 다운로드할 수 있는 IBM 시험판 소프트웨어를 사용하여 후속 오픈 소스 개발 프로젝트를 구현해 보자.
IBM 제품 평가판을 다운로드하거나 IBM SOA Sandbox의 온라인 시험판을 살펴보고 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere®.