Em Codeplex desperdiça seis meses reinventando rodas, Ryan Davis tem um problema com a Microsoft:
Vi um anúncio [in March, 2007] que o CodePlex, a versão da Microsoft do Sourceforge, tem lançou um cliente de controle de origem.
Este enfurece me. Essa coisa legal que eles passaram seis meses (seis!) escrevendo se chama Subversão, e teve uma versão 1.0.0 [in early 2004]. O Subversion teve sua primeira versão beta no final de 2003, portanto, o pessoal do Codeplex está muito atrasado em relação ao estado da arte nesse caso.
Como um todo, acho que o estado do software é péssimo. A única maneira de melhorá-lo é parar de escrever novos códigos. O código novo está sempre cheio de bugs, e é um caminho caro para ir da tela em branco ao programa estável. Precisamos tratar a programação de forma mais parecida com a matemática, precisamos construir com base em nossos resultados. As ferramentas de desenvolvimento são um mercado especial, pois nossas necessidades são todas muito semelhantes e, quando precisamos de uma ferramenta, temos as habilidades para criá-la.
É um ótimo discurso – o senhor deveria ler tudo — mas não sei se concordo totalmente com o senhor.
Embora eu tenha empatia com o sentimento geral que Ryan está expressando aqui, também me vi concordando com Addy Santo, que deixou este comentário:
O autor parece pensar que todo o desenvolvimento de software é feito em porões e dormitórios. A realidade é que o software é um setor como qualquer outro, e segue as mesmas regras simples de economia. Quantas marcas de tênis esportivos existem? Quantos MP3 players diferentes? Sabores de pasta de dente? Se o senhor puder passar pela fila de refrigerantes e não ficar “enfurecido” com o Vanilla Cherry Diet Doctor Pepper, então talvez seja um hipócrita.
Portanto, se o senhor acha que o tipo específico de controle de origem da Microsoft é redundante, o senhor vai realmente odiar Diet Cherry Chocolate Dr. Pepper.
(Agora sou obrigado por lei a criar um link para o Tay Zonday’s Chuva de Chocolate com Cereja vídeo. Minhas desculpas antecipadas. E se isso não fizer sentido para o senhor, veja aqui.)
Existem diferenças significativas entre o tipo de controle de versão do Team Foundation da Microsoft e o Subversion? A resposta curta é que não há. se tudo o que o senhor está procurando é uma bebida gaseificada. Se tudo o que o senhor precisa é de tarefas básicas e centralizadas de controle de código-fonte, eles são basicamente o mesmo produto. Então, por que não escolher o gratuito?
Mas o Team Foundation é muito mais do que apenas controle de código-fonte. É claro que existem equivalentes de código aberto para grande parte da funcionalidade oferecida no Team System, como Ryan é rápido em apontar.
A equipe do Codeplex afirmou que precisava escrever seu próprio cliente para se integrar à infraestrutura do servidor TFS. De acordo com um artigo do MSDN (Coloque todos os seus desenvolvedores em uma fila com o Visual Studio 2005 Team System), o TFS parece ser uma ferramenta complicada para ajudar a gerenciar seus desenvolvedores. Lendo a descrição, o TFS é um rastreador de problemas, testador de unidade, integração contínua, sistema de controle de origem e plug-in do Visual Studio. Portanto, basicamente uma combinação de Trac, NUnit, CruiseControl.NET, Subversãoe um plug-in do Visual Studio. Por que não escrever apenas o plug-in do Visual Studio e conectar-se às ferramentas que as pessoas já estão usando? Todas essas ferramentas têm arquiteturas de plug-in avançadas que provavelmente suportariam qualquer adição sensata que o senhor quisesse fazer.
A resposta, é claro, é que a Microsoft faz todo esse doloroso trabalho de integração para o senhor, por um preço.
Se o senhor tiver tempo para olhar mais de perto, encontrará diferenças mais saborosas entre o Subversion e o controle de código-fonte do TFS. Diferenças mais semelhantes a, digamos, Dr. Pepper e Mr. Pibb.
Não vou enumerar aqui todas as diferenças sutis e não tão sutis entre os dois; não é meu objetivo discutir entre dois sistemas modernos e centralizados de controle de versão. Os dois são ótimos. Escolha o sistema moderno de controle de código-fonte que preferir e dedique um tempo para aprender a fundo sobre ele. O controle de fontes é o alicerce da engenharia de software modernae encontrei pouquíssimos desenvolvedores que realmente entendem como ele funciona. Todo esse tempo que iríamos gastar discutindo se o seu sistema de controle de código-fonte pode vencer o meu sistema de controle de código-fonte? Tenho uma ideia radical: vamos gastá-lo com o aprendendo o maldito material em vez disso.
Ainda assim, há um problema muito mais profundo e endêmico ao qual Ryan faz alusão, e ele merece ser abordado.
Um dos maiores desafios da Microsoft nos últimos anos tem sido o fato de a seus concorrentes têm a liberdade de enviar componentes de código aberto bastante maduros como parte de seus sistemas operacionais. Quando foi a última vez que o senhor viu algum componente de código aberto qualquer coisa que esteja sendo enviado em um produto da Microsoft? Em algum nível corporativo profundo e sombrio, a Microsoft deve se sentir compelida a reescrever tudo para possuir completamente o código-fonte. Às vezes, uma pessoa mais cínica poderia dizer “muitas vezes”, isso resulta em cópias de baixa qualidade em vez de inovação real, como é o caso do muito criticado framework de teste unitário MSTest. É um clone do NUnit com todos os novos bugs e nenhum novo recurso, mas ele pode ser incluído na caixa com o Visual Studio e integrado ao produto. É um caso do tipo um passo à frente, dois passos atrás.
Todas as pessoas que conheço, inclusive nossa própria equipe do Stack Overflow, que tentaram usar a variante MSTest de testes unitários, disseram acabou levantando os braços e voltando para o NUnit. É muito doloroso; o clone comercial não tem a simplicidade, o poder e o suporte da comunidade da versão original de código aberto. Simplesmente não há razão para que o MSTest exista, exceto para satisfazer alguma diretriz corporativa bizarra de que a Microsoft nunca envie código-fonte aberto em seus produtos. Além disso, esse ponto cego prejudica os pontos de integração óbvios. A Microsoft poderia criar pontos de integração de primeira classe para o NUnit no Visual Studio. Mas não o fez, e provavelmente nunca o fará, porque muito esforço é dedicado à manutenção do clone de segunda categoria do MSTest.
Na verdade, quanto mais penso sobre isso, mais acho que a total incapacidade da Microsoft de integrar software de código aberto de qualquer tipo que seja em seus produtos pode acabar matando-os. É um problema enorme, que só vai piorar com o tempo. O software de código aberto parece evoluir de acordo com uma lei de potência diferente do software comercial. Se eu trabalhasse nos altos escalões da Microsoft, estaria olhando para o gráfico de crescimento do software de código aberto de 1999 a 2008 e me borrando nas calças agora mesmo.
É uma pena, pois a melhor maneira de “vencer” o código-fonte aberto é juntar-se a ele, integrar-se a ele e fornecer componentes de código-fonte aberto como parte de seu produto. Infelizmente, esse é o único caminho que a Microsoft parece não querer seguir.
Atualização: Para saber mais, leia a explicação de Jon Galloway: Por que a Microsoft não pode enviar código-fonte aberto.