Offcanvas

���������������

깃허브, ‘코드 리뷰 제한’ 기능 추가

깃허브의 새로운 관리 기능은 ‘드라이브-바이(drive-by)’ 풀 리퀘스트 승인 및 ‘스팸성(spammy)’ 변경 요청을 처리하도록 설계됐다.  지난 11월 1일(현지 시각) 깃허브가 깃(Git) 기반 버전 관리 시스템 및 코드 공유 사이트 사용자를 위해 코드 리뷰 제한을 추가하고 모바일 알림을 개선했다.  회사에 따르면 코드 리뷰 제한의 목적은 ‘드라이브-바이’ 풀 리퀘스트 승인과 스팸성 변경 요청 문제를 해결하는 것이다. 메인테이너는 이제 풀 리퀘스트에 대해 변경을 승인하고 요청할 수 있는 사용자를 제한할 수 있다.  즉, 리포지토리 수준에서 읽기 이상의 액세스 권한을 명시적으로 부여받은 사용자로 승인 및 변경 요청을 제한할 수 있다. 사용자 또는 조직 계정과 연결된 모든 리포지토리에서 코드 리뷰 제한을 활성화할 수도 있다.  리포지토리 코드 리뷰 제한을 활성화하려면 해당 리포지토리의 설정 페이지로 이동하여 왼쪽 메뉴에서 조정 설정(Moderation Settings)을 선택한다. 그다음 ‘코드 리뷰 제한(Code review limits)’을 누른 후 ‘읽기 이상의 권한이 명시적으로 부여된 사용자로 제한(Limit to users explicitly granted read or higher access)’ 상자를 체크한다.    또한 깃허브 모바일 앱에서 스팸성 이슈와 풀 리퀘스트를 처리하기 어렵다는 문제를 해결하기 위해 모바일 알림이 개선됐다. 이제 모바일 알림에 스팸 이슈 또는 풀 리퀘스트 팝업이 표시되면 쉽게 해당 이슈를 닫고, 개발자의 스마트폰에서 바로 조직의 사용자를 블록할 수 있다.    이 2가지 기능은 깃허브가 올해부터 제공하기 시작한, 오픈소스 커뮤니티의 ‘삶의 질 향상’에 초점을 맞춘 기능 중 하나다. 이를 지원하는 다른 기능은 아래와 같다.  • 문제 양식(Issue forms): 필수 필드를 포함한 양식 필드로 문제 템플릿을 생성해 문제...

깃허브 코드 공유 코드 리뷰 풀 리퀘스트 버전 관리 리포지토리 개발자 오픈소스 메인테이너

2021.11.04

깃허브의 새로운 관리 기능은 ‘드라이브-바이(drive-by)’ 풀 리퀘스트 승인 및 ‘스팸성(spammy)’ 변경 요청을 처리하도록 설계됐다.  지난 11월 1일(현지 시각) 깃허브가 깃(Git) 기반 버전 관리 시스템 및 코드 공유 사이트 사용자를 위해 코드 리뷰 제한을 추가하고 모바일 알림을 개선했다.  회사에 따르면 코드 리뷰 제한의 목적은 ‘드라이브-바이’ 풀 리퀘스트 승인과 스팸성 변경 요청 문제를 해결하는 것이다. 메인테이너는 이제 풀 리퀘스트에 대해 변경을 승인하고 요청할 수 있는 사용자를 제한할 수 있다.  즉, 리포지토리 수준에서 읽기 이상의 액세스 권한을 명시적으로 부여받은 사용자로 승인 및 변경 요청을 제한할 수 있다. 사용자 또는 조직 계정과 연결된 모든 리포지토리에서 코드 리뷰 제한을 활성화할 수도 있다.  리포지토리 코드 리뷰 제한을 활성화하려면 해당 리포지토리의 설정 페이지로 이동하여 왼쪽 메뉴에서 조정 설정(Moderation Settings)을 선택한다. 그다음 ‘코드 리뷰 제한(Code review limits)’을 누른 후 ‘읽기 이상의 권한이 명시적으로 부여된 사용자로 제한(Limit to users explicitly granted read or higher access)’ 상자를 체크한다.    또한 깃허브 모바일 앱에서 스팸성 이슈와 풀 리퀘스트를 처리하기 어렵다는 문제를 해결하기 위해 모바일 알림이 개선됐다. 이제 모바일 알림에 스팸 이슈 또는 풀 리퀘스트 팝업이 표시되면 쉽게 해당 이슈를 닫고, 개발자의 스마트폰에서 바로 조직의 사용자를 블록할 수 있다.    이 2가지 기능은 깃허브가 올해부터 제공하기 시작한, 오픈소스 커뮤니티의 ‘삶의 질 향상’에 초점을 맞춘 기능 중 하나다. 이를 지원하는 다른 기능은 아래와 같다.  • 문제 양식(Issue forms): 필수 필드를 포함한 양식 필드로 문제 템플릿을 생성해 문제...

2021.11.04

코드씨(CodeSee), 오픈소스 개발자용 코드베이스 온보딩 포털 공개

컨트리뷰터의 온보딩 프로세스를 용이하게 하는 것을 목표로 OSS 포트(OSS Port) 커뮤니티 사이트는 오픈씨 맵(CodeSee Maps)을 활용하여 오픈소스 코드베이스를 시각적으로 워크스루할 수 있도록 지원한다.    코드씨(CodeSee)가 잠재적 컨트리뷰터를 오픈소스 프로젝트와 연결하고 간편한 온보딩 프로세스를 지원하는 커뮤니티 웹사이트 ‘OSS 포트’를 선보였다. 코드씨는 대규모 코드베이스를 시각화하고 이해하는 데 도움을 주는 도구를 개발한다.  회사에 따르면 이 웹사이트는 개발자가 코드를 작성하는 것보다 이를 이해하는 데 더 많은 시간을 소모하는 상황을 해결하고자 한다.  OSS 포트를 통해 소프트웨어 프로젝트 메인테이너는 코드베이스를 시각화하고 실행 흐름을 매핑하는 기술인 ‘코드씨 맵’을 사용하여 코드베이스에 관한 모범 사례, 지침, 인터랙티브 비주얼 워크스루를 제공할 수 있다(참고로 코드씨 맵은 현재 베타 상태다). 이어서 ‘코드씨 맵’은 고(Go), 자바스크립트(JavaScript), 자바(Java), 파이썬(Python) 코드베이스 전체에서 종속성을 표시할 수 있다고 회사 측은 덧붙였다.  한편 코드씨는 지속적인 코드 이해를 목표로 하향식 및 상향식 관점에서 코드베이스 가시성을 제공하고자 한다. 코드씨 맵은 풀 리퀘스트가 병합될 때마다 업데이트된다.  궁극적으로 코드씨는 온프레미스 소프트웨어까지 제공하는 엔터프라이즈 SaaS 회사로 나아갈 계획이다. 깃허브를 통해 OSS 포트에 프로젝트를 나열할 수 있다. 코드씨는 깃허브의 기술 파트너다. ciokr@idg.co.kr  

코드씨 개발자 코드 코드베이스 워크스루 코드 리뷰 오픈소스 컨트리뷰터 메인테이너 깃허브

2021.10.05

컨트리뷰터의 온보딩 프로세스를 용이하게 하는 것을 목표로 OSS 포트(OSS Port) 커뮤니티 사이트는 오픈씨 맵(CodeSee Maps)을 활용하여 오픈소스 코드베이스를 시각적으로 워크스루할 수 있도록 지원한다.    코드씨(CodeSee)가 잠재적 컨트리뷰터를 오픈소스 프로젝트와 연결하고 간편한 온보딩 프로세스를 지원하는 커뮤니티 웹사이트 ‘OSS 포트’를 선보였다. 코드씨는 대규모 코드베이스를 시각화하고 이해하는 데 도움을 주는 도구를 개발한다.  회사에 따르면 이 웹사이트는 개발자가 코드를 작성하는 것보다 이를 이해하는 데 더 많은 시간을 소모하는 상황을 해결하고자 한다.  OSS 포트를 통해 소프트웨어 프로젝트 메인테이너는 코드베이스를 시각화하고 실행 흐름을 매핑하는 기술인 ‘코드씨 맵’을 사용하여 코드베이스에 관한 모범 사례, 지침, 인터랙티브 비주얼 워크스루를 제공할 수 있다(참고로 코드씨 맵은 현재 베타 상태다). 이어서 ‘코드씨 맵’은 고(Go), 자바스크립트(JavaScript), 자바(Java), 파이썬(Python) 코드베이스 전체에서 종속성을 표시할 수 있다고 회사 측은 덧붙였다.  한편 코드씨는 지속적인 코드 이해를 목표로 하향식 및 상향식 관점에서 코드베이스 가시성을 제공하고자 한다. 코드씨 맵은 풀 리퀘스트가 병합될 때마다 업데이트된다.  궁극적으로 코드씨는 온프레미스 소프트웨어까지 제공하는 엔터프라이즈 SaaS 회사로 나아갈 계획이다. 깃허브를 통해 OSS 포트에 프로젝트를 나열할 수 있다. 코드씨는 깃허브의 기술 파트너다. ciokr@idg.co.kr  

2021.10.05

"기술과 비즈니스 융합"··· 'MBA'보다 나은 '오픈소스 프로젝트'의 가치

하버드 MBA를 취득할 시간이나 의향이 없었는가? 상관없다. 대신 오픈소스 프로젝트를 시작하라.  IT 분야 사람들은 각자가 서로 다른 역량을 보유하고 있고, 이에 따라 작업을 수행한다고 생각하는 경향이 있다. 이를테면 엔지니어는 코드를 설계하고 작성한다. 반면에 비즈니스 부문의 사람들은 마케팅과 영업을 한다.  그러나 오픈소스 엣지 및 서비스 프록시 ‘엔보이(Envoy)’를 개발한 매트 클라인의 생각은 조금 다르다. 그에 따르면 오픈소스는 엔지니어링과 비즈니스가 융합되는 영역이다.  이어서 클라인은 “오픈소스 프로젝트를 시작하는 것은 회사를 설립하는 것과 같다”라고 덧붙였다. 하버드 MBA를 취득할 시간이나 의향이 없었는가? 상관없다. 대신 오픈소스 프로젝트를 시작하라.    오픈소스 MBA  이 말이 언뜻 이해되지 않을 수 있지만 오픈소스에 참여해봤던 사람이라면 누구든 클라인의 주장을 인정할 것이다. 물론 비즈니스 관점에서 오픈소스 프로젝트를 바라보지 않을 수도 있다. 하지만 이 둘은 매우 유사한 스킬셋을 포함한다. 이와 관해 클라인은 다음과 같이 말했다.    “스타트업을 키우기 위해 필요한 활동들을 살펴보자. 채용, 마케팅, 엔지니어링 등일 것이다. 이 모든 것이 융합돼야 회사를 성공시킬 수 있다. 오픈소스도 마찬가지다. 마케팅하고, 홍보하며, 엔지니어링한다. 또 컨트리뷰터와 메인테이너를 찾는다(채용한다). 그리고 이를 제대로 하지 못하면 프로젝트는 아마 성공하지 못할 것이다.”  클라인은 과거 한 인터뷰에서도 이 모든 작업이 제대로 진행되지 않았을 때 어떻게 오픈소스 프로젝트가 실패할 수 있는지에 관해 이야기한 바 있다. 그는 “홍보, 마케팅, 채용 등의 일을 하지 않는다면 이는 그냥 벽 너머로 무언가를 던지는 것이고, 오픈소스 개발자와 사용자 모두 피해를 본다”라고 지적했다.  언제나 ‘고객 확보’가 우선  성공적인 오픈소스 프로젝트 메...

오픈소스 엔보이 엔지니어링 비즈니스 현업 컨트리뷰터 메인테이너 구글 애플 마이크로소프트

2020.12.11

하버드 MBA를 취득할 시간이나 의향이 없었는가? 상관없다. 대신 오픈소스 프로젝트를 시작하라.  IT 분야 사람들은 각자가 서로 다른 역량을 보유하고 있고, 이에 따라 작업을 수행한다고 생각하는 경향이 있다. 이를테면 엔지니어는 코드를 설계하고 작성한다. 반면에 비즈니스 부문의 사람들은 마케팅과 영업을 한다.  그러나 오픈소스 엣지 및 서비스 프록시 ‘엔보이(Envoy)’를 개발한 매트 클라인의 생각은 조금 다르다. 그에 따르면 오픈소스는 엔지니어링과 비즈니스가 융합되는 영역이다.  이어서 클라인은 “오픈소스 프로젝트를 시작하는 것은 회사를 설립하는 것과 같다”라고 덧붙였다. 하버드 MBA를 취득할 시간이나 의향이 없었는가? 상관없다. 대신 오픈소스 프로젝트를 시작하라.    오픈소스 MBA  이 말이 언뜻 이해되지 않을 수 있지만 오픈소스에 참여해봤던 사람이라면 누구든 클라인의 주장을 인정할 것이다. 물론 비즈니스 관점에서 오픈소스 프로젝트를 바라보지 않을 수도 있다. 하지만 이 둘은 매우 유사한 스킬셋을 포함한다. 이와 관해 클라인은 다음과 같이 말했다.    “스타트업을 키우기 위해 필요한 활동들을 살펴보자. 채용, 마케팅, 엔지니어링 등일 것이다. 이 모든 것이 융합돼야 회사를 성공시킬 수 있다. 오픈소스도 마찬가지다. 마케팅하고, 홍보하며, 엔지니어링한다. 또 컨트리뷰터와 메인테이너를 찾는다(채용한다). 그리고 이를 제대로 하지 못하면 프로젝트는 아마 성공하지 못할 것이다.”  클라인은 과거 한 인터뷰에서도 이 모든 작업이 제대로 진행되지 않았을 때 어떻게 오픈소스 프로젝트가 실패할 수 있는지에 관해 이야기한 바 있다. 그는 “홍보, 마케팅, 채용 등의 일을 하지 않는다면 이는 그냥 벽 너머로 무언가를 던지는 것이고, 오픈소스 개발자와 사용자 모두 피해를 본다”라고 지적했다.  언제나 ‘고객 확보’가 우선  성공적인 오픈소스 프로젝트 메...

2020.12.11

칼럼ㅣ‘리눅스’는 여전히 ‘표준’이다

'리눅스(Linux)'는 오픈소스의 성공 기반을 닦았을 뿐만 아니라 오픈소스 커뮤니티의 운영 방식을 구체화했다. 우리는 리눅스에 대해 충분히 이야기하고 있는가? 오픈소스 세상에서 자라난 사람뿐만 아니라 오픈소스를 처음 접한 사람 모두 리눅스 커뮤니티의 선구적인 역할에 감사해야 한다. 어쨌든 리눅스는 오픈소스가 무엇을 의미하는지, 그리고 이것이 개인, 기업, 정부에 무엇을 의미할 수 있는지를 보여주는 대표적인 첫 모델이었다.    리눅스 창시자 리누스 토발즈를 포함한 ‘리눅스 커뮤니티’는 오늘날 오픈소스가 작동하는 방식 또한 정의했다. 깃(Git)부터 조직 구조(메인테이너, 커미터 등)에 이르기까지 리눅스는 오픈소스 커뮤니티 운영 방식에 직접적으로 또는 간접적으로 영향을 미쳤다.  여기서는 리눅스 재단의 ‘2020년 리눅스 커널 역사 보고서(2020 Linux Kernel History Report)’에 따라 리눅스가 어떻게 오픈소스의 기반을 닦아 놓았는지를 살펴본다.  대규모 협력 리눅스는 모든 것이 크다(임베디드 리눅스 배포판을 실행하는 수많은 IoT 장치는 예외다). 올해로 리눅스는 탄생 29주년을 맞았다. 현재까지 2만 명이 넘는 기여자(contributors)가 참여했고, 100만 개의 커밋(2020년 8월 기준)이 추가됐다. 지난 몇 년으로 따지자면 평균 7만 5,000개의 커밋이 추가됐다. 놀라운 기록이다.  물론 처음부터 이렇진 않았다.  리눅스는 토발즈의 단독 프로젝트로 시작됐다. 그리고 1996년경 앨런 콕스와 존 네일러가 합류했다. 이들은 서로를 ‘메인테이너’라고 불렀다. 같은 기간 동안 아파치 웹 서버와 같은 다른 프로젝트도 조직적인 형태를 갖췄지만, 필자가 아는 한 메인테이너 계층을 중심으로 이렇게 빠르게(그리고 공식적으로) 조직화된 사례는 없었다.  이러한 계층은 중요했다. 최초의 MAINTERS 파일(커널 v1.3.68용)에서 밝힌 바와 같이 프로젝트 커뮤니케...

리눅스 리누스 토발즈 리눅스 커뮤니티 메인테이너 커미터 컨트리뷰터 기트허브 기트랩 오픈소스 레드햇

2020.09.11

'리눅스(Linux)'는 오픈소스의 성공 기반을 닦았을 뿐만 아니라 오픈소스 커뮤니티의 운영 방식을 구체화했다. 우리는 리눅스에 대해 충분히 이야기하고 있는가? 오픈소스 세상에서 자라난 사람뿐만 아니라 오픈소스를 처음 접한 사람 모두 리눅스 커뮤니티의 선구적인 역할에 감사해야 한다. 어쨌든 리눅스는 오픈소스가 무엇을 의미하는지, 그리고 이것이 개인, 기업, 정부에 무엇을 의미할 수 있는지를 보여주는 대표적인 첫 모델이었다.    리눅스 창시자 리누스 토발즈를 포함한 ‘리눅스 커뮤니티’는 오늘날 오픈소스가 작동하는 방식 또한 정의했다. 깃(Git)부터 조직 구조(메인테이너, 커미터 등)에 이르기까지 리눅스는 오픈소스 커뮤니티 운영 방식에 직접적으로 또는 간접적으로 영향을 미쳤다.  여기서는 리눅스 재단의 ‘2020년 리눅스 커널 역사 보고서(2020 Linux Kernel History Report)’에 따라 리눅스가 어떻게 오픈소스의 기반을 닦아 놓았는지를 살펴본다.  대규모 협력 리눅스는 모든 것이 크다(임베디드 리눅스 배포판을 실행하는 수많은 IoT 장치는 예외다). 올해로 리눅스는 탄생 29주년을 맞았다. 현재까지 2만 명이 넘는 기여자(contributors)가 참여했고, 100만 개의 커밋(2020년 8월 기준)이 추가됐다. 지난 몇 년으로 따지자면 평균 7만 5,000개의 커밋이 추가됐다. 놀라운 기록이다.  물론 처음부터 이렇진 않았다.  리눅스는 토발즈의 단독 프로젝트로 시작됐다. 그리고 1996년경 앨런 콕스와 존 네일러가 합류했다. 이들은 서로를 ‘메인테이너’라고 불렀다. 같은 기간 동안 아파치 웹 서버와 같은 다른 프로젝트도 조직적인 형태를 갖췄지만, 필자가 아는 한 메인테이너 계층을 중심으로 이렇게 빠르게(그리고 공식적으로) 조직화된 사례는 없었다.  이러한 계층은 중요했다. 최초의 MAINTERS 파일(커널 v1.3.68용)에서 밝힌 바와 같이 프로젝트 커뮤니케...

2020.09.11

칼럼 | 오픈소스 지속 가능성은 '코드'가 아니라 '사람'의 문제

‘오픈소스 지속 가능성’ 논의의 대부분은 지속하는 데 실제로 도움이 필요 없는 한 가지에 초점을 맞춰왔다. 바로 소프트웨어다. 오픈소스 및 웹 표준 컨설턴트 토비 랑겔이 지적한 것처럼, 오픈소스 코드는 희소 자원이 아니다. 사실은 정반대다. 사용자와 생태계에 제로 원가로 무한 재생산할 수 있다. 또한 자금 문제가 진정한 문제는 아니지만, 진실에 더 가깝기는 하다.   대신 오픈소스의 지속 가능성을 둘러싼 실제 문제는 바로 사람이다. 또는 랑겔은 "오픈소스에서 소스 코드를 작업하는 메인테이너(maintainer)야말로 보호, 육성해야 하는 진정한 희소 자원이다"라고 말했다.   커뮤니티는 공동의 책임 지난 몇 주 동안 필자는 인기 있는 오픈소스 프로젝트의 여러 메인테이너를 인터뷰했다. 모두가 입을 모아 오픈소스가 재미있기 때문에 각자 어떻게 기여하는지 얘기했지만, 오픈소스 개발의 일부 측면이 확실히 ‘재미없게’ 만들 수 있음을 인정했다. 누락된 기능이나 기존 버그에 대해 불평하지만 코드나 수정에 기여하지 않고 요구만 하는 사람들이 대표적이다. 메인테이너 대부분은 열정을 재정적 독립으로 바꾸는 방법을 찾았지만, 랑겔은 오픈소스를 지속하려면 자금이 중요하다고 강조한다. "시스템을 위험에 빠뜨리는 것은 바로 오픈소스 코드의 기능이 무료로 무한히 재생산될 수 있다는 것이다. 수익이 없으면 유지관리도 없고, 유지관리가 없으면 공공의 이익은 매우 빠르게 오염된다. 왜 그럴까? 생태계가 빠른 속도로 변하기 때문이다. 새로운 패러다임이 등장하면서, 오래된 오픈소스 자산에 의존하는 것은 비즈니스의 변화에 빠르게 적응하는 데 방해가 되는 골칫거리가 된다. 새로운 보안 문제가 발견되면 업데이트되지 않은 오픈소스 코드가 보안 위험이 된다." - 오픈소스 및 웹 표준 컨설턴트 토비 랑겔 다시 말해, 재현 비용이 들지 않는 대규모 코드 풀이 있기 때문에, 이를 적극적으로 유지관리하는 사람이 없으면 온갖 종류의 문제가 발생하게 된다. 랑겔은 "(오픈소스의) 공공의...

오픈소스 메인테이너 기여자

2020.08.25

‘오픈소스 지속 가능성’ 논의의 대부분은 지속하는 데 실제로 도움이 필요 없는 한 가지에 초점을 맞춰왔다. 바로 소프트웨어다. 오픈소스 및 웹 표준 컨설턴트 토비 랑겔이 지적한 것처럼, 오픈소스 코드는 희소 자원이 아니다. 사실은 정반대다. 사용자와 생태계에 제로 원가로 무한 재생산할 수 있다. 또한 자금 문제가 진정한 문제는 아니지만, 진실에 더 가깝기는 하다.   대신 오픈소스의 지속 가능성을 둘러싼 실제 문제는 바로 사람이다. 또는 랑겔은 "오픈소스에서 소스 코드를 작업하는 메인테이너(maintainer)야말로 보호, 육성해야 하는 진정한 희소 자원이다"라고 말했다.   커뮤니티는 공동의 책임 지난 몇 주 동안 필자는 인기 있는 오픈소스 프로젝트의 여러 메인테이너를 인터뷰했다. 모두가 입을 모아 오픈소스가 재미있기 때문에 각자 어떻게 기여하는지 얘기했지만, 오픈소스 개발의 일부 측면이 확실히 ‘재미없게’ 만들 수 있음을 인정했다. 누락된 기능이나 기존 버그에 대해 불평하지만 코드나 수정에 기여하지 않고 요구만 하는 사람들이 대표적이다. 메인테이너 대부분은 열정을 재정적 독립으로 바꾸는 방법을 찾았지만, 랑겔은 오픈소스를 지속하려면 자금이 중요하다고 강조한다. "시스템을 위험에 빠뜨리는 것은 바로 오픈소스 코드의 기능이 무료로 무한히 재생산될 수 있다는 것이다. 수익이 없으면 유지관리도 없고, 유지관리가 없으면 공공의 이익은 매우 빠르게 오염된다. 왜 그럴까? 생태계가 빠른 속도로 변하기 때문이다. 새로운 패러다임이 등장하면서, 오래된 오픈소스 자산에 의존하는 것은 비즈니스의 변화에 빠르게 적응하는 데 방해가 되는 골칫거리가 된다. 새로운 보안 문제가 발견되면 업데이트되지 않은 오픈소스 코드가 보안 위험이 된다." - 오픈소스 및 웹 표준 컨설턴트 토비 랑겔 다시 말해, 재현 비용이 들지 않는 대규모 코드 풀이 있기 때문에, 이를 적극적으로 유지관리하는 사람이 없으면 온갖 종류의 문제가 발생하게 된다. 랑겔은 "(오픈소스의) 공공의...

2020.08.25

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.31