Escrevo do Hotel Milão Turis, em Porto Alegre. Cheguei há pouco para o FISL que começa amanhã. Vim com o colega Hugo Lavalle, que trabalha na Diretoria de TV Digital do CPqD. Felizmente o avião não atrasou. O único problema é que eu quase não coube na poltrona tamanho diet. Mas tudo bem, quer dizer, não posso reclamar pois eu pedi pra vir.
O problema aconteceu na chegada. Eu vinha para o Milão mas o Hugo ia ficar num outro Hotel. Pegamos o mesmo taxi e eu o deixei lá primeiro e vim pra cá. Quando estava quase chegando ele me liga dizendo que naquele hotel eles não tinham uma reserva pra ele. Resultado, como todos os hotéis de POA estão lotados para o evento (são quase 5.000 inscritos), ele acabou vindo pra cá e vai ficar comigo. Felizmente o quarto tem três camas. :-)
A expectativa para amanhã é grande e o sono também. Vou fechando por hoje pra agüentar o rojão dos próximos dias. Fiquem ligados!
FISL8, a chegada
Pré-FISL 8
Fui a São Paulo ontem participar do evento Pré-FISL, no Hotel Macksoud. Como eu ia sozinho, resolvi anotar a rota no Google Maps com ajuda do meu colega marioct. Ajudou, mas não resolveu. Como sempre acontece comigo, bobeei e tive que dar umas voltinhas a mais.
Cheguei atrasado ao evento e peguei a primeira palestra pela metade, do Josh Berkus, sobre as novidades das novas versões do PosgreSQL. Aprendi que o Skype usa PostgreSQL nos seus servidores para implementar o processo de provisionamento do serviço. Aprendi, também, que de acordo com alguns benchmarks, o PostgreSQL consegue, hoje, atingir 80% do desempenho de um tal "EnterpriseDB" custando apenas 1/3 do custo total de propriedade. (EnterpriseDB é o codinome que o Josh usou para designar o maior servidor de bancos de dados proprietário atual. Parece que a sua licença proíbe o seu uso para este tipo de comparação.)
O Josh está trabalhando na Sun, e uma de suas tarefas é usar o DTrace do Solaris para trabalhar na otimização do código do PostgreSQL. Alguém perguntou se o DTrace estaria sendo portado para outros sistemas operacionais livres e ele disse que já existem patches para integrá-lo ao FreeBSD.
Quanto ao Linux, a integração é impedida devido à incompatibilidade das licenças. É interessante que a Sun já anunciou que futuras versões do OpenSolaris poderão ser disponibilizadas sob a futura GPLv3 enquanto o Linus Torvalds já disse várias vezes que pretende manter o Linux sob a GPLv2. Ou seja, pelo menos no futuro mais imediato, a licença do OpenSolaris deverá continar a ser incompatível com a licença do Linux, o que impede a integração de coisas interessantes, como o DTrace, no Linux.
Mas nem tudo está perdido no mundo Linux. O Josh mencionou o projeto SystemTap que pretende ser para o Linux o que o DTrace é para o OpenSolaris. Eu ainda não pude estudá-lo, mas a referência é quente.
A segunda palestra do dia foi a mais esperada. Jon 'maddog' Hall falou sobre thin clients. Faz tempo que eu queria ouvi-lo falar, pois já havia lido muitos elogios a seu respeito. Ele não me decepcionou. A palestra foi muito interessante, apesar de que especificamente sobre thin clients não houve muita novidade. Ele falou basicamente do LTSP. Mais interessante do que falar das vantagens do modelo thin client foi falar das desvantagens do modelo tradicional de PCs. Eles são caros, ineficientes (em termos de consumo de energia), barulhentos, espaçosos, um risco muito grande pra segurança e ecologicamente incorretos.
A questão da seguraça foi ressaltada com a história dos faxineiros com carros de luxo. Segundo o maddog, há muitos casos de faxineiros noturnos que "chupam" os dados dos PCs das empresas com seus pen drives e vendem os segredos obtidos para a concorrência, conseguindo, assim, aumentar a renda da família e comprar carros de luxo. Ainda não vi gente assim no Brasil, mas estou de olho.
Sobre "pirataria" de software, o maddog disse que os índices mais recentes são de 34% nos EUA, 84% no Brasil e 98% na China. Segundo ele, se a China decidisse pagar todas as licenças que usa, precisaria depositar todo o seu PIB na conta da Microsoft. Obviamente, isso não justifica o delito, mas mostra que há algo de errado no modelo de negócios ou na estrutura jurídica. Alguma coisa tem que mudar.
Uma dica do maddog foi o projeto MythTV, que seria algo como um Tivo livre.
No final da palestra ele mencionou a existência de um "plano de negócios" que ele tem bastante detalhado e que pretende apresentar para o governo brasileiro e para outras empresas do setor de telecomunicações. Ele não entrou em muitos detalhes, mas entendi que se trata de prover Internet para 100% da população brasileira através da interconexão de milhares de servidores numa rede wireless mesh. A tecnologia não é a novidade, mas o modelo de incentivo à adesão. Segundo ele, o modelo propiciaria inclusive a criação de um milhão de empregos. Peguei uma referência sobre isso com o Cesar Brod pra estudar melhor o assunto.
Na seção de perguntas alguém fez a de sempre: como fazer pro Linux deslanchar no desktop? O maddog disse que nos seus quase 40 anos de atuação na área ele descobriu uma grande lição:
It isn't the OS. It's the volume. Volume is the only thing.Ou seja, é tudo uma questão de volume de vendas ou de presença no mercado. Haveria um ponto sem retorno de participação no mercado a partir do qual a adaptação dos desktops Linux para a população seria ladeira abaixo. Mas pra chegar lá, é preciso usar outras armas... é como a questão do frescor do Tostines.
A terceira e última palestra da manhã foi do Cezar Taurion, da IBM. Ele falou sobre os vários modelos de negócio baseados na utilização ou no desenvolvimento de software livre. Gostei muito, mas tive uma ou outra questão com os slides. Convidei-o a repetir a palestra no CPqD e ele aceitou. Vai ser ótimo poder conversar um pouco mais com ele.
Alguém fez uma outra pergunta comum, sobre o fato de haverem muitas distribuições Linux e como isso parece ser um desperdício de esforço. Não me lembro da resposta do Cezar, mas fiquei pensando numa nova abordagem de resposta. Diferente das tradicionais que normalmente fazem analogia com o processo de evolução por seleção natural. Uma outra forma de pensar na questão é lembrar das lições do Fred Brooks no seu clássico The Mythical Man-Month. Ele dizia, se a memória não me falha, que quando o número de pessoas participando de um projeto aumenta, o esforço de comunicação entre elas aumenta numa taxa maior. Chega um ponto em que não adianta acrescentar mais gente que o resultado chega a ser um decréscimo na eficiência geral do grupo. Pois bem, imagine que todos os desenvolvedores que hoje participam de todas as distribuições Linux resolvessem se juntar numa única distribuição BigLinux. Dificilmente alguém conseguiria gerenciar um projeto tão grande e o mais provável é que ele entrasse em processo de estagnação e de colapso. O fato de haverem múltiplas distribuições mantém os grupos menores e coesos, garantindo a eficiência interna. Quanto à sinergia entre as distribuições, isso acontece. Talvez não com a velocidade ideal, mas provavelmente com a velocidade possível.
Junto do material que nos foi distribuído havia um jogo de palavras cruzadas cujas perguntas eram todas relacionadas ao tema software livre. No meio da manhã disseram que os três primeiros que entregassem o jogo totalmente preenchido após o almoço receberiam um Tux de pelúcia. Daí eu pensei: já tenho um Tux mas tenho dois filhos... não custa tentar, né? Consegui preencher quase tudo antes do almoço, mas ainda faltavam umas cinco questões. Fui almoçar e passei ao lado de uma Lan House. Por um real dava pra usar por quinze minutos. Pensei: um real pelo Tux? Tá valendo... Com ajuda do Google consegui preencher tudo menos uma. Chutei e voltei ao Hotel. Chegando lá entreguei o jogo e fiquei esperando. Antes da primeira palestra da tarde me chamaram e disseram que eu tinha sido o único até então a entregar o jogo, mas que havia uma resposta errada. Peguei o jogo de volta e desisti, pois eu não sabia mesmo a resposta. Ao final da primeira palestra anunciaram que havia mais um pretendente, mas que ele tinha umas três respostas erradas. Passados alguns minutos chega um cara pra mim perguntando se eu era o outro pretendente. Ele sentou-se ao meu lado e "trocamos figurinhas". Assim, conseguimos um Tux pra cada um.
Não acho que fizemos nada de errado. Afinal, a cola é uma metodologia colaborativa de aprendizado, não é? Bem apropriado ao tema do evento.
A primeira palestra da tarde foi do Kristian Kielhofner, sobre o Asterisk. Ele é o mantenedor do AstLinux, uma distribuição Linux especializada no Asterisk. Aprendi com ele o que é jitter, e por que isso é um problema para VoIP em geral e como o Asterisk trata o problema. Outra coisa que aprendi foi que em geral não é possível usar máquinas de fax numa rede VoIP. O Asterisk implementa um truque interessante para possibilitar isso.
Depois foi a vez do Amauri Zavatini, da Caixa Econômica Federal, falar sobre as experiências daquela instituição financeira com software livre. A palestra foi muito longa. Acho que ele devia ter se concentrado em apresentar poucos projetos relevantes, mas ele tentou falar de tudo. Mas aprendi algumas coisas interessantes:
- A Caixa tem 118.000 funcionários e um número equivalente de desktops.
- 70% destes desktops ainda rodam NT4.0!
- Tiveram dificuldade na implantação do OpenOffice.org. A estratégia foi cancelar as atualizações do MS Office e configurar a máquinas para abrirem todos os documentos do Office com o OpenOffice.org. Mas ainda não tomaram a medida definitiva.
- Estão para substituir o Exchange pelo Expresso Livre, desenvolvido pelo Governo do Paraná.
- Eles têm 25.000 impressoras na rede e os custos dos insumos de impressão correspondem à 80% dos custos dos insumos de escritório em geral.
- Estão experimentando uma solução de IM baseada no servidor Jabber do SuSE e nos clientes Pandion (Windows) e Gaim (Linux). O sistema fará autenticação dos usuários no AD da rede e deverá atender 1.500 usuários.
- Ele mencionou o Framework Laszlo para desenvolvimento de aplicações web ricas. Eu já havia lido sobre ele... acho que merece atenção.
Foi isso. A volta de carro transcorreu sem maiores incidentes. E a Juliana adorou o Tux.
Trabalho em casa
O “trabalho em casa”, ou home office, parece ser uma tendência irreversível para as empresas do setor de tecnologia. Isso é fácil de explicar tendo em vista os baixos custos de conectividade à Internet via banda-larga e a disponibilidade de ferramentas de colaboração remota eficientes como VoIP, mensagens instantâneas, correio-eletrônico, além do acesso direto e seguro via VPN a todas as ferramentas de suporte ao desenvolvimento.
Sun, IBM, HP, Cisco e Accenture são algumas das empresas de tecnologia que têm oferecido aos seus empregados a possibilidade de adotarem um horário mais flexível de trabalho, permitindo que eles trabalhem parte do tempo em casa. Algumas delas vão mais longe e arcam com os custos de conexão à Internet e com o computador que o empregado utiliza em casa. Mas não são apenas as empresas de tecnologia que estão experimentando esta novidade. BMW, Shell, Royal Bank of Scotland, Nationwide Building Society e Marks & Spencer também têm programas semelhantes.
O gerente da IBM na Índia explica desta maneira as vantagens deste modelo:
"Acreditamos que um ambiente de trabalho flexível dá aos empregados mais flexibilidade e controle sobre seu trabalho, tornando-se um meio importante para conquistar um maior equilíbrio entre suas vidas e seu trabalho, além de aumentar sua produtividade. Nós (na IBM) somos flexíveis sobre como e em que local o trabalho é realizado e somos focados nos resultados do negócio e não no “tempo de cadeira”. Flexibilidade, no ambiente de trabalho da IBM, é um grande fator de atração para novos talentos, aumentando a efetividade, o foco e a produtividade."
Há economias óbvias que esta abordagem traz às empresas, como a redução no custo de infra-estrutura de suporte aos empregados, particularmente em espaço físico, mobiliário, equipamentos, linhas telefônicas, transporte e serviços em geral.
Outra vantagem menos óbvia desta flexibilização é libertar a empresa das restrições geográficas para contratar seu pessoal. Com uma boa infra-estrutura de suporte, uma empresa pode contratar os melhores candidatos de qualquer parte do Brasil e do mundo para constituir sua força de trabalho. Para uma empresa com clientes internacionais, a possibilidade de contar com empregados trabalhando em fuso horários diferentes pode ser fonte de economia para atividades de atendimento ao cliente, por exemplo.
O empregado ganha com a redução no tempo e nos custos de transporte e com a possibilidade de trabalhar perto da família. Além disso, muitos teriam a chance de trabalhar num ambiente mais confortável, mais amplo e menos susceptível a interrupções, o que pode proporcionar ganhos de produtividade significativos.
Obviamente, nem todos os empregados preferem trabalhar em casa, seja por não possuírem um ambiente adequado, seja por não conseguirem separar suas atividades domésticas das atividades de trabalho. Alguns sentem-se isolados, apesar do acesso fácil aos seus colegas através de ferramentas de comunicação eletrônicas. Outros perdem contato com a cultura da empresa. É preciso encontrar o equilíbrio ideal entre a quantidade de horas trabalhadas na empresa e a quantidade de horas trabalhadas em casa, para cada empregado.
Há dificuldades para a empresa também. Os gerentes precisam se acostumar a gerenciar seus subordinados remotamente. A avaliação de desempenho e a manutenção da capacitação dos empregados também podem ser mais difíceis. Sem mencionar os riscos de segurança envolvidos no acesso remoto aos sistemas da empresa por um grande número de funcionários.
De qualquer modo, isso me parece uma tendência inevitável. E eu sei que eu preferiria trabalhar onde estou agora. :-)
Licenças de software
Hoje eu tive uma daquelas valiosas experiências que acontecem conosco quando percebemos que estamos errados. Ao ler a transcrição de uma palestra do Richard Stallman sobre a GPLv3 vi que ainda há detalhes sobre a GPLv2 que eu desconhecia.
Aliás, o assunto "licenças de software", em geral, é normalmente envolto em muito mistério, mito e ignorância. Não sei bem o porquê, mas tenho uma teoria: as pessoas não formam conceitos a partir de definições oficiais mas sim de analogias banais. Quando, à primeira vista, o significado de um termo parece óbvio, não nos passa pela cabeça a possibilidade de estarmos enganados a seu respeito.
Todo mundo acha que sabe o que é uma licença de software. É o preço do programa, certo? Afinal, não existe o "custo de licença"? E aí, quando alguém vem e diz que existem "licenças livres" dá um nó na cabeça, pois isso mais parece um oxímoro.
Errado. Eu já disse antes que uma licença de software é o contrato estabelecido entre o distribuidor do software e quem o adquire, especificando os direitos que o adquirente está obtendo. Como de costume eu estava errado. Não é o distribuidor mas sim o autor do software (ou o detentor do seu copyright, no direito anglo-saxão) que pode estabelecer um contrato com o usuário, pois ele é quem detém os direitos exclusivos sobre o software.
Uma licença de software não é um contrato de venda. O autor do software não cede seus direitos através da licença. Ele apenas os concede de maneira parcial e limitada. É como um ingresso de cinema. Você não sente que está comprando o filme. Você sabe que está apenas comprando o direito de assistir a uma determinada sessão.
As licenças de software propritário tradicionais são bem parecidas com o ingresso de cinema. Normalmente, elas concedem ao usuário o direito de executar o programa em um único computador e só. Há variações, como as licenças flutuantes, que permitem um número limitado de ativações simultâneas do programa em um número indeterminado de máquinas em rede. Outras vezes, a licença especifica o tipo de máquina em que o programa pode ser executado, não permitindo que ele seja usado em máquinas de maior poder computacional.
Acho que o melhor jeito de entender a função de uma licença de software é prestar atenção não na palavra "software", mas sim na palavra "licença". É exatamente isso. O autor "dá licença" ao usuário de usar o software de uma determinada maneira. Como ele detém os direitos exclusivos sobre sua obra, só ele pode "dar licença" para que outras pessoas o utilizem e ele pode dar uma licença tão ampla ou tão restrita quanto lhe der na telha. Chato pro usuário, não?
E tem mais. O autor pode dar uma licença diferente para usuários diferentes. Ele pode cobrar uma baba por uma licença flutuante que interesse a uma empresa. Pode cobrar um valor menor por uma licença individual. E pode não cobrar nada da sua esposa. A idéia é que enquanto seus direitos durarem ele os pode conceder como bem entender.
Então, em princípio, um software não licenciado só pode ser usado pelo seu autor. Outros usuários só podem usá-lo respeitando o contrato de licença estabelecido explicitamente pelo autor.
Diferenças individuais de produtividade
É uma percepção comum que há diferenças significativas de produtividade entre desenvolvedores de software. De fato, esta grande variação parece existir em todos os trabalhos intelectuais, coisa que não acontece com tanta ênfase em trabalhos mecânicos.
O livro Peopleware - Productive Projects and Teams é um clássico da gerência de projetos de software que eu sou incapaz de elogiar o suficiente. Seus autores, DeMarco e Lister, realizaram um estudo para verificar a extensão desta diferença de produtividade e como ela se distribui entre os desenvolvedores. O estudo consistiu em uma série de competições nas quais programadores de diferentes organizações realizavam várias atividades de programação e de testes. Ganhava quem terminasse primeiro e com o menor número de defeitos. A série de competições durou vários anos e os resultados se mantiveram constantes.
O gráfico abaixo mostra o resultado de uma das competições, considerando como métrica de produtividade o tempo que cada participante levou para terminar a tarefa. Segundo DeMarco e Lister, a característica da curva é a mesma, independentemente da métrica de produtividade que se empregue. Em particular, isto também vale para métricas de qualidade expressas em quantidade de defeitos.
As três regras gerais que eles puderam inferir sempre que mediram a variação de produtividade entre um grupo de indivíduos são seguintes:
-
A diferença de produtividade entre o melhor e o pior é da ordem de 10 vezes.
-
A diferença de produtividade entre o melhor e o mediano é da ordem de 2,5 vezes.
-
A diferença de produtividade entre a metade mais eficiente e a metade menos eficiente é da ordem de 2 vezes.
Analisando estes resultados eles procuraram correlacioná-los com fatores do ambiente de trabalho dos participantes. Alguns fatores que não tiveram grande influência na produtividade foram os seguintes:
-
Linguagem de programação: Não houve correlação entre a linguagem usada pelos participantes e sua produtividade.
-
Anos de experiência: Programadores com até seis meses de experiência na linguagem de programação utilizada saíram-se pior que programadores mais experientes. Contudo, a partir daí a variação passou a não ser significativa. Por exemplo, programadores com dez anos de experiência não se saíram melhor que programadores com apenas dois anos de experiência.
-
Número de defeitos: Aproximadamente um terço dos participantes completaram os exercícios sem nenhum defeito. Este nível de qualidade não teve impacto negativo na produtividade do grupo. De fato, eles levaram, em média, um pouco menos de tempo que os demais participantes que completaram o exercício com um ou mais defeitos.
-
Salário: Os níveis salariais variaram significativamente entre os participantes. Apesar disto, houve uma correlação muito fraca entre salário e produtividade. A metade mais produtiva dos participantes recebia, em média, 10% a mais que a metade menos produtiva, mas a diferença de produtividade foi de 100%. Já a variação de produtividade dentro de cada nível salarial era quase tão grande quanto sobre o total de participantes.
Um fator que teve surpreendente influência na produtividade dos participantes foi a sua origem, i.e., a organização em que trabalham. O estudo mostrou que a diferença de produtividade entre participantes da mesma organização foi de aproximadamente 21%. Já a diferença entre os grupos de desenvolvedores das 92 organizações que participaram da competição foi marcante. O melhor grupo trabalhou 11 vezes mais rápido que o pior e todos os desenvolvedores da organização campeã desenvolveram código sem defeitos.
Esta observação é ainda mais surpreendente quando se considera que os grupos não trabalharam como equipe durante a competição. Cada desenvolvedor trabalhou individualmente, no seu próprio ambiente de trabalho dentro da sua organização.
A conclusão é que os melhores desenvolvedores tendem a se concentrar em algumas organizações enquanto os piores tendem a se concentrar em outras. Isto contradiz um certo fatalismo manifestado por alguns gerentes em relação às diferenças individuais. Eles crêem que estas diferenças são inatas, de modo que não se pode fazer muito a respeito. Mas fica difícil ser fatalista sobre o efeito de concentração observado. Deve haver algo relacionado ao ambiente de trabalho e à cultura corporativa que afaste ou que atraia os bons desenvolvedores.
Uma das conjecturas mais fortes que DeMarco e Lister sugerem como explicação para o problema da improdutividade é o fato de que o ambiente de trabalho na maioria das empresas é tumultuado, barulhento e cheio de interrupções. Para testar esta hipótese, cada participante da competição preencheu um questionário sobre as condições físicas de trabalho, antes de executar o exercício. A Tabela 1 sumariza os resultados dos questionários respondidos pelo melhor e pelo pior quartil dos desenvolvedores. A diferença de produtividade entre os dois grupos foi de 2,6 vezes.
O ambiente de trabalho do primeiro quartil de produtividade é mais quieto, oferece maior privacidade, é menos susceptível a interrupções e mais espaçoso.
Os dados apresentados não provam que um ambiente de trabalho melhor vai ajudar os desenvolvedores a trabalhar melhor. Eles podem também estar indicando que os melhores desenvolvedores tendem a procurar trabalhar nas organizações que proporcionam um melhor ambiente de trabalho. Em última análise, porém, o importante é que um bom ambiente de trabalho tende a ser usado por bons desenvolvedores.
