강의소개
기술융합으로 산업간 경계가 허물어지는 4차 산업혁명은 삶의 형태, 비즈니스 방식, 국가 운영체계까지 뒤바꿀 것으로 전망하고 있습니다. 모든 것이 연결되고 보다 지능적인 사회로의 진화하는 '초연결사회'에서 소프트웨어는 중심이며 자동화, 최적화, 유연화를 통해 문제를 해결하는 SW의 역할도 확대 될 것입니다.
특히, 4차 산업혁명을 이끌 유망기술에서도 공개SW가 핵심적이며, 중심적인 역할을 하고 있습니다. 공개 SW에 대해 전반적인 이해를 돕고, 오픈소스 철학과 문화를 이해할 수 있도록 본 교육과정을 제공합니다.
이민석
現) 국민대학교 교수
前) 이노베이션아카데미 학장
공유와 협업을 통한 혁신 오픈소스 소프트웨어
Microsoft Encarta
* Encyclopedia of Microsoft
- Bill gates starts Encarta project in the middle of 1980`
-> CD-ROM with Multi-media contents
- Inspired by Britannica
-> Britannica sales on 1990 : US $650M
- First version released on 1993
-> Full of Multimedia Contetns
- On 2009...
마이크로소프트가 엔카르타 라는 백과사전을 만든적이 있다.
https://namu.wiki/w/%EC%97%94%EC%B9%B4%EB%A5%B4%ED%83%80
백과사전이 워낙 뚜껍기 때문에 CO-ROM에 모든 컨텐츠를 담고, 오디오, 사진을 담았다.
빌게이츠의 인생역작이라 생각.
그 전에 브리태니커라는 유명한 백과사전이 있었다. 90년도에 6억 5천만불의 매출을 올렸다.
https://en.wikipedia.org/wiki/Encyclop%C3%A6dia_Britannica,_Inc.
93년에 첫 번째 버전이 나옴.
2009년에 잉카르타 사업을 접었다. 비용 감당이 안되서 접음.
wikipedia
since 2001
https://terms.naver.com/entry.naver?docId=1257279&cid=40942&categoryId=34661
백과사전 시장의 99%를 차지하는 독보적인 백과사전이다.
브리태니커도 백과사전 사업을 접었다.
한국어는 518,000+ 문서가 있으며 영어는 6,146,000+ 가 있다.
나무위키는 802,573+ 문서가 있다.
나무위키와 위키피디아는 완전히 다르다. 나무위키는 사실 사람들이 어떤 생각을 담은 글들이 많다. 아주 잘 리뷰가 잘 되어 있고 근거만 있는 자료만 있는 건 아니다. 나무위키는 개인적인 감정도 담겨있고 비전문가들이 리뷰한 글들이 많다. 나무위키는 내용이 풍부하고 재미있기 때문에 구글이 나무위키 내용을 많이 찾아준다.
위키피디아는 사람들이 자원해서 협력해서 내용을 담아가고 있다. 2009년에 잉카르타를 접었다고 했는데 그 시점에 이미 위키피디아의 글 수는 3,100,000+에 이르렀다. 지금도 계속 발전하고 있고 현재도 계속 늘어나고 있다.
Lee, Sedol VS AlphaGo, 2016
AI Issues
- The Ethics of AI
- To order or To be ordered
- Basic Income, Robot Tax
On the Year of 2015,
- 'TensorFlow' by Google
- 'DMLT' by Microsoft
- 'SystemML' by IBM
- 'Veles' by Samsung
- 'Torch' by Facebook
Now,
- Apache Spark, MLlib, Apache Singa, Caffe, MS Azure ML Studio, AML, MS CNTK, Brainstorm, mlpack 2, Marvin, Neon,
as Open Source
2016년에 이세돌 알파고 바둑대결을 했고 이세돌이 당연히 이길거라 생각했지만 알파고가 4 : 1로 이김
그때부터 인공지능 이슈가 많이 붉어짐.
인공지능이 가져온 가장 큰 이슈는
1. 인공지능이 윤리적인가
2. 인공지능을 보는 관점, 이용하는 사람이 될지, 이용당하는 사람이 될지,
3. 기본 소득, 로봇 세금 등
2015년에 상당히 유명한 회사들이 핵심적으로 개발한 머신러닝 툴들을 다 오픈 소스로 공개했다. 공개한 이유는 첫 번째는 자기가 이 기술의 리더를 증명하기 위함이고 두 번째는 더 많은 개발자들이 참여해서 이 기술을 더 빨리 발전시켰으면 좋겠다라는 의지가 담겨있다.
특히 요즘은, 인공지능, 머신러닝 관련해서는 소스 뿐만 아니라 논문도 빨리 공개하고 있다. 빨리 공개해서 사람들에게 아이디어도 얻고 아이디어 이후의 혁신을 빨리 수용하기 위함이다. 내가 만든 기술을 다른 사람들이 더 써야지 나도 유명해지고 이 기술도 발전한다.
요즘은 다 오픈소스로 진행된다.
or (35 years) of Open Source Software
User`s View
- Fear Uncertainty Doubt
-> the most Powerful Innovation Tool
Developer`s View
- Sharing(open, participate)
-> Mentoring
FOSS : free, OSS
FLOSS : free libre OSS
오픈소스는 갑자기 나온게 아니라 35년 전쯤 오픈 소스라는 단어를 썼다. 명시적으로 그것을 상업적 도메인에 쓰기 시작한 것은 20년 정도 되었다. 처음에는 오픈소스가 뭔지 모르겠다. 누가 만든지 모르겠다. 상업적으로 이용하는게 어렵겠다.
두려움, 불확실성, 의구심 등 FUD 전략
지금은 오픈소스가 혁신을 이루는 강력한 도구를 확인한 시점
개발자들의 입장은 처음에는 공개하고 참여해야하지 였다가 내가 더 많은 사람들이 오픈소스를 만들 수 있또록 도와주는 멘토링의 개념으로 바뀜
오픈소스에서 3사람
1985년 4월 리차드 스톨만 free software 라는 단어를 썼다.
소프트웨어는 지식의 영역이다 라고 생각했다. 소프트웨어는 팔 수 있는 물건이 아니다. 소프트웨어가 다 공개되어야 한다.
https://zdnet.co.kr/view/?no=20210331160451
https://yozm.wishket.com/magazine/detail/716/
1991년 10월 리눅스 토발즈는 리눅스를 만들었다.
리눅스를 재미로 만들었다. 이걸 free software와 함께 제대로된 os로 만들었다. 커널뿐만 아니라 os가 가져야하는 도구, 라이브러리를 만들어 리눅스를 배포했다. 94~95년 쯤에 인터넷을 접하고 서버를 만들면서 그 때 많이 사용했다. 지금은 세상 모든 장치들이 리눅스로 돌아가고 있다. 안드로이드도 리눅스로 돌아간다. 아이폰도 리눅스는 아니지만 오픈소스에 기반한 시스템이다. GPL이라는 라이센스로 만들어서 실질적으로 오픈소스가 상업적 도메인으로 성장하기 위한 중요한 기반을 만듬.
https://ko.wikipedia.org/wiki/%EB%A6%AC%EB%88%84%EC%8A%A4_%ED%86%A0%EB%A5%B4%EB%B0%9C%EC%8A%A4
1998년 2월 에릭 레이몬드 open source initiative는 오픈소스라는 것이 철학적으로 무조건 공유되어야하고 무조건 공개되어야하는것은 회사가 이용하는게 어렵다. 오픈소스라는 것을 상업 도메인에서 이용할 때 어떻게 볼것인지 정의를 새로 내림. 소스를 오픈하고 그거를 수정할 수 있고 재배포할 수 있으면 그것이 오픈소스다. 내가 오픈소스를 가져다가 뭔가를 개발한 다음에 내껄 다 공개해야하는냐를 마지막 조건을 뺀 것을 오픈소스로 포괄적으로 정의하자.
지금 오픈소스 소프트웨어라고 하는 것은 상업적 도메인에서 비교적 잘 이용할 수 있는 형태의 라이센스를 가진 오픈소스를 말한다.
https://ko.wikipedia.org/wiki/%EC%97%90%EB%A6%AD_%EB%A0%88%EC%9D%B4%EB%A8%BC%EB%93%9C
Why Open Source Software Contribution?
- It`s fun 재밌다.
- it can lead to increased happiness 자부심이 증가한다.
- Learn to code 코드를 배운다.
- Improve conding skills 코딩 실력이 향상
- Gain early experience 고객의 경험을 일찍한다.
- Improve production level software experiences
- Train you in ways that other people aren`t
- Provide a platform to do whatever you want
- Attract quality fellow developers
- Experiencing critical mass
- Stand on the shoulders of giants
- Involve in every design decision
- Build features you want
- Community and peer recognition
- Greater job prospectes
- There are good eyes on who is contributing what
- It shows you`re innovative
- Positions of public trust
- Direct democracy
- Trust enalbes cooperation
- Self-organization with shared goals
- Learn to communicate positively
- Learn respect otehr people`s ideas
- It can inspire passion
- Teaching the next generation
- It`s idealistic 이상적이고
- It`s the way of the future 오픈소스가 미래로 가는 길이다.
- Multiplying the company`s investment
- Benefitting from the most recent advance
- Spreading knowledge of the software
- Increasing the developer base
- Upgrading internal developer skills
- Building reputation
- Recruiting and retaining developers
- Faster startup of new companies and projects
회사에서는 최소의 투자로 최대의 결과를 얻는 방법이다. 오픈소스를 하는 대부분의 회사의 결정적 이유 중 하나는 우리 회사의 개발자들이 밖에 있는 개발자들하고 일한다. 밖에 있는 좋은 개발자들을 볼 수 있고 그 개발자들을 우리 회사로 끌어들일 수 있다.
Top Contributing Companies to GitHub
MS, GOOGLE, REDHAT, IBM, FACEBOOK, UBER, GITHUB
2018년에 MS가 Github를 인수했다. 오픈소스가 돈이 되기 때문이다.
2018년에 IBM도 Redhat이라는 리눅스를 인수했다. 리눅스 시장의 대부분을 redhat을 가지고 있다.
https://terms.naver.com/entry.naver?docId=3580446&cid=59088&categoryId=59096
오라클은 데이터베이스로 먹고 사는데 대표적인 비 오픈소스 회사이다.
Open Source의 정의
정의 1 : 자유롭게 열람, 사용, 수정하고, 다른 사람에게 배포할 수 있도록 만든 모든 것. (소프트웨어, 하드웨어, 설계, 저작물, 아이디어, ...)
- 강한 규칙 : 라이센스 (저작권)
GNU, BSD, Apache, MIT 등 70 + 종
에릭 레이먼드의 사이트에는 오픈소스 저작권에 대해 잘 정의 되어 있다.
정의 2 : Community에서 Open Projcet로 집단 협업으로 만든 모든 것
- 강한 절차(process)
-> 동료 검토 (Peer Review)
-> 효율적 의사결정
Open Source License
OSS 라이선스는 기본적으로
- 소프트웨어의 사용을 장려하기 위한 문서
- 참여자들의 (경제적 또는 비 경제적) 이익이 최대가 되는 합의
-> 코드 자산, 특허, 상표권
- 공유와 헌신에 대한 예의
-> Reputation, 원본 소스의 존중
-저작자의 오픈 소스에 관한 철학의 존중
-> 파생물의 공개 조건
Permissive (가져다 쓰고 수정/추가한 건 Open 하지 않아도 됨)
Strongly Protecttive (가져다 쓰고 난 다음 수정/추가한 건 너도 공개해야 함)
Weakly Protective (이런 조건이 되면 너껀 공개하지 않아도 됨 유보적인 영역을 두는 것)
지금은 Permissive한 영역의 오픈소스가 많아지고 있음. 내가 만들고 더 많은 사람들이 쉽게 쓸 수 있음.
Permissive License는 동작할까?
Bad Choice의 예
커뮤니티 v1.0이 있다.
우리회사 v1.0 + a = v1.0a (a)
-> v1.0을 가져다가, 버그 좀 고치고, 빌드 수정하고 우리 고객이 원하는 새로운 기능 a를 추가
(공개 x)
커뮤니티가 기능 b, c를 추가 v1.0 + b,c = v1.1 (bc)
우리회사 v1.1 (bc) + a, d = v1.1d (abcd)
우리 고객은 b, d 기능을 원하므로 v1.1을 가져다가
다시 버그 좀 고치고, 빌드 수정하고, 다시 기능 a와 / 새로운 d를 추가 -> v1.1d
커뮤니티 v1.1 (bc) + A, e = v1.2(abce)
커뮤니티도 기능 a를 A로 구현, e 기능도 추가
-> 우리 고객도 당연히 a와, 새로운 e, 그리고 f 기능도 원하는데? 앗, A는 a 기능 접근 API가 다르네??
커뮤니티 v1.2 + dfghij = v2.0 (abcdefghi)
-> 세상 모든 고객이 원하는 기능 d,f,g,h,i,j를 추가 메이져 버전 업
우리회사 v1.2 + d, f = v1.2f( abcdef)
-> 아니면 v1.2를 가져다가 다시 버그 좀 고치고, 빌드 수정하고 우리 a를 쓰던 코드를 A에 맞게 수정하고 다시 d와 새로운 f를 추가
-> 빨간 글씨들의 작업들이 새로운 가치를 만들지 않는 작업이다. 개발자들이 저 일을 하면 짜증난다. 이런게 버전이 증가하면서 계속 발생한다. 그런데 어느 순간이 되면 우리 고객이 심각한걸 원하거나 예전에 했던 작업들을 계속 반복해야 하는게 힘들 때 커뮤니티 버전과 다른 새로운 버전을 만들어서 따로 가겠다.
우리회사 v1.1d + e, f = x2.0
-> v1.1d에 새로운 e, f를 추가 이제부터 따로 가는 거야
커뮤니티도 우리 회사도 계속 발전하는데 나중에 가면 커뮤니티가 발전한 것과 상관없이 우리가 모든 리소스를 새로 들여 개발을 하는 문제가 발생하고 비용이 발생한다. 비용이 반복적으로 들어간다. 그래서 Permissive한 라이센스를 잘 활용하는 방법으로 우리걸 숨기는 건 좋지 않은 방법이다.
Permissive License는 동작할까?
Good Choice의 예
커뮤니티 <== 우리회사 (혁신적인 고객을 가진)
커뮤니티 v1.0
우리회사 v1.0 + a = v1.01 (a)
-> v1.0을 가져다가, 버그 좀 고치고, 빌드 수정하고, 우리 고객이 원하는 기능 a도 추가하여 upstream에 반영
커뮤니티 v1.01(a) + b, c = v1.1 (abc)
-> 커뮤니티가 기능 b, c를 추가
우리회사 v1.1 + d = v1.11(abcd)
-> 우리 고객도 b와 새로운 d 기능을 원하므로 v1.1을 가져다가 기능 d를 추가하여 upstream에 반영
커뮤니티 v1.11(abcd) + e = v1.2(abcde)
-> 커뮤니티가 기능 e를 추가
우리회사 v1.2(abcde) + f = v1.21(abcdef)
-> 우리 고객도 e와 새로운 f 기능을 원하므로 v1.2를 가져다가 기능 f를 추가하여 upstream에 반영
커뮤니티 v1.21(abcdef) + ghji = v2.0(abcdefghi)
-> 세상 모든 고객이 원하는 기능 g, h, i, j를 추가 메이져 버전 업
중복 개발 없이, 기술 부채 없이, 새로운 기능만 개발 가능해진다.
What is so called OPEN?
Open to community (for participation / contribution)
- The Project : Source Code, Documents, Roadmap
- The Governance (process) : Decision Making, Contributing
- The People : Developers, Tech Evangelist, ...
Start at github.com
오픈이 뭐냐?
오픈 소스라는 의미대로 소스코드를 오픈, 문서도 오픈, 로드맵 공개
의사결정을 어떻게 하는지 공개
우리의 개발자를 공개
Why we hesitate?
Competition ?
- then, open early !!
- Win the technology ownership and leaership by keeping the originality
- Based on the ownership, lock users in the community
경쟁구도
Immature Code ?
- Then, open early !!
- Developers and the community will do the right thing
- Peer review always works
지저분한 코드
Security ?
- Then, open early !!
- Serious users will look and watch your codes line by line
- Let good hackers work earlier than bad hackers
보안
요약
Open Source Softeware 20년(에릭), 35년(스톨만), 수천년
- Why에서 What으로, What에서 How로
- 공유에서 참여로, 참여에서 멘토링으로
Way to Open Source
- Step 0 : 통제를 포기하는 신념
- Step 1 : Open하고 있어야 Open
- Step 2 : 진정성 그리고 기다림
Community로 나가세요
- ㅠㅠ
- Online community also works
문제 1. 강의에서 언급된 내용 중 오픈소스를 활요하지 않는 이유 중 옳지 않은 것은?
1. 경쟁 구도에 따른 우려심
2. 오픈소스 저작권의 독점
3. 소스코드 공개에 따른 보안 취약성
4. 중요 기술, 혁신 기술의 선점
문제 2. 오픈소스의 정의와 특징으로 옳은 것은?
1. 오픈소스는 누구에게나 공개하지만 사용과 수정은 불가능하다.
2. 자유롭게 열람, 사용과 수정은 가능하며, 상업적 용도 외에는 배포도 가능한 모든 소스를 말한다.
3. 자유롭게 열람, 사용과 수정이 가능하며, 다른 사람에게 배포할 수 있도록 하는 모든 소스를 말한다.
4. 오픈소스는 자유롭게 열람과 사용은 가능하지만 수정은 없이 원본 그대로 사용해야한다는 제약이 있다.
문제 3. 오픈소스의 중요성과 기여해야하는 이유로 옳지 않은 것은?
1. 처음부터 끝까지 다른 사람이 나의 프로젝트를 무료로 개발해준다.
2. 다른 사람과 소통을 하고 다른 사람의 소스를 보면서 경험을 쌓을 수 있다.
3. 다른 사람과의 협업을 통해 본인의 능력을 기를 수 있다.
4. 실제 오픈소스 수요자(고객 등)를 대하는 실습을 해볼 수 있다.
문제 4. 허용적인 라이선스(permissive license)의 동작 기능에 대한 설명으로 옳지 않은 것은?
1. 기업 내의 개발자만 참여가 가능하다.
2. 프로젝트 수정 및 보완 과정에서 버전 관리가 용이하다.
3. 프로젝트 수정 및 보완 과정에서 시간과 비용 절약이 가능하다.
4. 혁신적인 기능을 손쉽게 반영할 수 있다.
문제 5. 오픈소스 활용 및 선구자로 꼽히는 인물 중 옳지 않은 사람은?
1. chatGPT
2. 리처드 스톨만
3. 리눅스 토발즈
4. 에릭 레이몬드
21111