Às vezes percebo, naqueles que pouco ou nada conhecem (e portanto não compreendem) o Software Livre (SL), uma certa discriminação. Para esses é difícil compreender que não se trata de uma questão de caridade, embora alguns realmente se colocarem como "fanáticos religiosos". Executivos resistentes precisam começar a enxergar que os modelos de negócio estão mudando. Existem outras formas de ganhar dinheiro (consultorias, treinamentos, serviços de valor agregado), além de vendendo licenças de um produto proprietário.
Não é à toa que muitas empresas tem bancado seus funcionários para trabalharem tempo parcial (às vezes, total), em projetos de código aberto. Ou até, como aconteceu com o Eclipse, simplesmente "doam" milhares de linhas de código, atribuindo uma licença livre ao seu software. A Sun seguiu o rastro, comprou a empresa que construiu o NetBeans e vem investindo pesadamente nos últimos anos. Não satisfeita abriu o Java como GPL e recentemente comprou a MySQL por 1 bilhão de dólares (veja em seu blog o que o próprio CEO fala sobre a aquisição). Quem ganha com a competição? Nós, desenvolvedores, com certeza. Mas você acha que eles não?!
Eric Raymond diz que "Para resolver um problema interessante, comece achando um problema que é interessante para você.". Pode parecer um pouco egoísta, mas faz bastante sentido. Se eu resolvo cooperar com algo é porque tenho interesse naquilo, serei beneficiado com os resultados. Não lhe parece lógico que a maioria dos desenvolvedores do Linux sejam também usuários? Quem ganha se o Linux evoluir rapidamente? Em primeiro lugar, eles próprios!
Apresentando essa visão "interesseira" não estou, de forma alguma, minando o princípio da colaboração e ajuda mútua. É claro que também tem muita gente imbuída - e isso deve ser louvado - do espírito social e investem seu tempo em fazer algo em benefício do próximo. Mas, no mundo do software, minha impressão (principalmente com relação à Bahia) é que, em geral:
1) Ainda somos "sanguessugas" - queremos usar SL, mas pouco contribuímos. Queremos participar de eventos, mas não ajudar a organizar.
2) Desenvolvedor é um "Ser Oso" - orgulhoso, vaidoso e teimoso. Tende a se achar melhor do que os outros, não gosta de receber crítica e termina "fazendo do meu jeito que é melhor". Conclusão: Retrabalho e pouca colaboração.
3) Gastamos muito tempo precioso - ninguém reclama em passar horas no Orkut, MSN ou jogando PlayStation. Nada contra a diversão, mas para participar ativamente de projetos/comunidades livres, "não tenho tempo".
4) Queremos tudo mastigado - vejo isso nas empresas. Muitos esperam sentados que caia do céu um treinamento que, quando chega, "foi muito fraco". Estudar constantemente é essencial e precisa de vontade pessoal. Hoje todo mundo tem no mínimo pós-graduação (falo do "canudo", porque o conhecimento, sei não...). Então, qual o seu diferencial?
5) Somos condicionados a competir, não a colaborar - Na escola, família, colégio, vestibular, universidade, temos que ser "os melhores". Trabalhar bem em equipes, sem subir nas costas dos outros, é um grande desafio. Quando algo dá errado ouvimos "a minha parte está ok" ao invés de "vamos trabalhar juntos na solução".
Então, fica aqui essa análise: De um lado o mundo está mudando e as principais empresas de TIC do mundo estão atentas (e agindo) quanto a isso. Do outro, continuamos como dizia Raul: "com a boca escancarada cheia de dentes, esperando a morte chegar". Profissionais diferenciados, além de todo o know-how técnico, desenvolverão mais cedo as habilidades necessárias para atuar nesse novo cenário. E quando os gerentes perceberem o que está ocorrendo, aí sim as empresas começarão a mudar significativamente.
segunda-feira, 24 de março de 2008
terça-feira, 18 de março de 2008
Os 5 Tipos de Projeto Open Source
Procurando informações sobre tipos de projeto de código aberto, achei um texto muito interessante de Josh Berkus, membro do time do PostgreSQL desde 2002. Em The 5 Types of Open Source Projects, ele procurou uma classificação organizacional, focando em quem toma as decisões, quais são objetivos estratégicos, como alguém pode se juntar ao projeto, dentre outros. Farei aqui um breve resumo, dando uma pitada da minha visão.
1 - Solo. Um ou dois colaboradores mantém 100% do código e tomam todas as decisões. Normalmente é fácil contribuir, afinal eles abriram o código com objetivo de compartilhar, portanto sentem-se meio que emocionados quando alguém oferece ajuda. A maioria (mais de 90%) dos projetos está nessa categoria.
2 - Monarquia. É um "Solo que deu certo". Mesmo tendo uma criado uma comunidade grande em torno do projeto, as decisões principais ainda são tomadas pelo seu líder ou um pequeno grupo por ele indicado. Contribuir (e obter retorno) é relativamente fácil, ainda mais quando há aproximação com o líder ou o núcleo principal.
3 - Comunidade. Com um número significativo de contribuintes, existe um processo social intenso (fóruns e listas extremamente ativos) e as decisões são tomadas numa combinação de meritocracia e concenso. A"voz" de cada um é proporcional à qualidade e quantidade das contribuições.
4 - Corporativo. Geralmente código fechado de uma empresa, que mesmo após aberto ainda não se desvencilhou dela. A maioria dos colaboradores ainda é empregado da companhia, portanto sujeita aos seus direcionamentos. Contribuir é frequentemente difícil, por isso os programadores independentes não se sentem muito atraídos. Um suporte de melhor qualidade pode ser obtido através de um contrato ou licença comercial.
5 - Fundação. O ponto máximo de organização formal em um projeto open source bem sucedido, que necessita das vantagens de uma estrutura legal e a possibilidade de empregar funcionários e receber doações. O ingresso (individual ou de empresa) normalmente passa por um processo formal. Existem patrocinadores que também dão sustentação comercial.
A classificação de 1 a 5, acima, indica uma tendência crescente de formalismo. Os Solo são mais informais e menos burocráticos, enquanto os Corporativos e de Fundação possuem exigências e regras documentadas, inevitável aos seus participantes. Berkus enfatiza que essa é uma classificação subjetiva, sugerindo que verifiquemos as coisas por nós mesmos.
Finalizando, entender como funciona o mundo do Software Livre nos ajudará a encontrar os caminhos para promover uma maior colaboração interna às organizações. Nada melhor, porém, que participar ativamente de algum tipo de comunidade ou grupo de usuários, para perceber o quanto estamos perdendo tempo em aplicar esses princípios no nosso dia-a-dia. Escolha um tema do seu interesse e comece já!!!
1 - Solo. Um ou dois colaboradores mantém 100% do código e tomam todas as decisões. Normalmente é fácil contribuir, afinal eles abriram o código com objetivo de compartilhar, portanto sentem-se meio que emocionados quando alguém oferece ajuda. A maioria (mais de 90%) dos projetos está nessa categoria.
2 - Monarquia. É um "Solo que deu certo". Mesmo tendo uma criado uma comunidade grande em torno do projeto, as decisões principais ainda são tomadas pelo seu líder ou um pequeno grupo por ele indicado. Contribuir (e obter retorno) é relativamente fácil, ainda mais quando há aproximação com o líder ou o núcleo principal.
3 - Comunidade. Com um número significativo de contribuintes, existe um processo social intenso (fóruns e listas extremamente ativos) e as decisões são tomadas numa combinação de meritocracia e concenso. A"voz" de cada um é proporcional à qualidade e quantidade das contribuições.
4 - Corporativo. Geralmente código fechado de uma empresa, que mesmo após aberto ainda não se desvencilhou dela. A maioria dos colaboradores ainda é empregado da companhia, portanto sujeita aos seus direcionamentos. Contribuir é frequentemente difícil, por isso os programadores independentes não se sentem muito atraídos. Um suporte de melhor qualidade pode ser obtido através de um contrato ou licença comercial.
5 - Fundação. O ponto máximo de organização formal em um projeto open source bem sucedido, que necessita das vantagens de uma estrutura legal e a possibilidade de empregar funcionários e receber doações. O ingresso (individual ou de empresa) normalmente passa por um processo formal. Existem patrocinadores que também dão sustentação comercial.
A classificação de 1 a 5, acima, indica uma tendência crescente de formalismo. Os Solo são mais informais e menos burocráticos, enquanto os Corporativos e de Fundação possuem exigências e regras documentadas, inevitável aos seus participantes. Berkus enfatiza que essa é uma classificação subjetiva, sugerindo que verifiquemos as coisas por nós mesmos.
Finalizando, entender como funciona o mundo do Software Livre nos ajudará a encontrar os caminhos para promover uma maior colaboração interna às organizações. Nada melhor, porém, que participar ativamente de algum tipo de comunidade ou grupo de usuários, para perceber o quanto estamos perdendo tempo em aplicar esses princípios no nosso dia-a-dia. Escolha um tema do seu interesse e comece já!!!
sábado, 1 de março de 2008
V0
"Libere cedo. Libere frequentemente. E ouça seus fregueses.". Para mim esse é um dos trechos mais inteligentes e profundos da Catedral e o Bazar e se aplica a diversos casos, não só a produção de código. Analisemos uma situação típica nas empresas, para interpretar o conceito.
Está em elaboração um novo processo interno, inspirado em algum modelo de referência ou conjunto de melhores práticas (PMBOK, CMMI, ITIL, XP ou RUP, por exemplo). Até aí nenhum problema, afinal modelar/reavaliar processos é fundamental para uma organização em crescente melhoria. Mas como sua empresa o faria? Provavelmente contrataria uma consultoria e colocaria para trabalhar junto com meia dúzia de "papas do conhecimento", pessoas com (teoricamente) vasto conhecimento sobre o assunto, ou pelo menos gosto por aprendizagem. Depois de alguns meses (às vezes, anos), a primeira versão está disponível para uso. Políticas, normas, diagramas, manuais de procedimentos, templates de artefatos, tudo pronto! Agora podemos usar! Palestras, reuniões de sensibilização, equipes de auditoria, grupos de trabalho, todo mundo mobilizado (espera-se!) para internalizar a nova realidade. Sucesso absoluto?! Raramente...
Quantas vezes você viu programas desse tipo fracassarem? Qual são normalmente as maiores falhas? Esquecem de ouvir as pessoas! Aqueles que de fato executam os processos e teriam muito a contribuir. Estabelecem uma divisão entre os teóricos ("aqueles que definem os processos mas não sabem nada do dia a dia") e os práticos ("os que trabalham"). Nem 8 nem 80, né!? Os dois tipos de perfil são necessários, mas eles precisam trabalhar juntos.
Voltemos. Se ao invés de trabalharem "trancados" e só envolverem as pessoas com um processo teoricamente pronto, fosse liberada uma primeira versão ainda bem insipiente (libere cedo), mas que permitisse a crítica e validação do corpo funcional, quantos problemas seriam evitados?
Com várias revisões coletivas (libere frequentemente), o quão rápido chegaríamos numa primeira versão estável? Aliás, seria necessário esperar tanto para começar a praticar? Pensou nos benefícios em partir para avaliar a prática executando um piloto em um departamento ou projeto?
E o principal, oferecendo (e incentivando) a oportunidade de contribuição das pessoas (ouça seus fregueses) o quanto se queimam etapas? As pessoas começam a conhecer, praticar, identificar falhas e pontos de melhoria e aos poucos passam a acreditar, pois sentem-se comprometidas com o resultado. Como está no texto de Raymond, os usuários são constantemente mantidos "estimulados pela perspectiva de estar tendo um pouco de ação satisfatória do ego, recompensados pela visão do constante (até mesmo diário) melhoramento do seu trabalho.".
Portanto, precisamos estimular a cultura da Versão Zero. Até pela velocidade com que as coisas mudam, não dá para esperar modelar o mundo perfeito para depois divulgar e envolver o restante da empresa. "O bom é inimigo do ótimo", mas começando pelo "quase bom" (V0) - liberando cedo, frequentemente e ouvindo seus fregueses - é possível chegar lá!.
Está em elaboração um novo processo interno, inspirado em algum modelo de referência ou conjunto de melhores práticas (PMBOK, CMMI, ITIL, XP ou RUP, por exemplo). Até aí nenhum problema, afinal modelar/reavaliar processos é fundamental para uma organização em crescente melhoria. Mas como sua empresa o faria? Provavelmente contrataria uma consultoria e colocaria para trabalhar junto com meia dúzia de "papas do conhecimento", pessoas com (teoricamente) vasto conhecimento sobre o assunto, ou pelo menos gosto por aprendizagem. Depois de alguns meses (às vezes, anos), a primeira versão está disponível para uso. Políticas, normas, diagramas, manuais de procedimentos, templates de artefatos, tudo pronto! Agora podemos usar! Palestras, reuniões de sensibilização, equipes de auditoria, grupos de trabalho, todo mundo mobilizado (espera-se!) para internalizar a nova realidade. Sucesso absoluto?! Raramente...
Quantas vezes você viu programas desse tipo fracassarem? Qual são normalmente as maiores falhas? Esquecem de ouvir as pessoas! Aqueles que de fato executam os processos e teriam muito a contribuir. Estabelecem uma divisão entre os teóricos ("aqueles que definem os processos mas não sabem nada do dia a dia") e os práticos ("os que trabalham"). Nem 8 nem 80, né!? Os dois tipos de perfil são necessários, mas eles precisam trabalhar juntos.
Voltemos. Se ao invés de trabalharem "trancados" e só envolverem as pessoas com um processo teoricamente pronto, fosse liberada uma primeira versão ainda bem insipiente (libere cedo), mas que permitisse a crítica e validação do corpo funcional, quantos problemas seriam evitados?
Com várias revisões coletivas (libere frequentemente), o quão rápido chegaríamos numa primeira versão estável? Aliás, seria necessário esperar tanto para começar a praticar? Pensou nos benefícios em partir para avaliar a prática executando um piloto em um departamento ou projeto?
E o principal, oferecendo (e incentivando) a oportunidade de contribuição das pessoas (ouça seus fregueses) o quanto se queimam etapas? As pessoas começam a conhecer, praticar, identificar falhas e pontos de melhoria e aos poucos passam a acreditar, pois sentem-se comprometidas com o resultado. Como está no texto de Raymond, os usuários são constantemente mantidos "estimulados pela perspectiva de estar tendo um pouco de ação satisfatória do ego, recompensados pela visão do constante (até mesmo diário) melhoramento do seu trabalho.".
Portanto, precisamos estimular a cultura da Versão Zero. Até pela velocidade com que as coisas mudam, não dá para esperar modelar o mundo perfeito para depois divulgar e envolver o restante da empresa. "O bom é inimigo do ótimo", mas começando pelo "quase bom" (V0) - liberando cedo, frequentemente e ouvindo seus fregueses - é possível chegar lá!.
Assinar:
Postagens (Atom)