정부 지원금으로 개발되는 소프트웨어

주의: 이글은 계속해서 수정되어진다.
왜냐면 내생각이 정리되면서 이글을 그때그때 반영하기때문이다.
따라서 이글을 고지곳대로 보아서는 안된다.
이내용에 관심이있다면 적어도 장기간 이글의 변화를 관찰할 필요가 있다.

우선 사람들이 햇갈려하겠지만 운영체제도 소프트웨어에 속한다는 전제를 둔다.
그것은 합리적이고 당연한것이니까.

우리나라 정부주도로 개발을 진행했던 OS들 대체 지금 그것들이 무엇을 남겨놨는지 모르겠다.
그래서 그간의 것들은 정말 비효율적이었다고 생각한다.

정부 주도의 국산 OS의 필요성은 충분히 느낀다.
그러나 그전에도 우리가 OS를 개발한다고 얼마나 많은 돈을 퍼부었던가?

그러나 그런 프로젝트들이 지금 오픈소스 세계에 무엇을 기여했는가?
또 그것들중 지금 그 결과물들을 이용할수있는것들은 몇개나 되나?
어차피 정부주도의 국산OS들은 기존의 오픈소스의 결과물을 기반으로 하지않던가?
그런것들이 지금에 무엇의 밑거름이 되었던가?
우리나라에서 만든 그것들은 세금으로 자신들의 배나 불리웠지
대체 오픈소스나 국민들이 체감할 만족할 결과물이란걸 내놓은게 있던가?

예를들면 정부 지원금으로 만들어진 하모니카는 그저 UI만을 한글화하는데 목적이 있는것 같다.
사용할때 간혹 떠오르는 버그는 어떻게 처리되는건가?
그들은 시스템의 안정성에 기여를 하고있던건가?
그리고 정부지원이 끊났을때 지속가능한 운영체제로 남아있는가?
그건 그렇다해도 그들이 기존 소프트웨어들을 이용하여 OS를 구성하면서도 그것들중에 어떤것에 집중적으로 오픈소스의 기여를 했었던가?

구름OS 또한 그런식으로 진행될거라면 또는 진행중이라면 개발하나마나한것아닌가?
그리고 하모니카로부터 무엇을 받아낼수있는건가?

그래서 나는 다음과같이 제안한다.

1. 프로젝트의 선택

업체들이 지속가능한지를 봐야한다.
정부 지원이 끊겼을때도 존재가 가능한지도 중요하다.
정부지원이 살아있을때만 꽃을 피웠다가 끊기면 죽는 고목같은 프로젝트는 최소화되어야한다.

2. 프로젝트의 관리
정부주도의 진행중인 프로젝트는 국가가 관리하는 저장소에 주기적으로 백업되어야한다.
그리고 반드시 계획표에 맞는 중간 점검을 받도록 해야한다.

3. 프로젝트의 결과물
반드시 다음과같은 결과물이 저장소에 저장되어 있어야한다.
(가) 제안서
(나) 계획서
(다) 저장소에 제출한 의견(commit)
(라) 문서
(마) 의견달린 소스
(바) 바이너리 결과물
(사) 기타 개발에 진행된 모든 문서
개발중인 프로젝트는 비공개로 처리되고 개발이 중지된 프로젝트는 필요한 항목을 공개해야한다.

4. 선택과 집중의 기여
모든 운영체제 개발은 본인들이 맨땅에 개발하는게 아니고 가져다 쓰는정도일것이다.
그럼에도 불구하고 모든것을 전부 조금씩 손대봐야 버그만 나오므로 그게 무엇이되었던간에 정확하게 하나에만 집중해야한다.

따라서, 다음과같은 정책이 필요하다.

(가) 운영체제의 안정화에따른 기여
(나) 구성 소프트웨어들 중 하나에 대한 안정화 기여

여기서 기여라는 단어는 중요하다.
오픈소스이므로 반드시 언젠가는 공개되어야한다는것이다.

(나)항은 예를 들면 한글입력기하나만큼은 앞으로도 크게 손대지 않을정도로 확실하게 
문서화, 의견(주석)달린 소스, 바이너리를 결과물로 제공하게 하는데 목적을 둬야 한다.
아니면 웹레이트나 트랜스펙정도는 번역해주는 결과물은 있어야 하는것아닌가?

최소한 개발이 중단되더라도 오픈소스를 통해 누가되었던간에 
거기서 건져낼수있는건 건져내게 해야한다.

예를 들어 자동차를 만들다 실패하더라도 변속기나 기관아니면 최소한 에어백 시스템정도는 건져서 다른 프로젝트때 쓸 수 있어야 한다는것이다.
새로운 프로젝트에서 그것을 100% 그대로 쓸 순 없겠지만, 문서와 소스, 결과물이 모두 존재한다면 
조그만 손보고 재사용되게 해주는정도는 되어야하는것아닌가?

나라의 세금이용하는데 이정도의 결과물을 요구하는게 타당하지않겠는가?


5. 최대한 오픈 소스 시스템을 이용할것
소스는 깃허브에, 한글 번역은 웹레이트나 트랜스펙을 이용하여 후대 프로젝트들이 그것을 그대로 이용할수있도록 해야한다.
그리고 정부가 이런 결과물을 보관하기위한 저장소를 운영해야한다.

6. 정부 지원이라도 실패하면 누구라도 상용화 할수있도록할것.
GPL 허가서라는건 누구든 사용하는데 문제가 되지않는다.
왜 정부지원 결과물이 실패하면 받아서 상용화라도 시켜야한다.
다만 아래의 내용은 반드시 강제시켜야한다.

(가) 그대로 상용화 해서는 안되고, 반드시 수정해야하고, 또한 최소한 반드시 성장가능한 소프트웨어 1종에는 기여해야한다.
(나) 반드시 정부지원제품이라는 워터마크나 기록을 보이는곳에 해야한다.
(다) 정부가 만든 소스로 개발한 소스는 일정기간 개발이 중단되면 반드시 정부에 반환해야한다.
(라) 사용자가 같은 국가라면 사용에 제한을 둬서는 안된다. 
- 이부분은 다른나라의 국가주도 오픈소스 프로젝트 정책을 참고할 필요가 있다.


7. 그리고 지속적으로 오픈소스를 성장시켜야한다.
오픈소스가 성장되도록하려면 지속적인 관심과 지원이 필요하다.
멍청한 시장원리로 돈안되니 신경을 끄게되면
우리는 그멍청한 시장원리를 배반한 국가들의 제품을 비싼돈을 내고 사용해야한다.
국내 어떤회사가 안드로이드를 쳐내는 과오따위를 저지르지 말아야 한다.
(어쩌면 잘된 일일 수 있겠지만..)


8. 성장이 끝난 프로젝트
정부는 결과물을 반드시 수거하고, 이성장을 이어줄 후속 사용자를 발굴해야한다

9. 사용자들이 오픈소스에 기여할 수 있는 환경
사실 위의것들은 대부분 돈을이용해 기업을 통해 움직일수 있다.
그러나 가장 중요한것은 최종 사용자이다.
최종 사용자들이 사용하지 않으면 그것이 도대체 무슨의미가 있겠는가?
하모니카처럼 최종사용자의 요구사항을 맞추지 못한체 정부눈치만 보며 개발물만 덩그러니 만들어놨으니 이게 전시행정이 아니고 무엇이겠는가?
이게 하모니카의 문제가아니라 대부분 관공서를 끼고 하는 사업들이 국민의 눈높이를 맞추지 못하고 공무원들 기준에만 맞춰 사업을 하다보니 세금들여서 국민만 불편하게만든다는 말이 나오는것이다.

나는 정답을 되줄순없지만, 이런것은 역추적해봐야한다.
최종사용자들이 결과물에 불만을 가졌다는 기사나 소문이나온다.
-> 왜? 최종사용자와는 전혀 맞지않기때문이다.
-> 동호회를 만들어둔다.
    동호회는 사유화되어서는 안된다.
    왜냐면 거기서나온의견은 세금에대한 평가이기때문인데 사유화되면 의견들이 조작될 수 있기때문이다.
    사유화되면 내용이 초기화되거나 비공개되거나 삭제될수있다.
    따라서 국가에서 직접 이런 의견을 받는 저장소를 제공해야한다.
-> 최종사용자들이 모여든다.
-> 최종사용자들의 의견이 모여진다.
-> 의견에 맞는 개선을 한다.

결론은 사용자들에게 떡밥을 던져서 물게 하는것이 좋다.
사용자들의 관심이 소프트웨어를 개선시키는데 동력이된다.

이런사용자들의 참여 또는 기여의 방법에는
영문을 한글화(예를들면 하모니카 리눅스의 홈페이지처럼 한글화하는 환경을 제공하는것.),
유용한 프로그램파일을 공유(예를들면 사용자가 재고관리 엑셀을 만들어 다른 사용자끼리 공유하는것)
확장 소프트웨어를 만드는것(예를들면 파이어폭스나 리브레오피스가 사용자에의해 부가기능프로그램을 제작할수있는 API와 공유할수있는 환경을 제공함)
등이있다.

이렇게하려면 사용자들이 비빌언덕인 플랫폼을 만들어놔야 한다.
이런 플랫폼에는 API를 제공해야하고 그것을 통해 사용자들이 제작하고 배포하고 다운받을수있는 환경도 제공해야한다.
즉, 윈도우즈 시리즈에서는 마켓기능, 구글에는 구글스토어같은것이고 파이어폭스나 리브레오피스도 그런환경을 지원하고있다.

10. 정부의 역할
정부는 개발 업체들이 더 좋은 청사진을 만들게하고
그 청사진에 맞는 개발물을 차질없이 만들게 하는것이다.
그리고 개발물을 최종사용자들이 잘 사용하고 잘 참여하게 해야한다.
이런 방식은 구글이나 애플같은 기업이 공장없이 스마트폰을 만드는 방식과 같다고 할 수 있다.