오픈 소스에 대한 오해와 진실은 다음과 같습니다:

  1. 오해: 오픈 소스 소프트웨어는 무료로만 이용할 수 있다. 진실: 오픈 소스 소프트웨어는 주로 무료로 이용할 수 있지만, 이는 "무료"라는 개념을 가진 것은 아닙니다. 오픈 소스 소프트웨어의 라이선스는 대부분 자유롭고 수정 가능하며 재배포 가능한 조건을 가지고 있지만, 상업적 이용이나 수정한 버전의 판매에 대해서는 추가 요구사항이 있을 수 있습니다.
  2. 오해: 오픈 소스 소프트웨어는 품질이 낮다. 진실: 오픈 소스 소프트웨어는 수많은 개발자 및 사용자의 협력과 검토를 거쳐 개발되기 때문에 품질이 매우 높을 수 있습니다. 많은 오픈 소스 프로젝트는 전 세계적으로 대규모로 개발되고 유지보수되며, 많은 사용자가 버그를 찾아내고 수정하거나 보안 취약점을 보완합니다. 오픈 소스 소프트웨어는 공동체의 지원과 풍부한 테스트를 통해 안정성과 신뢰성을 확보할 수 있습니다.
  3. 오해: 오픈 소스 소프트웨어는 보안에 취약하다. 진실: 오픈 소스 소프트웨어는 일반적으로 많은 개발자와 보안 전문가들에 의해 검토되기 때문에 보안 취약점이 빠르게 발견되고 수정될 수 있습니다. 또한, 오픈 소스 소프트웨어는 투명성을 가지고 있어 누구나 코드를 검토하고 보완할 수 있으므로, 악의적인 코드나 보안 취약점이 숨겨진 경우가 적습니다. 그러나, 오픈 소스 소프트웨어 역시 보안 취약점이 있을 수 있으며, 이를 해결하기 위해서는 업데이트와 보안 패치를 지속적으로 적용해야 합니다.
  4. 오해: 오픈 소스 소프트웨어는 개발자에게 이익이 없다. 진실: 오픈 소스 소프트웨어를 개발하는 개발자들은 자신의 기술력을 향상시키고 다른 사람과의 협력을 통해 더 좋은 소프트웨어를 만들기 위해 기여합니다. 또한, 오픈 소스 소프트웨어는 개발자에게 다양한 경제적 이익을 제공할 수 있습니다. 예를 들어, 개발자는 오픈 소스 소프트웨어에 기여하여 자신의 프로젝트에 대한 노출을 얻을 수 있고, 상업적인 지원, 컨설팅, 서비스 제공 등의 비즈니스 모델을 구축할 수 있습니다.
  5. 오해: 오픈 소스 소프트웨어는 모든 종류의 소프트웨어에 적합하다. 진실: 오픈 소스 소프트웨어는 모든 종류의 소프트웨어에 적합하지는 않을 수 있습니다. 일부 상용 소프트웨어는 공개되지 않은 알고리즘, 특정 기능, 또는 소유권 보호 등의 이유로 오픈 소스로 제공되지 않을 수 있습니다. 또한, 기업이 자체적으로 개발한 소프트웨어의 경우에는 오픈 소스로 공개하지 않을 수 있습니다.

이러한 오해와 진실을 고려하여, 오픈 소스 소프트웨어는 현대 소프트웨어 개발과 사용에 있어서 중요한 역할을 수행하고 있으며, 다양한 장단점을 가지고 있습니다.

느낌 아시는 분들은 아시겠지만, 위에는 ai.com 이 답변한 것입니다. 오픈 소스에 대한 생각을 AI가 잘 정리해 놓아서 저도 놀랐습니다.

그리고, 오픈 소스에 참여하는 방법은 어렵지 않습니다.

자기가 짠 코드를 무.조.건. 오픈하라는 것은 아닙니다. 개인적인 의견은 `오픈 소스 프로젝트`에 참여를 권장합니다. 좋은 오픈 소스를 사용하고 피드백하는 것은 매우 도움이 되기 때문입니다.

hadoop (https://hadoop.apache.org) 이전에는 or*cle 세상이었는데, 오픈 소스 hadoop이 RDBMS의 전횡을 바꿀 수 있었다고 생각합니다.

M$도 스티브 발머 이후 사티아 나델라 이후에 오픈 소스로 완전히 돌아서기도 했고, 지금도 계속되고 있습니다.

물론 국가기밀이나 회사의 영업 비밀은 오픈하면 안 됩니다. 인터넷에 오픈할 게 있고, 하지 말아야 하는 것은 존재합니다.

 

오픈 소스에 관한 퀴즈 하나입니다.

오늘 발표한 자료 공개합니다.

https://bit.ly/egovcontrib

 

프론트엔드 웹개발의 한 획을 그었고, 아직도 현재 진행중인 리액트(React.js)의 10년 역사를 80분 정도로 요약한 다큐멘터리가 나왔습니다.

페이스북이 오픈 소스로 리액트를 만들었다는 정도만 알고 있는 저에게 창립 멤버들의 활동은 잘 알지 못했습니다. 영상을 캡처해서 공유합니다. 2013년 5월 29일에 리액트의 public release 커밋이 처음으로 올라갔군요.

capture from: React.js: The Documentary

아래는 영상 링크입니다. 참고로 유튜브에서 C(Capture) 키를 누르면 자막이 보입니다. #개발자단축키지상주의

https://www.youtube.com/watch?v=8pDqJVdNa44 

from Honeypot Youtube

좋아하는 것이 생기면 그에 관련된 역사나 에피소드들이 매우 흥미진진해 집니다. 리액트로 삶을 꾸려가는 엔지니어들에게 좋은 영상이 되면 좋겠습니다. ✨

OSPO 101 교육 모듈

OSPO 101은 오픈 소스 프로그램 오피스 관리에 대해 알아야 할 모든 것에 대한 과정입니다.

콘텐츠를 단편적으로 재사용할 수 있도록 모듈화하기 위한 것입니다.

OSPO 101 과정 자료는 조직을 위한 본격적인 패키지 과정으로 LF 교육에서도 사용할 수 있습니다.

https://training.linuxfoundation.org/training/open-source-management-and-strategy/

 

재밌는 서비스입니다. GitHub의 활동을 기준으로 재밌는 리포트를 생성해주는 서비스입니다.

http://osrc.dfm.io/kenu





다음 커뮤니케이션의 초청으로 제주대에서 발표한 자료입니다.

파일 첨부합니다.


20120518_다음제주_내가 경험한 오픈소스.zip





세상에는 두 종류의 사람 얘기하면서 Hello World를 아는 개발자와 모르는 일반인으로 구분하고는 했습니다. 유사한 경우가 소스라고 했을 때 소스 코드가 먼저 떠오르면 개발자고 토마토 소스처럼 요리용 소스가 생각나면 일반인으로 구분할 수도 있을 것 같습니다.


오픈 소스에 관한 글이 하나 떠서 소개합니다.
http://www.ibm.com/developerworks/kr/opensource/newto/index.html

오픈소스를 가져다가 활용하기 때문에 요즘 프로그래밍 기술에 가속도가 붙어있습니다. 예전처럼 코드를 꽁꽁 숨기려는 노력보다는 바벨탑을 쌓아가듯이 코드를 공유하는 문화가 개발자들 사이에서 유행처럼 번지고 있습니다.

좋은 의도에서 소스를 오픈했는데, 아무리 비용이 들지 않는다 하여도 가져다 쓰는 예의와 법이 있습니다. 그것에 대해서 잘 얘기해주고 있는 글입니다.

첫 장부터 펼쳤습니다. 아직 섹션 하나만 읽은 상태죠. 그런데 왠걸 좋네요. ^^; 브룩스의 Mythical Man-Month 요약도 스토리 중에 잘 되어 있고, 프로그램 용어나 생리를 잘 모르는 사장님 같은 사람들에게 설명하기 쉽도록 표현된 부분도 많군요.

메일링 리스트, 블로그, 버그 관리 소프트웨어, 소스코드 버전 관리 소프트웨어 등 그들이 활용했던 수 많은 도구에도 불구하고 개발자들끼리 커뮤니케이션을 효율적으로 유지하고 필요한 정보를 효과적으로 공유하는 일은 너무나도 어려웠다.
발췌: 드리밍 인 코드, 스콧 로젠버그, P.34

이 책을 다 읽으면 알겠지만 첫 번째 섹션 마지막 표현이 기대하게 만드네요.

케이퍼가 OSAF라는 회사 이름에도 사용한 오픈소스 개발 방법론은 브룩스 이후에 등장한 개념이었다. 그리고 오픈소스 개발 방법론은 브룩스의 패러독스를 극복해줄 가장 그럴듯한 무기처럼 보였다.
발췌: 드리밍 인 코드, 스콧 로젠버그, P.34

데드라인과 같은 소설이 아닌 경험담이라서 더 와닿을 것 같습니다.

^^; 읽을 책 많은데 우선 순위 좀 바꿔야겠습니다. 고 놈 재밌군요.

익숙한 툴을 벗어나서 새로운 툴에 적용하는 것은 아주 어려운 일입니다. 윈도우에서 맥으로 스위칭하는 것이 그랬고, 이번엔 이미지 편집기도 고가의 포토샵에서 Gimp로 바꾸는 연습을 하고 있습니다.

작업창의 일부입니다. 오른쪽에 보시면 아시겠지만 레이어 기능이 지원됩니다. psd파일 호환도 되고요.

http://gimp.kr/ 김프코리아는 아직 자주 들어가진 않았습니다. 저처럼 쉽지 않은 길을 선택한 분들인데, 사실 도구는 익숙함의 문제가 아닌가 싶습니다.


평소에 들여다 보았으면 좋았을텐데 하는 아쉬움이 남습니다. CVS에서 SVN으로 모든 프로젝트가 이전하는 것은 몇 년 전에 알고 있었는데, 오늘 책을 쓰다가 아파치 소프트웨어 재단(Apache Software Foundation)의 저장소를 보고 놀랬습니다. 백 개가 넘는 모든 프로젝트들이 한 저장소에서 관리되고 있습니다. 각 프로젝트별로 trunk, branches, tags 를 각기 관리하고 있습니다.
리비전 번호에 신경을 쓰지 않아도 될 듯 합니다. 숫자는 다르다는 것만 표시하면 될 뿐, 통합 저장소로 인한 리비전 번호의 증가에 괜히 신경쓰지 않아도 될 것입니다.


톰캣 프로젝트 내에도 여러 서브프로젝트들이 존재합니다. 저장소 구성은 다음과 같습니다.

괜히 은근슬쩍 2002년이 떠오르는군요. 자카르타서울 프로젝트. 지금은 동면상태이죠.
http://www.apache-korea.org

고전적인 자바 클래스의 테스트는 main() 메소드에 값을 찍어보는 코드를 넣어서 콘솔에서 확인합니다. 이클립스에 익숙해진 덕에 JUnit에서 System.out.println() 집어 넣는 것은 초딩같은 습관이라고 생각을 "저만"했었습니다. 하지만, 찍어본다는 것 그리고 그것을 눈으로 확인하는 것은 굉장한 심리적 안정감을 주기는 합니다. 아직 assertEquals() 는 보이지 않는 신뢰가 필요하기 때문이죠.

httpunit의 테스트코드를 보니 재밌는 부분이 있었습니다. 상당히 많은 수의 테스트케이스에 main() 메소드가 있었고, 그 메인메소드는 JUnit을 기반으로 해당 테스트코드를 수행하도록 만들어주는 것이었습니다.


suite() 메소드를 inline 리팩토링하면 junit.textui.TestRunner.run( new TestSuite( EncodingTest.class ));  를 통해서 실행을 합니다. Java Application 으로 실행한 결과는 다음과 같습니다.

..............
Time: 3.813

OK (14 tests)

물론 이 클래스는 JUnit을 통해서도 실행됩니다.

다른 사람의 코드를 읽는 것, 프로그래머 소통의 시작이 아닐까 생각해봅니다.

참고로 HttpUnitTest 클래스의 상속구조입니다. ctrl+T 로 이클립스에서 볼 수 있습니다.


 

+ Recent posts