O tweet original foi apagado… A URL continua no ar… mas talvez nao por muito tempo…

Ai vai um screenshot:

In 1999, when we idealized FISL and immersed into the construction of what is today the “Brazilian Free Software Project”, we were being visionaries, as we didn’t know the exact dimension that Free Software would reach in the whole world. But the visionaries had a firm conviction that the fight for freedom and technological autonomy of our country would necessarily pass by Free Software and the ideals built, initially by Richard Stallman, and, later, by the hackers and developers of the GNU/Linux operational system.

We were able to build a collective event with the participation of the various Free Software communities from our country, the heart of FISL and, later, aggregated other social subjects into this scenario: public administrators, entrepreneurs, academics, Information and Communication Technology professionals and defenders of the freedom of knowledge in all areas. FISL has always been, in all its editions, a major physical meeting point for those who daily meet on the web to work and share knowledge and ideas.

We are also certain that FISL has helped consolidate a positive image of Brazil in the international scene and is today the most well-known and respected Brazilian technology event outside our country.

Surely many of us have in our minds thrilling and unforgettable moments which we carry for all our lives. Many of today’s professionals, activists, entrepreneurs and public administrators had FISL as an inspiration and a great time of opportunities.

We launch the beginning of our tenth anniversary in a global scenario of economical crisis and strong attacks to the liberties of the Internet all around the world. For these reasons, FISL becomes even more important. Never has Free Software and the new forms of social relations, initiated by our community in a global scale, have been so important for overcoming the crisis of an old model. Never has the fight for democracy and freedom have been so important for guaranteeing a sustainable development and a better future for our country. All these elements have been and will be present on our tenth anniversary.

We cheer on our Brazilian Free Software community, the heart of FISL, to present lecture proposals, workshops and courses, and to help in the construction and mobilization of yet another extraordinary moment for our country and for our personal lifes.

We call upon our strategic partners of the public and private sectors to join this great network that surrounds FISL, helping make this dream come true. Do not miss the opportunity to expose your brand and your projects to the biggest and most important community of the Internet, establishing contacts, discovering news paths and creating new business possibilities.

At FISL you will find the greatest technological innovators of the Brazilian Internet, will be in contact with new forms of relations brought by the social networks of the Internet, and with the new and successful business models of the network society.

FISL is a great opportunity for all of us.

We officially open FISL 10.

Porto Alegre, March 10th, 2009

I can understand the fact that you have spent a lot of money funding a great software and now you’d like to have at least some money back. But I believe the auction isn’t the best move for edgeio success. This is just my opinion, but I hope you consider at least thinking about “why not?”…

Instead of doing an auction and practically killing what could be a successful classified advertising platform (there are no bids until now, and the majority of people think that the price isn’t going to be higher than 50-60k)… you could do a very important move for the web2.0 history: release EDGEIO under the *new* FSF GNU Affero GPLv3 license – please read that license.

Why? In short because this license extends the rights and freedom of the “normal” gpl to remote web users, which means that if anyone improves Edgeio and makes it available online, they should provide a way (e.g. a direct link) to the new source code, thus generating a positive improvement cycle on web applications (just like gplv2 did for desktop applications years ago).

That’s amazing now, because as you might know, successful free softwares are mostly “generic” platforms serving different markets (openoffice, firefox, mysql, pidgin, gimp…), and Edgeio has yet no parallel in the free software world (just a matter of time tough). I could go on arguing about the infinite possibilities of improvements and uses for Edgeio around the world, but I think you have a lot of ideas you’d like to see implemented… I’m sorry to say that the auction is just going to kill all of them.

The combination Free Software + Web Applications could lead Edgeio to a renaissance in the hands of passionate developers willing to improve the system, and would enable current users to stick with their current system (maybe ask for donations – build a foundation like mozilla does) and prevent advertisers from running away before the auction finishes. Along with this changes, the need to provide support and related services will come (if still your interest or interest of your past employees) or – at least – you’ll just get some free publicity (which will probably worth more than $250,000) and a very good image around the world for your future startups.

Well, at this point I can imagine you can’t cancel the auction. So I’ll propose something to you: if the auction doesn’t reach the reserve price, make a public call asking people to donate something (probably current users will donate something), until the donations reach $200,000 and compromise to release the application under Affero GPLv3. You get your money, everybody else benefits too. You know that if the auction fails… you’ll probably won’t get $200,000. About the servers and other “physical goods”? Easy, for every $10 donated, the donor gets one numbered raffle “ticket”. The winning tickets split the prize…

Make History, Make Good, not money.
I hope you investors think about it seriously…

Best Regards,
Giovani Spagnolo

Na maioria dos casos, apesar de ser um programador que começa tentando resolver um problema particular através da implementação de um software, o líder Open Source ao longo do tempo programa cada vez menos. Entre suas principais atribuições de liderança podemos destacar: dar uma visão ao projeto; assegurar-se que o projeto esteja dividido em pedaços pequenos e bem definidos (módulos), os quais um indivíduo poderá responsabilizar-se em implementar sem interferir nas outras tarefas do projeto; atrair mais programadores e, por último, mas não menos importante, manter o projeto unido, ou seja, prevenir que seja abandonado ou que aconteça um “fork” (ramificação do projeto que acaba originando um novo projeto derivado com características e funcionalidades de sistema similares àquele original, que usa geralmente como base os códigos fonte já existentes, mas com uma nova liderança).

O líder, ao começar seu projeto, deve estar apto a apresentar uma quantidade suficiente de código que permita uma reação por parte da comunidade onde está inserido. A solução inicial não precisa estar funcionando corretamente e pode conter diversos erros. O que é preciso é convencer de que o seu programa tem potencial para fazer bem aquilo que se propõe a fazer. Também é importante que o programador líder não realize a maior parte do trabalho inicial sozinho, e que deixe tarefas desafiadoras para que outros programadores as realizem. Podemos dizer que é relativamente mais fácil atrair os colaboradores ao início do projeto porque, caso haja sucesso, surgirão novos interessados e usuários, e as colaborações dadas ao início do projeto serão mais visíveis e valorizadas dentro da comunidade. A verdade é que um projeto Open Source necessita de um desafio constante, caso contrário não haverão interessados em participar de um projeto cuja liderança seja passiva diante dos obstáculos que se apresentam.

Outro aspecto determinante no sucesso de um projeto Open Source parece ser a natureza de sua liderança. As estruturas de governança variam muito de projeto a projeto. Em diversos casos, como no desenvolvimento do Linux por exemplo, existe apenas uma liderança, sem disputa. Ao mesmo tempo em que algumas tomadas de decisão são delegados a outras pessoas, uma forte centralização da autoridade caracteriza este tipo de projeto. Enquanto o líder estiver tomando as decisões corretas, contentando e valorizando o trabalho geral da equipe, continuará a receber o apoio incondicional de seus seguidores. Existem outros casos, como o desenvolvimento do Apache Web Server, onde existe um comitê que resolve as disputas internas através de votos ou consenso geral.

Apesar das diferenças nos tipos de governança, os líderes de projetos livres têm diversas características em comum. A maioria deles são programadores que iniciaram escrevendo o código inicial do sistema, ou realizaram alguma importante contribuição no início do projeto e, mesmo não fazendo mais colaborações a nível de código e tendo agora tarefas mais amplas de gerenciamento, consideram aquela experiência inicial como fundamental para dar-lhes a credibilidade necessária para liderar o projeto.

Mas o que uma liderança de um projeto Open Source realmente faz? Através de uma primeira análise podemos dizer que a natureza quase anárquica de evolução destes modelos deixam pouco espaço para a existência de uma liderança. Essa análise, entretanto, é equivocada. Em primeiro lugar, como já descrito, o líder define a visão do projeto. Se o líder é respeitado pelos colaboradores e se a sua visão é convincente, as expectativas de sucesso são positivas. Em segundo lugar, mesmo que os participantes sejam livres para levar o projeto pelos caminhos que quiserem (pois todos possuem o código fonte), a aceitação ou rejeição de modificações ou adições no sistema por parte do líder do projeto provê uma certa forma de certificação de qualidade do produto final, mantendo a integração e compatibilidade com o resto do projeto.

Acima de tudo, os programadores devem acreditar na sua liderança. Devem acreditar que os objetivos propostos pelo líder são convergentes com os seus, e que não estejam contaminados nem influenciados por opiniões e decisões políticas, comerciais ou que promovam o “ego” do líder. A confiança na liderança é também a chave para prevenção de um fork do projeto. A presença de um líder carismático reduz a probabilidade de divisão do projeto em ao menos duas maneiras: os colaboradores indecisos ficam mais propensos a seguir as alternativas do líder, e a facção dissidente pode não ter um líder natural com o mesmo nível de carisma do original, desencorajando adesões ao fork.

Por fim, uma boa liderança deve claramente comunicar os objetivos e procedimentos de avaliação do projeto. De fato organizações Open Source optam por fazer a natureza de seu processo de tomada de decisão o mais transparente possível: o processo pelo qual um comitê avalia novas propostas de soluções é freqüentemente enviado à uma lista de correio eletrônico e todas mensagens são arquivadas.

Como em empresas tradicionais, percebe-se que muito da probabilidade de sucesso ou fracasso de uma iniciativa no mundo livre depende da postura tomada pelas pessoas que estão à frente do processo. Atitude.

Como regra geral, os programadores de software participam
voluntariamente de projetos Open Source e, dependendo de suas
contribuições, envolvem-se com mais ou menos profundidade no projeto do
sistema e em sua estrutura de tomada de decisões. Estes projetos nascem
e organizam-se naturalmente. A participação no projeto do software é
voluntária e, a princípio, não prevê recompensas financeiras a seus
participantes. Ao contrário de projetos de software tradicionais, os
projetos livres não começam analisando as necessidades dos usuários
finais, mas partem de uma idéia ou solução de um problema específico
que um desenvolvedor resolveu implementar. O projeto começa com a
publicação de seus objetivos e um código fonte original, base da
solução. Se o projeto mostrar-se interessante, mais desenvolvedores
aparecerão e se juntarão à equipe do projeto. Se o projeto cresce,
provavelmente organiza-se uma estrutura na qual existe um mantenedor ou
uma equipe núcleo, que é responsável por fazer as decisões críticas a
respeito do futuro do projeto. Em uma estrutura assim, existem diversas
formas de colaboração no projeto, desde pessoas que apenas fazem testes
e sugerem novas funcionalidades, passando por pessoas que apenas
corrigem bugs ou documentam o projeto, até chegar àqueles que
verdadeiramente escrevem o sistema. As formas de comunicação preferidas
são o e-mail, listas de discussão e salas de conversação IRC (Internet
Relay Chat).

A comparação entre um bazar e a construção de uma catedral é comumente
usada como exemplo para ilustrar este tipo de desenvolvimento
colaborativo. Nesta comparação, o desenvolvimento de softwares livres
se assemelha muito à organização de um bazar.

Na sua obra entitulada “A Catedral e o Bazar”, Eric S. Raymond defende que:

Dada uma base grande o suficiente de beta-testers e co-desenvolvedores,
praticamente todo problema será caracterizado rapidamente e a solução
será óbvia para alguém. Ou, menos formalmente, “Dados olhos
suficientes, todos os erros são triviais.” Eu chamo isso de: “Lei de
Linus”. Minha formulação original foi que todo problema “será
transparente para alguém”. Linus objetou que a pessoa que entende e
conserta o problema não é necessariamente ou mesmo freqüentemente a
pessoa que primeiro o caracterizou. “Alguém acha o problema,” ele diz,
“e uma outra pessoa o entende. E eu deixo registrado que achar isto é o
grande desafio”.
Está claro que ninguém pode codificar desde o início no estilo bazar.
Alguém pode testar, achar erros e aperfeiçoar no estilo bazar, mas
seria muito difícil originar um projeto no estilo bazar. Linus não
tentou isto. Eu também não. A sua comunidade nascente de
desenvolvedores precisa ter algo executável e passível de testes para
utilizar.

Quando você começa a construção de uma comunidade, o que você precisa
ter capacidade de apresentar é uma promessa plausível. Seu programa não
precisa funcionar particularmente bem. Ele pode ser grosseiro, cheio de
erros, incompleto, e pobremente documentado. O que não pode deixar de
fazer é convencer co-desenvolvedores em potencial de que ele pode
evoluir para algo realmente elegante em um futuro próximo.

Isso significa que um dos pontos iniciais para o desenvolvimento de um
modelo auto-sustentável de negócios em software livre é a existência de
uma comunidade interessada no constante desenvolvimento dos produtos
livres e lideranças naturais dentro destes projetos. A partir daí, é
preciso estabelecer um relacionamento empresa-comunidade de forma em
que todos saiam ganhando. As empresas podem decidir por exemplo
contratar desenvolvedores de software livre para customização interna
dos seus projetos, e os permitir colaborar paralelamente com outros
projetos Open Source. O importante dentro de uma empresa “amiga” da
comunidade é que ela saiba reconhecer o valor de seus colaboradores
e/ou eventuais voluntários de projeto, ao mesmo tempo em que devolve à
comunidade o produto (ou ao menos uma boa parte dele) final deste
esforço conjunto, para que o ciclo de desenvolvimento colaborativo
continue funcionando de forma saudável.

Esse assunto é matéria atual nos veículos de TI, e um prato cheio para
os defensores do modelo de Software Proprietário. No entanto, me
pergunto se o que aconteceu é realmente ruim para o futuro do Software
Livre, ou se é possível tirar novas lições que fortaleçam ainda mais o
movimento.

At̩ o final do ano de 2002 era preciso Рde forma urgente Рcorrigir um
vício das administrações públicas. Além disso, o Software Livre estava
mostrando sua cara e precisava de exposição. Os órgãos públicos
entendiam àquela época que em processos licitatórios só era possível
adquirir softwares “de caixinha” e, assim, negavam-se a dar atenção aos
produtos de código livre. Enquanto esteve em vigor, a Lei 11.871 de 19
de dezembro de 2002 cumpriu no que pôde seu papel, informando muitos
governantes dos benefícios e da viabilidade do uso de Software Livre em
suas administrações. Infelizmente neste ano de 2004 alguns pontos da
lei foram julgados como ferindo princípios da Constituição, segundo a
visão dos ministros do STF. Talvez a pressa tenha sido inimiga da
perfeição, literalmente.

Acredito, no entanto, que a verdadeira batalha judicial que o movimento
Software Livre deve travar seja contra o absurdo que encontramos
diariamente ao abrir um jornal e ler os avisos para licitação de
softwares. Exige-se “Windows XP” ao invés de um “Sistema Operacional”,
“Microsoft Word” ao invés de “Processador de Texto”, “Office XP” ao
invés de “Suíte de Aplicativos de Escritório”. Nestas licitações é que
vemos claramente o quão dependente ainda somos das tecnologias
proprietárias estrangeiras. Esta sim é a prática que impede a livre
competição, que restringe mercados e abafa o desenvolvimento
tecnológico no Brasil.

Somos fadados a importar softwares enlatados e traduzi-los com nosso
próprio dinheiro para utilizá-los no Brasil, obviamente pagando ainda
os royalties para cada cópia a ser utilizada. Em um modelo de Software
Livre, diversas empresas poderiam capacitar-se a dar suporte,
treinamento e manutenção em qualquer tipo de software. O que seria bom
para a economia, pois o mercado tornaria-se mais amplo e competitivo;
benéfico para as empresas, pois poderiam possuir em seu portfólio
produtos que antes não possuíam e benéfico para o consumidor final,
pois pagaria mais barato por uma tecnologia melhor e mais segura. Para
serem bem sucedidas estas empresas dependeriam de sua capacidade em
manter serviços de alta qualidade, com preço competitivo e maior
capacidade técnica de atualização, gerando cada vez mais empregos na
área.

Software Livre não tem nacionalidade, o que também significa a
possibilidade de empresas trazerem para o Brasil (ou levarem daqui)
softwares inovadores que podem ter sido originalmente criados nos
Estados Unidos ou na África do Sul. Uma empresa poderia optar por
investir muito capital descobrindo por si mesma como dominar a
tecnologia empregada no software ou, melhor ainda, poderia contratar os
serviços dos desenvolvedores originais para uma transferência de
tecnologia mais rápida e eficaz. É uma relação ganha-ganha, onde cada
parte lucra com o resultado.

O que quero demonstrar é que o modelo de negócios baseado na filosofia
de Software Livre é benéfico para o País. E é isso que importa também
para o Governo. Se o Brasil fosse um País com grandes empresas de
Software Proprietário, à altura de empresas como a Microsoft, alguém
poderia argumentar que talvez uma mudança para um modelo de Software
Livre pudesse trazer algum tipo de efeito colateral na economia, pois
reduziria consideravelmente as entradas de royalties. Mas todos sabemos
quem realmente ganha com a propriedade intelectual de softwares
atualmente, não é mesmo? ADOBE, Macromedia, Corel, EA, Microsoft…
Monopólios em seus segmentos de mercado. Todo monopólio faz mal para a
saúde de um País: limita opções, aumenta custos e amarra a um
fornecedor. É preciso cuidar da saúde econômica do Brasil.

O Projeto Software Livre Brasil emitiu um primeiro comunicado oficial
sobre a decisão do STF em http://www.softwarelivre.org/news/2016. Sua
frase final resume bem as idéias do modelo livre. “Software Livre:
Socialmente Justo, Economicamente Viável, Tecnologicamente Sustentável”.