Tem uma coisa que o Raphael vira e mexe fala que me dá arrepios: “FOSS não funciona como estímulo para a inovação”. A última vez que eu me lembro que ele falou isso foi aqui. E pelo jeito não sou o único que tem estes arrepios como se pode ver pelo comentário do Carlos Costa neste mesmo post do Raphael.

E eu não sinto arrepios porque sou um defensor inveterado do software livre. Na verdade eu acho que existem coisas boas tanto do lado do software livre como do lado do software proprietário e acho que tem espaço para todo mundo. Sinto arrepios porque realmente acho que software livre tem muita inovação de verdade. O problema é que eu ainda não consegui achar um contra-exemplo cabal para você, Raphael. Pelo menos não para o sentido de inovação que eu acho que você quer dar à sua frase.

De certa forma eu concordo parcialmente que os conceitos implementados em software livre já foram testados no mercado. Isso é verdade muitas vezes. Mas eu acho que este ponto de vista é limitado. No fundo eu acho que os conceitos implementados em software livres são maduros o suficiente, tendo sido ou não implementados pelo mercado. Isto porque quando você se envolve em uma comunidade de pessoas, em geral a tendência é aceitar apenas coisas que já estejam maduras o suficiente e que portanto, irão muito provavelmente gerar código de qualidade.

Não me entendam mal: não acho que software livre não tenha inovação por completo. Se olharmos de perto o GCC, ou o Eclipse ou vários outros projetos open source veremos que eles tem sim uma grande dose de inovação. Mas eu diria que, na visão macro, eles são mais inovadores na forma de fazerem coisas que já existem do que na forma de criarem coisas novas. O que não impede, é claro, que muitos testes e invenções estejam sendo feitas na visão micro destes softwares. Eu diria que eles são mais parecidos com o que a Apple anda fazendo nos últimos anos(copiando conceitos já existentes e dando uma roupagem diferente a eles, inventando uma coisinha aqui e outra ali) do que com o que a Intel ou a IBM fazem no campo de processadores por exemplo (efetivamente pesquisando novas tecnologias e tentando aplicá-las no mundo real).

Aonde eu quero chegar com isso? Para mim o principal problema na frase do Raphael é o mal uso da palavra inovação.

O que é inovação? Quando eu vejo alguma coisa como “FOSS não funciona como estímulo à inovação” eu interpreto mais como “FOSS não funciona como estímulo para a invenção”. Até pouco tempo atrás eu achava muito sútil e muitas vezes inexistente a diferença entre invenção e inovação. Mas a cada dia eu venho me atentando mais para a diferença entre estas palavras. Invenção é realmente inventar coisas novas, fazer algo que nunca foi feito antes. Inovar não é necessariamente inventar: inovar é muitas vezes pegar algo que já existe e, com uma roupagem nova, criar algo que tenha um apelo ou uma utilidade ainda maior do que aquilo que existia antes. Ainda que eu não goste muito da frase, como diria Jean Paul Jacob, “Inovação é o enlace entre invenção e a visão do valor desta invenção”. É exatamente isto que a Apple anda fazendo muito bem nos últimos anos: efetivamente não inventando nada de novo, mas habilmente dando um novo valor e uma nova visão a produtos que já existiam.

Sob esta ótica eu acho que software livre é extremamente inovador. Inovador no modelo de desenvolvimento. Inovador nas idéias implementadas. E, algumas vezes, inovador ao inventar novas coisas e novos conceitos também. Como eu disse antes, ainda não achei um exemplo cabal de um produto completo de software livre que seja totalmente novo (e talvez aí esteja a falha na minha argumentação contra a frase do Raphael… alguém pode me ajudar?). E acho até que isto é apenas um reflexo da economia de mercado: se você inventou algo que acha bom, porque não ganhar dinheiro com isso? Software livre é muito usado em partes já comoditizadas de sistemas (o que não exclui inovação) e a parte de maior valor agregado tende a ser proprietária justamente para gerar mais lucro. Mesmo assim eu poderia citar diversas funcionalidades que foram implementadas antes em software livre (algumas até mesmo no projeto em que eu trabalho) e que nunca tinham sido feitas antes por nenhum outro software. Quer um exemplo? Suporte em sistema operacional, compiladores e debuggers a plataformas híbridas: processadores que possuem núcleos de diferenças arquiteturas no mesmo chip. Isso é totalmente novo. E apareceu primeiro em plataformas de código aberto. Se isto não é inovação, o que é então?

Enquanto boa parte da molecada por aí que ainda não aprendeu a pensar por conta própria ficou triste com o anúncio da Google que encerrava as especulações sobre o gPhone, ficando sem imagens que pudessem copiar para os seus (spam-)blogs, e por tabela sem assunto para entupir os agregadores de conteúdo com notícias idênticas, o “velhaco” aqui parou para pensar no impacto e no potencial futuro da Open Handset Alliance. Eu vi, e gostei. Um plano como esse é uma lição clara de quem aprendeu com o Passado para pensar o Futuro.

Se você não entendeu o que estou falando, fique tranquilo. Vamos por partes.

Computação Pessoal

Computeiros, tautologicamente, têm suas vidas focadas no computador. Ficamos com o tocador de música ligado o dia inteiro, com nossas coleções imensas de canções nem sempre obtidas legalmente. Resgatamos contato com nosso amigo que se mudou para o Curdistão para popularizar o futebol de botão. Mantemos nossas memórias, vídeos, fotos, cartinhas de amor que queríamos enviar para a nossa musa mas ficamos com vergonha de mandar, já que você, no fundo, no fundo, sabia que não era muito romântico declarar algo como “você é tão bela quanto a Lara Croft no Tomb Raider 2″. O computador é o meio, começo e o fim de boa parte de nosso cotidiano.

Para nós e para os profissionais que já estão fazendo parte diretamente ou indiretamente da Economia Digital, a linha que separa o computador-pessoal do computador-ferramenta-de-trabalho é tênue, cada vez mais imperceptível. Entretanto, há muitos outros que olham o computador como uma besta indomável, complexa, para não dizer supérflua.

Isso não quer dizer, entretanto, que eles estão livres da evolução tecnológica. Mesmo aqueles que se recusam a sentar na frente de um monitor estão fazendo parte da revolução que começou nos anos 80, da Computação Pessoal.

Vou tentar simplificar: Computação Pessoal é tudo que envolve o uso de um computador, cuja finalidade principal não é o trabalho. Aquela viagem chata que você levava o Game Boy? Computação Pessoal. O seu primeiro Discman? Computação Pessoal. O seu decoder de tv a cabo? Câmera Digital de 32 Gigapixels? Tudo é Computação Pessoal.

O ponto mais interessante. Mesmo os tecnófobos, estes que não sabem nem mexer em um mouse, provavelmente têm o seu “Computador Pessoal”. À diferença de nós, estes fazem uso da tecnologia através de outro dispositivo. Para eles, o PC é outro e cabe no bolso: é o telefone celular.

Acho que o que eu escrevi acima não é nenhuma novidade. A velocidade do ciclo de desenvolvimento dos aparelhos celulares, as toneladas de funcionalidade presentes nos aparelhos mais básicos, as inúmeras apresentações de executivos falando sobre a questão da convergência digital, etc, etc. Você não precisa de mais um blogger chato querendo dizer “Eureka! Celulares vão se tornar tão poderosos quanto computadores”, não é mesmo?

Padronização do Desktop: um pouco de História.

Computadores, hoje, são quase oni-presentes e aparentemente são bastante diferentes. Mas, por baixo de marca, gabinete, ou até mesmo sistema operacional, todos acabam sendo muito parecidos. Todo mundo (e por todo mundo, entenda “mais de 99,99% dos consumidores normais”) tem um computador que usa um chip com arquitetura x86 (ou alguma extensão dela, como a x86-64). Placas auxiliares são instaladas em slots padronizados (AGP, PCI ou PCI-x). Periféricos se comunicam através de USB. Comunicação sem fio é predominantemente feita por Wi-Fi (802.11*).

Tudo isso não acontece por acaso. São padrões determinados pela indústria, com o propósito primário de facilitar o desenvolvimento e a fabricação de componentes para um sistema complexo. Assim, subsistemas desse sistema complexo podem ser trocados com razoavel segurança. Assim como eu sei que eu posso colocar qualquer motor elétrico de 110V na tomada aqui de casa, eu sei que eu posso comprar qualquer Pen Drive USB para o meu computador, e sei que vai funcionar.

É claro que essa padronização não surgiu de uma hora para outra. Os primeiros mini-computadores e computadores que pretendiam ser de uso doméstico tinham arquiteturas completamente diferentes entre si. Um computador como o Altair rodava apenas programas feitos para ele, e era arquiteturalmente diferente de um TRS-80. Um usuário entusiasta de um computador aprendia a programar para uma máquina e assim ficava, pois não havia necessidade de portar seu aplicativo para outra arquitetura.

Isso é muito comum, se analisarmos o progresso e a evolução de inventos humanos. Traçando um paralelo com a teoria de evolução de Darwin, uma nova tecnologia pressiona o surgimento de novos produtos (assim como uma mudança no ambiente causa um aumento no número de mutações genéticas em espécies já existentes), e desses novos produtos sobrevivem os que se mostram mais aptos ao ambiente (o produto que satisfaz melhor o público é o que acaba sendo mais copiado e prospera), determinando qual será a tendência de design de produtos. Veja como os aparelhos de TV e os primeiros aviões eram diferentes entre si, e vejam o quanto eles são similares hoje em dia. Dá pra sacar que, até com memes, existe o que é chamado de “survival of the fittest”?

No fim de 1970, as apostas de todos provavelmente seriam na Apple, com o Apple I e com o Apple II. Seus computadores poderosos e fáceis de usar começaram a ganhar momento. Empresas passaram a desenvolver aplicativos para ele. O sucesso do Visicalc serviu como um efeito bola de neve. Mais pessoas queriam o Apple por conta do Visicalc, que aumentava o interesse dos desenvolvedores pela plataforma Apple, que fazia da Apple a arquitetura com uma coleção de software mais interessante. Darwin trabalhava, enquanto a concorrência padecia. Por mais simples que fossem as arquiteturas da época, era trabalhoso portar software. Muitos programas ainda eram desenvolvidos em linguagem de máquina. Compiladores BASIC eram caros e para profissionais. A Apple parecia a grande vitoriosa.

Parecia. A Apple passou a ter concorrência da IBM e do padrão PC. Aproveitando a explosão do mercado de computadores para uso doméstico, a IBM deu a sua tacada: um padrão livre, que pudesse ser seguido por qualquer que quisesse montar um computador compatível. Dessa forma, uma empresa que quisesse entrar no mercado de desktops poderia fornecer apenas um componente do produto, ao invés de ter que desenvolver todo um computador (e ainda ter que tentar competir com a Apple). Isso também serviu para incentivar a concorrência, o que levou a uma redução acelerada dos custos.

Vá lá: tudo que a IBM acertou com o padrão-PC, ela errou ao ter dado uma licença de fornecimento exclusiva do Sistema Operacional para uma empresa pequena, chamada Micro-soft-com-hífen. Mas a estratégia do padrão aberto funcionou. A Apple, que manteve-se verticalizada (oferecendo hardware e software) acabou perdendo terreno para os milhares de concorrentes horizontais que trabalhavam no padrão IBM-PC.

Fale com o Miguel, se quiser mais detalhes da história da Apple. Mas vou resumir: eles teimaram um bom tempo em manter-se verticais, e só recentemente abriram mão disso, e foram obrigados a admitir que a estratégia vertical não deu certo. O hardware de um Macintosh é, hoje, virtualmente idêntico ao de um computador da HP ou da Dell. Para desgosto de muitos fanáticos, hoje é um Intel que roda em Macs. Até mesmo software para o mercado de DTP tem menos features em suas versões para Mac OS, comparada com a versão para Windows. Muito do charme some quando se tira o teclado com backlight.

Pois bem. Não é de hoje que o mercado de desktop é chato, sem grandes surpresas. Como eu já disse antes, POSIX já ganhou, e boa parte do pacote de soluções que gerou bilhões para a Microsoft-sem-o-hífen já é “good enough” há uns bons 6 anos.
Se é que existe alguma coisa que ainda é sexy para desenvolvedores, isso está em aplicativos que fazem uso da Internet e dos avanços de telecomunicações.

O Mercado de Mobile

Entra o mercado de mobile. Acho que foi em 1999 que meu pai chegou em casa com um StarTac, da Motorola. O que tinha de especial? Pouca coisa, além de um desenho moderno e o fato de ser um dos primeiros modelos no Brasil que foram trazidos para as linhas digitais. De qualquer forma, podemos ver o quanto mudou em apenas 8 anos. Celulares hoje em dia mandam mensagens de texto, mensagens multímidia, possuem câmera integrada, mp3, possuem jogos, conectam à internet, fazem cafezinho e até pagam suas contas - inclusive aquela conta absurdamente cara da sua última fatura de celular.

Tudo muito legal, tudo muito divertido. Mas ainda falta alguma coisa. Por exemplo: e se eu quiser trocar a minha câmera digital? Ou como faço para adicionar um HD ao meu smartphone? E se eu quiser usar outra bateria, ou adicionar uma placa que me permita usar dois chips GSM no mesmo aparelho?

Mudanças em hardware, nem pensar. Software deveria ser um pouco mais flexível, mas ainda está longe do satisfatório. Diferentes sistemas operacionais, diferentes versões, diversos padrões de rede (GSM, CDMA, iDen, entre outros) e - mais importante - diferentes plataformas de desenvolvimento de software fazem com que planejar um produto para o mercado mobile seja tão fácil quanto atirar em um grilo usando uma escopeta numa sala pequena, depois de tomar meia garrafa de tequila. Chamar de “mercado dinâmico” é um eufemismo. É um mercado caótico.
Quer adicionar uma outra variável na brincadeira? A penetração de aparelhos celulares é muito maior que a de computadores domésticos. No Brasil, já passamos há tempo a marca de 60 milhões de aparelhos ativos. Isso passa (em muito) o número de computadores. Na Itália, mais de 90% da população possui telefone celular. Os números de usuários de Internet não chegam à metade. O celular é, sem dúvida, o Verdadeiro Computador Pessoal.

E aí apareceu a oportunidade de ouro para a Apple e o iPhone. Do mesmo jeito que fizeram com o Apple I e com o Apple II, a estratégia para o iPhone é reduzir o número de subsistemas (poucos aplicativos de terceiros, sistema operacional próprio, software próprio) e lutar para manter controle sobre cada uma das partes. Quem melhor que Steve Jobs, com seu senso de design, para delimitar o melhor ponto para atender todos os requisitos conflitantes que existe num mercado caótico como o mobile?

Enquanto todos batem cabeça e não se entendem, a Apple usa a sua vantagem como fabricante de hardware e espera neutralizar as operadoras de telefonia futuramente, apostando no crescimento do Wi-Fi e pensando que o seu iPhone poderá ser um telefone (VoIP) e, principalmente, como um dispositivo para a distribuição de conteúdo digital. Só depois, e quando for do seu interesse, ela precisaria abrir o iPhone para terceiros. Ela nem mesmo precisaria ter um “Visicalc”, pois ela já se encarregou de fazer isso antes: chama-se iTunes Music Store.

Do jeito que se vê hoje, a Apple tem tudo em mãos para se tornar a força dominante do mercado de mobile computing. A vingança de Steve Jobs, tardia, seria em sua dominação do Verdadeiro Computador Pessoal.

Android: estamos de novo em 1981

Not so fast, Steve. Você acreditou mesmo que todo mundo ia ficar assistindo você ficar com todo o bolo? As operadoras de telefonia ainda querem briga. E aqueles que desenvolvem software também precisam ter um ambiente onde eles sabem que seu sistema rode sem que eles tenham que pedir permissão para ninguém.

Qual a melhor maneira de garantir isso? Ora, lançando um padrão de referência para quem quiser desenvolver dispositivos móveis! Foi exatamente isso que a Google fez essa semana. Ao invés de lançar um aparelho de celular, foi anunciado o Android. O Android é uma plataforma aberta de desenvolvimento, com especificação de sistema operacional, middleware e aplicativos finais. Quem quiser desenvolver um aplicativo para um celular que seja Android, basta trabalhar de acordo com a spec.

Os fanáticos por Java vão apontar para o JavaME, como forma de ter uma plataforma de desenvolvimento livre e definida. Eu vou dizer “Nice try, but no.” Do mesmo jeito que acontece no desktop, aplicativos JavaME acabam limitados pela qualidade da implementação das bibliotecas que funcionam “embaixo”. Por exemplo: assim como um toolkit como o SWT tem que ser um mínimo denominador comum entre os ambientes gráficos subjacentes (GTK, MFC, Cocoa), uma implementação de JavaME é, no máximo, tão poderosa quanto o pior sistema usado atualmente nos aparelhos celulares. O padrão do Android é a partir do zero, não fica obrigado então a fazer nenhum tipo de compromisso por conta de limitação tecnológica.

Em suma: Android é a versão mobile do padrão IBM-PC. Não importa se você for um desenvolvedor de aplicativo ou de componentes para celular, você poderá ter um pouco mais de segurança na hora de começar o seu investimento. Isso levará a muita inovação no mercado, pois teremos mais empresas tentando arriscar algo novo, sem medo de ver seu investimento sendo jogado fora por alguma reorientação tecnológica. Isso levará a redução ainda maior de custos. De comoditização total de hardware. Até mesmo podemos pensar em maior integração entre serviços que hoje só são pensados para web. Um celular Android poderá, efetivamente, tornar-se o PC 2.0.

Apple vs o resto. Dessa vez, até pode ser diferente.

Cabe a Apple decidir se vai querer que o iPhone se torne um sucesso como o Mac ou como o iPod. Usuários (e lucros) ela terá em qualquer hipótese. Entretanto, a insistência da Apple em manter todo o controle da arquitetura se mostrou falha na guerra dos desktops. Até hoje, com geeks tietando a Apple da mesma forma que adolescentes tietavam Britney Spears, o mercado da Apple não passa de magros 3%. Será que ela vai se posicionar, de novo, para manter apenas um nicho ou pretende ir para as cabeças?

Dois fatores pesam a favor, dessa vez. O primeiro: é muito difícil que o Google faça por alguma empresa o que a IBM fez pela Microsoft, o que levaria a uma grande procura por celulares com o padrão Android e a um possível monopólio de algum serviço dentro dele. O outro: o mercado de mobile business está bem mais maduro, hoje, do que o mercado de computadores era em 1981. Quase metade dos habitantes do planeta usa um celular, e a imensa maioria já está acostumada a mudar de aparelho a cada 18 meses. Não há nada que impeça que eles resolvam fazer a mudança.

De um jeito ou de outro, é uma época bem interessante para trabalhar com o desenvolvimento de aplicações para o Verdadeiro Computador Pessoal.

A versão 2.2.1 do NeoOffice para Mac está disponível. O site do aplicativo promete suporte nativo a drag-and-drop, copy-paste e impressão, compatibilidade com Office 2007 e macros de Excel e uso do corretor ortográfico nativo do Mac OS e acesso ao Adress Book. Para quem não sabe, o NeoOffice é baseado no código do OpenOffice.

Em geral, as pessoas que gostam do pacote Office torcem o nariz para o o OpenOffice e afins, devido a alguns problemas de compatibilidade com arquivos xls ou ppt. Eu não tenho nada contra, muito pelo contrário. Minha experiência de desenvolver apresentações ou escrever textos com NeoOffice foi muito boa. É bem verdade que eu eu não sou um fã do pacote Office e tampouco um heavy-user. Mas garanto que para o uso no dia a dia, ele quebra muito bem o galho e é totalmente aberto e livre.

Uma versão preliminar da documentação da Juice Lib está disponível em http://code.google.com/p/juicelib/wiki/JuiceDoc

Ontem coloquei no ar a versão 0.1.2 da Juice Lib. A grande novidade é o sistema de pooling com AJAX. Este sistema permite que uma requisição seja feita de tempos em tempo via XMLHTTPRequest para um endereço, e que o resultado seja processado em background.

Segue um exemplo de criação de objeto de pooling:

• sched = new juice.rpc.AjaxScheduler(”http://minhaurl.com”,{response: response_handler,delay: 10000});

A primeiro parâmetro é o endereço a ser chamado. O parâmetro response recebe uma função a ser chamada quando a resposta estiver disponível. O parâmetro delay define o tempo entre duas chamadas em milisegundos.

Ainda é possível passar os seguintes parâmetros:

• um parâmetro error que recebe uma função para tratamento de erros de requisição,
• um parâmetro request que pode ou receber uma string de parâmetros a serem enviados na requisição (no formato de URL) ou uma função que é chamada antes de cada requisição e que retorna a string de parâmetros (útil para requisições que podem variar ao longo do tempo)
• um parametro method que define o método de envio (get ou post). O método default é get.

Quem já tentou baixar o OpenOffice para Mac OS X sabe que o porte atual só funciona rodando sobre X11. Por algum motivo que me escapa, não existem planos pelo pessoal do OpenOffice de portar para um ambiente nativo Mac. Mas existe o projeto NeoOfficeJ que fez este trabalho. Estou usando a versão 2.0 Beta, que executa bem tarefas simples de edição de arquivos de texto e planilhas tanto no formato MS Office quanto nos formatos XML. Como não sou heavy user de pacote Office, isso já resolve meus problemas. Em breve irão lançar uma versão totalmente Aqua. Acho que vale a pena conferir.

A idéia deste post surgiu das duas reclamações que o Miguel já fez neste blog a respeito da falta de documentação em projetos de Software Livre (uma destas reclamações está aqui) e de algumas conversas que tive com ele sobre este assunto baseadas na recente experiência que estou tendo no meu trabalho.

Bom, antes de mais nada, concordo com o Miguel de que falta documentação na maior parte dos projetos de software livre que eu já vi. Quer dizer, depende do que nós estamos acostumados a chamar de documentação. O meu referencial de documentação de um projeto vem dos conhecimentos de Engenharia de Software que eu tenho e da vivência com outras Engenharias. Deste ponto de vista, na minha opinião, documentação é tudo aquilo que te ajuda, de alguma forma, a explicar um sistema, como ele funciona, quais são suas funcionalidades e, talvez o mais importante, como usá-lo de uma maneira correta e eficiente, ou seja, para que o sistema serve.

Acho que a grande falha neste sentido para muitos projetos de software livre está no fato de que muitas pessoas da comunidade acreditam que a documentação é o código-fonte, afinal, que melhor maneira haveria para obter informações a respeito de um sistema do que simplesmente poder ver como o sistema funciona nos mínimos detalhes? A falha neste pensamento, comparado ao que eu disse no parágrafo anterior, está na palavra “ajuda”. A documentação deveria ajudar a entender o sistema e olhar o código fonte nem sempre ajuda muito no início. Em sistemas grandes como o Eclipse, pode-se demorar uma semana ou mais para se pegar o “jeito” e conseguir, a partir de então, obter informações relevantes do sistema a partir do código-fonte. Em projetos grandes, uma semana pode não ser muito tempo, mas isto inibe, por exemplo, que uma pessoa que nunca tenha feito um plugin para Eclipse se aventure a fazer um plugin que lhe pareça útil… simplesmente porque o tempo que ela vai gastar para entender a arquitetura do sistema lhe dá apenas duas opções: ou ela vai utilizar uma parte do seu tempo livre para entender o funcionamento do sistema ou vai se virar sem a funcionalidade que ela queria implementar e, provavelmente, distribuir gratuitamente para uso-fruto do resto da comunidade.

Outra questão importante é: se há documentação, muitas vezes ela não é de fácil acesso. É muito comum os sites que hospedam projetos de software livres terem estruturas complicadas, pouco amigáveis. Apesar de eu achar este um detalhe menor, é importante citá-lo também, pois isso leva com que pessoas que trabalham com software livre se comportem de uma maneira diferente de pessoas que, por exemplo, trabalham com software proprietário.

Quando eu programava em tecnologias proprietárias, minha maior fonte de referência não era o Google. Era muito mais fácil achar referências e soluções para meus problemas na própria documentação gerada pela empresa desenvolvedora do sistema. Tive esta experiência, por exemplo, com Visual Basic 6. Não quero aqui discutir as virtudes ou não desta linguagem e muito menos as virtudes ou não da Microsoft (isto dariam vários outros posts e este já vai ficar grande o suficiente). No entanto, a Microsoft fornece uma documentação muito completa, rica em exemplos e de fácil navegação e busca. Simplesmente isto fazia com que eu dificilmente recorresse a sites específicos a respeito de VB6, ou a fóruns ou ao próprio Oráculo, digo, Google. Isto também faz com que VB6 seja, ainda hoje, uma das linguagens mais conhecidas e mais utilizadas no desenvolvimento de sistemas, mesmo com todas as suas limitações e com o fim de suporte oficial da Microsoft à linguagem.]

Em compensação, todas as vezes que eu trabalho com software livre, “Google is my friend!”. Gosto das listas de discussão também, mas acho que elas são mais complicadas de serem utilizadas, pois existe toda uma etiqueta para participação de listas, o que inclui a leitura dos FAQs e perguntas antigas das listas, o que geralmente eu não tenho muita paciência para fazer. De qualquer forma, poderíamos dizer que neste caso a documentação não está escrita formalmente. Se ela existe, é difusa e esta mal catalogada (por melhor que o Google seja, ele não pode ser utilizado como catálogo de nada, até porque o objetivo dele não é este, por enquanto). Isto, na minha opinião, acaba inibindo alguns novos desenvolvedores a experimentarem o software livre. A filosofia de que a documentação é o código-fonte, para estas pessoas, não funciona.

Os mais puristas em relação ao modelo de desenvolvimento do software livre poderão pensar que eu estou exagerando, e talvez esteja mesmo. Mas eu queria chamar atenção para o fato de que talvez um processo mais elaborado de geração de documentação poderia fazer com que projetos de software livre fossem mais bem vistos por desenvolvedores de uma forma geral e pelas corporações também (afinal, hoje grandes empresas também têm papel decisivo no desenvolvimento de projetos de software livre).

Não estou dizendo também que se deva adotar um processo formal de qualidade de software no desenvolvimento de software livre. Este esquema, na minha opinião, não funciona com o modelo de desenvolvimento criado pelas comunidades de software livre. Um processo exagerado de documentação certamente desmotivaria os colaboradores dos projetos livres, mas alguns controles, como os criados, por exemplo, pelo Gforge, poderiam ser interessantes. Isto sem levar em conta alguns argumentos interessantes da comunidade de software livre para a ausência total de documentação nos projetos de software livre. Algumas que eu acho interessante e faço questão de comentar:

• Software de qualidade não necessariamente é feito com processos de qualidade e nem todo software feito com processo de qualidade tem qualidade. Isto é uma verdade indiscutível.
• Processos de qualidade de software como o CMMI focam boa parte do trabalho na definição dos processos pois se a empresa ou o grupo de desenvolvimento tiverem os processos bem definidos, isto significa que, teoricamente, a saída de uma pessoa do grupo e a sua substituição por outra pessoa não deveria interferir na qualidade do software produzido. Isto faz com que as pessoas sejam transformadas em meros recursos, o que, definitivamente, não é a idéia das comunidades de desenvolvedores de software livre, onde os desenvolvedores são os principais atores.
• Espera-se que a comunidade de software livre tenha colaboradores bons. E uma pessoa que não seja boa o suficiente para ler um código-fonte e entendê-lo não agregará nenhum valor ao movimento. Isto, na minha opinião, é uma verdade pela metade. Uma das grandes batalhas de um dos principais representantes do mundo de software livre, o Linux, é que ele seja um sistema operacional mais aceito e utilizado mundialmente. E, para que isto aconteça, é necessário, antes de mais nada, que o sistema seja fácil de usar e seja entendido por pessoas que não fazem nem idéia do que seja um código-fonte. Qual é a melhor maneira de se fazer entender neste caso? Eu acho que uma boa documentação poderia ajudar bastante nesta hora.
• Na comunidade de software livre, boa parte dos problemas que seriam resolvidos com processos de qualidade de software são resolvidos pelo mantenedor do projeto. Sem dúvida nenhuma, o mantenedor é uma figura crucial em projetos de software livre e ele é o responsável, como o próprio nome diz, pelo bom andamento do projeto. Dizer que o processo de desenvolvimento de software livre não possui nenhum processo formal de qualidade pode até ser verdade, mas isso não significa que o mantenedor e seus colaboradores não tenham que definir funcionalidades, recursos, estimar tempo de desenvolvimento e definir milestones e releases do produto. Tudo isto também acontece com software livre.

Em suma, acho que o que talvez falte para o software livre seja pegar algumas poucas idéias dos processos complexos de qualidade de software e tentar aplicar estas idéias de uma forma apropriada à sua realidade. Sei que cada projeto é um caso diferente e que as regras não seriam universais, mas alguns conceitos poderiam ser usados para tentar ajudar a vida não só dos desenvolvedores, mas também dos usuários comuns que queiram propagar a filosofia de ser livre.

Eu acho que em algum post antigo deste blog eu já reclamei da falta de documentação decente da maioria dos projetos de software livre. Até projetos do porte do Eclipse e jakarta-Apache são bem fracos nesta parte. A Jakarta fornece uma documentação geral bastante interessante, sobre conceitos dos sub projetos deles, e sobre instalação básica, quick install, etc… Mas quando se precisa de detalhes de configuração e coisa mais profissionais, aí a documentação não dá conta (por exmplo: até hoje não consegui encontrar uma lista completa dos validadores disponíveis no struts, com sintaxe, parâmetros e coisas do gênero).
Nessas horas, essa falta de documentação é compensada pelas listas de discussão dos projetos. Uma característica muito forte da comunidade OpenSource/Software livre é a facilidade com que se consegue trocar informações e idéias com usuários e desenvolvedores. Recentemente, tive dificuldades pra resolver um problema da minha aplicação struts: pesquisei durante dois dias em documentação, blogs, artigos, e simplesmente não conseguia encontrar a forma de fazer o que eu queria. Daí resolvi me cadastrar na lista de usuários e desenvolvedores do projeto: em duas horas consegui uma resposta, e de quebra ainda tirei dúvida de duas pessoas e treinei meu inglês. Eu já tinha tido a oportunidade de usar estas listas quando trabalhava com programação de barramento Firewire em Linux. Aconselho fortemente o uso deste recurso, mas sempre respeitando as regras das listas. E sobretudo: uma boa pesquisa prévia sobre o assunto é sempre bem vinda.

A algum tempo atrás, o Ricardo me falou sobre este site. Recentemente,
recebi um artigo do Dicas-L falando sobre o mesmo site, portanto acho
que vale a pena comentar aqui.O site PortableApps.com disponibiliza vários pacotes de programas conhecidos do mundo OpenSource como Firefox 1.5, Gaim (ICQ, MSN, GoogleTalk, Jabber), Thunderbird e OpenOffice em versões portáteis, que cabem em um PenDrive USB. A idéia dos desenvolvedores é possibilitar que você carregue seus aplicativos favoritos consigo, permitindo roda-los a partir de qualquer computador (desde que o OS seja compatível) com porta USB.

Uma grande vantagem dessa idéia é permitir ter um mini escritório virtual de bolso. Outra vantagem é minimizar problemas de compatibilidade. Por exemplo: se é preciso realizar alguma apresentação em formato OpenOffice Impress, posso garantir que onde quer que eu vá sempre será possível fazer a apresentação, já que além desta, no pen-drive, terei o aplicativo necessário para exibi-la.

Um unico defeito do projeto é que por enquanto, os softwares só são para windows.

O texto What Business Can Learn from Open Source discute como é possível que projetos Open Source, desenvolvidos por programadores do mundo todo (em geral trabalhando de graça), podem competir em pé de igualdade com programas desenvolvidos por multinacionais (que investem milhões), e como isso pode ser utilizado como filosofia de trabalho para empresas e pessoas em geral.

A ZNet publicou uma entrevista muito interessante com Richard Stallman, onde ele fala sobre o movimento Software Livre, sobre o sistema Linux (ou melhor, GNU/Linux) e sobre política. Longo, mas bastante interessante. Vale ressaltar a explicação entre as diferenças dos movimentos de Open Source e Free Software, e a menção à UNIVATES e ao SAGU.

Clique aqui para ler o artigo.

PS: Agradeço ao Danilo, que me indicou o texto.