Acabei de voltar de minhas primeiras férias de snowboard em oito anos. Depois de um período tão longo fora das pistas, eu realmente não sabia se precisaria reaprender completamente - se eu acharia toda a provação muito aterrorizante, ou seria capaz de pular na minha prancha e fingir que aqueles oito anos tinham sido oito dias. No final, foi o último.

Eu consegui me amarrar na primeira manhã, apontar a prancha para o morro e chegar ao fundo da encosta sem deslocar o joelho esquerdo ou empurrar os esquiadores perdidos para uma fenda. Parece que, embora não haja muita semelhança entre andar de bicicleta e descer uma encosta gelada em uma tábua, nem vai deixar você esquecer como andar depois de aprender.

Como resultado, tive uma semana fantástica explorando um novo território e reconstruindo minha antiga confiança. Agora, acho que há um link entre o software de código aberto e a maneira como você aprende a andar de snowboard.

É a velha ideia de que, sem correr riscos, você não se desenvolve. E não quero dizer grandes riscos como pular de um penhasco ou tomar uma rota direta até o final da pista. Refiro-me a riscos pequenos e considerados, como ir um pouco mais rápido, ficar um pouco mais apertado ou seguir para uma pista desconhecida..

Mesmo se você cair, o que você vai, você precisa levar sua habilidade além de seus limites atuais para entender melhor como melhorar. É só depois que você cavalgou mais rápido, mais íngreme ou mais difícil que você pode voltar para as pistas antigas com confiança, habilidade e percepção renovadas. É como todos nós melhoramos, e isso não acontece se você não se esforçar.

Apesar da falta de montanhas e raclette, acho que o Linux e o software livre são como o snowboard, e é o ciclo de aventura, falha e melhoria que é fundamental para o sucesso deles. Lançamento antecipado, lançamento muitas vezes é uma idéia arriscada, popularizada por Eric S Raymond em seu ensaio de leitura obrigatória, A Catedral e o Bazar.

Experimentação a chave

Há muitas maneiras diferentes de interpretar isso, desde o rápido disparo das versões do kernel até o ciclo de distribuição como o Arch, mas no seu nível mais baixo, é uma ideia que deve empurrar os milhares de projetos que já escalaram o primeiro declive. um problema específico - para publicar pelo menos um lançamento.

Existem dois projetos meus em que posso pensar. Um era editor de um sintetizador difícil de programar (um Alesis Micron) e o outro era um controlador de software. Eu provavelmente gastei centenas de horas com eles, mas porque nenhum deles está apto para uso (e provavelmente nunca será porque eu mudei para outras coisas), eles nunca verão a luz do dia.

Eles nunca serão compartilhados porque são pouco funcionais, contêm atalhos de codificação terríveis e não têm suporte. Se eu tivesse lançado o código assim que achasse que o projeto era maduro o suficiente para compilar facilmente, independentemente da qualidade geral, há mais do que zero chance de que um desses projetos - ou pelo menos parte dele - continuasse vivo..

Decodificar os dados binários para o sintetizador levou muito tempo, por exemplo, e essa informação salvaria outro desenvolvedor tendo que fazer exatamente a mesma coisa.

As desvantagens

Mas há duas enormes desvantagens com essa abordagem. O primeiro, e mais problemático, é que, como não há controle de qualidade, a maioria dos projetos aumentará o interminável ruído de fundo da Internet. Você só tem que dar uma olhada nas centenas de milhares de projetos definhando em sites como o SourceForge.net para ver o que eu quero dizer.

O segundo problema é que, ao fazer um lançamento como esse, você está se abrindo à crítica e ao ridículo, porque nunca será um padrão que você normalmente definiria. Isso significa que é importante que os usuários e desenvolvedores reconheçam a diferença entre uma versão final e uma versão "em andamento". Este é um problema sutil para o software livre, porque há tantas maneiras diferentes de lidar com o mesmo problema.

A versão em progresso do kernel pode ser baixada a qualquer momento a partir de um repositório Git, por exemplo, enquanto as versões entre as versões 1.0 e 2.6.x usam versões secundárias de números ímpares para denotar um estágio de desenvolvimento. Esse método foi substituído quando o Linux adotou uma abordagem mais 'liberada com frequência', negando assim a necessidade de versões de desenvolvimento em conjunto..

Mas esta estratégia de lançamento só funciona aqui porque muitas pessoas estão trabalhando com o kernel todos os dias. Não funciona para projetos pequenos, ou mesmo para grandes projetos como o Gnome. O grande lançamento do Gnome 3.0, como o KDE 4 antes dele, levou a comunidade a uma direção que não estava preparada, fazendo com que uma grande atualização parecesse uma ideia em progresso muito arriscada..

No entanto, apesar dessas dificuldades e dos problemas que eles causam, o software livre acabou por provar que a metodologia de divulgar as suas ideias em público, correr riscos e sair das pistas é a melhor maneira de inovar. É algo com o qual as empresas proprietárias não podem competir. Afinal, se você estivesse preocupado em se machucar, parecendo um idiota ou saindo da sua zona de conforto, você nunca.