오픈소스 소프트웨어는 인공지능(AI), 사물인터넷(IoT), 클라우드 빅데이터 등 다양한 분야에서 4차 산업혁명과 지능정보사회의 핵심 기술로 부상하고 있습니다. 글로벌 시장에서는 구글, 페이스북 같은 글로벌 대기업도 개방형 혁신활동을 중요하게 여기며 이를 위하여 자사의 기술을 외부에 공개하고 오픈소스 커뮤니티를 중심으로 핵심기술을 주도하려는 노력을 하고 있습니다.

전통적으로 기술혁신은 자체적인 우수 인적자원의 확보 및 효율적 내부자원의 활용을 중심으로 조직 내부의 연구개발을 통해 이루어져 왔습니다. 이러한 방식은 아이디어의 발굴에서 기초연구, 제품개발, 사업화에 이르는 모든 기술혁신의 과정을 기업 내부에서 독자적으로 수행하는 것을 의미합니다. 

그러나 기술의 복잡성이 증대하고 제품 수요가 다양해지고 시장경제의 글로벌화가 가속되며 기술혁신의 비용은 급증하는 상황을 맞이하여 조직의 연구개발 생산성을 제고하기 위해 기술혁신 과정에서 외부와 협력하는 현상이 확대되고 있는데 UC버클리 대학의 Chesbrough 교수가 주창한 개방형 혁신(open innovation) 이론에 따르면 개방형 혁신의 개념을 다음과 같이 요약하고 있습니다.

“개방형 혁신은 기업이 안으로의 지식 흐름(inflow)과 밖으로의 지식 흐름(outflow)을 적절히 활용하여 내부의 혁신을 가속화하고 혁신의 외부 활용 시장을 확대하는 것이다. 개방형 혁신은 기업들이 내부 아이디어뿐 아니라 외부 아이디어도 활용할 수 있고, 또 활용해야 하며, 자사의 기술을 상업화하여 시장에 진출할 때 내부뿐 아니라 외부 경로도 사용할 수 있고, 또 사용해야 함을 전제하는 혁신 패러다임이다. 개방형 혁신과정은 내부와 외부 아이디어를 결합하여 아키텍처와 시스템을 구현한다. 이 아키텍처와 시스템에 대한 요구 사항은 비즈니스 모델을 통해 정의된다. 비즈니스 모델은 내부와 외부 아이디어를 활용하여 가치를 창출하고 그 창출된 가치의 일부를 자사의 몫으로 전유하기 위한 내부 메커니즘을 정의한다. 개방형 혁신은 부가가치를 창출하기 위해 내부 아이디어가 외부 경로, 즉 기업의 기존 비즈니스 모델 밖에 있는 채널을 통해 시장으로 나갈 수 있음을 전제한다 (Chesbrough 2006b: 1)” 

이론에 따르면 개방형 혁신은 연구, 개발, 상업화에 이르는 일련의 기술혁신 과정에서 조직 내부와 외부 사이에 일어나는 모든 형태의 지식 교류 활동을 의미하며, 집단 지성을 활용한 지속적인 개선과 사용자 피드백을 반영한 기술혁신이 이루어지는 오픈소스 커뮤니티는 개방형 혁신 활동의 대표적인 예로 볼 수 있습니다.

우리나라도 최근 이런 흐름을 반영해서 전통적인 연구개발을 오픈소스 개발방식으로 진행하려는 오픈R&D에 대한 학교와 기업의 흐름이 증가하고 있죠. 

저는 리눅스 커뮤니티 하모니카(http://hamonikr.org)를 운영하고 있는데 최근에 활발하게 커뮤니티가 성장하고 있으며 현재 하모니카 커뮤니티는 월평균 만명정도의 방문자가 있습니다. [참고] 웹로그 분석 : http://hamonikr.org/board_aMBI05/49687

때문에 저 자신도 오픈소스 커뮤니티 운영에 고민이 있고 그러다 보니 오픈소스 커뮤니티의 구축과 운영을 어떻게 하면 좋을지에 대한 현장의 고민을 자주 듣습니다. 

오늘은 오픈소스 커뮤니티를 구축하고 운영하는데 무엇이 필요할지 정리해 보겠습니다.


오픈소스 커뮤니티 현황 

오픈소스 커뮤니티[5]란 누구에게나 프로그램의 소스코드에 대한 동등한 접근을 보장하고 책임과 권한을 공유하며 지속적인 개발자와 사용자의 기여에 의해서 프로젝트가 변하는 커뮤니티를 의미하며, 오픈소스 커뮤니티를 기반으로 형성되는 소프트웨어 개발 모델은 소프트웨어 릴리스를 위한 활동을 중심으로 형성되는 개발자 커뮤니티와 공개된 소프트웨어에 대한 테스트, 버그 제출, 의견 제시 등을 중심으로 형성되는 사용자 커뮤니티가 존재합니다.


그림 1 Open Source Development Model


정보통신산업진흥원의 최근 조사 자료에 의하면 전 세계 대표적인 오픈소스 소프트웨어의 소스코드 저장소인 깃허브(Github)에서는 약 38만 건의 프로젝트 개발이 활발히 진행 중이며, 약 2,000만 명이 약 16만 개의 오픈소스 커뮤니티에서 소프트웨어 개발 및 프로젝트 기여를 위해 사용자․개발자로 참여하고 있다고 합니다. 이에 비해 국내의 경우 총 248개의 오픈소스 커뮤니티가 운영중인 것으로 파악되어 글로벌 대비 0.1% 수준의 규모이며 그 중에서도 사용자 커뮤니티 214개(86%), 개발자 커뮤니티 34 개(14%)로 국내 오픈소스 커뮤니티의 다수는 오픈소스의 사용자 커뮤니티로 조사되었습니다. 


조사 결과에 따르면 해외에서는 여러 재단을 중심으로 커뮤니티에서 오픈소스 프로젝트의 개발 참여와 기여가 활발하지만 국내에서는 개발에 참여보다는 오픈소스 커뮤니티가 제공하는 결과물을 활용하거나 사용법을 묻는 것이 대부분으로 나타났으며 또한 국내 오픈소스 커뮤니티 중 해외 오픈소스 커뮤니티와 프로젝트를 공유하거나 국제 행사 참가를 통해 교류중인 커뮤니티는 14개로 파악되었습니다. 국내의 오픈소스 생태계는 생산자 관점의 오픈소스 커뮤니티 활용이 매우 저조한 실정임을 알 수 있습니다. 따라서 향후 국내 기업의 오픈소스 커뮤니티 기반 개방형 혁신을 확산하기 위해서는 현재의 사용자 커뮤니티 중심의 국내 오픈소스 커뮤니티를 글로벌 개발자 커뮤니티와 상호 협력할 수 있도록 지원하는 노력이 필요하다고 생각합니다.


오픈소스 커뮤니티의 구축 


직접 오픈소스 커뮤니티를 구축하기 전에 먼저 원하는 공개하려는 소프트웨어와 유사한 관심사에 대한 커뮤니티가 국내·외에 이미 존재하는지 검색하는 것이 중요합니다. 

만약 동일한 관심사의 커뮤니티가 이미 존재하는데 새로운 커뮤니티를 형성하려고 하면 참여자들의 커뮤니티의 신규 생성에 대한 당위성을 설득하기 어려우며 기존의 다른 오픈소스 커뮤니티의 지지를 얻기 힘들기 때문입니다. 따라서 만약 유사한 관심사를 다루는 오픈소스 커뮤니티가 이미 존재한다면 별도의 커뮤니티를 생성하여 새로운 기반을 형성하는 것 보다는 해당 커뮤니티에 참여하여 협업하는 것이 가장 좋습니다.

이 경우에는 이미 오픈소스 커뮤니티 활성화의 기반이 존재하기 때문에 공개하려는 소프트웨어를 해당 커뮤니티의 사용자들이 사용할 수 있도록 해당 기능을 추가로 제안하여 기존 공개된 소프트웨어의 기능을 강화하는  방식의 접근이 필요합니다.

기존의 커뮤니티 중 공개하려는 소프트웨어와 유사한 관심사를 가진 커뮤니티가 없는 경우 새로운 오픈소스 커뮤니티는 생성하게 되는데, 이렇게 생성되는 오픈소스 커뮤니티의 성장 단계는 Tech-nical Stage, Open Source Stage, Ecosystem Stage의 세 가지 단계로 구분할 수 있습니다.


그림 2 오픈소스 커뮤니티 성장단계


Technical Stage

Technical Stage는 오픈소스 커뮤니티의 참여자들 중 개발자들 보다는 사용자들을 대상으로 공개한 소프트웨어의 바른 사용 방법과 권한을 제공하는 것에 중점을 두는 단계이며 이 단계에서는 공개한 소프트웨어의 라이선스를 컴포넌트 별로 식별한 소프트웨어 라이선스 프레임워크를 통해 프로젝트의 라이선스 정책을 사용자들에게 배포하고 공개한 소프트웨어의 기능을 확인할 수 있는 프로그램 데모를 제공하는 것이 필요합니다. 프로젝트를 소개할 수 있는 웹사이트, 제공하는 소스코드를 다운로드 할 수 있는 공개된 저장소, 의사 소통을 위한 메일링 리스트와 커뮤니케이션 채널, 프로그램의 버그를 추적관리 할 수 있는 버그 트래킹 도구, 각종 문서를 쉽게 작성해 공유할 수 있는 문서화 도구 등이 필요하게 되며 사용자들이 공개된 소프트웨어를 활용할 수 있는 범위와 사용에 따르는 책임을 명확하게 인지할 수 있도록 준비해야 합니다.


Open Source Stage

Open Source Stage는 오픈소스 커뮤니티에 참여하는 사용자와 개발자를 대상으로 잘 구성된 오픈소스 커뮤니티 거버넌스 모델을 구축하는 데 중점을 두는 단계이며 이 단계에서는 커뮤니티 참여자들에게 프로젝트의 구조를 쉽게 설명하는 문서를 준비하고, 프로젝트의 로드맵을 제시하게 됩니다. 또한 커뮤니티 참여자가 어떻게 참여할 수 있는지를 개발자와 사용자로 구분하여 자세히 알려주고, 커뮤니티 내 분쟁이 일어나거나 의사결정이 필요할 때 어떤 방식의 의사결정과정을 따르게 되는지를 투명하게 공개해야 합니다.

오픈소스 커뮤니티의 전략적 방향에 따라 수많은 유형의 거버넌스 문서가 필요할 수 있으나 일반적인 오픈소스 커뮤니티 거버넌스 문서에 포함되어야 하는 공통적인 요소는 다음과 같습니다.

    • 개요 (overview)

    • 역할과 책임 (roles and responsibili-ties)

    • 지원 (support)

    • 기여 과정 (contribution process)

    • 의사결정 과정 (decision making pro-cess)


Open Source Stage 단계에서는 커뮤니티 참여자들의 역할과 책임에 따른 운영 조직이 구성되고 커뮤니티 운영 조직과 커뮤니티 참여자 간 투명한 합의를 기반으로 커뮤니티 운영이 이루어져야 합니다. 이를 위해서 프로젝트 마일스톤과 릴리스를 관리할 수 있는 프로젝트 관리도구, 개발자 및 사용자를 위한 포럼, 이슈관리, 자동화 빌드, 소프트웨어 품질 가시화, 문서 협업 도구 등이 필요하며 외부의 참여자들이 프로젝트에 어떻게 기여할 수 있는지 자세히 안내하는 문서를 준비하고, 커뮤니티의 참여자들과 지속적으로 소통을 유지하는 것이 중요합니다 


Ecosystem Stage

공개한 소프트웨어의 사용자의 수가 늘어나고 오픈소스 커뮤니티가 성장하면서 커뮤니티 참여자들에 의한 사용자 지원으로는 기업 사용자들이 요구하는 서비스 수준을 제공하지 못하는 문제가 발생하게 되는데 Ecosystem Stage는 오픈소스 커뮤니티의 확산과 지속가능성을 보장하기 위하여 공개한 소프트웨어를 이용하여 비즈니스에 활용하는 기업 멤버들과 다른 오픈소스 커뮤니티와 함께 상생협력을 중점으로 운영하는 단계입니다. 따라서 이 단계에서는 프로젝트를 지원할 수 있는 기업들로 구성된 비즈니스 협의체가 조직되고 공식 기술지원 파트너 기업이 커뮤니티에서 홍보되어 기업에서 공개된 소프트웨어를 사용하기 위한 신뢰성을 제공할 수 있도록 커뮤니티에 참여하는 기업들을 중심으로 긴밀한 관리가 필요합니다.

이클립스 재단의 경우 다음과 같이 사용하는 프로젝트의 파트너 기업들이 제공하는 제품을 소개하는 마켓플레이스를 직접 운영하며, 활용 사례를 소개하고, 공식적인 기술지원이 가능함을 홍보하여 프로젝트의 신뢰성을 확보하고 있습니다.


그림 3 Eclipse Foundation Marketplace


이처럼 오픈소스 커뮤니티가 원활한 지속적 운영을 보장하기 위해서는 공개한 소프트웨어를 기반으로 기술지원을 제공하는 파트너 기업을 발굴하고 기업 멤버를 커뮤니티에 흡수하여 커뮤니티의 발전방향이 커뮤니티 참여 기업의 비즈니스 전략에 영향을 미치는 관계가 형성되어야 자연스럽게 커뮤니티 지속을 위한 재원 확보가 이루어지고 향후 공개한 오픈소스 프로젝트를 중심으로 성공한 재단의 형태로 성장하는 것을 기대할 수 있습니다.


오픈소스 커뮤니티의 운영 


오픈소스 소프트웨어 프로젝트 및 커뮤니티 운영이 성공하기 위하여 가장 중요한 요소는 투명성과 문서화를 꼽을 수 있습니다. 

투명성은 프로젝트 관련하여 참여하는 사람들과 외부 참여자들에 대한 프로젝트 관련 도메인 및 기능을 어떻게 유지할 것 인가에 대한 명시를 의미하는데 오픈소스 소프트웨어의 특성상 투명성의 유지는 대단히 중요할 뿐 만 아니라, 기업에 의해서 주도되는 오픈소스 소프트웨어라면 투명성의 확보는 해당 오픈소스 소프트웨어 커뮤니티의 운명을 쥐고 있는 열쇠라고 해도 과언이 아닙니다. 

어떤 오픈소스 소프트웨어 개발자들도 보이지 않는 장막 뒤에서 펼쳐지는 오픈소스 소프트웨어에 참여하고 싶은 사람은 없으며 특히 기업이 오픈소스 소프트웨어 전환을 시도할 경우, 그 동안 기업 내부의 습관에 의해 투명성을 소홀히 하고 내부 프로세스를 공개하지 않는 경우가 있는데, 그런 경우 커뮤니티를 활성화하기란 매우 어려우며 오픈소스 소프트웨어 커뮤니티로의 전환의 실패로 이어질 확률 또한 매우 높습니다.

오픈소스 커뮤니티에 투명성이 필요한 요소는 공개한 소프트웨어의 비전, 로드맵, 릴리스 계획, 형상관리 계획, 커미터 자격 조건, 새 기능 추가 또는 소프트웨어 패치의 제출 과정 등이 대상입니다. 

오픈소스 커뮤니티 운영의 다른 한가지 중요한 요소는 문서화입니다. 실제로 오픈소스 소프트웨어는 자발적으로 참여하는 사람들이고 개발자 위주로 돌아가는 생태계이기 때문에, 문서화에 소홀하게 되는 경우가 많습니다. 

커뮤니티의 운영을 위해서 공개한 소프트웨어 자체에 대한 문서화와 오픈소스 커뮤니티의 구조 및 프로세스에 대한 문서화도 포함하여 작성해야 합니다. 문서를 통해서 커뮤니티 거버넌스 모델 명시, 커뮤니티 구조 및 프로세스 명시뿐만 아니라, 해당 소스코드에 대한 문서화도 명확하게 해두어야 많은 사람들이 참여하여 오픈소스 소프트웨어 커뮤니티를 활성화 시키게 되기 때문에 커뮤니티에 참여하는 개발자 및 사용자들이 쉽게 이해하고 도움을 받을 수 있으며, 참여자들이 쉽게 편집할 수 있는 수준의 문서화를 제공하는 노력이 중요합니다.


마치며


해외의 경우 Apache, Eclipse, Openstack, Linux 등 다양한 오픈소스 재단이 설립되어 클라우드, 빅데이터, 인공지능 등 분야에서 핵심 기술을 주도하고 있는데 비해 국내에서는 공개된 소프트웨어를 가져다 쓰는 사용자 커뮤니티를 중심으로 오픈소스 커뮤니티가 형성되어 있으며 글로벌에 영향력이 있는 개발자 커뮤니티는 찾아보기 힘든 실정입니다.

최근 우리 정부는 국가의 ICT R&D 경쟁력 강화를 위한 지속적인 정책적 노력과 집중 투자에도 불구하고, 창의적․선도적 혁신역량 제고와 성과확산에 한계를 인식하고 개방형 혁신의 장점을 반영한 핵심 원천기술의 오픈R&D를 추진하여 미래 유망기술을 글로벌 시장에서 선도하고 연구개발 결과물의 활용도를 제고하기 위하여 노력하고 있으나 외부의 참여자들과 협력하는 오픈소스 커뮤니티 기반의 개방형 혁신에 익숙하지 않은 연구기관들은 체계적인 관리모델의 부재로 인한 혼란이 가중되고 있습니다. 

오픈소스 커뮤니티를 중심으로 세계시장 기술 경쟁력 기반확보를 위해서 정부에서는 오픈소스 생태계를 이해하고 소프트웨어 기술 연구개발을 오픈소스 프로젝트를 방식으로 전환하고 오픈소스 커뮤니티를 통한 사용자 저변이 확산될 수 있도록 지속적인 노력을 기울여야 하며 기업의 경우 오픈소스 커뮤니티에 참여하는 내부 개발자에 대하여 비판적인 시각에서 벗어나 글로벌 오픈소스 프로젝트의 참여와 기여는 기업의 우수한 기술력을 홍보하는 효과적 수단임을 인식하고 내부 개발자의 오픈소스 커뮤니티 참여 활동을 적극 권장하고 기업의 비즈니스 전략에 오픈소스 커뮤니티와 연계한 개방형 혁신을 위한 노력이 필요합니다.


참고문헌

  • 김석관 : Chesbrough의 개방형 혁신 이론. 과학기술정책, 2008 

  • OW2 : open source software the governance makes the difference. https://www.slideshare.net/OW2/open-source-software-the-governance-makes-the-difference, 2015

  • 조재홍 : 공개SW 소비국을 넘어 기여국으로 성장을 위한 제언. NIPA, 2018









최근 국가연구개발사업이 오픈R&D 형식으로 전환되는 움직임이 많아지면서 기존의 연구개발방식을 수행하던 사람들이 여러가지 질문을 하는데 그 중 자주 묻는 질문이 "오픈R&D를 하면 특허는 어떻게 하나요"라는 질문이다.

이 질문에 대한 결론부터 말하자면 "오픈소스로 배포하는 기술이라도 특허는 등록할 수 있다"이다.

이에 관련하여 공개SW역량프라자에서 얼마전 배포한 오픈소스 라이선스 해설서를 보면 다음과 같이 설명하고 있다.


우선 오픈소스 소프트웨어 진영에서는 모든 프로그램을 자유롭게 사용할 수 있도록 한다는 철학이기 때문에 특허를 반기지 않는다. 많은 오픈소스 커뮤니티는 소프트웨어의 일부 아이디어를 해당 특허로 등록한 후 특허 소송에 관여 시켜 소프트웨어 사용을 막아 수익을 올리려 하거나, 오픈소스 소프트웨어 개발을 법적으로 금하게 하는 특허, 오픈소스 개발자의 오픈소스 원칙을 약화 시키는 특허 등록에 대해서 걱정한다.

그러나 소프트웨어 특허에 대항하려는 오픈소스 소프트웨어 커뮤니티의 시도와 관계없이 소프트웨어 특허법은 존재하는 것이 현실이며 법을 준수하려면 특허 제약사항을 알고 대응해야 한다. 오픈소스 라이선스들은 이 필요성을 인식하고 존중하는 입장이며 오픈소스 라이선스들의 전문에는 특허조항이 권한부여 또는 권한취소에 대하여 여러 문장으로 표현되어 있다.

• 권한부여 라이선스(granting license)의 문맥에는 소프트웨어 일부분에 기여하고 배포하는 행위는 기여자, 배포자의 모든 특허가 전체 소프트웨어(다소 깊게 내포된 라이브러리를 포함) 사용에 필요한 “주어진 자유”라는 상황을 불명확하게 유발한다는 점을 고려해야 한다는 내용이 있다. 따라서 특허 포트폴리오의 핵심 특허 일부가 특허조항에 의해 피해를 받는지, 그리고 이에 따라 해당 오픈소스 소프트웨어 일부를 사용 또는 배포하지 말아야 하는지를 점검하고 싶다면 삽입된 라이브러리 역시 반드시 점검해야 한다.

• 권한부여 라이선스의 문맥에는 특허조항에 근거하여 ‘배포된 소프트웨어를 사용 가능하게 하기 위한 사용을 허용한다.’는 취지로 특허 사용만 허가되는지를 고려해야 한다. 특허조항은 일반적으로 특허를 양도하지 않는다. 이 때문에 오픈소스 소프트웨어에 의해 (고의적이지 않은) 특허 양도의 위협이 크지 않을 때(특허의 사용이 단지 소프트웨어의 결합에서만 부여되는 경우)도 있다. 특허 사용은 소프트웨어와 결합될 때만 권한이 주어진다. 한편 오픈소스 소프트웨어가 대규모의 프로세스에 내포 여부에 상관없이 오픈소스 소프트웨어를 사용하기 위해서는 특허 사용이 필요하기 때문에, 특허 사용 권한을 얻지 못하고는 오픈소스 소프트웨어를 사용하지 못할 수 있다. 반면 오픈소스 라이선스에 근거하여 허가된 오픈소스 소프트웨어가 없이 오픈소스 라이선스의 특허조항에 의해 양도된 특허를 사용할 수는 없다. 그 이유는 특허조항만이 오픈소스 소프트웨어 사용가능 여부를 나타내기 때문이다.

• 권한취소 라이선스에 의한 취소 형태는 어떤 경우에는 소프트웨어 사용 취소를, 또 어떤 경우에는 특허 사용 취소를 나타내는 것인지를 언급해야 한다. 그러나 자비로운 오픈소스 소프트웨어 사용자의 실용적 관점에서 볼 때 두 번째 경우의 특허 취소는 암묵적으로 소프트웨어 사용 권한을 해지한다고 판단할 수 있다. 특허 사용이 소프트웨어의 일부분을 법적으로 사용하기 위해 필요하다면 역시 특허 사용 권한을 갖지 않고 소프트웨어 사용이 허용될 수는 없다(그리고 특허 사용이 소프트웨어를 사용하는데 필요하지 않다면 이 특허는 특허조항이 적용되지 않는다). 따라서 이 유형의 특허조항은 소프트웨어 사용/배포 또는 수정하는 권한을 해지하는 것으로 보인다. 이런 이유로, 기업 또는 조직뿐만 아니라 단일 사용자들은 오픈소스 소프트웨어를 확실히 법률을 준수하면서 사용하고자 한다면 그런 특허조항을 중시해야 한다.

• 따라서 오픈소스 기여자와 배포자는 오픈소스 라이선스를 허가하는 것이 법적으로 소프트웨어를 사용하는데 필요한 모든 권한을 명시하지 않으면서도 저절로 허가하고 있는지, 권한취소 라이선스의 경우, 특허조항에 금지로 이해될 수 있는 부정적 조건이 있는지 고려해야 한다. 



4차산업혁명이라는 단어가 정치, 마케팅, 기술 등 분야를 가리지 않고 확산되면서 국가 전체의 화두가 되어있습니다. 그러다보니 여러부처의 지원사업들이 4차산업혁명을 동반하고 쏟아지고 있죠.


4차산업혁명에서 활용가눙한 공개SW 기술이 다양하게 존재하는 덕분에, 여러 지원사업에서 공개SW라는 단어를 종종 만나게 되고, 요몇일동안은 공개SW R&D 추진전략에 대한 의견을 전달하게 되었습니다. 


다들 연구개발 지원사업을 오랫동안 해 온 전문가들 이지만, 공개SW R&D의 유형은 일반적인 연구개발의 유형과는 다른 특징을 가지게 되고 준비해야하는 내용도 다를 수 밖에 없습니다. 이번에 의견을 전달하면서 달라진 연구개발의 요구사항에도 불구하고 사업계획을 준비할 수 있는 기초 정보가 부족해서 많은 분들이 어려움을 겪는 것을 알게 되었고 그 과정에서 자료를 좀 정리해야할 필요성을 느끼게 되어서 새 글을 작성합니다.



https://www.slideshare.net/AhmadRb/iem2014-foss


일단 정부의 지원사업에서 공개SW R&D를 한다는 취지를 생각해보면, 1) 사업을 수행하는 동안 기존의 인하우스 개발방식이 아닌 참여와 공유를 통한 공개SW 개발방식을 경험하면서 공개SW 기술의 역량이 축적되고 2) 열심히 노력한 사업의 결과물을 공개SW로 누구나 사용할 수 있게 배포함으로서 산업 활성화에 기여하는 것을 기대하는 것이라 생각합니다.


먼저 지원사업을 발주하는 입장에서는 사업의 선정지표에 공개SW R&D에 대한 준비가 가능한 평가항목을 좀 더 구체화해야 할 것 같습니다. 단순히 '공개SW R&D에 대한 추진방안' 정도로 표현하면 공개SW R&D 사업의 경험이 없이 사업을 준비하는 입장에서는 의도를 파악하기가 어렵습니다. 따라서 어떤 지원자가 참여하면 좋을지 생각하고 있는 의도를 표현할 수 있도록 보다 구체적인 서술을 포함하는 것이 좋겠습니다. (공개SW에 대한 이해, 공개SW R&D 환경, 결과물의 공개SW 라이선스와 배포 방안, 공개SW R&D 관련 경험 등)


뿐만 아니라, 사업의 결과 평가 시점에서도 공개SW로 배포될 결과물에 대하여 평가할 항목을 선정하여 공개SW로 배포되는 사업결과물의 활용을 극대화 하려는 노력이 필요해 보입니다. 공개SW는 특성상 공개SW 커뮤니티를 통하여 배포되고 성장하기 때문에 다운로드수, 홈페이지 방문자수 같은 수치가 아닌 여러가지 공개SW 고유의 지표들을 이용할 수 있고, 공개SW 자체에 대한 성숙도 평가를 하고자 하는 시도 역시 Qualipso OMM, OpenBRR, QSOS, 공개SW 성숙도 및 적용성 평가지침 등이 존재합니다. 따라서 사업의 평가 시점에도 이를 반영하기 위한 노력이 필요하다고 생각됩니다.


또한 사업을 지원하는 입장에서는 어떠한 공개SW R&D 방식을 사용할지, 개발환경은 어떻게 준비할지, 개발과정에서 외부의 참여를 받아들일 준비는 어떠한지, 커뮤니티화 운영을 할때 필요한 거버넌스는 준비되어 있는지, 배포할 결과물에 대한 라이선스 관리전략은 무엇인지 등의 고민을 사전에 해보고, 특허나 기술이전으로 실적을 이야기하던 방식에서 벗어나 공개SW의 특성을 반영한 활용방안과 비즈니스 가능성을 고민하여 제시하는 노력이 필요합니다.


공개SW산업에서 일을 하는 입장에서 보면, 기존의 정부지원사업에서 혁신을 가져온 공개SW R&D 방식 시행되는 것을 대단하게 생각하고 있습니다. 여러가지 부정적인 결과들을 예상할 수 도 있지만, 그 또한 변화의 긍정적인 신호라고 생각합니다. 어찌되었던 이런 좋은 의도의 지원사업을 통해 많은 사람들이 쉽게 기술에 접근해서 아이디어를 구현해보기 좋은 세상이 되었으면 좋겠네요.

최근 해외 기업들의 오픈소스 활용을 어떻게 하는지 살펴보면 모든 기업이 오픈소스 모델의 다양한 가치를 인식하고, 오픈소스 커뮤니티에 적극적으로 참여하고, 오픈소스 기반의 비즈니스 모델을 발견하려는 노력이 점차 강화되는 추세입니다. 이번에 자료를 정리하면서 여러 기업의 비즈니스 전략을 구분해 보았습니다.



기업들의 오픈소스 활용 전략들을 살펴보면 크게 4가지 유형으로 구분할 수 있습니다


1) 자사의 기술이나 서비스를 오픈소스 모델로 전환하여 타사와 경쟁할 수 있는 파괴적 전략으로 채택

2) 고객의 제품이나 서비스의 완성을 위한 전문성을 오픈소스 모델로 지원하는 전략

3) 오픈소스 개발, 배포모델을 기업 비즈니스 목표 달성을 위해 활용하는 전략

4) 오픈소스의 부가적인 가치를 기업 경영에 활용하는 전략


 

1) 전통적 SW개발 기업이 자사의 기술이나 서비스를 오픈소스 모델로 전환하여 타사와 경쟁.

 

- 듀얼 라이센싱 모델이나 코어 오픈모델을 사용하는 등 지적산출물에 대한 접근 통제를 가치로 파는 전략

- MySQL과 sleepycat(버클리 DB)가 듀얼 라이센싱으로 유명. 즉, GPL 버전은 무료로 쓰지만, non-GPL버전을 쓰려면 돈을 내야 한다. 소프트웨어를 Embed 해서 재판매 하려는 회사에 해당된다.

- Xen, SugarCRM 과 같은 회사에서는 코어 오픈모델을 사용. 즉, 코어는 공짜로 풀고 부가기능은 돈을 받고 파는 모델이다. 여기서 “판매가치”는 “특화 기능 (Differentiated Features)”들이 만들어 낸다.

- 보통 듀얼라이센싱을 하기 위해서는 오픈소스에 대한 판권을 가져야만 한다. 즉, 코어 개발자를 직접 고용해야 한다는 것을 의미한다. 즉, 개발력이 내재화되어 있으면, 코어를 오픈소스로 풀기도 하고 GPL버전을 만들어서 뿌리는 것도 자유롭다.

 

2) 전통적인 SW개발 모델이 아닌, 고객을 위한 분산된 컴포넌트의 통합을 교육훈련과 지술지원으로 돕는 오픈소스 전문 비즈니스 전략

 

- 소프트웨어 회사들은 자사의 개발과 산출물들이 조직 밖으로 나와도, 여전히 회사가치가 남아 있는가에 대한 불안이 존재한다. 하지만 Dixon, Pentaho, RedHat, OpenGeo 등의 회사들은 오픈소스 커뮤니티가 만들어내는 소프트웨어를 팔릴만한 물건으로 만들기 위해 가치를 더해줌으로써 선순환 구조를 완성시킨다. 그리고 그 이익으로 다시 개발자와 스태프를 고용하고 오픈소스 커뮤니티가 새로운 가치를 계속 만들어내도록 지원한다.

- 이런 기업들은 실질적인 코어 개발자들을 물리적으로 보유함으로써 지적 자산을 보호해준다.

 

3) 오픈소스 개발, 배포모델을 기업 비즈니스 목표달성을 위해 활용

 

- 기업의 이익을 위해 선별적으로 오픈소스 소프트웨어를 선택하는 이른바 체리 피킹(cherry-picking:선별적 경쟁) 전략을 의미.

- 근간 기능(Commodity Features)은 소프트웨어의 프레임워크으로 뼈대를 형성하는 것이므로 전체 소프트웨어의 중요 부분을 차지하는 경우가 많다. 일반적으로 근간 기능(Commodity Features)은 비용과 시간 절감 및 OSS 사용층 유입의 장점이 있기 때문에 OSS로 구현되는 경우가 많다. (예) 빅데이터 플랫폼 Apache Hadoop)

 

4) 오픈소스의 부가적인 가치를 기업 경영에 활용

 

4-1) 오픈소스에 대한 공유와 협업으로 기업 이미지 마케팅 가시성 확보

 

- 최대 규모의 사유 소프트웨어 기업인 MS조차도 다양한 오픈소스 기여 활발하게 진행 중


아직 관련 매출을 발표한 적이 없음에도 불구하고 오픈소스 계획을 발표한 후로는 1억 달러로 우리가 얻을 수 있었던 것보다 더 많은 마케팅 가시성을 확보하게 됐다. - 아이오나 CEO 피터 조토(Peter Zotto)

 

4-2) 기업 내 조직운용의 실용성을 오픈소스를 통해 확보.

 

- 중소 벤처기업 아라스(Aras)는 MS기술로만 작성된 자사의 PLM(Product Lifecycle Management)기술을 오픈소스화 한 이후 영업직을 없애고 그 자리에 고객의 중요한 요구사항에 대한 서비스를 제공할 애플리케이션 엔지니어들을 추가했다.

 

4-3) 오픈소스를 활용한 소프트웨어 개발의 변화

 

- 오픈소스는 소프트웨어 산업에서 오랜 시간 논의 되었던 재사용, 재공학 등의 문제를 신뢰도 높은 소프트웨어의 재활용, 개발자의 전문성 강화, 오픈소스 개발프로세스의 활용 등 상당 부분 해결해주고 있다.

- 기업들은 공유와 협업이라는 오픈소스 문화의 적극적 도입으로 소프트웨어 개발 문화도 애자일, 린 개발법 등 다양하게 변화되고 있다.

 

최근의 기업 동향을 살펴보다 느끼는 점인데 예전과는 참 많이 달라진 모습이더군요. 저는 오픈소스가 시장에서 점점 더 많은 역할을 할 것을 기대하는 쪽이라 이런저런 재미있는 생각을 많이 하고 있습니다. 개발자에서 출발해서 지금은 개발보다는 다른 일을 더 많이 하는 자리가 되었지만 초심을 잃지 말고 제 나름대로의 방식으로 보다 좋은 세상을 위해서 기여하며 살고 싶다고 생각해봅니다.


지난 몇년간 오픈소스 거버넌스 이야기를 많은 분들과 나누면서 가장 많이 들은 이야기는 '그건 진정한 거버넌스가 아니죠, 제가 아는 거버넌스랑 다른데요' 였습니다. 그외에도 '그게 뭐예요' 또는 '괜히 그런 거 하지 마시지' 등의 이야기도 여러 번 있었습니다. ㅎㅎ


사무실에 혼자 앉아서 이런저런 자료를 만들다가 한번 정리해보고 넘어가야지 하는 생각에 또 글을 적네요.

위키피디아를 보면 거버넌스라는 단어는 1980년대부터 대두된 통치 시스템의 개념으로 아직 정의에 대한 학문적 합의는 이루어 지지 않았다고 합니다.


그래서인지 다양한 목적으로 다양한 분야에서 거버넌스라는 단어가 사용되고 있습니다. 

예를 들면, 뉴 거버넌스, 기업 거버넌스, IT 거버넌스, 정보보안 거버넌스 등이죠.

때문에 거버넌스에 대한 해석이 혹자는 정치 철학으로 혹자는 조직 관리 방법으로 해석하는 것도 당연한 일이겠죠. 


저는 몇년동안 여러 전문가 분들과 오픈소스를 기업과 공공이 어떻게 써야 좋을지에 대해서 고민해왔는데 그 결과물이 예전에는 도입가이드, 적용가이드 등에서 현재는 공개SW거버넌스가 되었습니다. 목적은 변하지 않았는데 좀 더 세련된 이름으로 불리게 되었죠.


지금의 저는 공개SW거버넌스를 이렇게 정의하고 있습니다.


공개소프트웨어를 안전하게 사용·적용 및 배포하기 위해 필요한 사항을 다양한 관점에서 활용할 수 있도록 소프트웨어 라이프 사이클 단계별로 제시한




거버넌스라는 단어가 아직 대중적이지 못한 단어이기에 정리해서 자료를 만들었습니다만, 그 이름이 무엇이라고 불리던 간에, 오픈소스를 사용하는 사람들에게 필요한 자료가 되기를 바랍니다.



주말에 공개SW 개발자대회 참가자를 위한 멘토링이 토즈에서 있었습니다.

다른 참가자 분들에게도 도움이 될지 모르니, 제가 멘토링한 부분에 대해서 정리해서 공유해 두려고 합니다.



제가 준비해간 멘토링의 진행순서는 다음과 같습니다.


1) 참가자 현황분석

2) 대회를 위해서 준비할것 협의

3) 멘토링에서 얻고 싶은 목표 합의

4) 멘토링

5) 향후 멘토링 계획안 협의


제가 담당한 멘티들의 현황을 분석한 결과는 다음과 같습니다.


A팀)

 - 보안기술동향을 분석하지 않은 낮은 기술성

 - SW의 가시성 확보 필요

 - 불확실한 개발 일정 계획

 - 개발문서의 미흡


B팀)

 - 공개SW를 이용한 비즈니스시 위험관리

 - 공개SW 커뮤니티를 활용한 비즈니스 방법

 - 비즈니스를 위한 공개SW 라이선스 컴플라이언스 방안


C팀)

 - SW의 가시성 확보 필요

 - 개발문서의 미흡

 - SW품질에 대한 이해 부족


각각의 이슈에 대하여 제가 취한 조치는 아래와 같습니다.


기술동향 : 최근의 보안기술동향 및 관련사이트 소개

SW의 가시성 : 정적분석도구에 대한 소개 및 활용법, 테스트 커버리지에 대한 가이드, 유닛테스트 및 테스트자동화 안내

개발문서 : 개발방법론 소개 및 개발 산출물 관리방안 가이드

공개SW 비즈니스 위험관리 : 공개SW를 기반으로 외부서비스를 하는 기업의 경우에 필요한 거버넌스 체계소개

공개SW 커뮤니티 운영 : 공개SW 커뮤니티 운영유형 및 필수요소 가이드

라이선스 컴플라이언스 : SW 라이선스 유형 소개 및 활용방안 제시.


짧은 시간에 전달하기에는 내용이 많이 부족했기 때문에 각 팀별로 멘토링 내용을 메일로 전달해주고, 향후 멘토링 가능한 일정계획을 제시해주고 마무리했습니다.


부족한 시간때문에 멘토링에 대한 회고를 하지 못해서 아쉬움이 남네요.






Vagrant는 쉬운 개발환경의 구성을 도와주는 오픈소스로서 팀내의 개발환경을 동일하게 유지해야 할 경우 유용하게 사용할 수 있습니다. 



오늘 새 노트북에 개발환경을 구축하기 위해서 Vagrant를 이용하여 설치할 일이 있었기에 진행 과정을 남겨두려고 합니다.

개발환경은  CentOS 6.4 + Apache 2.2.15 + MySQL 14.14 + PHP 5.3.3 + Tomcat 6-6.0.36 로 구성되었습니다.


1) 필수 환경 구성

먼저 자신의 환경에 맞는 아래의 프로그램을 각각 설치합니다.

- VirtualBox : https://www.virtualbox.org/

- Vagrant : http://downloads.vagrantup.com/


2) 가상이미지(box) 설치

- 저는 손에 익숙한 centos 64bit 를 설치하기로 했습니다.

- 다른 이미지를 사용하고 싶은 경우 http://www.vagrantbox.es/ 참고하세요


우선 box 설치

// 형식 : vagrant box add [title] [download-url] 

$ vagrant box add centos64 http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130427.box


box 초기화

$ vagrant init centos64


초기화 하고 나면 Vagrantfile 이라는 환경설정 파일이 생깁니다.(제 경우는 C:\Users\Administrator 안에 있네요.)

어디있는지 모를때는 링크를 참고하세요. http://docs.vagrantup.com/v2/vagrantfile/index.html


box 구동하기

$ vagrant up


box 재구동

$ vagrant reload


box 종료

$ vagrant halt


그리고 예상하시는 것처럼 vagrant help 명령으로 더 많은 내용을 확인할 수 있습니다.


vagrant up 명령으로 구동을 마치면 ssh 클라이언트로 접속해서 사용할 수 있습니다. 

ssh 호스트는 localhost 포트는 2222

id : vagrant/ pw : vagrant


3) apache, tomcat, mysql, php 환경구성


- httpd 설치

$ yum install httpd httpd-devel


- php 설치

$ yum install php


- mysql 설치

$ yum install mysql-server mysql


- php mysql 연동

$ yum install php-mysql


- java 설치

$ yum install java-1.6.0-openjdk.x86_64


- tomcat6 설치

wget http://jpackage.org/jpackage50.repo -O /etc/yum.repos.d/jpackage50.repo

$ yum install tomcat6 tomcat6-admin-webapps tomcat6-webapps


설치후 JAVA_HOME 설정

vi /usr/share/tomcat6/conf/tomcat6.conf

JAVA_HOME="/usr/java/jdk1.6.0_45" (각자의 환경에 맞는 JAVA_HOME을 설정해야 합니다.)


4) Vagrantfile 환경설정

- Vagrantfile 에서 apache, tomcat, mysql 포트 포워딩 설정을 아래처럼 변경해 줍니다.


  # guest : vm 머신의 포트 / host : local 포트

  # 아래와 같이 설정하면 localhost 33306 으로 접속할때 vm 머신 3306으로 접속된다.

  config.vm.network :forwarded_port, guest: 3306, host: 33306


  # httpd

  config.vm.network :forwarded_port, guest: 80, host: 8000


  # tomcat6

  config.vm.network :forwarded_port, guest: 8080, host: 9999


설정을 마쳤으면 재 구동합니다.





5) 설치확인

- 테스트 파일을 만들어서 확인해 줍니다.

vi /var/www/html/info.php 

<?php phpinfo(); ?>


http://localhost:8000/info.php

http://localhost:9999/


기타) box와 운영OS의 파일공유

- 설치 후 가상이미지 상의 /vagrant 디렉토리는 윈도우(내 경우)의  C:\Users\Administrator 폴더와 연결되어 있으니 개발 PC와 이미지의 파일공유가 필요하신 경우 사용하시면 됩니다.

- 폴더 공유 관련 설정은 다음 링크 참고. http://docs.vagrantup.com/v2/synced-folders/basic_usage.html


* 접속 문제가 있는경우 iptables 를 변경하거나 중지해 보세요.





오늘 페이스북 타임라인을 읽다보니 '리눅스 HWP 공개 라이브러리 개발' 건에 대한 라이선스 이야기를 하는 글들이 보이네요. 저도 예전에 FCKEditor를 적용한 제품때문에 LGPL의 정체가 뭔지 몰라서 어려웠던 기억이 납니다. 글타래를 읽다보니 LGPL에 대해서 애매한 이야기들이 좀 있는것 같아서 정리해봅니다. 


1. 공통적으로 지킬 것

일단 OSI(Open Source Initiative)에 등록되어 있는 오픈소스SW 라이선스는 GPL이건 LGPL 이건 상관없이 공통적으로 지켜야 하는 내용이 두가지 있습니다. 


가. 저작권 관련 문구 유지

- 가져다 쓰는 것은 자유롭게 하고 개발자의 정보는 삭제하지 않는 것이죠. 이것은 원 저작권자의 인격을 보호하기 위한 사항으로 마음대로 삭제하시면 안됩니다.


나. 제품명 중복 방지

- 아파치, 리눅스 같은 프로젝트명을 선택하면 안된다는 의미입니다.


두 가지 모두 무엇인가를 직접 만들어본 사람이라면 상식적인 수준에서 지켜야 하는 것이죠.


2. LGPL 라이선스를 가져다 쓰는데 소스코드를 공개해야만 하나요?

LGPL은 GPL의 조건이 너무 엄격해서 사람들이 쓰는 것을 꺼려할까봐 이를 감안해서 만든 라이선스 입니다. 따라서 GPL과는 다르게 LGPL 라이브러리에 응용프로그램을 정적 혹은 동적으로 링크시킨다고 해도 응용프로그램의 소스코드를 공개할 필요가 없습니다. LGPL 전문에 있는 ”라이브러리의 복제본을 무상이나 유상으로 배포할 경우에, 당신은 우리가 당신에게 부여한 모든 권리를 수취인에게도 그대로 부여해야 한다.“라는 내용으로 요구 조건만 준수한다면 상업적인 유상 배포도 허용하고 있습니다. 따라서 자기가 만든 소스코드의 공개없이 가격을 받는 상용제품으로 판매하셔도 됩니다.


다만, LGPL 라이브러리의 소스코드를 수정하였을 때에는 2차적 파생 저작물에 해당하므로 라이브러리의 소스코드를 제공해야 합니다.


3. LGPL을 가져와서 개발하고 GPL 라이선스로 변경해도 될까요?

대답은 변경해도 됩니다. 아래 내용을 보시면 "양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다"라고 표기되어 있습니다. 하지만 GPL 소스코드를 가져와서 임의로 LGPL로 변경하는 것은 안됩니다.


http://olis.or.kr/ossw/license/license/detail.do?lid=1005&mapcode=&currentPage=

3.

 당신은 양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다. 이를 가능케 하기 위해서는 본 라이선스를 언급하는 모든 사항들을 GNU 일반 공중 라이선스 버전2의 사항들로 대체시켜야 한다. (만약 GNU 일반 공중 라이선스 버전 2 이후에 신규 버전이 공표되었을 경우에는 원한다면 신규 버전을 사용할 수 있다.) 그 외에 다른 사항들은 변경할 수 없다.

복제물에 대해 이러한 수정이 이루어졌을 경우에는 라이선스를 다시 변경하는 것은 불가능하며, 따라서 해당 복제물을 기반으로 만들어진 모든 저작물과 복제물에는 GNU 일반 공중 라이선스가 적용되어야 한다.

이러한 선택 사항은 라이브러리의 코드 일부분을 라이브러리가 아닌 프로그램에 포함시키고자 할 경우에 유용하다.

하지만 LGPL을 제외한 나머지 라이선스는 원 저작자가 아닌 사람이 임의로 라이선스를 변경할 수 없습니다. LGPL은 명확하게 전문에 표기하였기 때문에 문제가 없지만 다른 오픈소스SW 라이선스는 이를 허용하지 않습니다. 


4. 더 궁금하시면

다른 오픈소스SW 라이선스에 대하여 궁금하시다면 아래의 링크를 이용하시면 됩니다.

- 한국저작권위원회 라이선스 설명 : http://olis.or.kr/ossw/license/license/list.do  

- 공개SW역량플라자 라이선스 설명 : http://www.oss.kr/45607

공개SW 라이선스 가이드 다운로드 http://www.oss.kr/?mid=oss_license&page=3&document_srl=70139 

오픈소스 라이선스 해설 http://www.oss.kr/oss_license/92922



그림출처 : http://terokarvinen.com/freehelia_licenses_and_the_definition_of_free_software.html

  1. ㅇㅇ 2013.11.09 22:24 신고

    LGPL이 그런거였군요 오호...GPL은 사실상 유료이고..

    • Favicon of http://openbee.kr BlogIcon 오픈비 chaeya 2013.11.16 01:57 신고

      GPL이 유료는 아니구요~ 오히려 소스코드를 같이 공유하고 발전시키자는 의미의 규제가 더 강한것이 GPL입니다. GPL, LGPL은 두가지 모두 무료입니다.

  2. Lucy 2013.11.14 17:34 신고

    감사합니다. 도움이 많이 되었습니다. ^^

  3. Favicon of http://blog.snooey.net BlogIcon Snooey 2013.12.11 12:26 신고

    솔직히 저 사건에 대한 관점은
    1. 오픈소스를 위한 정부지원사업을 부당하게 진행
    2. 까보니 라이센스 저작권 및 사전 협의 없는 라이센스 변경
    3. 라이센스 위반 상황에서 소스 대조를 해보니 변경점 거의 없음

    이런 상황이었던 것인지라 라이센스만을 이야기할 사건은 아니었지요.
    하지만 라이센스 문제가 부각되어버린 안타까운 사건입니다.(...)

  4. Favicon of http://blog.snooey.net BlogIcon Snooey 2013.12.11 13:44 신고

    안녕하세요. 라이센스 문제를 불러일으켰던 장본인으로써 인사 드립니다.
    솔직히 이야기해서 1항의 가 항은 라이센스 파일 내에는 절대 강제하는 부분이 아닙니다.
    또한, 만약 그 내용이 강제되고 있어서 동일 라이센스의 파생 소스에 해당 정의가 추가되는 것이 옳은 방법이라면 한 네댓번 프로젝트가 분기되면 소스파일 반절 이상이 아마 라이센스 도배만으로 이루어졌으리라 생각됩니다.
    하지만 실제 그런 일은 GPL에서도 발생하고 있지 않은 부분입니다.
    프로젝트명 자체가 갈라지는 게 아닌 같은 프로젝트로써 공생을 하는 관계라면 라이센스 자체에 수정을 가할 필요는 없지만, 만약 프로젝트가 분기되어 프로젝트 명칭이 달라지는 경우에는 라이센스 소유자 자체를 변경하는 것이 전혀 이상하지 않은 것으로 알고 있습니다.
    소스에 대한 소유를 인정하는 GPL 계열 라이센스의 특징을 생각한다면 틀린 사용법이 아닌데도, 왠지 국내는 라이센스 저작권자 수정에 굉장히 민감하더군요.
    제 생각엔 진짜 원 저작자를 존중한다면 오히려 라이센스에 저작권자 도배질보다는 오류 수정이나 기능 기부 등 소스적으로 제공해서 더 나은 소프트웨어를 위해 제공하는 게 맞을텐데 말이죠.
    이런 논리가 국내 일부 오픈소스 개발자에겐 안 통하는 것 같아 좀 씁쓸합니다.(...)
    (추가)
    생각지도 못한 내용이었는데 잘못을 지적받아 조금 더 씁니다.
    프로젝트 분리로 인해 소유자가 바뀌는 경우, 원 저작권 자체를 완전히 지우는 것은 금지이고, 라이센스 전문 하단에 원 저작권 항목을 붙이는 것이 맞다고 하더군요.
    잘못 알고 있던 부분이라 죄송합니다.(...)

    • Favicon of http://openbee.kr BlogIcon 오픈비 chaeya 2013.12.15 23:15 신고

      방문해주셔서 감사합니다. 원 저작자에 대한 존중도, 상호 협력을 통한 좋은 소스코드도 오픈소스 프로젝트의 중요한 요소라고 생각됩니다. 이런 이슈를 통해서 향후 오픈소스 커뮤니티에 대한 지원정책이 좀 더 개선되고 좋아진다면 좋겠네요.

  5. Favicon of http://jung2159.tistory.com BlogIcon 허정욱 2014.10.06 20:17 신고

    잘 보고갑니다 ^^ 오픈소스 프로젝트를 하다가 잘 몰라서 검색했는데 정말 잘 설명하셔서 바로 알아들을 수 있었습니다.. ㅎㅎ ^^ 좋은 정보 담아가겠습니다!!!



최근 클라우드 분야에서 오픈소스SW의 활약이 대단하죠~

클라우드컴퓨팅지원센터, 공개SW클라우드협의회 등의 기관 및 단체들이 생겨나는 걸보면 

공개SW가 이제는 시장의 대세로 변하고 있는것은 느끼게 됩니다.


올해 개최된 OSCON 2012 발표 자료를 읽다보니 

오픈소스SW 클라우드 플랫폼 OpenStack, Eucalyptus, CloudStack, Ganeti 를 비교한 자료가 있어서 정리해 봅니다.



오픈스택 (www.openstack.org)

2010년 Rackspace 와 NASA 의 공동프로젝트로 시작해서 많은 기업들이 참여했습니다.

국내에도 최근에는 자주 세미나가 열려서 많은 분들이 관심을 가지고 있죠.

Nova, Swift, Glance, Keystone, Horizon 등의 컴포넌트로 구성되어 있습니다.



유칼립투스 (www.eucalyptus.com)

UC Santa Barbara 에서 연구프로젝트로 시작해서 2009년 상용으로 되었다가 

2012년 다시 오픈소스SW로 전환되었습니다.

Cloud Controlle, Walrus, Cluster Controller, Storage Controller, Node Controller 등으로 구성되어 있습니다.



클라우드스택(www.cloudstack.org)

Cloud.com 에 의해 개발되었고 2010년 5월에 오슨소스SW로 배포되었습니다.

Citrix 가 Cloud.com 을 인수하여 2012년 ASF(Apache Software Foundation)에 기증하여 현재 APLv2 입니다.

Management Server, Hypervisor Nodes, Storage Nodes, Layers(Zone, Pod, Cluster, Host, Primary Storage, Secondary Storage) 로 구성되어 있습니다.



가네티 (code.google.com/p/ganeti)

무중단 서버를 위하여 구글 내부에서 시작되어 내부 업무용 서버로 사용되다가 

2007년 8월 오픈소스SW로 공개되었습니다. 

Master daemon, Node daemon, Conf daemon, API daemon, Htools 로 구성되어 있습니다.



기업이 클라우드 플랫폼을 사용하기 위해서는 사용성, 서비스 가용성, 도입 및 관리 비용 절감, 성능, 이기종 호환성, 빠른 프로비저닝 등의 다양한 요소를 고려해야 하지만, 이런 의사결정을 바르게 할 수 있는 전문인력을 보유하고 있는 기업은 많지 않은것이 현실입니다. 향후, 공개SW기술이 클라우드 분야에서 확산되기 위해서는 우선 기업의 의사결정을 돕는 다양한 자료가 필요하겠습니다.


 



CentOS 5.x + Redmine 2.x


이슈관리를 위하여 레드마인을 설치하려고 보니 2.x 가 최신이네요

최신버전을사용하려면 상위버전의 ruby가 필요하고 또 다른것도 좀 있어야 합니다. 

설치순서는 ruby > rubygems > rails > redmine 의 순서로 설치.




1. Download ruby source

wget http://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7.tar.gz

tar -zxvf ruby-1.8.7.tar.gz


2. Install dependencies

sudo yum install gcc

sudo yum install gcc-c++

sudo yum install zlib-devel

sudo yum install openssl-devel

sudo yum install readline-devel

sudo yum install sqlite3-devel


3. Build ruby from source

cd ruby-1.8.7

./configure --with-openssl-dir=/usr/lib64/openssl

make

sudo make install


4. Download rubygems source

wget http://rubyforge.org/frs/download.php/69365/rubygems-1.3.6.tgz

tar -zxvf rubygems-1.3.6.tgz

cd rubygems-1.3.6

sudo ruby setup.rb


5. Install gems

sudo gem install rake

sudo gem install rails

sudo gem install mysql2


6. Install Redmine 

아래 문서를 따라서 차근차근 진행합니다.

http://www.redmine.org/projects/redmine/wiki/RedmineInstall


트러블슈팅

1) bundle install --without development test 


>>> 오류 발생 rmagick, postgresql, sqlite 등을 사용하지 않아서 아래처럼 제거하고 설치

`bundle install --without development test rmagick`

`bundle install --without development test postgresql sqlite`


2) ruby 위치를 못찾아서 'ln -s /설치위치 /usr/bin/ruby' 로 링크해 줌


나머지는 매뉴얼대로 설치 진행.


standalon 구동방식) 서버를 재시작해도 레드마인이 구동되기 위한 Init script 적용

/etc/init.d/redmine 파일의 내용


#!/bin/bash
#
# chkconfig: - 16 84
# description: Start up Redmine
#
# processname: redmine
# config: /etc/sysconfig/redmine

# source function library
. /etc/rc.d/init.d/functions

# Get network config
. /etc/sysconfig/network

[ "${NETWORKING}" = "no" ] && exit 0

# Defaults
DAEMON_HOME=/usr/local/redmine
DAEMON_ARGS="-e production -d"

# Daemon
NAME=redmine
RUBY=$(which ruby)

APP_PIDFILE=$DAEMON_HOME/tmp/pids/server.pid
DAEMON_PIDFILE=/var/run/$NAME.pid
DAEMON_LOCKFILE=/var/lock/subsys/$NAME

start() {
    echo -n $"Starting ${NAME}: "
       
    cd $DAEMON_HOME
    #redmine 2.x 인경우
    $RUBY script/rails server webrick $DAEMON_ARGS
    #redmine 1.x 라면 아래의 구동스크립트 사용
    #$RUBY script/server webrick $DAEMON_ARGS

    sleep 2

    status -p $APP_PIDFILE &> /dev/null && echo_success || echo_failure
    RETVAL=$?

    if [ $RETVAL -eq 0 ]; then
        touch $DAEMON_LOCKFILE
        cat $APP_PIDFILE > $DAEMON_PIDFILE
    fi

    echo
}

stop() {
    echo -n $"Shutting down ${NAME}: "
   
    killproc -p $DAEMON_PIDFILE
    RETVAL=$?

    [ $RETVAL -eq 0 ] && /bin/rm -f $DAEMON_LOCKFILE $DAEMON_PIDFILE

    echo
}

case "$1" in
    start)
        start
    ;;
    stop)
        stop
    ;;
    restart)
        stop
        start
    ;;
    status)
        status -p $DAEMON_PIDFILE $NAME
    ;;

    *)
        echo "Usage: $SCRIPTNAME {start|stop|restart|status}" >&2
        exit 3
    ;;
esac


위의 redmine 파일을 /etc/init.d/ 디렉토리 안에 넣고 아래의 순서를 따른다.

chmod +x /etc/init.d/redmine
chkconfig --add redmine
chkconfig redmine on
/etc/init.d/redmine start



아파치 연동방식) 가상호스트로 구동시킬 때


passenger 설치하고 아파치 모듈설치


gem install passenger
passenger-install-apache2-module


/etc/httpd/conf.d/redmine.conf 파일추가 후 아파치 재 시작


LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-3.0.18/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.18
PassengerRuby /usr/bin/ruby

<VirtualHost *:80>
  ServerName redmine.abydos.co.kr
  # 레드마인이 설치된 디렉토리 안의 public 디렉토리를 지정

  DocumentRoot /opt/webRoot/redmine/public

  <Directory /opt/webRoot/redmine/public>

   # This relaxes Apache security settings.
   AllowOverride all
   # MultiViews must be turned off.
   Options -MultiViews
  </Directory>

   ErrorLog "|/usr/sbin/rotatelogs /etc/httpd/logs/redmine-error.%Y-%m-%d.log 86400"
   CustomLog "|/usr/sbin/rotatelogs /etc/httpd/logs/redmine-access.%Y-%m-%d.log 86400" "%h %l %u %t %D \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""

</VirtualHost>


나눔고딕폰트로 변경)

나눔고딕으로 스타일 적용하려면

설치디렉토리안의 public/stylesheets/application.css 파일을 아래와 같이 수정


css 파일의 맨위에 아래 내용을 삽입하고

@import url('http://api.mobilis.co.kr/webfonts/css/?fontface=NanumGothicWeb');


원하는 부분에서 아래처럼 사용

font-family: 'NanumGothicWeb'


플러그인)

http://www.redmine.org/projects/redmine/wiki/Plugins



백업 및 복구, 데이터 이전)

다른 서버의 레드마인을 이전하거나, 장애에 대비하여 백업할때를 위하여 스크립트를 작성하고 cron으로 등록.


참고 : http://www.redmine.org/projects/redmine/wiki/HowTo_Migrate_Redmine_to_a_new_server_to_a_new_Redmine_version


고쳐서 사용중인 스크립트(git 대신 일자별로 백업되게 변경)

redmine_bak


crontab -l

0 2 * * * /root/redmine/redmine_bak


마이그레이션) 버전이 다른 레드마인을 업그레이드 하는 경우 아래의 과정 필수


http://www.redmine.org/projects/redmine/wiki/RedmineUpgrade

[root@localhost redmine]# rake generate_secret_token

[root@localhost redmine]# rake db:migrate RAILS_ENV=production

[root@localhost redmine]# rake redmine:plugins:migrate RAILS_ENV=production 

[root@localhost redmine]# rake tmp:cache:clear

[root@localhost redmine]# rake tmp:sessions:clear

[root@localhost redmine]# /etc/init.d/httpd restart


시작페이지를 위키로 바꾸고 싶을 경우)


설치된 디렉토리안의 app/controllers/welcome_controller.rb 파일을 수정

@news = News.latest User.current
@projects = Project.latest User.current

to

@news = News.latest User.current
@projects = Project.latest User.current 
redirect_to :controller => 'projects', :action => 'show', :id => '이동시킬프로젝트아이디/wiki'



+ Recent posts