생각 실험 : 오픈 프로젝트 하나의 닫힌 프로젝트를 설정하려면 어떻게 그것이 걸릴까요?
내 마음속에 떠오른 첫 번째 문제는 다음과 같습니다
1. 클리어 코드와 내부 물건의 구성 : URL을 독점 키, 상용 라이브러리와 물건. - 당신이 설정, 적은 이름 / 비밀 번호 안의 내부 데이터베이스 서버의 IP를보고 싶지 않아. 당신이 오픈 소스 프로젝트 내부에 암호화 키를 떠나고 싶지 않아, 물론 당신의 (내부) 코드에 걸쳐 어떤 하드코드된 가치가 없다! 당신은 어떻게?, 음, 걱정하지 ...
2. 빈 OS와 사람이 소프트웨어를 설치할 수 있도록 가능한 (개미, maven ...)와 문서 설치 과정으로서 자동화
3. 컴파일하는 방법에 대한 시작 안내서 작성, 디버깅 - 이런 건 코드에 할 수있다면 가장 인기있는 플랫폼 프로젝트 (리눅스, 윈도우, OS X)으로 컴파일하는 방법에 대한 페이지에 한두세요. 디버그 / 오류 로그를 찾기 위해 디버그 모드와 위치를 설정하는 방법을 알아두기 ... (일부 프로젝트는 이미 내부적으로 문서를 가지고,하지만 (거의) 다 본 것 ...)
4. 프로젝트가 이미 하나가 아니라면, 좋은 이름을 찾으십시오. - 사람들은 쉽게 문장에서 프로젝트의 이름을 사용하여 대화하고 싶어. "나는 단지 BKL를 뽑아 ...", "나는 트렁크에 BKL 업그레이 드해야합니다 ..."이동 번호 : 프로젝트 BKL이며, 누군가가 말을하지 상상해보십시오. 그것은 어색하고 성가신입니다. 이것은 가장 importan 일부가 아닌, 그리고 좋은 물건을 갖는 것은 나쁜 이름 위에 마우스를 이겼습니다.
5. 프로젝트를 호스팅하기위한 좋은 장소를 찾으십시오. 버전 관리, 위키, 문제, 로드맵, 메일링리스트 : - 당신은 프로젝트에 관련된 모든 정보의 중앙 지점을 갖고 싶습니다. 이 많은 자유 제안이 있지만 일부는 다른 사람보다 더 인기가 있고, 프로젝트의 일부에 대한 액세스의 다양한 모드를 제공합니다 ...
당신의 코드를 개설 나중 후에는 공개 기여하는 방법을 얻습니까?
1. 귀하의 사이트 / 메일링리스트 / 위키 오픈 제안 섹션
2. 기여하는 방법은 간단하면서도 효과적인 규칙 만들기
예를 들어, 규칙은 다음과 같을 수 있습니다.
참여자는해야합니다
1. 그들의 변화를 (귀하의 응용 프로그램 내부의 변화, 여러분의 LIB (들)이어야 함) 설명하는 상세한 제안 양식 제출
2. 다른 참가자의 메일링리스트 및 현장 건설적인 비판을 공개적으로 자신의 제안을 논의
3. 그들의 변화를 구현할 수있는 패치의 프로토 타입 집합을 생산할 수 있도록 준비
그리고 마지막으로,하지만 가장 중요한 - 열 수있는 흥미로운 프로젝트가있어!
나는 열려있는 한 (이것은 단지 가상 실험)에 (성숙) 클로즈드 소스 프로젝트를 변환에서 많은 작품이있다 확신합니다. 가끔은 라이센스 및 저작권 또한 정치적인 이유와 같은 비 기술적인 문제도 있습니다.
그것이 코드와 오픈 소스가 될 수있는 프로젝트를 잘 할 이유를 하나의 프로젝트를 변환하고 싶었 사람은 정말 강력한 인수를 가져야합니다. 그리고 많은 사람들이 민첩성의 속도와 성능에 대한 보안까지 있습니다. 당신은 당신을위한 혜택 적절한 집합을 찾아야 해.
해피 해킹!
최근 댓글