내가 일하고있는 회사는 몇 가지 어려움에 직면 해 있으며 우리의 미래는 불확실하다고합니다. 지난 몇 년 동안 우리는 커뮤니티 앱과 소셜 네트워크를 구축하기위한 프레임 워크를 개발했습니다. 우리는이 이니셔티브를 완전히 잃어 버려서는 안되며 커뮤니티에 유용 할 수 있으므로 소스를 공개하기로 결정했습니다.기존 코드베이스를 opensource하는 방법은 무엇입니까?
나는 그 질문이 아주 공개되어 있고 간단한 대답은 없다는 것을 알고 있지만 비슷한 경험을 가진 사람들로부터 듣고 싶습니다.
미리 감사드립니다.
라이센스의 경우 라이센스에 대한 목표가 무엇인지 물어야합니다. 코드를 기여한 사람들의 커뮤니티를 구축하고 다른 사람이 독점적 인 코드 포크를 만들지 못하도록하는 목표는 무엇입니까? 그렇다면 GPL을 선택하는 것이 좋습니다. 저작권을 유지하고 오픈 소스로 배포 할 수 있지만 독점 소프트웨어와 연결하려는 사람들을위한 대체 라이센스를 제공하는 것이 목표입니까? 다시 말하지만 GPL은 좋은 선택 일 수 있습니다.이 경우 기여를 다시 라이센스 할 수 있도록 변경 사항을 다시 보내는 다른 제공자의 저작권 할당을 설정해야합니다.
코드가 서버 측 소프트웨어 일 수 있습니다.이 경우 AGPL을 조사하고 싶을 수 있습니다. AGPL은 GPL과 비슷하지만 사람들이 자신의 서버 (GPL이 필요로하지 않는 서버)에서 소스를 변경하여 소스를 배포 할 것을 요구합니다.
사람들이 독점 소프트웨어를 작성하는 동안 사람들이 그것을 구축 할 수 있기를 원하지만 여전히 소프트웨어 자체에 대한 변경 사항을 제공하려면 LGPL이 좋습니다. 독점 포크에 신경 쓰지 않고 단순히 허용할만한 것이 있으면 MIT 라이센스를 선택하는 것이 좋습니다.
합법적으로 출시 할 수없는 코드를 제거하는 것만 수정하면됩니다. 모든 코드에 대한 저작권을 소유하고 있다면 모든 코드가 좋지만 암호화 코드는주의해야하며 프로그램에 코드가 있으면 변호사와상의하십시오. 수출 제한은 처리가 어려울 수 있지만, 오픈 소스 소프트웨어에 대해 프로세스를 단순화하는 규정이 있습니다.
필요한 수정 외에도 가능한 한 많은 시스템에서 코드를 작성하고 실행할 수 있는지 확인하는 것이 좋습니다. 예를 들어, 어떤 의존성이 필요한지와 어떤 것을 종속성으로 만들 수 있는지 확인해야합니다. 소프트웨어를 빌드하고 설치하는 방법에 대한 좋은 문서뿐만 아니라 시스템 구축, 단위 및 회귀 테스트 등 모든 소프트웨어 개발 (오픈 소스뿐만 아니라)에서 원하는 모든 일반적인 것들도 좋습니다.
에 대해 생각하는다른 몇 가지 사항은 다음과 같습니다
나는 더 많은 세부 사항을 올릴 수 있었지만 이미 말한 것들을 반복하고있을 것이다. 자세한 정보가 필요하면 Karl Fogel의 Producing Open Source Software을 읽어 보시기 바랍니다.
지난 몇 주 동안 동일한 작업을 수행했습니다. 우리는 Mercurial을 버전 제어 시스템으로 선택합니다.이 시스템은 매력처럼 작동합니다. Bitbucket은 오픈 소스 프로젝트에 무료 호스팅을 제공하는 호스팅 회사입니다. 전 세계의 다른 사람들도 프로젝트에 참여할 수 있기 때문에 더 많은 문서가 필요합니다. 이는 옆집 동료에게 상황을 설명하는 것과는 다른 것입니다.
하나의 중요한 점은 당신이 염두에 두어야 할 점은, 이제는 당신이 귀찮게하고 싶은 청중이 있다는 것입니다. 내부 개발을 통해 API, 데이터베이스 스키마 등을 자주 변경합니다. 오픈 소스를 사용하면 부 버전과 필요한 경우 명확한 마이그레이션 경로간에 호환성이 있어야한다는 점을 명심해야합니다.
이 소프트웨어의 공개 소싱을 회사에 돈을 버는 방법으로 통합하려는 경우 Joel Spolsky's take은 내가 읽은 가장 청결한 것 중 하나입니다.
오픈 소스 라이선스 주제에 관한 한 권의 책 만 읽는다면 Lawrence Rosen의 Open Source Licensing보다 잘 수행하기가 어려울 것입니다.
이 답변을 주셔서 감사합니다. 정말 도움이됩니다. – MatthieuP