내부 소스

Inner source

InnerSource는 오픈 소스 소프트웨어 개발 베스트 프랙티스를 사용하고 비 오픈 소스 및/또는 독점 소프트웨어의 개발을 위해 조직[1] 내에서 오픈 소스 같은 문화를 확립하는 것이다.이 용어는 Tim O'Reilly가 2000년에[2] 그의 칼럼에서 만들었다.[3]

동기

오픈 소스는 고품질 소프트웨어를 제공할 수 있는 것으로 인정된다.[4]게다가 오픈 소스의 오픈 협업을 통해 경쟁사들 간의 협업이 가능하다(예: ARM과 Intel은 성과에 기반한 결정을 Linux 커널에서 작업한다).

결과적으로, 소프트웨어 개발 조직은 그 결과(소프트웨어 구성요소와 도구)뿐만 아니라 오픈 소스 세계에서 행해지고 확립된 개발 관행으로부터도 이익을 얻기를 원한다.[5]

사용된 오픈 소스 관행

Apache Software Foundation, Linux Foundation, Eclipse Foundation과 같은 재단에서 확립된 여러 관행 외에도 InnerSource와 오픈 소스 프로젝트는 개방형 협업, 개방형 커뮤니케이션 및 적절한 품질 보증을 필요로 한다.

오픈 콜라보레이션

InnerSource를 활용하는 회사의 모든 직원이 필요한 모든 개발 유물(예: 코드, 문서, 이슈 트래커 등)에 액세스할 수 있어야 한다.중앙 소프트웨어 통합은 개방형 협업을 구현하는 데 필수적인 도구다.

오픈 콜라보레이션(평등주의, 성과주의, 자기 조직화) 원칙에 기초해, InnerSource 프로젝트를 기꺼이 돕겠다는 모든 기고자는 전형적으로 환영받는다.InnerSource 프로젝트에 대한 기여는 일반적으로 프로젝트에 가져오는 가치에 기초하여 성과론적으로 판단된다.메리토크라시 역시 의사결정이 공개적으로 논의되는 만큼 열린 소통으로 가능해진다.조직이 반드시 InnerSource를 채택하기 위해 완전히 자체 조직화되는 것은 아니지만, InnerSource는 개인, 조직 단위 및 프로젝트 커뮤니티에 더 높은 수준의 자체 조직화를 허용한다.

오픈 커뮤니케이션

InnerSource 프로젝트 및 프로그램은 모든 커뮤니케이션을 모든 직원이 공개적으로 액세스할 수 있도록 하기 위해 개방형 커뮤니케이션에 의존한다.개방형 커뮤니케이션은 (회사 내에서) 공개적이고, 작성되고, 보관되고, 완성되는 커뮤니케이션이다.이 특성의 결과로, 통신은 비동기적이다.목표는 InnerSource 프로젝트에 이해관계가 있거나 관심이 있는 개인 또는 당사자가 커뮤니케이션에 참여할 수 있도록 하는 것이다.개방형 통신 토론이 보관됨에 따라 소프트웨어에 대한 상세 설명서가 수동적으로 수집되어 과거 토론과 결정을 다시 볼 수 있게 된다.

통합으로부터 기여 분리를 통한 품질 보장

전용 코드 검토와 기여자 및 커밋자(통합자, 쓰기 액세스 권한이 있는 개발자)의 분리는 오픈 소스 프로젝트의 품질을 보증하며, 따라서 InnerSource 프로젝트도 보증한다.

혜택들

오픈 소스 소프트웨어의 품질 속성 이외에 다음과 같은 이점이 보고된다.[6][7]

보다 효율적이고 효과적인 개발
  • 출시 기간 단축
  • 개발 비용 절감
조직 단위 경계 극복
  • 조직 단위 간의 비용 및 리스크 공유
  • 조직 단위 경계에 걸친 협업
  • 프로그램 전반에 걸친 정보 교환
보다 성공적인 재사용
  • 컴포넌트 프로바이더에서 누락된 역량 사용
  • 재이용자와 제공자 간의 독립성
  • 부품 제공업체 구제
더 나은 소프트웨어 제품
개발자의 보다 유연한 활용
  • 개발자 배치 간소화
  • 단독 개발자 협업
향상된 지식 관리
  • 커뮤니티 기반 학습
  • 지식의 개방성과 가용성
직원 동기 부여 증가

유병률

InnerSource를 채택한 기업은 다음과 같다.[6]

InnerSource 채택 핵심 요소

InnerSource는 소프트웨어를 개발하는 큰 조직에게 유망한 접근법이 될 수 있다.그러나 모든 설정에서 적절하지는 않을 수 있다.다음의 9가지 요인을 세 가지 범주로 분류하여 이너 소스가 어느 정도 적합할 수 있는가를 측정하기 위해 참조할 수 있다.[13]

제품인자

  • 커뮤니티 유치를 위한 시드 제품
  • 다양한 기여를 위한 여러 이해관계자
  • 기여자 및 사용자 유치를 위한 모듈화

공정 및 도구 요인

  • "Baza-style" 개발을 지원하는 관행
  • "Baza-style" 품질 보증을 지원하는 업무
  • 협업 촉진을 위한 툴 표준화

조직 및 커뮤니티 요인

  • 내부 성과주의 출현을 지원하기 위한 조정과 리더십
  • 조직을 개방하기 위한 투명성
  • 관리 지원 및 인력 참여에 대한 동기 부여

참조

  1. ^ Capraro, Maximilian; Riehle, Dirk (2017-02-06). "InnerSource Definition, Benefits, and Challenges" (PDF). ACM Computing Surveys. 49 (4): 1–36. doi:10.1145/2856821. ISSN 0360-0300. S2CID 5385511. Inner source (IS) is the use of open source software development practices and the establishment of an open source-like culture within organizations. The organization may still develop proprietary software but internally opens up its development.
  2. ^ Ven van 't ende (2016-05-09). "InnerSource: An Open Source Approach to Community Culture". Tim O’Reilly, the founder of O’Reilly Media, coined the term “inner-sourcing” in 2000, describing it as: “the use of open source development techniques within the corporation.”
  3. ^ O'Reilly, Tim (2000-12-01). "Open Source and OpenGL". oreilly.com. O'Reilly and Associates. Archived from the original on 2015-02-15. Retrieved 2017-02-22. [W]e've also worked with companies on what we call “inner sourcing” — that is, helping them to use open source development techniques within the corporation.
  4. ^ Kevin Crowston, Kangning Wei, James Howison, Andrea Wiggins (2012), ACM (ed.), "Free/Libre open-source software development: What we know and what we do not know", ACM Computing Surveys (in German), 44 (2): 1–35, doi:10.1145/2089125.2089127, S2CID 2246943{{citation}}: CS1 maint : 복수이름 : 작성자 목록(링크)
  5. ^ Stol, Klaas-Jan; Fitzgerald, Brian (2014). "Inner source—adopting open source development practices within organizations: a tutorial" (PDF). IEEE Software. doi:10.1109/MS.2014.77. hdl:10344/4443. S2CID 1965218. [...] a number of organizations have adopted open source practices to develop their software. [...] Unlike traditional approaches, developers of an inner source project do not belong to a single team or department. Instead, anybody within the confines of the organization can become a contributing member of this internal community, either as a user or contributor.{{cite journal}}: CS1 maint: 작성자 매개변수 사용(링크)
  6. ^ a b Capraro, Maximilian; Riehle, Dirk (2016-12-01). "Inner Source Definition, Benefits, and Challenges". ACM Comput. Surv. 49 (4): 67:1–67:36. doi:10.1145/2856821. ISSN 0360-0300. S2CID 5385511.
  7. ^ Stol, Klaas-Jan; Fitzgerald, Brian (2015-07-01). "Inner Source - Adopting Open Source Development Practices within Organizations: A tutorial" (PDF). IEEE Software. 32 (4): 60–67. doi:10.1109/MS.2014.77. hdl:10344/4443. ISSN 0740-7459. S2CID 1965218.
  8. ^ Microsoft Internal Solorigate Investigation Update.
  9. ^ Oram, Andy (2015). Getting Started with InnerSource. O’Reilly Media, Inc. ISBN 978-1-491-93758-7.
  10. ^ Smith, Jared (2016). Using open source methods for internal software projects. O’Reilly Media, Inc.
  11. ^ Ghostarchive 및 Wayback Machine에 보관:
  12. ^ "Watch: Creating an Inner Source Hub at Siemens". JFrog. 2020-07-28. Retrieved 2020-12-09.
  13. ^ Stol, K. J.; Avgeriou, P.; Babar, M. A.; Lucas, Y.; Fitzgerald, B. (2014). "Key factors for adopting inner source". ACM Transactions on Software Engineering and Methodology. 23 (2): 1. doi:10.1145/2533685. hdl:10344/3897. S2CID 6995068.