어떻게 아파치 소프트웨어 재단의 운영은

이 문서에서는, 나는 당신이 의심되어했다고 생각 독자 모두를위한 아파치 소프트웨어 재단의 형태에 대한 개요를 제공 할 것입니다하지만 시간은 내용에 대해 문의가 없습니다. 커버 : 회원 및 커미터와 보드가 무엇인지 선거를 실시하는 방법을 무엇을, 인프라 및 작동 방법을 결정의 PMC 무엇인지, 인큐베이터 뒤에이 무엇인지 철학, 어떻게 ASF 거래의 차이 새로운 프로젝트와 수년에 걸쳐 가져 참여자의 놀라운 성장의 도전. 장면은 아파치 소프트웨어 재단, 프로브 뒤에 작동 메커니즘을 접근 뒤에이 기사는 당신을 데려 갈 것이다.

저자 : SI에 적합

원본 출처 : HTTPS : //www.apache.org/foundation/how-it-works.html

공공 ALC 베이징 호에서 재판

무엇 아파치 소프트웨어 재단?

아파치 소프트웨어 재단은 1999 년에 설립 된 미국 503 © 3에 등록 된 비영리 공공 자선 단체, 주요 목적이다 :

공개 소프트웨어 프로젝트의 공동 개발에 대한 지원을 제공하기 위해 하드웨어, 커뮤니케이션 도구 및 비즈니스 인프라를 제공함으로써 1.

2. 개인 또는 회사 후원 할 수 있으며, 이러한 자원이 공공의 이익을 위해 사용 될 수 있도록 할 수 있도록하는 별도 법인의 창조.

3. 개별 자원 봉사자 재단 프로젝트에 대한 법적 절차를 방지 할 수 있습니다.

다른 조직 4. 보호 자사의 소프트웨어 제품 "아파치"브랜드, 남용.

독자는 다음 보여 건조 지루한 사실이 될 것입니다,주의,하지만 난 모든 일이 얼마나 많은 사람들이 여전히 호기심 아파치 남아 생각? 그것은 얼마나 자세한 사항?하지만 걱정, 약간의 역사를하자 기억을하지 않습니다.

아파치 소프트웨어 재단의 간략한 역사

보호하기 위해 몇 년 전 때문에 위해, "아파치 그룹", 소위 이유와 그들이 다음 NCSA HTTPD에 의해 개발 지원 : 재단은 1999 년에 설립되었으며, 이름이라고 자신을 준 몇 사람이 있었다 웹 서비스를 제공합니다.

시간이 지남에 따라 웹 서비스 소프트웨어뿐만 아니라 소스 코드를 포함하면 무료 방식으로 제공되는 HTTPD 것을 그런 상황 등이다 자유롭게 라이센스 계약의 보조 제공하는 사람들을 수 있도록하는 수정을 포함하고 있지만, 점차적으로 개발자의 관심을 전송 한 후, 다른 것들은 사용자 프로젝트 인 상황의 결과로 바쁘게 시작,하지만 더 지원.

이 시점에서 우리는 소프트웨어를 해결하기 위해 서로 일부 사용자 교환을하기 시작했다 ( "패치"라고 함), 어떻게 수정 문제 및 정보 코드를 개선하고, 브라이언 벨렌 도프는 그래서, 자신의 컴퓨터에 메일 링리스트를 생성 우리는 버그를 수정 유지하고 HTTPD 웹 서비스를 개선하기 위해 공동 작업을 수행 할 수 있습니다.

주로 전쟁 전략과 끊임없는 체력과 유명한에서 우수한 기술을 가진 미국 원주민 부족과 관련, 아파치 부족을 위해, "아파치"등의 이름을 선택했다. 그러나 그것은 또한 말장난, 웹 서비스의 패치 워크, 그러나 "는 누덕 누덕 기운 웹 서버가"솔직히 말해서,이 모든 사람의 마음이되지이다, 재미있다. 이러한 방법으로, 긴 "아파치 그룹 '이었다 스스로라는 사람들의 아파치 소프트웨어 개발 및 유지 보수를하지 않았다.

1995 년부터 1999 년까지 아파치 HTTPD 웹 서비스는 "아파치 그룹"에 의해이 지금까지, 지금도 65 %의 시장 점유율을 차지, 시장의 선두 주자가 된 웹 서버 소프트웨어의 개발을 이끌었다.

그러나 세상은 해당 경제적 혜택도 개발 된 네트워크 크기의 성장과 개발 중단 적이있다, 아파치는 새로운 관련 프로젝트 (등 mod_perl을, PHP 프로젝트, 자바 프로젝트와 같은 프로젝트), 성장 필요성의 숫자를 호스팅 시작 더 일관되고 잠재적 인 법적 공격을 방지하려면 조직을 조직했다. 그래서, 상황 등의 아파치 소프트웨어 재단.

엘리트주의

아파치 웹 서버 및 기타 소프트웨어는 원래 독립을 시작 (예 : 리눅스 커널, 펄, 파이썬 언어 등) "영웅"에 의해 만들어진되지 않은만큼, 오픈 소스 라이센스 계약에 따라 개발 된 것이 아니라, 여러 가지가 소유 일반적인 아이디어는 사람들이 정보를 교환 땜질하여 서로를 알아, 당사자가 작성 권장 사항을 수용하는 것을 계속한다.

그룹이 자신의 소프트웨어 버전을 개발하기 시작으로, NCSA의 원래 버전을 포기, 점점 더 많은 사람들이 매력을 몇 패치이나 제안을 보내 먼저 도움을 제공하기 시작했다, 또는 전자 메일 메일 링리스트에 회신된다 , 더 큰 기여를 제공 할 수있다.

팀은 지역 사회의 자격, 그들은 개발자들에게 팀의 강도를 계속 증가 할 코드 저장소에 직접 액세스 권한을 부여 할뿐만 아니라, 팀 개발 프로젝트를 개선 할 때 한 한 개발자는 "원"생각하는 경우 팀을보다 효율적으로 유지 보수 및 개발의 결과로 능력.

우리는 "엘리트주의"이라는 기본 원칙 전화 : 말 그대로,이 정부 또는 일반적인 이름의 주요 장점이다.

그것은 개발이 모델은 매우 좋은 지적 가치가 너무 많은 마찰을 발생하지 않았다이며,이 여러 가지 방법으로 인해 다른이며, 여기에 중앙 집중식 전원이없고, 부부가 제공하는 것이 바람직 간주됩니다 아파치 팀의 보수화 자원 봉사자, 작업을 훔치는 싶은 사람없는 사람들의 도움이됩니다.

때문에 새로운 사람들을 도울 수 아파치 팀 대단히 희망, 그래서 그들은 단지 그들이 필요한 다른 사람과이 작업과 일치를 달성하기 충분한 고려 사람들을 선별, 혼란 그 자원 (돈, 에너지, 시간)없이 친절한 태도, 의견, 특히이있을 때.

다음에, 우리는 어떤 역할을 밖으로의 종류를 보자는 ASF의 조직 구조를보십시오.

조직 재단

아파치 웹 서버의 인기와 시장 점유율을 점진적으로 인해 프로젝트의 기술적 인 장점 뒤에 사회의 개방성에 증가하기 시작, 사람들은 아파치 웹 서버의 둘레 프로젝트의 숫자를 생성하기 시작했다. 지역 사회에 의해 자신의 문화적 영향이 항상 있었다 때문에,이 프로젝트는 또한 동일한 커뮤니티 관리 모형을 사용했다.

당신은 ASF를 만들 때 몇 가지 별도의 지역 사회가 있기는하지만 그래서, 각 지역 사회는 서로 다른 문제 웹 서비스에 대해 우려하고 있지만이 지역 사회 모두 동의 의사 소통의 과정과 공동의 목표의 설립에, 같은를 수행하면서 문화적 규칙의 집합입니다.

이러한 독립적 인 "프로젝트"로 알려진 지역 사회, 유사하지만, 그러나 각각의 사회는 그들을 특별하게하는 약간의 차이를 보였다.

순서 마찰을 줄이기 위해 개발의 다양성을 장려하기에서, ASF는 아파치 세계 있도록, 각 프로젝트는 자신의 중심 의사 결정기구이며, 하나의 소위 고급 문화의 강박을 선택하지 않았다. 각 프로젝트는 자체 소프트웨어 개발 기관이며, 자신의 기술과 자신의 법령 거버넌스 규칙을 설계하는 자유의 큰 정도가있다.

몇 년이 경과 그래서, 기본 아파치 팀의 문화적 영향은 매우 깊고 넓은 여전히 현재 지역 사회 사이의 유사성이 매우 높은 학위를 가지고 있다는 것입니다.

재단은 다음과 같은 기관에 의해 관리됩니다 :

재단은 위원으로 구성되는 이사회에 의해 관리됩니다.
프로젝트 관리위원회 특정 프로젝트 (PMC) 관리, 그들은 제출자를 구성한다. (제출자에있어서 각 부재가 정의이다)
특정 지역 재단 (법률, 브랜딩, 기금 모금 등)에 회사의 다양한 정책의 임원의 이사회에 의해 임명.

1 이사회 (보드)

이사회는 재단 전세 회사의 사업 및 업무에 대한 관리 및 감독있어서 책임이있다. 이것은 (인프라 자금 조달, 지적 재산권, 상표 및 지원 프로젝트에 필요한) 재단의 자산 관리 및 프로젝트에 대한 자원의 할당을 포함한다.

그러나, 아파치 프로젝트의 내용과 방향에 관한 기술적 인 의사 결정 능력은 각각의 프로젝트 관리위원회에 할당됩니다.

이사회는 현재 재단의 회원들에 의해 선출, 9 명으로 구성되어 있습니다. 자세한 사항은 집행위원회의 수 있어야한다 지정하지 않은,하지만 역사적으로,이 이사회의 수를 변경 적이 처음이다. 매년 이사 선거위원회.

보드 페이지에는 이사, 회의 일정 및 과거 회의록의 현재 목록과 같은 추가 정보를 제공합니다.

2 프로젝트 관리위원회 (PMC)

프로젝트 관리위원회는 이사회의 결의에 의해 결정되는 사회, 하나 개 이상의 활성 관리에 대한 책임을 이사회의 결의에 의해 설립했다.

각 PMC는이 회장으로 지정 될 것이며, ASF의 하나 또는 그 이상의 다른 회원을 포함 할 수있다, 적어도 하나의 ASF 관리로 구성되어 있습니다.

이사회와 ASF 관리 (VP)에 임명 PMC 의장은 이사회의 의장은 주요 책임과 PMC 지역 사회의 일상 관리를위한 규칙과 절차를 수립 할 수있는 권리가 PMC 자체의 구성을 포함하여 책임 부담. 또한 토론, 관리자 이유 장소의 회장.

여기와 여기에 : ASF 헌장 임무와 PMC의 회장, 과거에 목록 정보를 메일 링하는 것은 더 설명을 얻을 수를 정의합니다.

뷰 재단의 역할의 지점에서 PMC를 감독하는 것입니다. PMC에서의 주요 역할은 코드를 작성하지 않고, 코드 리뷰가 아니라 모든 법적 문제가 해결되는 것을 보장하기 위해, 프로그램이 다음에 각각 출시 된 버전은 완전히 지역 사회에 기반을 둔 것이다. 이것은 우리의 소송 보호 메커니즘의 핵심입니다.

둘째, PMC의 역할은 지역 사회에 장기적이고 건전한 발전을 통해 촉진하고, 특정 균형 및 동료에 대한 액세스 찬양을 보장하기 위해, 그리고 협력을 계속 할 수 있습니다. ASF는 내, 우리가 걱정하는 커뮤니티가 있다는 것이다 대해 소수 제어 코드의 관점에서 모두 해로운 견고 함이나 안정성면에서 우려의 장기 발전을위한 커뮤니티로, 또는 조작 또는 사회 구조 자체가 우려된다.

우리는 확고 그것은 당신의 직업이나 현재의 고용주 또는 회사와는 아무 상관이없는, 역할의 역할의 ASF에서 당신의 역할은, 자신의 개인을 결정하는 당신까지이며, 부여 된 ASF에 의해 동료가 있다고 생각합니다.

PMC에서 매우 높은 기준을 가지고위한 ASF입니다. PMC, 특히 PMC 회장, 사실, "눈"과 "귀"의 이사 ASF 보드, 그래서에 의존하고이 역할에 의해 제공되는 법적 감독을 신뢰합니다.

이사회는 PMC가 결의안을 통과 종료 할 수있는 권리를 보유합니다.

아파치 개발자 정보 페이지는 PMC 작업에 대한 자세한 정보를 가지고에서는 물론, 당신은 또한 현재의 모든 최상위 아파치 프로젝트를 검색 할 수 있습니다.

3 관리자

아파치 소프트웨어 재단의 관리 직원이 재단의 일상 업무를 감독 할 책임이있다, 관리자는 이사회가 선출했다.

역할

각 지역 사회 아파치 프로젝트에서 엘리트 시스템은 서로 다른 역할을 구별 할 필요성을 의미한다 :

사용자

사용자는 공공 아파치 소프트웨어를 사용하는 것입니다. 그들은 아파치 프로젝트에 기여 오류 및 권장 사항의 함수 형태를보고하여 개발자에게 피드백을 제공합니다. 사용자는 메일 링리스트에 다른 사용자를 지원하여 프로젝트에 기여할 수있다.

개발자

개발자는 비교적 잘 이해 코드를 작성하거나 문서는 그들이 그러한 논의 개발자 메일 링리스트에 적극적으로 프로젝트에 참여의보다 다양한 형태를 가지고 사람들에 기여하는 프로젝트의 형태로 작성하는 것입니다되어, 코드를 제출 패치, 문서, 제안, 심지어 비판을 제출합니다. 개발자는 일반적으로 알려져 있습니다 기여 .

에 의해 제출

에 의해 제출 개발자들이 코드를 작성 저장소 운영 기관에이 방법, 그들은 또한 기여자 사용권 계약 (CLA) 파일을 서명, 그들은 접미사 전자 메일 주소가 패치를 제출할 때,에 의존하지 않는 apache.org에 있습니다 다른 사람은, 사실, 그들은 프로젝트에 대한 약간의 단기 의사 결정을 할 수 있습니다. 프로젝트 관리위원회 위원 (PMC)은 물론, 영구적 일 수 있습니다 동의 (사실, 기본값) 및 커미터와 같은 일부 개발자의 승인을 할 수있다, PMC는 또한 개발자가 제출을 거부 할 수 있습니다. 여기에 있다는 점 유의 하시길 바랍니다 : PMC는 결정이 아니라 몇 가지 독립적 인 회원입니다.

프로젝트 관리위원회 위원

PMC 회원이 그 수상자를 제출하거나 프로젝트의 개발에 개발자의 뛰어난 성능에 의해 선출되어, 그들이 의결권의 지역 사회 관련 업무와 함께, apache.org 접미사 전자 메일 주소로 쓰기 코드 저장소에 권한이, 오른쪽은 활성 사용자의 참여를 제출합니다. PMC는 자사 프로젝트의 일환으로 유일한 기업이며, 다른 그룹은 참여할 수 없습니다. 특별 강조는 PMC는 공식 출시 프로젝트 소프트웨어 제품을 투표를해야합니다.

프로젝트 관리위원회 위원장

프로젝트 관리위원회 (PMC) 회장은 PMC 회원들로부터 이사회에 의해 임명된다. PMC는 프로젝트 기업의 관리 및 리더십이다. 대통령의 역할은 프로젝트 관리위원회의 위원장뿐만 아니라 다른 특정 임무로, 물론 보드와 프로젝트 사이의 의사 소통의 다리 역할을하는 것입니다.

ASF 회원

ASF 회원은 현재 회원에 의해 지명하고 가용성에 따라 선거를 실시하는 재단의 발전을 촉진한다. 우려의 ASF 회원은 일반적으로 프로젝트 관련 및 프로젝트 간 활동의 근본 원인에 의해 입증된다 아파치 소프트웨어 재단 자체입니다. 법적으로 말하기, 재단의 "주주"의 회원들은 또한 소유자의 하나입니다. 그들의 권리는 이사회 후보로 이사 선거의 보드를 선출하고, 제안자의 구성원이 있습니다. 그들은 또한 새로운 인큐베이터 프로젝트를 제안 할 권리가있다 (우리는 나중에 무슨 뜻인지를 볼 수 있습니다). ASF 회원 메일 링리스트 및 연간 회의를 통해 조정 일상 업무를 수행합니다.

프로젝트 관리 및 협업

아파치 프로젝트는 협업 프로세스의 합의에 따라 관리됩니다. 아파치는 어떤 계층, 조직의 다른 권리와 책임과 기여의 물론, 다른 그룹입니다.

지정된 프로젝트 관리위원회는 자치 정부의 자체 규칙을 제정 할 수있는 권한을 가지고, 프로젝트 관리위원회는 프로젝트와 지역 사회를 실행하는 방법에 대한 하나의 비전이 없다.

거기에 약간의 차이가 있지만 있지만 동시에, 모든 프로젝트는 몇 가지 공통점이있다 :

통신

통신은 메일 링리스트를 통해 이루어집니다. 이 방법은 모든 "가상 회의실은"비동기이며, 전 세계에있는 개발자, 그것은 특히 중요하기 때문에이를 바탕입니다. (아파치의 관점에서 각 프로젝트를 위해 세계 각국에서 종종의 경우)

일부 프로젝트는 의사 소통의 도구 (예 : IRC 또는 다른 인스턴트 메신저 등), 음성 통신 방법의 사용은 매우 드문 동기화 할 수 있습니다, 또한 추가 사용됩니다 일반적으로하기 때문에 쓰기에 비해 비용과 언어 (언어 적 텍스트의 장벽 ) 이해하기 더 어렵습니다.

일반적으로,이 (검색 및 검사를 위해) 아카이브를 생성 할 수 있기 때문에 비동기 통신이 더 중요하고 더 중요한 사회 자원 봉사자의 성격에 맞춰 비동기 통신이다.

파일

관련 정보 멘토, 개발자, PMC 등을 제출이 있습니다 - 각 프로젝트는 자세한 내용은 ASF 인프라를 액세스 할 수 있습니다, 자신의 프로젝트 사이트가 책임이 있습니다.

결정

프로젝트는 일반적으로 자체 관리, 몇 가지 작업을 수행하는 자원 봉사자들에 의해 구동된다. 이것은 그들의 선택이 작업을 직접, 아무도보고되지 할당 된 일을 완료하는 것을 의미한다 "할 - ocrac을"모드로 알려져 있습니다. 그것은 일반적으로 잘 작동합니다!

최종 결정을 조율 할 필요가 게으른 방법보다 합의에 의해 채택되는 경우 : 어떤 긍정적 인 투표의 반대 투표의 일부는 충분하다.

다음 투표의 세 가지 형태가 있습니다 :

한 - 투표에 동의
0 - 기권, 노 코멘트 없다
-1-- 반대

때 투표, 명확 상세 대안에 설명하고, 반대 투표를해야한다. 커뮤니티 다음은 문제를 해결하기위한 대안의 제안에 합의에 도달하려고합니다. 대부분의 경우이 방법은 부정 투표에 대한 우려를 해결하기 위해 이어질 수 있습니다.

"합의"우리는이 중요한 심볼의 커뮤니티 메이크업, 건강 기능이라고 생각 :이 과정은 우리가 호출합니다.

원리 (철학)

비록 명시 적으로 인정 또는 공식 지정하지만, 다음 여섯 개 가지 원칙은 철학의 기초 뒤에 핵심 아이디어 아니다. 이것은 군중 "아파치 방법"칭찬을하는 것입니다 :

소프트웨어 개발을위한 협력
비즈니스 친화적 인 표준 라이센스
높은 품질의 소프트웨어의 일관 생산을 유지하기 위해
존중, 정직, 기술은 친구가 될 것입니다
표준의 충실한 구현
필수 보안 기능으로

모든 ASF 프로젝트는 멀리 부적절 상업 영향에서, 아파치 프로젝트는 별도의 치료를 필요,이 여섯 개 원칙, 동일을 따릅니다.

운영

모든 아파치 프로젝트는 자원 봉사자들로 구성되어, 아무도 (아파치 구성원 또는 관리자 인 경우에도) 지불 재단이 지급됩니다, 아마도 거기에 지불 한 GET의 기여에 제출하지만하는 사람들 일부는 아파치 소프트웨어하지 없습니다 재단은 지불했다. 당사국은 소프트웨어가 더 강력한되고 싶은, 그 회사는 아파치 소프트웨어를 사용할 수있는 보수 때문에 특정 개선이.

엄숙 팁 : 아파치는 계정, 뉴스, 미디어 관계 및 인프라 관리와 같은 서비스의 번호를 수행하는 것입니다.

개인의 ASF 원리

모든 참여 ASF 회원 : 보드 석, 관리 직원, 제출자뿐만 아니라 구성원 모두가 이점 ASF 인, 독립적 인 개인이며, 소속은 개인 기부에 영향을 미치지 않습니다.

그들이 특별히 언급하지 않는 한, 그들 자신에 의해 메시지 목록에서 언급 한 것들 중 하나라도 완료합니다. 이 아니라 회사의 급여 따 발행의 대표로, 개인의 대신에 따, 전체보기 독립의 개인 지점입니다, 심지어보기의 ASF 이사가 될 수 없습니다.

사실, 모든 ASF 회원들은 각각의 역할을 가지고, 특히 이사회, 관리자와 PMC의 회장이다. 그들은 때때로 너무 개인적인 의견을 표현하는 것을 방지하기 위해, 그들은 그들의 특별한 상태에 얘기하는 것을 말할 것이다, 정책 문제에 대한 이야기를해야합니다. 개인 의견이 일반적으로 매우 효과가 있기 때문에, 대부분의 경우이 필요하지 않습니다.

에도 불구하고, 자신의 진술이 특히 따옴표로 묶여 빨려 어떤 사람이, 어떤 사람들이 사용가 있습니다에 apache.org 접미사 메일 주소를 자신의 역할을 선언하는 이메일에 특별한 바닥 글을 사용하여 어떤 사람들은 그들이 많은 사람들이 apache.org 접미사 메일을 가지고 있기 때문에 당신은 개인 사서함을 사용할 수있는 마지막 방법은 권장되지 않는다.

개인 정보 보호 및 공개 토론의 균형에 대해

우리는 개방, 공공 기록을 장려하는 공공 장소에서 가능한 한 많이 토론하고 더 넓은 지역 사회 바랍니다.

하지만 가끔은 내부 개인 메일 링리스트는 명시 적 허가리스트를 사용하지 말고, 당신은 공공 장소에서 그러한 정보를 공개해서는 안 필요하다. 민간 및 공공 목록 사이에 (당신이 CC 필요하지 않습니다) 전자 메일을 복사하지 마십시오. 이러한 이벤트는 전자 메일 에티켓, 잃어버린 신뢰에 대한 일반 요구 사항을 초과 할 것입니다. 그것은 불필요한 혼란과 토론 현명하지 못한 원인이 심각한 결과를 초래할 수 있습니다.

개인 목록은 일반적으로 전용 (예 : 새 저자의 투표와 같은) 개인 관련 문제, 기밀 법률 문제와 함께 사용됩니다.

재단의 인큐베이터 프로젝트

새 프로젝트가 원활를 작성하려면, ASF는 특별히 성공적으로 ASF에 가입 할 수있는 새로운 프로젝트를 돕는 책임을, 같은 프로젝트 인큐베이터를 설정합니다.

때문에 ASF 엘리트 규칙의 ASF 프로젝트의 초기 단계는 기여 이것을 이해해야 참여하는 경우 등 지배 구조의 장기적인 안정성을위한 상향식 (bottom-up) 작업이 다시 필수입니다 이 프로젝트는 같은 철학적 태도와의 협력과 개방성을 예상했다.

보육의 책임은 다음과 같습니다 :

새 프로젝트 또는 하위 프로젝트를 만드는 목적의 필터 편지
도움이 필요하면 프로젝트와 인프라를 구축
지역 사회의 감독과지도의 인큐베이션, 이는 그들이 우수한 열린 문화를 달성 할 수있다
결론은 실패 인 경우, 다음 은퇴를 통해 해결 될 수있는 반면 만기 평가 인큐베이션 프로젝트는, 또는, 국가의 공식 프로젝트 / 하위 프로젝트로 업그레이드 할 수.

인큐베이터가 (단지 보드와 같은) 기술적 인 문제를 기반으로 필터링을 수행하지 않도록주의해야합니다. 존경의 기초와 기술 다양한 방법을 추천하기 때문입니다. 그것은 혁신 걱정, 심지어 사이의 기능 프로젝트의 중복 내에서 경쟁을 허용하지 않습니다.

인큐베이터가 성공적으로 엘리트 그룹이 프로젝트를 필터링 할 수있는 가능성을 기반으로, 가장 기본적인 요구 사항 프로젝트 배양은 다음과 같습니다 :

사용 가능한 코드 저장소 - 많은 년 후에, 또한 실패의 다양한 경험은, 재단은 점차 한 가지를 이해하기 시작했다 : 더 초기 사용 가능한 코드 저장소가없는 경우, 당신은 매우 어려운 기본적으로 커뮤니티를 시작합니다. 사실, 이유는 그, 매우 간단합니다, 당신은 심지어 코드 저장소, 원하는 개발자는 다음 몇 가지 매우, 매우, 지역 사회의 초기 단계의 분위기를 파괴 할 문질러 아이디어에 대해 이야기 혼자, 추가로 시작할 수없는 이해 않는다 아웃.
ASF 회원 또는 관리 지원 - 이것은 보육 PMC와 연락을 매일 세부 사항에 대한 도움 거래에 프로그램에 대한 안내뿐만 아니라 킵을 제공하는 차 멘토 역할을합니다.

프로젝트의 주요 결정의 잠복기의 길이는 보는 것입니다 :

이 프로젝트는 참여자의 다양성을 증가
그것은 엘리트 실행에 의해 확립 된 규칙에 따라 좋은 기반이 될 수 있습니다

이 모든 것은 그렇게 쉬운 일이 아닙니다 모든 자원 봉사자는 그렇게 어려운 일이 아니다 실현하기 위해,하지만 명심해야 할 것, 그리고 새로운 기부자를 유치, 환경의 가혹한 조건을 승진시켰다.

다양성은 주로 다음과 같은 두 가지 이유에 의해 매우 중요한 기여자입니다 :

이 프로젝트의 장기 안정성의 발전을 위해 제공 : 사실, 다른 회사 나 조직에 흩어져 개인보다 훨씬 더 큰 함께 프로젝트의 가능성을 떠나 같은 시간에 같은 회사 나 조직에서 온 개발자,.
그것은 기술적 비전을 제공 : 더 나은 환경 제약을 준수하고 소프트웨어의 실제 사용을보다 효율적으로 파악 결과, 사용자의 요구를 충족 할 수 있습니다.

기타 사항 재단

인큐베이터처럼, 재단은 또한 예를 들어, ASF 및 실제 사무실 공간 또는 건물의 재단에 걸쳐 여러 프로젝트는, 그것은 단지 인터넷에 존재하는 가상 엔티티이다가 제대로 기능에 이르기까지 모든 것을 할 수 인프라 팀의 수송 인프라 유지 보수 및 관리에 만들어집니다.

재단에서이 프로젝트의 자세한 설명은 재단 페이지로 이동하시기 바랍니다.

ASF는 재단의 전체 메일 링리스트, 자세한 내용은 동일한 호스트, 메일 링리스트 페이지를 이동하십시오.

투쟁은 계속 ......

아파치 소프트웨어 재단이 이십일년을 위해 운영하고 있습니다, 그것은 아파치 소프트웨어 재단은 구조와 유연성 사이의 균형을 찾기 위해 열린 조직의 모범 사례 중 하나를 나타냅니다 밝혀졌습니다. 우리는 7000 명 이상의 참여자 200에서 성장을 계속하고 수 성장을 계속, 우리는 각각의 시장에서 선도적 인 위치에있는 소프트웨어 제품의 숫자를 만들었습니다, 우리는 또한 성적과 경제성 사이에 개방 발견 좋은 밸런스 점, 그리고 지금 우리는 모든 사람의 존경과 인정을 승리, 그들은 일부 대형 다국적 기업을 포함한 독립적 인 개인을 포함, 우리는 또한 기업, 정부, 교육 및 기타 소프트웨어의 미래에 대한 희망 재단 영감.