Li no blog Flex Brasil que a comunidade brasileira de desenvolvedores Flex chegou a marca de 1.500 registrados, com expectativa de até o final do ano dobrar esse número.

Quero deixar aqui meus parabéns à comunidade, que já é a segunda maior do mundo em Flex, e meus votos para que ela logo se torne a primeira.

No post anterior lancei um repto para juntos criarmos uma comunidade focada em ergonomia de software. Neste post eu gostaria de explicar um pouco sobre as regras e a estrutura dessa comunidade. Na verdade, estamos entrando “numa selva”, desconhecida para a maioria de nós e um pouco assustadora. Por isso, regras claras devem ser estabelecidas desde o início, para evitarmos o risco do “fogo amigo”.

Eu sou um ex-desenvolvedor e, como vocês sabem, uma vez desenvolvedor, sempre desenvolvedor. Mas o tempo e as prioridades acabam nos afastando um pouco de nossas origens. Eu confesso a vocês que, apesar de ainda curtir muito o tema desenvolvimento de software, estou um pouquinho “enferrujado”, mas ainda com uma boa visão de padrões de mercado e arquitetura de software ;-). Meu dia a dia hoje é recheado de outros temas, tais como aquisições, marketshare, análise de rentabilidade, resultados de vendas, etc., inevitáveis na rotina de um CEO.

Por essa razão pedi auxílio à minha equipe de desenvolvimento de produtos, que fez uma criteriosa seleção das opções que à disposição. Esse processo está sendo dirigido diretamente por Edimilson Correa, com o apoio de Alvacir Schulze e sua equipe, formada por Glauco Scheffel, Rodrigo Bernardi e Isabel Haufe. No final deste post reproduzo um texto do Glauco – coordenador do projeto –, sobre os principais aspectos que foram avaliados e as opções que temos para dar o “ponta pé” inicial na nossa comunidade de desenvolvimento colaborativo em ergonomia de software.

Gostaria de agradecer à minha equipe de desenvolvimento pelo empenho para propor num curto espaço de tempo toda a estrutura e as regras de nossa comunidade e assim abraçarmos definitivamente o sonho do desenvolvimento colaborativo.

Espero que você, leitor do blog, opine sobre os pontos apresentamos neste post, principalmente aqueles constantes do texto do Glauco, e nos ajude para a rapidamente dar o “pontapé inicial” na nossa comunidade.

No próximo post irei propor um encontro na web (web panel) para debatermos de maneira mais focada a criação da Comunidade Colaborativa de Desenvolvimento de Ergonomia de Software.

COMPILAÇÃO DO TEXTO DO Glauco Vinicius Scheffel

Amigos desenvolvedores, quando o Jorge nos propôs o desafio de criarmos uma comunidade de desenvolvimento colaborativo, focada em Ergonomia de Software, confesso que fiquei assustado. Tudo isso é muito novo, mesmo fora do Brasil. Num segundo momento a insegurança se transformou em entusiasmo e toda a equipe de desenvolvimento Datasul passou a curtir a pesquisa pró-ativa sobre o tema. Gostaria de compartilhar com todos vocês um pouco do que aprendemos e nossas sugestões para iniciar a formação da comunidade.

A primeira questão importante a se abordar é a hospedagem da comunidade, ou seja, a escolha da plataforma de colaboração. Nós propomos utilizar a plataforma Atlassian Jira, mas é importante expor a vocês as razões dessa escolha.

A primeira alternativa seria criar e hospedar uma comunidade em espaços públicos existentes e estruturados com ferramentas conhecidas. Opções para esta modalidade, podem ser encontradas aqui. O líder disparado desta modalidade é o SourceForge. Essa alternativa não nos pareceu a mais viável neste momento, pois para fomentarmos a comunidade deveríamos ter os processos mais próximos de nossa estrutura de gestão.

A segunda alternativa seria utilizar uma plataforma de colaboração de mercado (free ware). A primeira ferramenta avaliada foi o CollabNet. Achomos a ferramenta fácil para instalar, configurar e usar, o que traz muita confiança, destacando-se que ela é a base tecnológica do SourceForge. Eu, particularmente, fiquei impressionado com o fato do processo de desenvolvimento da ferramenta poder ser configurado por projeto, além do suporte para projetos que adotam RUP - Rational Unified Process . Apesar disso, como em nossa empresa não possuímos experiência de uso e administração de RUP, buscamos outra opção, e passamos a analisar a suíte Atlassian Jira – a qual já utilizamos no passado. Nossa experiência com essa ferramenta nos demonstrou que ela engloba o ciclo completo de desenvolvimento com excelente usabilidade. Com ela teremos: a) wiki; b) build contínua; c) revisão por pares; d) ferramentas para comparar versões de códigos; d) controle de chamados/sugestões. Outra coisa que conta a favor dessa ferramenta é o fato dela ser usada pela Apache Foundation, extremamente admirada pelos membros da minha equipe e pelo mercado.

Dessa forma, propomos criar e hospedar a comunidade num servidor da Datasul, usando a suíte Atlassian Jira e disponibilizando-a em breve pela URL http://opensource.datasul.com . Nosso time agora está trabalhando para liberar o servidor e softwares da comunidade, o que deverá ocorrer nos próximos 15 dias. A hospedagem interna nos permitirá ter os projetos internos sendo desenvolvidos em modelo colaborativo, o que simplifica o processo de migração desses projetos para uma infra-estrutura aberta quando oportuno.

A segunda questão importante que se coloca é o ordenamento jurídico do processo colaborativo. Creio que, como eu, a maioria de vocês não é versada no assunto. Por isso, estou buscando orientação jurídica para definir nosso MEMBERSHIP AGREEMENT. Em breve voltarei a vocês com mais detalhes sobre esta questão.

A terceira questão está relacionada ao licenciamento. Meu time recomendou que os códigos sejam liberados com uma licença padrão . Provavelmente nossa licença será Mozilla Public License 1.1 (MPL) . Em breve também voltaremos a discutir a esse respeito.

Finalmente, resta a questão relativa aos papéis dentro da comunidade (detalhados no post “Metas para um Desenvolvimento Colaborativo”). A questão é complexa e de difícil abordagem através de um post web. Esse é um aspecto que teremos que debater face a face, ou através de web panel. Inevitavelmente, teremos que discutir questões de liderança. Os líderes do processo de desenvolvimento colaborativo terão o direito de advertir desenvolvedores que não estejam se comportando conforme as regras acordadas pela comunidade, ou que estejam utilizando o espaço colaborativo de forma inadequada.
Glauco Vinicius Scheffel

Links relevantes para o tema deste post:

Eclipse Foundation, INC. Membership Agreement
Agile Unified Process

Open Source Software Development Image: OSSD process data diagram

Importantes referências da Wikipedia sobre o nosso tema:

Open source software development is the process by which open source software (or similar software whose source is publicly available) is developed. These are software products “available with its source code and under an open source license to study, change, and improve its design”. Examples of popular Open source software product are Mozilla Firefox and the OpenOffice.org Suite. The Open source software development method is very unstructured, because no clear development tools, phases, etc. have been defined like with development methods such as DSDM. Instead, every project has its own phases. There are, however, generalities between Open source development projects. In this entry these generalities will be described.

Nesse vídeo faço um convite às softwares houses, executivos de TI, desenvolvedores, departamentos acadêmicos de universidades, entre outros, para criar e participar de uma comunidade de discussão sobre ergonomia e requisitos para desenvolvimento de software colaborativo.

Estou aberto a feedbacks dos leitores, vamos lá!

Amigos, em meu último post apresentei alguns conceitos sobre comunidades colaborativas para desenvolvimento de software. Neste post , gostaria de dar continuidade ao tema, abordando as metas de nossa comunidade e questões relativas à organização de uma comunidade colaborativa.

Proponho que a principal meta de nossa comunidade seja:

“Criar componentes de interface Web 2.0 e sua infra-estrutura, a partir de requisitos desenvolvidos colaborativamente com o mercado, com foco na usabilidade”.

Dúvida: como administrar algo tão complexo como uma comunidade de desenvolvimento colaborativo? Existem vários modelos para a administração de comunidades:

• Throw code over the all? - Disponibilizar o código para a comunidade, mas para evoluir e manter esse código; só funciona se ele for revolucionário e muitas pessoas estiverem interessadas.
• Desenvolver internamente, postar externamente? - Pessoas olham, usam, passam, porém não se percebe o efeito comunidade.
• Open monarchy? - Aqueles que desenvolverão os requisitos são empregados da empresa, com algum apoio externo. Alguém da empresa concentra as decisões e os demais são desenvolvedores. A empresa controla tudo e atrai voluntários da comunidade.
• Desenvolvimento baseado em consenso? -Discussões, códigos e decisões são públicos. O desenvolvimento e o crescimento da comunidade é rápido, porém caótico e mais difícil de controlar. O código oferecido ao mercado é aberto, pode ser usado por quem desejar e a responsabilidade de quem disponibiliza é restrita. A evolução se dá por meio de consenso com a comunidade.

Apesar de entendermos as dificuldades, me parece que o “Desenvolvimento Baseado em Consenso” é a melhor opção (indico assistir este vídeo, em inglês, aprox. 50 min.). Algo para discutirmos juntos.

A próxima questão que se coloca é: quais são os papéis dentro da comunidade? Para cada projeto, nossa equipe sugeriu os seguintes papéis:

• Moderador: Sempre deverá haver um, que auxilia na tomada de decisões e interfere na solução de conflitos. Cabe a ele o “voto de Minerva”. O moderador é escolhido por votação e é o único que tem o poder de banir membros da comunidade
• Commiters: São as pessoas que definem os requisitos que nortearão o processo de desenvolvimento. São os elementos chaves da comunidade. O commiter é alguém que de alguma maneira já se envolveu com o desenvolvimento daquela peça de código. Não há limite para o número de commiters por projeto. Escolhidos pela comunidade por votação. O commiter tem alto compromisso com a qualidade e assegura que tudo foi testado e devidamente documentado.
• Colaboradores: Aberto a quem quiser participar. Participam do projeto, corrigindo bugs e submetendo patchs, para os commiters decidirem se entra no código ou não. Normalmente iniciam documentando ou testando o código.
• Usuários: Desenvolvedores que acompanham o projeto e baixam códigos fonte ou versões compiladas. Usam os produtos e sugerem requisitos.

Falando um pouquinho sobre o processo de colaboração, gostaria de propor uma divisão de cada projeto em 4 fases distintas:

• Lançamento de um componente para desenvolvimento público através de uma incubadora virtual
• Eleição dos membros da comunidade
• Definição dos requisitos (trabalho dos commiters)
• Desenvolvimento colaborativo
• Promoção dos projetos de incubados para disponíveis para a comunidade

Eis a idéia para aprofundarmos. Com base nos feedbacks, num próximo post entrarei em detalhes sobre a estrutura e o modus operandi da comunidade. Nesse post abordarei também questões como orçamento, plataforma de colaboração, infra-estrutura e quais componentes de software a Datasul pretende liberar num primeiro momento .

Sugestões sobre esses temas todos são muito bem vindas.

Referência:

Producing Open Source Software: How to Run a Successful Free Software Project; Karl Fogel – disponível on-line em FreeTechBooks.

O Século XXI vem quebrando várias barreiras e tabus, dentre os quais talvez o mais importante esteja ligado ao compartilhamento de informações. Hoje, por meio da web, podemos achar desde uma receita de bolo até como entender o funcionamento de um míssil. Apesar da obviedade, muitas empresas ainda acreditam que trancar segredos de negócios a “sete chaves” é o diferencial competitivo para seus negócios. Essas empresas pararam no Século XX e vão pagar um preço por isso. Em minha opinião, os segredos críticos para o negócio são aqueles relacionados à forma como transformamos produtos em serviços, para atender às necessidades latentes de nossos clientes.

No mundo das software houses são poucos os segredos relacionados com a funcionalidade oferecida. Há vinte anos, o algoritmo do MRP (Material Requirements Planning) era o “pulo do gato” dos sistemas ERP. Atualmente, a lógica do MRP é de domínio público. Pouco a pouco, a aderência do software aplicativo aos requerimentos do cliente se deslocou da funcionalidade para a ergonomia, como já abordei anteriormente. Por outro lado, a ergonomia de uso depende prioritariamente de requisitos que efetivamente atendam às prioridades do mercado e nem sempre o developer tem a necessária sensibilidade para interpretar essas prioridades, até porque elas mudam constantemente.

Por todas essas razões, acho que as software houses deveriam se reunir em comunidades de desenvolvimento colaborativo, com foco na melhoria da ergonomia, a partir de um melhor entendimento dos requisitos do mercado. Imaginemos que nosso produto seja o painel de um automóvel, cuja ergonomia queremos melhorar. O designer pode imaginar que o requisito mais importante é a visibilidade das informações no painel. O usuário, por sua vez, pode priorizar a simplicidade (só quer ler as informações críticas – tipo: falta óleo no motor, a pastilha de freios está gasta). O desconhecimento dos requisitos do usuário leva o fabricante a gastar com melhorias que não serão valorizadas pelo mercado (ou que não são as mais prioritárias). A questão que eu coloco é: como coletar, interpretar e priorizar os requisitos do mercado?

Minha sugestão: lançarmos juntos a SoftCom, uma Comunidade para o Desenvolvimento Colaborativo de Software. Essa entidade teria como foco a análise de requisitos para a melhoria da ergonomia de uso de determinados componentes de software. Quais componentes? Aqueles mais relacionados à Ergonomia de uso do software.

Nossa comunidade deve seguir as etiquetas e protocolos desenvolvidos pelo Open Source:

Numa referência ao livro The Cathedral and the Bazaar (*), estamos saindo da nossa catedral em direção a um bazar. Devemos acima de tudo perceber que nossos comportamentos e ações serão analisados e controlados por uma multidão e que nosso modus operandi deverá se adequar à realidade do bazar, para não sermos banidos deste.

As comunidades para o desenvolvimento colaborativo de software podem oferecer inúmeras vantagens:

• Criação de uma rede de confiança;
• Produção de softwares melhores e mais aderentes às necessidades do mercado;
• Melhoria no relacionamento com bases de clientes.

Tudo isso será possível por meio de:

• Extensão dos talentos técnicos disponíveis em nas empresas;
• Redução dos custos de desenvolvimento;
• Mudança na forma de desenvolver software.

Num próximo post, abordarei as questões relativas às metas da comunidade. Feedbacks são muito bem vindos.

*[RAY 99] The Cathedral and the Bazaar: Musings on Linux and Open Source by an accidental revolutionary;Eric S. Raymond – disponível on-line no Google Books