17 공개 과학과 협업
“공개(open)”의 반대는 “폐쇄(closed)”가 아니라 “망가짐(broken)”이다.
The opposite of “open” isn’t “closed”. The opposite of “open” is “broken”.
– John Wilbanks
정보의 자유로운 공유는 과학에서 이상적일지 모르지만, 현실은 좀 더 복잡하다. 현재 일반적인 현장 상황은 다음과 같다.
- 과학자가 데이터를 수집하고 학과에서 가끔 백업되는 컴퓨터에 저장한다.
- 데이터를 분석하기 위해 작은 프로그램을 작성하고 수정한다. (프로그램도 연구원의 로컬 노트북에 저장된다.)
- 적당한 분석 결과가 생성되면, 논문을 작성해서 제출한다. 데이터를 논문에 포함할 수도 있다. (점점 많은 저널이 데이터를 요구한다.) 하지만 프로그램 코드는 포함하지 않을 가능성이 크다.
- 시간이 흐른다.
- 저널에서 연구원 분야의 익명의 소수 심사자로부터 받은 검토(review) 결과를 보낸다. 검토 결과를 충족하도록 논문을 수정한다. 수정하는 동안 이전에 작성한 프로그램과 스크립트를 변경해서 다시 제출한다.
- 더 많은 시간이 흐른다.
- 최종적으로 논문이 출판된다. 논문에 데이터의 온라인 사본 링크를 포함할 수도 있다. 하지만 논문은 유료 장벽(paywall)에 막혀있어서 개인이나 기관 접근 권한을 가진 사람만이 논문을 읽을 수 있다.
하지만 점점 더 많은 과학자들이 진행하는 연구 프로세스는 다음과 같다.
- 과학자가 수집한 데이터는 수집되는 즉시 figshare나 Zenodo와 같은 공개 접근 저장소에 저장되고, 디지털 객체 식별자(Digital Object Identifier, DOI)가 부여된다. 또는 데이터를 미리 게시하고 Dryad에 저장한다.
- 과학자가 작업물을 보관할 GitHub 저장소를 생성한다.
- 분석 작업을 수행하면서 스크립트의 변경 사항을 (아마도 몇몇 산출물도 포함해서) 저장소에 푸시한다. 논문을 위한 저장소를 다목적으로 사용하며, 이 저장소가 다른 동료 과학자와 협업하는 허브가 된다.
- 논문 상태에 만족할 정도로 진행되면, arXiv 혹은 다른 사전 출판 서비스에 게시하고 다른 동료 과학자를 초대해서 피드백을 받는다.
- 피드백에 기초해서 저널에 논문을 최종 제출하기 전에 몇 번의 수정 사항을 게시할 수도 있다.
- 출판된 논문은 사전 출판 논문, 코드, 그리고 데이터 저장소의 링크를 포함한다. 이를 통해 다른 과학자가 해당 연구를 시작점으로 삼아 연구를 쉽게 연결해서 수행할 수 있다.
이러한 공개 연구 모형은 발견을 가속화한다. 연구 작업이 더 많이 공개될수록 더 많이 인용되고 재사용된다. 하지만 이런 방식으로 작업하고 연구하고자 하는 사람들은 실무에서 “공개(open)”가 정확히 무엇을 의미하는지에 대해 몇 가지 결정을 내릴 필요가 있다. 공개 과학(Open Science)에 관한 다른 측면에 대해서는 Opening Science를 참고한다.
이것이 버전 제어(version control)를 가르치는 (많은) 이유 중 하나다. 버전 제어가 꾸준히 사용될 때, 컴퓨터 작업에 대한 공유 가능한 전자 연구 노트로 활용되어 “방법”에 대한 질문에 답을 한다.
- 누가 언제 무엇을 했는지를 포함해서 작업에 대한 개념적 단계가 문서화된다. 모든 단계는 (커밋 ID) 식별자로 도장이 찍힌다. 식별자는 의도와 목적을 가지며 중복되지 않고 유일성을 갖는다.
- 정당성(rationale), 아이디어, 다른 지적 작업에 대한 문서화를 이로부터 파생된 변경 사항과 묶을 수 있다.
- 중복되지 않고 유일하며 복구 가능한 방식으로 컴퓨터 작업 결과물을 얻어서 연구에 사용할 것을 조회할 수 있다.
- Git 같은 분산 버전 제어 시스템으로 버전 제어 저장소는 영속성을 쉽게 얻을 수 있고 전체 이력을 담아낼 수 있다.
버전 제어 저장소에 올라온 모든 것(데이터, 코드, 논문 등)은 인용 가능한 객체로 변환될 수 있다. 인용 절에서 인용하는 방법에 대해 학습하게 된다.
연구실 동료 중 한 명에게 논문에 나온 내용과 웹으로만 최근에 본인이 성취한 결과를 재현할 수 있는지 물어본다. 동료 결과물 중 하나에 대해서도 같은 작업을 수행해 본다. 그리고 나서 일하고 있는 연구실에 나온 결과물에 대해서도 시도를 해본다.
2~3분 정도 인터넷을 검색하고 앞에서 언급된 데이터 저장소를 조사해 본다. 예를 들어, Figshare, Zenodo, Dryad. 전공 분야에 따라 본인 전공 분야별로 잘 알려진 저장소가 도움이 될 수 있다. Nature에서 추천한 데이터 저장소도 유용할 수 있다.
주변 동료와 현재 작업에 사용하고 있는 데이터 저장소에 대해 토론해 보고, 이유도 설명해 보자.
.md5나 .psd와 같은 대용량 데이터나 이미지 파일은 오픈 소스 확장 도구인 Git Large File Storage를 사용하여 GitHub 저장소 내에서 추적할 수 있다. 자동으로 대용량 파일의 내용을 원격 서버에 업로드하고 GitHub 저장소 내의 파일을 텍스트 포인터로 대체한다.
Git Large File Storage 확장 도구를 다운로드하여 설치한 다음, GitHub 저장소에 대용량 파일 추적을 추가한다. 동료에게 저장소를 복제하도록 요청하고, 해당 대용량 파일에 접근할 때 무엇을 보는지 설명요청을 한다.
17.1 협업
앞서 개인 이력관리와 GitHub 저장소에 중점을 두었다면 공개과학을 위한 협업방법을 살펴보자. 먼저, 짝을 이룬다. 한 사람이 “소유자”(연습을 시작하는 데 사용될 GitHub 저장소 주인)가 되고, 다른 사람이 “협력자”(소유자 저장소를 복제해서 변경을 하는 사람)가 된다. 목표는 협력자가 변경 사항을 소유자 저장소에 추가하는 것이다. 마지막에는 역할을 바꿔서 두 사람 모두 소유자와 협력자의 역할을 수행한다.
혼자서 쭉 진행해 왔다면 두 번째 터미널을 열어서 계속 실습을 진행할 수 있다. 두 번째 윈도우가 여러분의 협력자를 나타내고 다른 컴퓨터에서 작업하고 있는 것으로 볼 수 있다. GitHub 접근 권한을 다른 사람에게 줄 필요가 없어졌다. 왜냐하면 두 협렵 ‘파트너’ 모두 본인이기 때문이다.
소유자가 협력자에게 접근 권한을 부여할 필요가 있다. GitHub에서 오른쪽에 ‘setting’ 버튼을 클릭해서 협력자(Collaborators)를 선택하고 파트너 이름을 입력한다.
소유자 저장소에 접근 권한이 부여되면 협력자(Collaborator)는 https://github.com/notifications으로 이동한다. 그곳에서 소유자 저장소의 접근을 수락하면 된다.
다음으로 협력자(Collaborator)는 소유자 저장소 사본을 본인 컴퓨터로 내려받는다. 이런 작업을 “저장소 복제(cloning a repo)”라고 부른다. 소유자의 저장소를 본인 바탕화면(Desktop) 폴더에 클론하려면 협력자는 다음 명령어를 입력한다.
$ git clone https://github.com/vlad/planets.git ~/Desktop/vlad-planets’vlad’를 소유자 사용자 이름(저장소를 소유하고 있는 사람)으로 바꾼다.
앞서 작업했던 것과 정확히 동일한 방식으로 협력자는 이제 소유자의 저장소 클론에서 변경을 마음대로 할 수 있다:
$ cd ~/Desktop/vlad-planets
$ nano pluto.txt
$ cat pluto.txt
It is so a planet!$ git add pluto.txt
$ git commit -m "Add notes about Pluto"
1 file changed, 1 insertion(+)
create mode 100644 pluto.txt그리고 나서 변경 사항을 GitHub의 소유자 저장소로 푸시한다:
$ git push origin main
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 306 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/vlad/planets.git
9272da5..29aba7c master -> master주목할 점은 origin이라는 원격 저장소를 생성할 필요가 없다는 것이다. 저장소를 복제(clone)할 때 Git이 자동으로 origin 이름을 붙여준다. (수작업으로 원격 설정을 할 때 앞에서 왜 origin 이름을 사용한 것이 현명한 선택인지 이해할 수 있다.)
이제 GitHub 웹사이트에서 소유자 저장소를 살펴본다(아마도 웹 브라우저를 새로 고침해야 할 수 있다). 협력자가 신규 커밋을 한 것을 확인할 수 있다.
소유자 로컬 컴퓨터로 GitHub 원본 저장소의 변경 사항을 다운로드하려면 소유자는 다음과 같이 입력한다.
$ git pull origin main
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://github.com/vlad/planets
* branch master -> FETCH_HEAD
Updating 9272da5..29aba7c
Fast-forward
pluto.txt | 1 +
1 file changed, 1 insertion(+)
create mode 100644 pluto.txt저장소를 복제(clone)할 때 Git이 자동으로 origin 이름을 붙여주기 때문에, origin이라는 원격 저장소를 따로 생성할 필요가 없다는 점에 주목한다. (이것이 앞에서 원격 설정을 수작업으로 할 때 origin 이름을 사용한 것이 현명한 선택이었던 이유다.)
GitHub에서 소유자 저장소를 다시 살펴보면, 협력자가 만든 새로운 커밋을 볼 수 있다. 새로운 커밋을 보려면 브라우저를 새로 고침해야 할 수도 있다.
이제 로컬 저장소는 origin이라고 불리는 하나의 “원격 저장소”를 가지고 있었다. 원격 저장소는 다른 곳에 호스팅되어 있는 저장소의 복사본으로, 푸시(push)하고 풀(pull)할 수 있는 곳이며, 하나의 원격 저장소로만 작업해야 할 이유는 없다. 예를 들어, 대규모 프로젝트에서는 자신의 GitHub 계정에 자신만의 복사본을 가질 수도 있고(이를 origin이라고 부를 수 있음), 또한 메인 “상위” 프로젝트 저장소(예제에서는 이를 upstream이라고 부르겠음)를 가질 수 있다. 다른 사람들이 커밋한 최신 업데이트를 받기 위해 수시로 upstream에서 풀을 받을 것이다.
원격 저장소에 부여하는 이름은 로컬에서만 존재한다는 것을 기억하자. 임의로 선택한 원격 저장소 별칭으로 origin이든, upstream이든, fred든 - 원격 저장소 고유한 것은 절대 아니다.
git remote 명령어 계열은 저장소와 연결된 원격 저장소를 설정하고 변경하는 데 사용된다. 가장 유용한 명령어들로 다음과 같은 것들이 있다.
git remote -v: 설정된 모든 원격 저장소를 나열한다.git remote add [name] [url]: 새로운 원격 저장소를 추가하는 데 사용된다.git remote remove [name]: 원격 저장소를 제거한다. 원격 저장소 자체에는 전혀 영향을 미치지 않고, 단지 로컬 저장소에서 그것에 대한 링크만 제거한다는 점에 유의한다.git remote set-url [name] [newurl]: 원격 저장소와 연결된 URL을 변경한다. 원격 저장소가 이동했을 때 (예: 다른 GitHub 계정으로, 혹은 GitHub에서 다른 호스팅 서비스로), 또는 원격 저장소를 추가할 때 오타를 냈을 때 유용하다!git remote rename [oldname] [newname]: 원격 저장소의 로컬 별칭, 즉 이름을 변경한다. 예를 들어, 이를 사용하여upstream을fred로 변경할 수 있다.
GitHub에서 협력자의 변경 사항을 다운로드하기 위해 이제 소유자는 다음을 입력한다.
$ git pull origin main
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/vlad/planets
* branch main -> FETCH_HEAD
9272da5..29aba7c main -> origin/main
Updating 9272da5..29aba7c
Fast-forward
pluto.txt | 1 +
1 file changed, 1 insertion(+)
create mode 100644 pluto.txt이제 저장소 3개(소유자 로컬 저장소, 협력자 로컬 저장소, GitHub의 소유자 저장소) 모두 동기화되었다.
실무에서 협업하는 저장소의 가장 최신 버전을 갖도록 확인하는 것이 좋다. 어떤 변경을 가하기 전에 git pull 명령어를 먼저 실행해야 한다. 기본적인 협업 작업 흐름은 다음과 같다:
git pull origin main명령어로 본인 로컬 저장소를 최신 상태로 갱신한다.- 변경 작업을 수행하고
git add명령어로 준비 단계(staging area)로 보낸다. git commit -m명령어로 변경 사항을 커밋한다.- GitHub에
git push origin main명령어로 변경 사항을 업로드한다.
상당한 변경 사항을 포함한 단 한 번의 커밋보다는 작은 변화를 준 커밋을 많이 하는 것이 좋다. 작은 커밋이 가독성도 좋고 리뷰하기도 더 편하다.
역할을 바꿔서 전체 과정을 반복한다.
협력자에게 어떤 정보도 주지 않고 소유자가 저장소에 커밋을 푸시했다. 협력자는 명령줄(command line)을 통해 무엇이 변경되었는지 어떻게 알 수 있을까?
명령줄에서 협력자는 로컬 저장소에 원격 저장소 변경 사항을 git fetch origin master 명령어를 사용해서 가져올 수 있다. 하지만 그 자체로 병합(merge)되는 것은 아니다. git diff master origin/main 명령어를 실행해서 협력자는 터미널에 변경 사항을 확인할 수 있다.
GitHub에서도 협력자는 포크된 저장소로 가서 “This branch is 1 commit behind Our-Repository:master.” 메시지를 볼 수 있다. Compare 아이콘과 링크가 걸려 있다. Compare 페이지에서 협력자는 base fork를 본인 저장소로 변경하고 나서 “compare across forks” 위에 링크를 클릭한다. 마지막으로 head fork를 주 저장소로 변경한다. 이 작업을 하게 되면 차이 나는 모든 커밋을 볼 수 있게 된다.
협력자는 소유자가 변경한 한 줄에 대해 질문을 가질 수 있고 일부 제안 사항도 있다.
GitHub으로 커밋 차이에 대해 주석을 다는 것도 가능하다. 파란색 주석 아이콘(comment icon)을 클릭하면 주석 윈도우(comment window)를 열 수 있다.
협력자는 GitHub 인터페이스를 사용해서 코멘트와 제안을 남길 수 있다.
일부 백업 소프트웨어는 파일 버전에 대한 이력을 기록하고 있다. 또한 특정 버전을 복구하는 기능도 제공하고 있다. 이러한 기능이 버전 제어와 어떻게 다른가? 버전 제어, Git, GitHub을 사용하는 좋은 점은 무엇인가?
17.2 라이선싱
17.2.1 소프트웨어 라이선스
소스 코드, 원고, 다른 창의적 저작물을 갖는 저장소가 공개될 때는 저장소 기반 디렉터리에 LICENSE 혹은 LICENSE.txt 파일을 포함해서 콘텐츠가 어떤 라이선스로 이용 가능한지를 명확히 기술해야 한다. 이유는 소스 코드가 창의적 저작물로서 자동적으로 지적재산(따라서 저작권) 보호 대상에 부합되기 때문이다. 자유로이 이용 가능한 것으로 보여지거나 명시적으로 광고되는 코드라고 해서 그런 보호가 유예되는 것은 아니다. 따라서 라이선스 문장이 없는 코드를 (재)사용하는 누구나 스스로 위험에 처하게 된다. 왜냐하면 소프트웨어 코드 저자가 언제라도 일방적으로 재사용을 불법화할 수 있기 때문이다. 즉, 저작권 소유자가 당신을 저작권법 위반으로 고소할 수 있다.
라이선스는 그렇지 않다면 보유하지 못할 권리를 다른 사람(라이선스 허여자, licensee)에게 부여함으로써 이 문제를 해결한다. 어떤 조건 아래서 무슨 권리가 부여될지는 라이선스마다 다소 차이가 난다. 독점적 라이선스와 대조적으로, Open Source Initiative에서 공인된 오픈 라이선스(open licences)는 최소한 다음에 나온 권리를 모두 부여한다. 이런 권리를 오픈 소스 정의(Open Source Definition)로 부른다:
- 소스 코드는 제약 없이 이용 가능하고 사용되고 재배포될 수 있다. 종합 배포의 일부로서도 포함된다.
- 변형 혹은 다른 파생 저작물도 허락되고 또한 재배포될 수 있다.
- 이런 권리를 누가 받느냐의 질문이 차별의 조건이 되지 않는다. 예를 들어 상업적 혹은 학술적처럼 노력 분야에 의해서가 아님도 포함된다.
특히 지금까지 라이선스 몇 개가 인기를 얻고 있는데, choosealicense.com 웹사이트에서 본인 상황에 적합한 일반적인 라이선스를 선택하는 데 도움이 된다. 주요한 고려사항에는 다음이 포함된다:
- 특허권을 주장하고자 하는가?
- 파생 저작물을 배포하는 데 다른 사람도 소스 코드를 배포하도록 강제할 것인가?
- 라이선싱하는 콘텐츠가 소스 코드인가?
- 이왕이면 소스 코드도 라이선스할 것인가?
적절한 라이선스를 가장 잘 선택하는 것이 상당히 많은 가능한 조합이 있어 주눅이 들 수도 있다. 실무에서 일부 라이선스만 지금까지 가장 인기가 있고 다음이 그 범주에 포함된다:
- GNU 일반공중 라이선스 (GPL),
- MIT 라이선스,
- BSD 라이선스,
- 아파치 라이선스, 버전 2.0.
GPL은 다른 대부분의 공개 소스 라이선스와 다른데, 전염성이 있는(infective) 특징이 있다. 코드의 수정된 버전을 배포하는 누구나 혹은 GPL 코드를 포함한 어느 것이든지 자신의 코드도 동일하게 자유로이 공개 가능하게 만들어야 한다.
흔히 사용되는 라이선스를 선택하는 것이 기여자나 사용자의 삶을 편하게 한다. 왜냐하면 기여자나 사용자 모두 해당 라이선스에 친숙해서 사용할 때 상당한 양의 전문 용어를 꼼꼼히 살펴볼 필요가 없기 때문이다.
Open Source Initiative와 Free Software Foundation 모두 좋은 선택이 될 수 있는 라이선스 목록을 유지 관리하고 있다.
코드를 작성하는 과학자 관점에서 라이선싱과 라이선싱 선택지에 대한 전반적인 정보를 [@Morin2012] 에서 살펴볼 수 있다.
결국 가장 중요한 것은 라이선스가 무엇인지에 대해 분명한 문장이 있는지와 라이선스가 OSI와 FSF에서 승인되고 이미 검증된 것인지 여부다. 또한 저장소에 공개된 것이 아닐지라도, 처음부터 최선으로 라이선스를 선택해야 한다. 결정을 미루는 것은 나중에 더 복잡해진다. 왜냐하면 매번 새로운 협력자가 기여하기 시작하면 협력자도 저작권을 갖게 되기 때문이다. 따라서 라이선스를 고르자마자 승인을 득해야 할 필요가 있다.
여러분이 작성하고 있는 소프트웨어에 오픈 소스 소프트웨어 라이선스를 적용할 수 있는지 알아본다. 여러분이 라이선스 적용을 일방적으로 할 수 있는가? 혹은 여러분의 기관이나 조직의 다른 사람에게서 허락이 필요한가? 만약 그렇다면 누구일까?
17.2.2 콘텐츠 라이선스
만약 저장소 콘텐츠가 소프트웨어가 아닌 데이터, 창의적 저작물(매뉴얼, 기술 보고서, 원고) 같은 연구 제품이 포함되면, 소프트웨어를 위해 설계된 라이선스 대부분은 적합하지 않다.
데이터: 대부분 국가 사법권에서 데이터 유형 대부분은 자연에 대한 사실로 간주된다. 그러므로 저작권 보호를 받을 자격이 없다. (단, 아마도 사진과 의료 영상 정보 등은 예외) 따라서 저작자 표시로 사회적 혹은 학자적 기대치를 알리려고 저작권을 정의로 주장하는 방식으로 라이선스를 사용하는 것은 단지 법적으로 혼탁한 상황만 조장할 뿐이다. 크리에이티브 커먼즈 제로(Creative Commons Zero, CC0) 처럼 공중 도메인 권리 포기를 지지하는법적 표시를 분명히 하는 것이 더 낫다. Dryad 데이터 저장소는 사실 이를 요구하고 있다.
창의적 저작물(Creative works): 매뉴얼, 보고서, 원고, 기타 창의적 저작물은 지적재산 보호 대상이 된다. 따라서 소프트웨어와 마찬가지로 자동으로 저작권으로 보호된다. 크리에이티브 커먼즈(Creative Commons) 조직이 기본 제약사항 4개를 조합해서 라이선스 집합을 마련했다:
- 저작자 표시(Attribution): 파생 저작물에 대해서 최초 저작자의 이름, 출처 등의 정보를 반드시 표시해야 한다.
- 변경 금지(No Derivative): 저작물을 복사할 수도 있으나 저작물을 변경하거나 저작물을 이용하여 2차적 저작물 제작을 금한다.
- 동일조건변경허락(Share Alike): 2차적 저작물을 제작할 수 있으나, 2차적 저작물은 원래 저작물과 동일한 라이선스를 적용한다.
- 비영리(Noncommercial): 저작물을 영리 목적으로 사용할 수 없다. 영리 목적을 위해서는 별도의 계약이 필요하다.
출처 표시 (CC-BY)와 동일조건변경허락(CC-BY-SA) 라이선스만이 “오픈 라이선스”로 간주된다.
소프트웨어 카펜트리는 가능하면 폭넓게 재사용될 수 있도록 수업 자료에 대해서는 CC-BY, 코드에는 MIT 라이선스를 사용한다. 다시 한번, 가장 중요한 것은 프로젝트 루트 디렉터리에 있는 LICENSE 파일에 라이선스가 무엇인지 분명하게 언급하는 것이다. 본인 프로젝트를 참조하는 방법을 기술하는 데 CITATION 혹은 CITATION.txt 파일을 포함할 수도 있다. 소프트웨어 카펜트리 사례는 다음과 같다:
To reference Software Carpentry in publications, please cite both of the following:
Greg Wilson: "Software Carpentry: Lessons Learned". arXiv:1307.5448, July 2013.
@online{wilson-software-carpentry-2013,
author = {Greg Wilson},
title = {Software Carpentry: Lessons Learned},
version = {1},
date = {2013-07-20},
eprinttype = {arxiv},
eprint = {1307.5448}
}17.3 호스팅
저작물이나 작업을 공개하고자 하는 그룹에서 가지는 두 번째 큰 질문은 코드와 데이터를 어디에 호스팅할지 정하는 것이다. 방법 중 하나는 연구실, 학과, 혹은 대학이 서버를 제공하여 계정 관리와 백업 등을 관리하는 것이다. 주된 장점은 누가 무엇을 소유하는지 명확하다는 점이다. 특히 민감한 정보(예를 들어, 사람에 대한 실험 정보 혹은 특허 출원에 사용될 수도 있는 정보)가 있다면 중요하다. 큰 단점은 서비스 제공 비용과 수명이다. 데이터를 수집하는 데 10년을 보낸 과학자가 지금부터 10년 후에도 여전히 이용 가능하기를 원하지만, 학교 인프라를 지원하는 대부분의 연구 기금의 수명이 턱없이 짧다.
또 다른 선택지는 도메인을 구입하고 호스팅하는 데 ISP(인터넷 서비스 제공자, Internet Service Provider)에 비용을 지불하는 것이다. 이 접근법은 개인이나 그룹에게 좀 더 많은 제어권을 주고 학교나 기관을 바꿀 때 생기는 문제도 비켜갈 수 있다. 하지만 위나 아래 선택지보다 초기 설정하는 데 더 많은 시간과 노력이 요구된다.
세 번째 선택지는 GitHub, BitBucket, 혹은 SourceForge 같은 공개 호스팅 서비스를 채용하는 것이다. 웹 인터페이스를 통해서 저장소 코드를 생성하고, 보고, 편집할 수 있게 한다. 이러한 서비스는 이슈 추적, 위키 페이지, 이메일 통보, 코드 리뷰를 포함한 커뮤니케이션과 프로젝트 관리 도구도 제공한다. 이러한 서비스는 규모의 경제와 네트워크 효과로 모두 이익을 볼 수 있다. 즉, 동일한 표준을 갖는 작은 많은 서비스를 실행하는 것보다 큰 서비스 하나를 실행하는 것이 더 쉽다. 또한 사람들이 협업하기도 더 쉽다. 대중적인 서비스를 사용하면 이미 동일한 서비스를 사용하는 커뮤니티와 본인 프로젝트를 연결하는 데 도움이 된다.
예를 들어 소프트웨어 카펜트리는 GitHub에 있어서 해당 페이지에 대한 소스 코드를 찾아볼 수 있다. GitHub 계정을 갖는 누구나 해당 페이지에 변경 사항을 제안할 수 있다.
GitHub 저장소에서 Zenodo에 릴리스(release)를 연결하면 DOI를 부여할 수도 있다. 예를 들어 10.5281/zenodo.57467이 “Git 소개”에 대해 주조된 DOI다.
규모가 크고 잘 정립된 서비스를 사용하는 것이 빠르게 강력한 도구의 장점을 흡수하는 데 도움을 줄 수도 있다. 지속적 통합(Continuous Integration, CI)이 그런 도구 중 하나로 자동으로 소프트웨어 빌드를 돌리고 코드가 커밋되거나 풀 요청이 제출될 때마다 실행된다. 온라인 호스팅 서비스와 CI의 직접 통합은 어떤 풀 요청에도 해당 정보가 존재해서 코드 완결성과 품질 표준을 유지하는 데 도움을 준다는 것을 의미한다. 여전히 CI가 자가 구축한 호스팅 환경에서도 이용 가능하지만 온라인 서비스 사용과 연계되면 초기 설정과 유지 보수 업무를 줄일 수 있다. 더욱이 이러한 도구가 오픈 소스 프로젝트에 무료로 제공되기도 한다. 사설 저장소에 대해서만 비용 일부를 지불하고 이용 가능하다.
공유가 과학에는 이상적이지만 많은 기관에서 공유에 제약을 가한다. 예를 들어 잠재적으로 특허 가능한 지적재산을 보호하는 데 말이다. 만약 여러분이 그런 제약과 마주한다면 특정 프로젝트 혹은 도메인에 예외를 요청하거나, 제도 혁파를 통해서 더 공개된 과학을 지지하도록 좀 더 앞서 나가는 데 근본적인 동기에 관해 질의하는 것이 더 생산적일 수 있다.
본인 작업을 공개 저장소에 공개할 수 있는지 알아보자. 공개 작업을 일방적으로 할 수 있을까? 혹은 속한 조직의 누군가로부터 허락이 필요한가? 만약 그렇다면 조직의 누구일까?