Quais os fatores que determinam o sucesso de um projeto open source?[fechado]
https://stackoverflow.com/questions/80997
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Nós temos uma série de aplicativos de código-fonte fechado e bibliotecas, para que nós pensamos que seria conveniente a abertura do código-fonte.
O que foi o bloqueio de nós, até agora, é o esforço necessário para limpar a base de código e documentação de origem, antes de abrir.
Queremos abrir a fonte só se tem uma chance razoável de projetos bem sucedidos, i.é.tendo colaboradores.Estamos convencidos de que o código seria interessante para uma grande base de desenvolvedores.
Quais os fatores que, excluindo-se a "falta de interesse" e "utilidade" do projecto, determinar o sucesso de um projeto de código aberto?
Exemplos:
- Limpeza de código
- A disponibilidade do código-fonte comentários
- Totalmente ou parcialmente documentado APIs
- A escolha da licença GPL (vs.LGPL vs.BSD, etc...)
- A escolha do repositório público
- O investimento em um site público
Solução
Há várias coisas que dominam o sucesso de código.Todos estes devem ser alcançados para a menor chance de adoção.
- Mercado - deve haver um mercado para o seu projeto de código aberto.Se o seu projeto é um espremedor de laranja no espaço, eu duvido que você vai ser muito bem sucedida.Você deve fazer certeza de que o projeto recebe um grande aprovação entre os usuários e desenvolvedores.Ele é duas vezes mais propensos a ter sucesso, se você pode obter outras empresas a adotá-lo como bem.
- Documentação - Como você tocou em versões anteriores da documentação é fundamental.Entre esta documentação é comentado código de decisões de arquitetura, e a API de notas.Mesmo se a sua documentação contém erros ou bugs sobre o seu software é ok.Lembre-se, a transparência é a chave.
- Liberdade - Você deve permitir que o seu código para ser "livre" - eu quero dizer, livre como na expressão, não como em cerveja.Se você tem uma sensação que o mercado está sendo uma biblioteca para que outras empresas de uma licença BSD é o ideal.Se o seu software está indo para executar em ambientes de trabalho, em seguida, a GPL é a sua escolha.
- Transparência - Você deve escrever o software em um ambiente transparente.Uma vez que você vá open source não há segredos escondidos.Você deve explicar tudo o que você faz, e o que você está fazendo.Isso irá irritar os desenvolvedores como nenhum outro
- Comunidade de desenvolvedores de Uma forte comunidade de desenvolvedores é necessária.Este deve ser existente.Apenas cerca de 5% dos usuários de contribuir para o projeto.Se alguém percebe não houve quaisquer liberações de um ano que não vai pensar "puxa, este software é feito," eles vão pensar que "os programadores tem de dumping." Mantenha seus desenvolvedores a trabalhar nisso, mesmo se isso significa que eles estão custando-lhe dinheiro.
- Comunicações - Você deve certificar-se que a comunidade é capaz de se comunicar.Eles devem ser capazes de bugs, discutir soluções, e publicar os patches.Sem comentários, é inútil para o projeto opensource
- Disponibilidade - Tornando o código fácil de começar é necessário, mesmo que isso signifique mijando fora de advogados.Você tem que certificar-se de que é fácil para baixar e utilizar.Você não deseja que o usuário tem que saltar através de 18 telas de cavalo e assinar um contrato para fazer isso.Você tem que fazer as coisas simples e limpo
Outras dicas
Eu acho que o fator mais importante é o número de usuários que estão usando o seu projecto.Caso contrário, é apenas um realmente bem escrito, interessante e bem documentado monte de coisas que senta-se em um servidor que não está fazendo muito...
Para adquirir contribuintes, você primeiro precisa que os usuários, em seguida, você precisa de algumas imperfeições.Você precisa acionar o "Isso é legal, mas eu realmente gostaria que tivesse isso ou foi diferente desta forma." Se você falta uma característica óbvia, é extremamente provável que um usuário vai se tornar um colaborador para adicioná-lo.
A coisa mais importante é que o programa seja bom.Se não é bom, ninguém vai usá-lo.Você não pode esperar que o ovo ou a galinha irá reverter e que as pessoas vão levá-lo para concedido até que ele se torne bom.
Claro, "o bom" significa simplesmente "melhor do que qualquer outra opção prática para um número significativo de pessoas," isso não significa que sua estritamente o melhor, só que ele tem algumas características que o tornam, para muitas pessoas, melhor do que outras opções.Às vezes o programa tem sem equivalente em qualquer outro lugar, caso em que não há quase nenhuma exigência em relação a isso.
Quando um programa é bom, as pessoas vão usá-lo.Obviamente, ele tem que ter um mercado entre os usuários-um bom programa que faz algo que ninguém quer, não é realmente bom, não importa o quão bem desenhado.Poderia se fazer um ponto sobre marketing, mas realmente bons produtos, até um ponto, têm uma tendência para o mercado em si.É muito mais difícil para promover algo que não é bom, então, claramente, uma primeira prioridade deve ser o produto em si, não promovendo o produto.
A verdadeira questão é ... - como é que você torná-lo bom?E a resposta para isso é uma dedicada, qualificada equipe de desenvolvimento.Uma pessoa raramente pode criar um bom produto em seu próprio;mesmo se eles estão muito melhor do que os outros desenvolvedores, de múltiplas perspectivas, tem um incrivelmente útil efeito sobre o projeto.É por isso que ter os patrocinadores corporativos é tão útil-ele coloca de outros desenvolvedores (da corporação) mente sobre o problema para dar a sua própria opinião.Isto é especialmente útil no caso de que o desenvolvimento do programa requer experiência significativa que não é comumente disponíveis na comunidade.
Claro, eu estou dizendo tudo isso a partir da experiência.Eu sou um dos principais desenvolvedores em x264 (atualmente o mais ativo), um dos mais populares de codificadores de vídeo.Temos dois principais desenvolvedores, várias pequenas desenvolvedores na comunidade que contribuam patches, e do patrocínio de empresas do Joost (Gabriel Bouvigne, que mantém ratecontrol algoritmos), a partir de Aproveitar a Mídia (que eu trabalho para, às vezes, no contrato e que estão actualmente a contratação de programadores no contrato para adicionar MBAFF entrelaçamento de apoio), e de alguns outros que surgem de tempos em tempos.
Um bom programador não faz um projeto--muitos bons desenvolvedores.E o resultado final disso é um programa que codifica o vídeo, mais rápido e com muito melhor qualidade do que a maioria dos concorrentes comerciais, hardware ou software, mesmo aqueles com absolutamente enormes orçamentos para o desenvolvimento.
Ao examinar estes problemas que você pode estar interessado em conferir a versão online de um curso de open source na UC Berkeley, chamado de Desenvolvimento de código Aberto e Distribuição de Informação Digital:Técnicos, Econômicos, Sociais, Legais e Perspectivas.É co-dirigidos por Mitch Kapur (Lotus fundador) e Paula Samuelson, uma faculdade de direito professor.Eu tenho uma longa viagem e colocar o áudio do curso no meu iPod no ano passado, eles falam muito sobre o que funciona, o que não e por isso que, a partir de uma muito ampla (embora, obviamente, acadêmico) perspectiva.
Livros têm sido escritos sobre o assunto.Na verdade, você pode encontrar um livro gratuito aqui: produção de software de código aberto
Realmente, eu acho que a resposta é 'como você executar o projeto'.
Todos os seus exemplos importa, sim, mas as principais coisas são como a interação entre os desenvolvedores é gerido, como patches, etc, são tratados/aceito, de quem é 'responsável' e como eles lidam com essa responsabilidade, e assim por diante e assim por diante.
Compare e contraste (a história não é muito difícil rastrear!) a gestão do desenvolvimento de Class::DBI e DBIx::Class em Perl.
Eu estava lendo hoje um excelente post sobre a usabilidade aspecto do bem-sucedida vs êxito projetos de código aberto.
Trecho:
Um monte de largura de banda foi desperdiçado discutindo sobre a falta de usabilidade em software open-source/software livre (doravante, "OSS").O debate continua no mesmo momento em blogs, fóruns, e Slashdot comentário threads.Algumas pessoas dizem que a má usabilidade é endêmica em todo o OSS mundo, enquanto outros dizem que o OSS usabilidade é grande, mas que o verdadeiro problema é a mente fechada usuários que esperar em cada programa para clonar Microsoft.Algumas pessoas afirmam que problemas de INTERFACE do usuário são temporário de dores de crescimento, enquanto outros dizem que as OSS modelo de desenvolvimento sistematicamente produz mau INTERFACE do usuário.Algumas pessoas ainda argumentam que a GPL indiretamente recompensas software que é difícil de usar!(Para o registro, eu discordo.)
Apenas open-source.Provavelmente, ninguém vai começar a contribuir ainda.Mas pelo menos você pode escrever na imprensa de que o seu produto é GPL, ou seja o que for.
O primeiro passo é que as pessoas começam a usá-lo...
E talvez então, depois que os usuários se sentir confortáveis, eles vão começar a contribuir.
Todos as respostas foram bem até agora, mas há uma coisa que falta e o que é bom de supervisão.Nada mata um projeto de código aberto mais rapidamente do que não ter algum tipo de gerenciamento de projetos.Não dizer às pessoas o que fazer tanto como apenas adicionar alguns estrutura e tarefas para os desenvolvedores que você está esperando para atrair.
Desorganizado projetos desmoronar rapidamente.Não é um pássaro, você apenas deixe ir e vê-lo voar.
