A experiência de pensamento: O que seria necessário para transformar um projeto fechado para um projeto aberto?
Primeiros números que aparece na minha mente são:
1. Código claro e configuração de coisas internas: URLs, teclas de proprietário, bibliotecas comerciais e outras coisas. - Você não quer ver a configuração do seu servidor de banco de dados interno está dentro de IP, nome de usuário less / senha. Você não quer deixar as chaves de criptografia dentro do projeto de código aberto, e, claro, você não tem qualquer valor codificado em todo o código (interno)? Você faz?, Hm, nevermind ...
2. Automatizar o máximo possível (Ant, Maven ...) e processo de instalação documento para qualquer pessoa com uma OS em branco pode instalar o seu software
3. Escreve guia de introdução sobre como compilar, depurar - Escreva uma página ou duas sobre como compilar projeto para a maioria das plataformas populares (Linux, Windows, OS X) se tal coisa pode ser feito em seu código. Dica de como ativar o modo debug e onde encontrá-debug / error logs ... (Alguns projetos já tem esse documento internamente, mas eu já vi (quase) tudo ...)
4. Encontrar um bom nome, a menos que seu projeto já tem uma. - As pessoas querem se comunicar facilmente usando o nome do seu projeto em frases. Imagine que seu projeto é BKL, e alguém dizendo: "Eu apenas compilado BKL ...", "eu preciso atualizar BKL ao tronco ..." Não vá. É estranho e pesado. Esta não é a parte mais importan, e ter um material bom sempre ganha mais má fama.
5. Encontrar um bom lugar para hospedar o seu projeto. - Você quer ter ponto central de informações sobre tudo relacionado com um projecto: versão, wiki, questões, roteiro lista de discussão,. Há uma abundância de ofertas gratuitas, mas alguns são mais populares que outros, e oferecem diferentes modos de acesso a partes do projeto ...
Mais tarde, depois que você abriu seu código, como você começa o seu público para contribuir?
1. Seção proposta aberta no seu site / mailing-list / wiki
2. Faça regras simples, mas eficaz sobre como contribuir
Por exemplo, as regras poderiam ser como a seguir.
Contribuintes devem:
1. Apresentar um formulário de proposta detalhada descrevendo sua mudança (que deve ser a mudança dentro do seu aplicativo, o seu lib (s))
2. Discutir suas propostas abertamente sobre uma lista de discussão e críticas construtivas de campo os outros participantes
3. Esteja preparado para produzir um conjunto de patches protótipo que poderia implementar sua mudança
E por último, mas o mais importante - ter projeto interessante para abrir!
Estou certo de que há muito mais trabalho na conversão (maduro) projeto de código fechado para um aberto (isto é apenas um experimento virtual). Há também as não-tech questões, como licenças e direitos autorais e também razões políticas em algum momento.
Uma pessoa querendo converter um projeto, deve ter argumentos muito forte por isso que vai fazer melhor para o código e um projeto a ser open source. E há muitos, de agilidade para a segurança de velocidade e desempenho. Você apenas tem que encontrar um conjunto adequado de benefícios para você.
Hackear feliz!
Comentários Recentes