Archive for the 'software livre' Category

O que diabos é AGPL?

A menos que você tenha passado os últimos dez anos preso em uma caverna em um planeta distante com os olhos e ouvidos vendados, deve pelo menos já ter ouvido falar da General Public License, a famigerada GPL. Ela (ainda) deve ser a licença mais usada no mundo para distribuir software livre e suas condições são bastante simples:

  1. Você tem acesso ao código-fonte do programa que está executando e pode fazer basicamente qualquer coisa com ele;
  2. Você pode inclusive modificar o programa, mas se quiser fazer isso precisa distribuí-lo sob os mesmos termos.

O sistema é bem elegante: você pode modificar os programas que recebe e/ou redistribuí-los sem modificação, mas deve oferecer a quem receber o programa de você os mesmos direitos que você recebeu. Isso garante que toda melhoria esteja disponível para todos os interessados e acaba criando comunidades em torno de uma peça de software. Claro que o texto completo da licença é bastante extenso, afinal de contas precisa incluir todo o advoguês para cobrir os casos limite e garantir que ninguém perca nenhum desses direitos no meio do caminho, mas a idéia é basicamente esta.

Porém há um detalhe bastante sutil neste esquema todo. Com a GPL, as pessoas precisam ter acesso ao código-fonte dos programas que estão executando. No caso de programas acessados através de uma interface de rede qualquer quem executa o código é uma máquina remota. Os usuários que acessam a aplicação de outras máquinas numa rede não podem ver o código-fonte e o dono do servidor pode modificar o programa o quanto quiser sem precisar distribuir o código-fonte. Afinal de contas, tecnicamente é só ele e mais ninguém que executa o programa. É completamente legal, por exemplo, que alguém baixe a versão 0.6.10 do Motiro, faça algumas modificações locais e sirva a aplicação para quem quiser usá-la sem ver o código-fonte correspondente.

As aplicações web, como o Motiro, são certamente o exemplo mais óbvio de onde este detalhe pode ser explorado para subverter as intenções iniciais do autor e, como parece que tudo atualmente está indo parar na web, ele ficou bastante evidente. Também é importante notar que é bem possível que o autor realmente quisesse deliberadamente permitir este uso, mas vou deixar esta discussão para outro dia. No caso do autor que quer que todos os usuários possam estudar e contribuir com seu programa, o universo de colaboradores pode ser bastante reduzido se forem considerados usuários apenas os donos dos servidores.

Colocando de uma forma bastante grosseira (e abrindo espaço para quem quiser corrigir), a GPL considera que os usuários são as pessoas que detém as máquinas que executam os programas. Neste sentido, os usuários têm todos os seus direitos, inclusive o acesso ao código-fonte, garantidos. Porém, no caso das aplicações web, as pessoas que realmente usam os sistemas (tipicamente através de seus navegadores) não têm nenhum desses direitos.

Num mundo repleto de processamento distribuído onde a maioria das pessoas não sabe exatamente que computador está efetivamente executando os programas que elas usam, a distinção entre executores e usuários deixa de fazer tanto sentido. A GNU Affero General Public License é uma licença com texto baseado na GPL original (dê uma olhada no texto completo para saber os detalhes, eu não sou advogado) que tenta consertar esta brecha. A história da licença é bem complexa, mas se eu tivesse que resumir, diria que para a AGPL não importa se as pessoas estão executando um programa em um processador local e usando os sistemas através dos seus teclados e monitores ou se acessam um servidor através da Internet; não importa se elas estão executando o programa por conta própria ou se usam do serviço de hospedagem oferecido por outra pessoa, se puderem efetivamente usar um programa, são consideradas usuários e, como tal, devem ter acesso ao código-fonte.

(Uma observação relacionada: consegui permissão dos demais autores do Motiro para mudar a licença de distribuição e hoje publiquei a versão 0.6.11 do programa, agora sob AGPL. Se estiver precisando de um sistema para acompanhamento de projetos, considere usar o Motiro.)

Pó de estrelas

Parece que Thomas Thurman, um programador envolvido no projeto Metacity, andou falando (ou pelo menos sugerindo) que os astros e estrelas da programação não estão interessados em fazer pequenos consertos. Houve uma discussão interessante sobre esse tema em um dos últimos episódios do LugRadio e os caras citam o Metacity como exemplo de aplicação que não deve parecer muito atrativo para os astros. Para quem não sabe, Metacity é um gerenciador de janelas, um programa responsável, entre outras coisas, por organizar as janelas na tela, decidir onde uma janela vai ser aberta e lidar com redimensionamento e movimentação; ou seja, um programa que quanto mais invisível melhor. Este projeto em particular é tão invisível que nem um website tem. Se você tomar o cuidado de verificar o link que coloquei acima, vai ver que fui obrigado a referenciar um site ftp que contém o código fonte, já que é a referência usada por todo mundo. O raciocínio é que programas de infra-estrutura invisíveis como este não são muito bons para massagear a fama, afinal é difícil ser visto dentro de algo invisível.

Porém programadores não costumam ficar famosos por programar. Então não faz muita diferença se alguém está programando um novo jogo revolucionário ou se dedica seu tempo a escovar bits em um driver para um dispositivo usado por um total de duas pessoas no mundo todo. Eu sei que dizer isso deve ser algum tipo de clichê, mas não posso evitar: programadores famosos não ficaram assim por se preocupar com código, mas por se preocupar com as pessoas.

Isso obviamente não significa que programadores famosos não cuidam do seu código. A maioria deles se preocupa bastante, mas esta não é a razão que os torna admirados por seus pares. Eles conseguem chegar aos pedestais porque tomam o cuidado de compartilhar idéias com os colegas e tornar a indústria toda um lugar melhor para se trabalhar.

Tomemos o Linus Torvalds como exemplo. O cara dispensa qualquer tipo de apresentação, ninguém consegue esquecer o que ele inventou. O que ele escreveu é um núcleo de sistema operacional, algo que, simplificando grosseiramente, só faz se comunicar com o hardware e distribuir tempo de processador e memória para os vários programas que as pessoas querem realmente usar. Ninguém usa o kernel em si, este é só um mal necessário para quem quer rodar programas úteis e é provavelmente o mais longe do usuário final e perto da máquina que se pode chegar. Ninguém nota o kernel trabalhando, assim como ninguém nota o Metacity. As pessoas só notam esses programas quando eles dão pau, se um driver não funciona direito ou se as janelas não querem sair do lugar, por exemplo. O programa do Linus é talvez ainda mais invisível do que o Metacity e mesmo assim ele é um dos programadores mais conhecidos atualmente.

Ele não chegou a este ponto simplesmente por ter escrito um kernel fantástico, mas porque tomou o cuidado de envolver as outras pessoas nisso. Pediu e ofereceu ajuda em listas de discussão, publicou seu código para ser estudado e criticado pelos outros, fez palestras sobre seu modelo de desenvolvimento e até escreveu um livro para contar a história. Ele divulgou uma mensagem e isso fez muita gente crescer junto com ele.

Para alguns exemplos aqui da terrinha vamos considerar primeiro alguns caras que publicam código, como Vitor Pamplona ou o Marcos Tapajós. Da última vez que olhei, o Vitor tinha quatrocentos e vinte e cinco mil, duzentos e noventa e dois projetos publicados como software livre (e o número já deve ter aumentado enquanto eu digitava esta frase). Mas ninguém ia saber quem ele é se não tivesse feito coisas como montar um fórum para reunir a comunidade Java, organizar um blog para escrever textos que ajudassem os outros a se desenvolver e publicar o código dos seus programas para os outros verem. Do mesmo modo, o Tapajós ainda estaria escondido em um buraco em algum lugar se não contribuísse com os outros através de comentários construtivos e se não compartilhasse sua experiência. Eles poderiam gabar-se de como seus programas são maravilhosos em quantas listas de discussão quisessem, se não fizessem nada pelos outros, ninguém iria dar muita atenção.

Não é necessário ter programas famosos para um programador ser respeitado. Um bom exemplo, também brasileiro, é o Vinicius Teles. Ele até andou divulgando um sistema de busca de imóveis misterioso no blog dele, mas acho que ninguém viu ainda o tal sistema até hoje. Também não sei se ele tem algum projeto com o código publicado em algum lugar da Internet. A questão é que eu nem preciso saber. Ele tem o meu respeito — e o de vários outros programadores — porque ajuda seus colegas de alguns outros zilhões de maneiras diferentes como ao publicar entrevistas e até pequenos desabafos em formato de podcast, ao participar em listas de discussão sempre com mensagens detalhadas e esclarecedoras ou até ao organizar conferências das quais não vou poder participar.

Para conseguir reconhecimento e respeito, um programador não precisa só programar muito bem: precisa divulgar seu trabalho. O segredo é que não adianta simplesmente bater no peito e gritar seus feitos aos quatro ventos. Se quiser que alguém o respeite, é preciso ajudar os demais. Ninguém gosta de um sabe-tudo. O crédito que um programador tem dentro de sua comunidade é muito mais uma função do tempo que ele dedica a seus colegas do que do tempo que investe em escrever código.

Sobre grandes alterações pequenas

Qual é a granularidade das modificações que você envia ao seu sistema de controle de versão? Você se limita a modificações pequenas (que mudam o nome de uma varíavel ou outra, por exemplo) ou gosta das mas volumosas (como as que mudam o nome de uma rotina, introduzem um parâmetro novo e ainda corrigem um defeito em um pedaço do código que a chamava)?

Não é uma pergunta retórica. Pode responder. O espaço para comentários ali embaixo serve exatamente para isso.

Quando envio patches para algum projeto, tento torná-los tão pequenos e localizados quanto possível. Eu sei que não é uma experiência muito agradável revisar modificações monstruosas que afetam toda a base de código e tento poupar disso os mantenedores dos projetos para os quais colaboro. Eles são programadores, mas também são gente.

Não é tão raro que uma parte das modificações em um patch sejam aceitas e outras não. Caso o patch enviado seja muito extenso, o mantenedor vai ter um bocado de trabalho para separar as partes boas das ruins. Se ele tiver muitas outras preocupações no dia (o que não é nada incomum), pode ser que ele simplesmente recuse todo o patch, apesar de haver mudanças úteis, só para poupar o trabalho de filtragem. Para quem está contribuindo, certamente é melhor que as modificações sejam aceitas e um conjunto de patches pequenos torna as chances disso acontecer muito maiores do que um único patch grande. Nem todo patch que enviamos é aceito e precisamos conviver com isso. Modificações pequenas e localizadas ajudam muito quando algumas delas precisa ser rejeitadas.

Patches pequenos costumam ser mais ortogonais e fazem muito sentido no contexto colaborativo de um projeto de código aberto, principalmente com sistemas de controle de versão distribuídos. Mas ainda existem sistemas centralizados e — pior — cuja única solução para edição concorrente é usar travas para tentar tornar o desenvolvimento serializado e impedir toda e qualquer tentativa de paralelismo. Como se este cenário não fosse suficientemente ruim, alguns sistemas não suportam commits com múltiplas modificações e obrigam todo mundo a registrar alterações arquivo por arquivo, mesmo que toquem em muitos pontos. Para terminar imagine que a única forma de interação da equipe com a ferramenta de controle de versão seja um cliente gráfico com interface do século passado e dificilmente automatizável.

É serio mesmo, essas coisas ainda existem.

E tem gente que precisa usá-las.

Quando o mundo conspira contra você com tanta intensidade, fica mais difícil resistir à tentação de fazer uma modificação monstruosa com um comentário altamente descritivo como “Modificações do código”. Porém, mesmo quando estou em algum ambiente parecido com este, ainda tento fazer modificações pequenas. Não faço alterações tão pequenas como quando estou usando Darcs e vez ou outra combino duas ou três modificações em uma, mas sempre evito registrar uma alteração que resolva mais de um defeito ou melhoria.

Parece haver um certo conflito entre commits localizados e implementação de recursos. A renomeação de uma rotina, por exemplo, pode ser um dos passos que leva à inclusão de uma nova funcionalidade, mas com certeza não vai resolver a bronca sozinha. As funcionalidades precisam de modificações maiores, mas modificações menores são mais fáceis de entender, revisar e reverter. Será que este conflito real ou apenas um produto da nossa imaginação?

Comunidade Eclipse lisonjeada

Parece que a Microsoft anunciou esta semana a nova versão do Visual Studio. Antigamente ele era um ambiente de desenvolvimento, mas agora parece que vai ser uma plataforma para várias aplicações. Pelo que pude encontrar de cobertura on-line, parece que agora eles querem produzir uma plataforma extensível para ferramentas de desenvolvimento. A idéia básica é usar o alicerce do Visual Studio para construir aplicações como plugins. Mais ou menos como o Eclipse vem fazendo desde os tempos memoráveis da versão 2.0, lá pelos idos de 2002. Qual será a próxima? Construir aplicativos de propósitos diversos sobre a plataforma Visual Studio? Algo como Eclipse RCP, que está disponível desde a versão 3.0 (que saiu mais ou menos em 2004)?

Ian Skerret, diretor de marketing da Fundação Eclipse está mais do que certo em afirmar que a cópia é a forma mais sincera de admiração. Todas as organizações e indivíduos que formam a comunidade de desenvolvedores da plataforma Eclipse devem estar lisonjeados. Afinal de contas quando os seus competidores mergulham com tanta vontade nesse tipo de perseguição gato-e-rato, eles estão involuntariamente dizendo que você estava certo o tempo todo.

Os fornecedores externos interessados em construir sobre esta nova plataforma devem estar ansiosos para que a brincadeira continue. Talvez eles consigam um pouco do ambiente colaborativo, da abertura e da flexibilidade que o Eclipse já experimenta há anos. Porém, tendo em vista os recentes desdobramentos do caso TestDriven.NET, parece que isso não vai acontecer muito cedo.

Novos Debian e Ubuntu: Instalação e efeitos visuais (resenha)

Este é o primeiro artigo de uma série com minha avaliação do Debian Etch e Ubuntu Feisty Fawn, lançados em abril de 2007. Os demais artigos serão publicados em breve, conforme sejam finalizados.


Abril foi um mês bastante movimentado no mundo Linux. Duas das maiores distribuições publicaram novas versões estáveis: o Debian 4.0 (Etch) saiu dia oito, quase dois anos depois do Sarge, e o Ubuntu 7.04 (Feisty Fawn) saiu duas semanas depois (quinta-feira, dia 19). Eu uso as duas no meu desktop principal e como iria fazer a atualização de qualquer modo, resolvi aproveitar para dedicar algum tempo a uma resenha simultânea.

Meu intuito não é criar mais uma polêmica com um artigo do tipo “Ubuntu matando Debian”: eu sinceramente não acho que o Ubuntu tenha esse tipo de tendência suicida. Esta breve resenha é somente para oferecer minha visão de usuário e entusiasta das duas distribuições. Eu sou programador (e, se é que isso faz alguma diferença, atualmente estou usando principalmente Ruby, Java e Haskell), portanto esta resenha deve ser mais útil para quem tem um perfil parecido. Mas, se este não é seu caso, não precisa abandonar a leitura ainda. O velho ditado já dizia que ninguém é de ferro e quem sou eu para contrariar velhos ditados? Eu também escuto música, assisto vídeos e uso alguns aparelhos externos como câmeras digitais e tocadores de música, coisas que todo mundo exige de um computador hoje em dia — e que em muitos casos são tudo que se exige. Só não espere encontrar algo sobre aplicativos de escritório por aqui.

O sistema

A máquina que estou usando para estes testes é meu sistema de casa. Na época em que a montei (há uns bons dois anos e meio) ela era razoavelmente possante, mas acho que hoje em dia equivale a um PC médio desses que já vêm encaixotado e que os vendedores de supermercado empurram para quem está “procurando um computador”. É um Athlon XP (32 bits) 2000+ com 512MB de memória RAM, 160GB de disco rídigo e placa de vídeo com chipset NVidia FX 5200 e 128MB de memória.

Na minha classificação esta máquina com certeza não está acima de “razoável”. Apesar disso, tanto com o Debian como com o Ubuntu, ela consegue se sair bem para o que preciso atualmente e não demonstra sinais de cansaço mesmo quando estou usando um ambiente de desenvolvimento muitas vezes considerado pesado (e, para quem conhece, este seria o Eclipse com alguns plugins personalizados), navegando com algumas abas abertas e com os efeitos de desktop 3D ativados.

Portanto, ponto para as duas distribuições no quesito performance.

Instalação

O processo de instalação para cada umas das duas distribuições demorou pouco mais de uma hora. Boa parte deste tempo foi usado na comunicação com os servidores. Eu fiz a instalação logo após os lançamentos oficiais e é de se esperar que o tempo seja um menor agora que o servidores estão um pouco menos sobrecarregados. Obviamente, tudo isso depende também da qualidade da sua conexão com a Internet.

Esperar uma hora pela instalação do sistema operacional não é uma das coisas mais divertidas que se pode fazer com um computador. No entanto, a instalação do Ubuntu brilha nesta área. O processo todo é feito a partir de um CD Live e o sistema pode ser usado normalmente durante a instalação. Isso significa que enquanto tudo é instalado você pode ler seus e-mails e notícias ou então começar a preparar algum artigo para o seu blog. A instalação do Debian, por outro lado, roda em modo texto. Você ainda pode navegar na Internet usando o lynx ou algum outro navegador em modo texto, mas a experiência com certeza não é a mesma. De qualquer modo, o processo não é tão traumático porque não é todo dia que você vai reinstalar um sistema Debian do zero. O meu poderia ter sido atualizado normalmente a partir da versão Sarge, só fiz uma instalação limpa para poder relatar minhas experiências aqui para meus 80 milhões de leitores.

Outro recurso da instalação do Ubuntu que me agradou bastante foi a habilidade de importar dados pessoais de outros sistemas operacionais. Isto permite, por exemplo, que você importe do seu Windows coisas como mensagens de e-mail salvas localmente, endereço de acesso ao Messenger e endereços gravados no seu navegador. Eu não precisava disso dessa vez, mas teria sido bem útil há um ano e meio quando instalei meu primeiro Ubuntu (que também foi meu primeiro Linux). Parabéns para a equipe do Ubuntu por facilitar a migração.

Colírio para seus olhos

Um dos recursos mais polêmicos desta versão do Ubuntu foi a inclusão de efeitos 3D para a área de trabalho. Durante o desenvolvimento do Feisty os boatos se espalhavam rapidamente. Era comum escutar numa semana que os efeitos estariam dentro e ver a notícia ser desmentida na semana seguinte.

Falar em efeitos visuais para desktop Linux ultimamente é falar de XGL, Compiz e Beryl. Porém, o pivô de toda a polêmica não foi nenhum dos três. Por trás de tudo estavam os drivers binários.

Os drivers de código-aberto para placas 3D sob Linux ainda não têm todos os recursos necessários para proporcionar o tipo de experiência que o Ubuntu queria. Como a filosofia do projeto é não incluir código proprietário na instalação padrão, eles precisaram chegar a algum meio termo razoável. E finalmente conseguiram: disponibilizaram os drivers proprietários de forma fácil após a instalação. Desse modo, quem quer ativar os recursos avançados pode fazê-lo facilmente ao mesmo tempo que aqueles que não fazem questão não precisam executar código proprietário.

A instalação dos drivers 3D está a dois cliques da instalação padrão. Depois que a instalação estiver concluída, é só parar de ler seus e-mails, reiniciar a máquina e seguir para Sistema > Administração > Gerenciador de Drivers Restritos. Isto vai fazer com que o driver seja automaticamente baixado e instalado. Para ativar os efeitos é só marcar um campo em Sistema > Preferências > Efeitos da Área de Trabalho. Fácil assim.

Resumo

Instalar e rodar as duas distribuições está bem fácil. A configuração padrão vem com os programas mais comuns e depois só é preciso adicionar aqueles outros mais específicos. Não é preciso saber exatamente que programas você precisa para fazer uma instalação, mas é possível escolher um por um se você souber o que quer.

O Ubuntu sai na frente para quem quer admirar alguns efeitos visuais interessantes no desktop por permitir a instalação fácil dos drivers binários e a ativação simples dos recursos visuais. Nada é impossível com o Debian, mas talvez você tenha que pesquisar e perguntar para mais pessoas e acabe levando um pouco mais de tempo.

Este artigo é apenas a primeira parte da resenha. A próxima parte, que será publicada em breve, irá se concentrar nos recursos multimídia, incluindo integração com dispositivos externos.

Impressões do E-SOL/CEFET-PE

Para quem está perdido, E-SOL/CEFET-PE significa Encontro de Software Livre do CEFET-PE. Mais detalhes no post anterior.

Agora que estamos esclarecidos, minhas impressões sobre o evento.

O evento foi um sucesso. O pessoal da organização do CEFET-PE e de todos os grupos locais que ajudaram fizeram um ótimo trabalho. Confesso que fiquei assustado quando fiquei sabendo que havia mais de 700 inscritos. Era minha primeira apresentação para público externo e por um momento cheguei a ficar preocupado de encarar a possibilidade de uma platéia lotada.

Mas no final deu tudo certo. Tive uma ótima impressão da comunidade de software livre de Pernambuco. A participação do pessoal, por exemplo, esteve em alta durante todo o evento. Na sexta-feira, só consegui ir à noite e tinha gente que estava lá desde a manhã. Na verdade, a maioria do pessoal tinha chegado cedo. O auditório estava bem cheio para as palestras sobre PHP e as experiências do SERPRO com software livre. Não tinha só aquela meia-dúzia de gatos pingados que seria de se esperar ao final do dia.

Novamente, parabéns para a organização e obrigado pelo espaço que me foi cedido.

Software Livre no CEFET-PE

Eu deveria ter anunciado isso antes, mas minha memória infelizmente me traiu. Está um pouco tarde, mas vou anunciar mesmo assim. Neste próximo fim-de-semana, na sexta-feira e no sábado (dias 5 e 6), acontecerá o 1o Encontro de Software Livre do CEFET – PE.

Eu estarei lá nos dois dias e vou fazer uma pequena apresentação sobre a plataforma Eclipse, com a qual trabalho há um pouco mais de dois anos. Acho que já andei falando do EclipseFP aqui…

Estou realmente ansioso por este evento. O pessoal da organização tem feito um ótimo trabalho e tenho certeza que todo o esforço deles será coroado com um evento de sucesso.

Recomendado para qualquer um que esteja envolvido (ou esteja considerando se envolver) de alguma forma com software livre. É um evento não só para entusiastas, mas para todo e qualquer tipo de curioso.

Projeto ganha nome

E o nome é Motiro.

Motiro é uma palavra tupi-guarani que, no português moderno, deu origem a mutirão. Os linguistas de plantão podem corrigir, pois a grafia original é motirõ. Nós apenas decidimos remover o til para dar uma sonoridade diferente.

Mutirão é uma reunião para trabalho em um objetivo de interesse de todos os participantes. Exemplos bastante comuns são as colheitas e construção de moradias. Num mutirão as pessoas se ajudam mutuamente a fim de dividir o resultado final do trabalho. Todos trabalham para todos os outros e para si mesmos. Não há mecanismos de centralização de poder, ninguém é imposto como chefe. Ao invés disso há lideres, e eles emergem naturalmente durante a atividade.

Um mutirão é uma organização dinâmica e descentralizada. Nele a responsabilidade é dividida ao máximo entre todos os participantes. Cada participante escolhe uma pequena parte do trabalho, extremamente fácil de ser gerenciada, de acordo com o que julga ser melhor para a comunidade como um todo.

Esta descentralização da capacidade de decisão é um dos pilares da filosofia Just-in-time que, aliás, funciona bem para construção de motores a jato e pode funcionar também para projeto de software, como mostram Mary e Tom Poppendieck em seu Lean Software Development: An Agile Toolkit.

Quem estiver interessado pode contactar a Equipe Motiro através de um grupo de discussão hospedado no Google Groups ou visitar a página do projeto (que está em construção) no BerliOS Developer.

Atualização em 30 de março de 2006: reelaborei alguns trechos sobre Lean e Just-in-Time depois de discutir o assunto com Carlos Miranda. Estou mais confortável com o novo texto. Obrigado, Carlos.

Novo projeto

Acredito bastante na eficácia de equipes auto-gerenciadas, formadas por programadores qualificados e motivados. Em contraposição à equipe com um gerente razoavelmente motivado e programadores subordinados a ele não tão motivados assim, o que em muitos casos os torna desqualificados.

Para estas equipes auto-gerenciadas atingirem seu potencial máximo, elas precisam do mesmo material que o gerente centralizado precisa: informação. Obviamente, a informação precisa ser democraticamente distribuída. Todo programador (provavemente também todo usuário) é um agente para a melhoria, por isso todos precisam ter acesso fácil à informação.

Por isso, estou iniciando um novo projeto. A idéia é fazer um portal para projetos de desenvolvimento de software, um local onde a comunidade possa se reunir e rapidamente obter informações sobre o bem-estar geral do produto. Em poucas palavras: reunir em um só local a multitude de informação encontradas em um projeto típico. Coisas como contribuições em código ao repositório de controle de versão, alterações na wiki, situação do build e mensagens nas listas de discussão. Deste caldeirão de informação, deste caos aparente, podem surgir idéias maravilhosas. Só é preciso deixar tudo ferver e esperar acontecer.

Este projeto vai ser desenvolvido em código-aberto, em algum site do tipo Source Forge ou BerliOS. Mais notícias em breve.



Seguir

Obtenha todo post novo entregue na sua caixa de entrada.