LBR, Trunk, Contribuições e Sugestões para o Futuro

#1

Entendo seu ponto de vista Alan. Realmente temos muitas dificuldades para manter o LBR. Eu estou trabalhando em uma forma de organizar os processos de desenvolvimento, recentemente estivemos no encontro mundial que ocorreu na Alemanha e conseguimos entender um pouco de como o projeto principal está se organizando. Ao meu ver a maior dificuldade é manter o código com qualidade, principalmente para que as instalações fiquem consistentes. Vamos citar como exemplo o caso do SPED, a minha idéia era fazer o desenvolvimento até certo ponto separado do trunk, a decisão de fazer assim era pra justamente disponibilizar quando estivesse uma versão que exigiria poucas correções para que funcionasse em outras empresas, assim poderíamos usar as contribuições da comunidade para melhorar o código. Acontece que tudo foi disponibilizado antes dentro do trunk, com muita coisa ainda hardcoded. Acredito que o ideal seria ter sido colocado em um branch separado e depois que estivesse pronto, deveria ser integrado no trunk, pois hoje temos um trunk com inúmeras classes do ECD/EFD que não servem pra nada, já que não tinha scripts até então.

Outra coisa que dificulta um pouco é que em alguns casos as soluções são feitas pensando em um ambiente específico, para solucionar o problema de um cliente, e quase nunca é feito de forma genérica. Quando você usa o Adempiere na sua empresa ou tem apenas uma instalação, isso não chega a ser um grande problema, pois você consegue mudar o que foi disponibilizado para atender a sua necessidade, mas depois de algum tempo cada empresa terá sua parte do sistema modificado e não conseguirão mais falar entre si. Quando partimos para uma empresa de consultoria esse problema é maior, pois temos que prezar pela qualidade no sistema de cada cliente e as rotinas precisam ser genéricas. Temos cenários atípicos onde uma instalação contém vários empresas com regimes diferentes ou até mesmo em países diferentes.

As contribuições da comunidade são de grande importância para os sistemas open-source, realmente temos que melhorar a forma como as coisas são feitas. Eu estou preparando uma contribuição para tentar servir de modelo, com melhor documentação, a codificação do LBR menos intrusiva no sistema core, maior aderência a legislação, entre outras melhorias. Devemos concluir esta primeira versão, já com os scripts de atualização na virada do ano. Infelizmente não foi possível fazer esta versão juntamente no trunk do LBR, pois muitas alterações no LBR são feitas sem documentação, sem consulta a comunidade, sem especificações de funcionamento, etc. Neste novo cenário a idéia seria que todas as contribuições devem ser feitas em branches separadas e depois de aprovadas poderão ser integradas no trunk. Desta forma teremos proveito dos dois cenários, citando o exemplo do ECD/EFD novamente, se uma empresa quer rodar o ECD/EFD ela pode contribuir nesta branch melhorando o código, ou simplesmente usar o código da branch se atender as necessidades dela, mesmo que existam problemas que impeçam a integração com o Trunk naquele momento, e posteriormente quando for mais testado e estiver com qualidade suficiente pode ser integrado no trunk. Resumidamente =) é isso que estava preparando para falar há algum tempo, como você tocou no assunto gostaria de ouvir a sua opinião e poderíamos abrir um novo tópico para que a comunidade se expresse.

Att.

EFD - Sped Fiscal e Contábil
#2

Caro Ricardo,

Concordo com a sua posição e reitero mais uma vez a posição que já lhe coloquei várias vezes. Desejamos sim, trabalhar de forma coordenada e de forma síncrona. Acho que cada vez mais chega a hora de conversarmos sobre a associação brasileira, como já colocado em pauta na reunião presencial de SP ano passado.
Quanto à nova versão, temos também algumas coisas para contribuir (DocFiscal que finalmente está pronta, configuração de parametrizações de CST do PIS/COFINS/IPI/… além de outras coisinhas).

Sem mais pelo momento,

Fernando Lucktemberg

#3

Ricardo, isso é ótimo. O versionamento e o uso adequado do branch/trunk vão melhorar bastante a qualidade e a consistência do lbr. Como você disse, o desafio é coordenar os trabalhos do lbr e tentar considerá-lo como o “projeto genérico de um cliente genérico”, evitando que o trunk se torne um repositório com códigos específicos de nossos clientes (e algumas vezes, incompletos).
Estamos ansiosos para maiores notícias sobre a nova versão. Também tenho contribuições na parte de nf-e.

Abraço.

#4

Legal Ricardo, quanto isso vai acontecer ? Já escuto isso a pelo menos 2 anos… Concordo que as coisas são “jogadas” no trunk e sem documentação, ou sem muita consulta… pq na boa, senão não anda isso aqui… aqui no fórum mesmo, quantos respondem questionamentos… 1, 2 e olhe lá… já vi vários falando que gostariam de ajudar, mas fica só no gostaria… Eu contribuo sim, e sei que muita coisa pode ser melhorada, mas o exemplo do SPED ECD/EFD mesmo, muita coisa nem fui um que fiz, e dai eu tinha aqui na empresa onde trabalho código da Kenos mesmo, com campos no meu banco de dados, com ids do lbr e não tinha o script… e ai, vou ficar com meu código parado aqui, e depois esperar a Kenos lançar o código no trunk totalmente diferente do que tenho aqui e com outros códigos…

Isso que mais reclamo das empresas de consultoria em adempiere no Brasil, é usado o cliente como “cobaia” e dai depois de muito tempo e olhe lá, volta para a comunidade… Eu faço diferente, pode não estar 100%… pode sim… tento sempre deixar com todos os scripts e funcional o código, mas não vai ser sempre, pois não ganho nada para ajudar, e tenho certeza que as empresas de consultoria usam muito dos códigos que disponibilizo e nem ganho um obrigado…

Muito bonito também Fernando, a mesma pergunta, quando ? Cara, já falei várias vezes… Este exemplo do DocFiscal que finalmente ficou pronto… Aonde tem isso documentado ? Quem sabe o que está sendo feito ? Qual foi a discussão sobre o assunto ? Legal hein… falar que tem que fazer de uma forma e faz totalmente diferente… e o quem sabe quando a comunidade vai ver isso…

Bom falei que não iria mais fazer parte do adempierelbr, pq juro que não concordo com as coisas como são feitas… e na boa, parece que isso nunca vai mudar… Quero sim ter na empresa onde trabalho o mesmo código que existe no adempierelbr, mas como ? quando ? onde ? isso ninguém sabe, e se tem alguma coisa nova na legislação brasileira e preciso atender a minha empresa e posso contribuir vou continuar contribuindo, como faço… pois só assim para as coisas andarem aqui

#5

Olá Mario,

Você tem razão em alguns pontos, há pelo menos 2 anos tentamos acompanhar o trunk e não conseguimos de forma consistente, é exatamente por isso que vamos tentar outra abordagem. Seguem os comentários:

Como eu citei, você possivelmente consegue lidar com esta situação porque é uma pessoa inteligente, bastante envolvida e tem o foco direcionado no seu negócio. Pensando em uma forma geral, teremos pessoas de diferentes níveis, muitas vezes sem experiência no Adempiere e que não terão a mesma facilidade que você para dar continuidade/manutenção no que foi disponibilizado. Apesar de achar a contribuição positiva, mesmo sem documentação ou incompleta, não concordo que seja feita desta forma, pois com o uso do Mercurial poderemos facilitar a criação de branches com as contribuições e assim todo mundo pode sair ganhando.

O objetivo do fórum é realmente ajudar, quem souber e quiser responder ou apenas dar sua opinião, será bem-vindo. Acredito que a única forma de resolver isso é tendo uma comunidade maior, mais organizada e documentada que irá atrair mais colaboradores.

A sua contribuição foi de grande valia para a comunidade, não tenha dúvida, porém o lançamento do código foi feito de uma forma uni-lateral, o que gerou este problema.

?!? Doc Brown? De Lorean? ã?

Seu ponto de vista reforça a idéia de que as coisas precisam ter qualidade para entrar no trunk, se você está fazendo as coisas e disponibilizando a partir do protótipo, esta contribuição não deve, em hipótese algum ir para o trunk. O nosso procedimento é estudar a solução, projetar, desenvolver, testar, homologar, entrar em produção, corrigir possíveis erros pós-produção (se houver) e depois disponibilizar. O fato da empresa ser a primeira a usar uma solução não a torna cobaia. Temos casos de implantação em órgãos públicos que exigem um nível alto de customização e qualidade, usando estas etapas citadas. Do meu ponto de vista pessoal, acho que sua contribuição foi/é de grande valia ao projeto, porém as coisas evoluem e muitas das soluções que foram dadas no passado por TODOS nós que contribuíram já não atendem as expectativas atuais. É por isso a sugestão de mudar esta abordagem para que isso não acontece, pelo menos não tão rapidamente no futuro.

Primeiramente OBRIGADO! Temos noção de quanto é importante a contribuição não só sua, mas de todos os envolvidos no projeto. Desde a pessoa que apenas testou o adempiere e reportou um BUG até pessoas como você que contribuíram amplamente com o projeto. Mas a comunidade open-source é assim mesmo, você está lendo uma mensagem num fórum em PHPBB que foi inicialmente criado pelo James Atkinson, hospedado num servidor Linux criado pelo Linus Torvalds, falando sobre Adempiere que foi baseado no Compiere criado pelo Jorg Jank, sabemos da importancia de cada um, mas acredito que nenhuma das pessoas que estão lendo isso já agradeceram eles.

Eu proponho fazermos uma nova reunião para definirmos regras (sim, novamente), desta vez sugiro colocarmos o controle de qualidade para evitar que o CORE fique prejudicado por contribuições sem documentação ou com baixa qualidade ou pouco aderentes a um modelo genérico. Você poderia manter as suas contribuições que não atendam os requisitos em um branch até que sejam resolvidas as pendências, o que acha? Vide o exemplo da janela de custo médio que você disponibilizou, mesmo tendo testado na sua empresa haviam vários BUGs e não funcionava para PostgreSQL, ou seja seria inviável para 90% dos usuários, nós fizemos alguns ajustes para que funcionasse, você realmente acha justo que isso entre no Trunk da forma que entrou?

#6

Boa noite à todos,

hoje eu entendo como vocês que trabalham com consultoria, passam por dificuldades de auxiliar no fórum, pois os clientes exigem demais de nossas horas de trabalho.

Eu sempre tento ajudar naquilo que posso e sei. E espero sempre aprender mais para poder ajudar ainda mais.

Espero que todos nós possamos caminhar na mesma trilha, pois a tendência é de todos crescerem.

Sempre que precisarem e puderem, podem pedir a minha contribuição, pois estou disposto a poder ajudar ainda mais à comunidade.

Com a ajuda do Pablo, que desenvolveu para mim o ECF, hoje utilizo o ADempiereLBR em comércio, para imprimir o cupom fiscal, porém terei que até o fim do ano homologar o sistema, aonde estou tendo muitas dúvidas para poder homologar com relação ao código se é de terceiro, próprio, se a empresa tem que ser de Desenvolvimento ou pode ser de serviços de ti. Possuo uma documentação em vídeo de como cadastrar os campos necessários no sistema, e a simulação em uma impressora virtual.

Precisando e com a autorização do Pablo eu posso disponibilizar.

Grato pela atenção de todos, abraço.

#7

Pessoal,

tenho sido passivo na comunidade por quase todo esse ano, recebi uma proposta de um cliente, o primeiro de muitos eu espero, para a implantação de um ERP baseado em open source, e como sou um pregador do open source fui de cabeça buscar a solução que melhor serviria ao cliente.

no início deste ano, olhei para Open Bravo, OpenERP e outros, até um que as mensagens estavam todos em alemão. Escolhi o adempiereLBR por perceber que já tinha alguma coisa das nossas demandas locais e uma comunidade em funcionamento. Já no começo das pesquisas percebi as diferenças que estavam no auge no ano passado, e gostei quando vi que parecia que os contribuidores estavam se entendendo. Espero que náo haja um retrocesso nisso!

antes de prosseguir gostaria de dizer que estou escrevendo tudo isso como um INCENTIVO e para a melhoria contínua do projeto e também para expressar um grande OBRIGADO a todos.

o Márcio já me ajudou respondendo algumas perguntas minhas, o Ricardo também já postou várias informações que me foram úteis, recentemente o Fernando me ajudou a colocar a DANFE para funcionar… só tenho a AGRADECER a estes e a muitos outros, e pedir desculpas por ainda não ter contribuído nada muito especial.

até o começo do ano eu programava apenas pequenos scripts em editores de textos simples, hoje estou mexendo um pouco no código Java do AdempiereLBR e inclusive já mandei uma pequena e modesta contribuição nos trackers, que infelizmente ainda não ganhou atenção… trata-se de uma alteração de uma linha (duas se contar o import no cabeçalho) que pega a sigla da unidade de medida traduzida.

estou colocando em produção o faturamento, já forneci ao cliente o suporte a NFe, impressão da DANFE e agora estou mexendo com o boleto, tive que trocar o código do jBoleto e do PDFBox para fazer rodar de acordo, inclusive com algumas alterações no cadastro dos bancos.

Tenho um comentário a fazer sobre o desenvolvimento fechado e o desenvolvimento aberto, que acredito feche com o que foi falado antes… Na minha opinião não deve ter desenvolvimento fechado, mesmo o esboço inicial de uma classe na minha opinião deve ser colocada no repositório, em uma branch (ou clone). Quando o fernando me ajudou com a DANFE, percebi no código dele referências à classe DocFiscal, ele me explicou que era algo que estava em desenvolvimento. Seguindo a minha opinião, este DocFiscal deveria estar em uma branch ou um clone marcado como “kenos” por exemplo, a qual eu poderia importar para o meu clone e ver se me serve, e, talvez um dia ela viesse a fazer parte do trunk, ou não.

Eric Raimond uma vez disse “Release early, release often”, como sendo o melhor jeito de conseguir ajuda, e eu acredito que isso seja uma verdade imutável do Open Source.

Ainda não me sindo confortável mexendo muito no código que pego do trunk, por isso talvez eu iria acompanhar mais um tempo o trunk para depois me aventurar a fazer modificações mais intrusivas, mas é o que eu pretendo fazer e pretendo contribuir tudo, 100% de volta, sem excessão. Não quero que vá tudo para o trunk, seria muita arrogância minha, e provavelmente se alguma das minhas soluções forem desfavorecidas contra alguma outra, pretendo usar a “oficializada”, tentando deixar as minhas instalações o mais próximo possível da versão COMUM do LBR. Se a minha ideia de não haver desenvolvimento fechado fosse aceita, com certeza teria um clone com o meu nome em algum lugar público, então, tenho algumas sugestões de algo que eu gostaria de ver:

  1. mercurial, o mais breve possível - farei e disponibilizarei meu clone imediatamente após ele estar disponível, por mais que não tenha nada muito relevante nele, eu devo isso a toda a comunidade que colocou o AdempiereLBR a minha disposição

  2. todo mundo, logo em seguida, que tem algum código e está disposto a contribuir, abre um clone para todos, indiferente de estar funcional ou não, de ser muito relevante ou não, mesmo que seja só pra ele trabalhar, colocar lá, pra todos testarem, comentarem e discutirem (este seria o equivalente da versão “Testing” da Debian/GNU/Linux)

  3. maior atividade e interação de todos, eu particularmente prefiro listas de discussão do que fóruns, mas o meio não importa, o importante é a comunidade interagir

  4. trunk - o “Stable” (seguindo a linha do Debian),onde entra o conteúdo testado, discutido, argumentado e aprovado.

Lógico que isto é o meu ponto de vista “de fora” do projeto, e com certeza tem muitos BUGS nessa minha sugestão, mas com certeza eu gostaria de qualquer outra que leve ao crescimento da comunidade e deste software.

Pra terminar este longo post, quero novamente deixar meu OBRIGADO a todos, e incentivar para que todos os de boa vontade continuem com o bom trabalho e as contribuições de forma que a comunidade do AdempiereLBR venha a crescer.

Claudemir Todo Bom
Administrador Linux Senior (LPIC-3)
Entusiasta de Open Source
Iniciante em desenvolvimento de ERP Open Source

#8

[teclado sem acentos, desculpem]

Mario, acho que devemos tentar levar as criticas de uma maneira mais construtivas no que diz respeito ao lbr.

  • Tenho acompanhado de perto o forum e vejo varias pessoas respondendo a questionamentos, bem mais do que os 2 que voce citou. Acho que o que falta eh conhecimento para muita gente ajudar mais. Quase nao vemos mais as duvidas basicas, ate porque o forum estah ficando bem completo e uma busca consegue resolver muitas duvidas. Eu mesmo leio as perguntas novas e acabando tendo as mesmas duvidas de quem abriu o topico ao inves de conseguir responder.
  • Eu arrumei muitas coisas de traducao, como padronizar os termos “remessa”, “expedicao”, “envio”, “recibo”, “recebimento”… as acoes de documentos “completo” para “completar”, documentei algumas telas para ajudar os usuarios do sistema, traducoes faltantes, as terriveis traducoes para conta-corrente e poupanca… mas eh complicado ver que seu eu abrir um ticket no sorceforge, provavelmente vai ficar lah sem qualquer resposta. Acho que nao sou apenas eu que tenho pensado assim ultimamente. Sei que todos tem suas atividades, mas os gestores do projeto tem uma certa obrigacao (mesmo que pequena) de continuarem levando em frente.
  • Eh interessante voce querer ter na empresa onde trabalha o mesmo codigo do trunk, mas se todos quiserem isso, vai ficar um monstro lah. Na minha opiniao o codigo deveria ser generico e, se necessario, cada um que faca as devidas alteracoes para atender as necessidades de cada um.
  • Sempre que eu estou trabalhando no source, eu vejo seu nome o tempo todo espalhado pelas classes e reconheco o esforco e tempo que voce investiu. Isso eh uma coisa boa. Seu nome estah espalhado por ai, em muitas implementacoes, e se voce nao recebe um obrigado diretamente, tenha certeza que muitos criaram uma imagem positiva do mgrigioni como conhecedor profundo e um dos pilares do lbr.

A implementacao hoje do lbr eh um tanto quanto complicada, muito mais que o projeto pai, e olha que o lbr eh bem menor se for comparado a ele. Desafio algum novato a utilizar o lbr, seja emitir um xml de nf-e, sem antes conhecer java e estudar as classes. Quantos nao desistiram pelo caminho? Quando recebo mensagem privada aqui no forum, eu costumo deixar claro que o lbr eh meio caminho das pedras, e a pessoa vai precisar se aventurar pelo codigo obrigatoriamente para obter resultado positivo.

Sinceramente acredito no espirito da colaboracao do opensource e tenho certeza que o lbr vai continuar seu caminho.

#9

Tópico dividido e movido

#10

Bom exemplo, veja que ninguém viu o seu tracker… Pq será? pq ninguém vê o projeto, ninguém cuida dele… Por isso que fico p… da vida quando vejo isso… Eu tentei reorganizar a comunidade, criei um “fork” do adempierelbr, tava tendo uma aceitação enorme, várias pessoas chegaram ao projeto o Pablo que foi citado no projeto… cara vc não vê muito o nome dele aqui ou ali no código, mas sei que ele ajuda muito…

Sei que a Kenos ajudou muito para o adempierelbr chegar aonde está, foi a empresa de consultoria que mais fez pelo adempiere no Brasil e respeito isso… Agora o que não pode é ficar como está, ou alguém vira “dono” do adempierelbr e comando tudo e “trabalha” para o projeto toda a semana, ou na boa nunca vai sair nada…

O que fico chateado, é quando no final do ano passado, falaram que iriam lançar a 3.6.0 no adempierelbr, falaram um monte e chegou na hora ninguém contribui com nada… Eu fiz o diff de todas as classes, gerei o customization.jar, fiz os dmps dos bancos e coloquei na internet… Desculpa, mas só “EU” sei fazer isso aqui ? Pq ninguém ajuda… por isso que falei que faço estas coisas e ninguém diz “obrigado”…

Então, existem 2 cenários:

1 - Itens específicos da Empresa: Não devem entrar no Adempierelbr

2 - Itens genéricos: NFe, SPED, Impostos… Isso, todas as empresas deveriam usar a mesma configuração… E isso que eu tento fazer… O meu código do SPED, atende todas as empresas… não, e sei que não… Vão existir coisas que pensei de uma forma e devem ser de outra para todos conseguirem usar… SIM, vão existir, mas se eu não colocar o código aqui e falar que funciona, e o pessoal começar a implementar e ver os erros, e começar a corrigir, isso NUNCA vai chegar no ponto onde todos podem usar…

Vc acha que a Kenos e a Faire não tem SPED no cliente deles ? Pq será que não volta nenhum a correção, já que o código é tão “hardcoded” como falam ou específico… será que não usam nada do que tem lá ?

Pq ninguém fala da NFe que ficou mais de 6 meses incompleta no adempierelbr quando me “tiraram” do projeto ? Pq ninguém fala da NFSe que está a mais de uma ano incompleta do sistema, sem script, sem processo ? E que só funciona na cidade de São Paulo ?

Como disse, é muito fácil criticar a ação dos outros e não olhar o que é feito… EDIT: Onde estão as consultorias que trabalham com AdempiereLBR ? E outras mais ? Muitos usam o código do adempierelbr… e Já escutei algumas pessoas falando… “Eu não coloco as coisas no adempierelbr pq qualquer empresa de consultoria pega as contribuições, sabe um pouco de java e consegue implementar… Vou pegar o que a comunidade fez, mas o que eu corrigir fica só pra “mim” e minha empresa. O meu adempierelbr funciona com integração bancária, SPED, NFe, NFS-e, e mais sei lá o que… e vou pensar se algum dia vou disponibilizar” … Bela visão open-source, continue assim

#11

Acho interessante que estas empresas declarem seu compromisso com o projeto, principalmente com relação ao desenvolvimento aberto.

Eu estou começando a mexer no código, tenho uma alteração no MLBRBoleto que passa a usar o jrimum ao invés do jBoleto, quero passar adiante isso porque sei que pode ser útil a muita gente. A WW Teleinformática, minha empresa de um homem só, que até então trabalhava apenas com infra estrutura de redes está entrando nesse mercado, ainda não tenho programadores contratados, mas desde antes mesmo de começar eu tinha a visão de abrir 100% do nosso código, pois é o melhor jeito de conseguir ajuda de fora… Tenho certeza que as empresas que atuam hoje com o Adempiere, se colocassem seus códigos no projeto, receberiam patches e ajustes de todo o lado… será que eles não percebem que isso é cérebro-de-obra grátis?

Pessoal, coloquem o código, mesmo incompleto, mesmo que seja só um STUB ou uma interface ainda… “release early, release often”! Se eu tivesse acesso de gravação, minha pasta de trabalho seria 100% igual ao meu branch. (pedido de acesso de escrita embutido nas entrelinhas deste parágrafo)

Eu gostaria muito de ver o código destas empresas abertos… gostaria de ver a palavra deles sobre este assunto nesta thread.

Abraços,
Claudemir

#12

Claudemir, cada empresa trabalha de um jeito, cada dono tem uma cabeça diferente, isso não é uma coisa que podemos exigir dos que usam o Adempiere. Existem empresas que vendem o Adempiere com outro nome, que talvez você nunca tenha ouvido falar, mas isso não é errado, a licença do Adempiere permite. Então isto não é uma coisa que podemos cobrar das pessoas, as contribuições são bem-vindas, mas não podem ser obrigatórias. Eu posso falar pela Kenos, temos contribuido desde o inicio com o projeto e últimamente alguns aspectos do projeto tem nos atrapalhado, a idéia deste tópico é realmente tentar melhorar estes aspectos para que nossas contribuições voltem a ser frequentes. Acho que podemos criar uma página (wiki) de boas práticas incentivando outras pessoas/empresas a colaborar, o lema pode ser “release early, release often” =)

Já mencionei meu ponto de vista no tópico acima, vou citar um exemplo de uma empresa que trabalha com o Adempiere na Austrália (Adaxa): Eles fizeram várias modificações como por exemplo um novo módulo de CRM, Sales Dashboard, nova WebStore, etc. Todos queriam ter essas funções aplicadas no Adempiere, mas isso não aconteceu, eles tem isso como um desenvolvimento deles, que eles investiram alto para chegar neste padrão de qualidade. Agora a pergunta, é justo fazer assim? não temos como saber se é justo ou não, o que sabemos é que é permitido. Em contra-partida eles contribuem com diversas outras coisas, como por exemplo a interface mobile. Você pode fazer uma pesquisa no código-fonte por “kenos” que verá parte das nossas contribuições.

#13

Fala pessoal,

Fazia realmente muito tempo que eu não passava pelo fórum, e por acaso ontem a noite me veio a cabeça ver como estava o movimento e me deparei com a discussão. Me surpreendeu, pois se não estou enganado, nesta mesma época no ano passado um mesmo movimento começou a se formar motivado pela então nova versão 3.60lTS. Este movimento na época gerou muita expectativa na questão de politica de qualidade, transparência na coordenação do projeto, prioridades à serem tratadas e outros assuntos importantes, e de interesse de todos.

Lembro na época de toda a discussão que surgiu em torno do Oseb, grande esforço do Mário, Pablo e Marcelo, do qual eu tive uma pequena participação, e que resultou posteriormente com a volta/integração de todos ao projeto LBR, e o código gerado resultou na versão que muita gente acabou utilizando como compativel com o ADempiere 3.60LTS, em outro grande esforço do Mário na versão liberada em Dezembro.

Na época muito se falou em fazer o projeto andar, começou-se a criar uma estrutura bacana e aparentemente realmente uma comunidade seria formada. O tempo foi passando, as idéias esfriando e tudo voltou a ser como antes, sem definição sem comunidade, sem direção. Eu inclusive na época prometi ajudar e liberar diversas melhorias que possuimos, e sempre tivemos a intenção de devolver para a comunidade, porém com este esfriamento, esta indefinição, fiquei somente na criação da branche, e nada mais.

Admiro e agradeço todo o esforço feito até aqui por todas as empresas e envolvidos no projeto LBR, mas em meu ponto de vista é hora de tomar um rumo mais ambicioso: crescer o projeto, ser imparcial, para deixar ele ter pernas para caminhar de maneira independente com membros, uma comunidade própria.

Também tive a oportunidade de estar recentemente em Berlin, no encontro realizado pela comunidade, e vejo que eles estão tomando uma direção muito interessante que deveriamos nos espelhar e seguir em frente. Um projeto realmente open source, onde idéias são sempre bem vindas. Preocupação com qualidade, evolução, atrair novos interessados, enfim, tudo o que nos falta. O LBR hoje é um conjunto de esforços isolados, com ótimos profissionais envolvidos, boas intenções e pouca ação.

Toda esta indefinição só tem a prejudicar empresas que utilizam o ADempiere internamente, ou mesmo para as que prestam serviços de consultoria p/ ADempiere no Brasil. Falta mão de obra, e do jeito que as coisas andam é difícil atrair profissionais interessados no sistema, a menos que estes necessitem realmente trabalhar com a ferramente. Falando um pouco do meu caso em específico, que é um projeto bem grande, hoje como não temos alternativa de mão de obra suficiente no mercado, estamos investindo em formação de profissionais para composição de equipe exclusivamente com o intuito de trabalhar com o ADempiere. Com esta equipe teremos cada vez mais muita coisa para devolver para a comunidade, e queremos fazer isso.

A idéia de “se eu soltar alguem pega e implanta” é muito errada, pois do outro lado também deve existir o pensamento “se alguém não tivesse soltado, eu não estaria implantando muita coisa hoje”. Mas também existem casos em que não se pode soltar alguma contribuição, por exemplo quando uma consultoria é paga para desenvolver uma funcionalidade específica, e seu cliente não quer que isso seja liberado gratuitamente. O Open Source permite este tipo de situação, e temos de entender estes casos. Vejo muitos problemas no LBR disponível hoje? SIM. Em nosso caso de implantação muita coisa estamos trabalhando na reformulação até completa, para conseguir obter resultados mais confiáveis ou então por melhoras de performance. Mas de qualquer forma, existiam coisas feitas, houve um esforço por parte de alguem e isso jamais pode ser desprezado, mas sim melhorado e continuado.

As contribuções devem ir além de código, documentação, informação, pessoas ativas que possam ajudar usuários em foruns, alguem que tenha tempo suficiente para organizar tudo isso. Não é fácil, todos tem seus afazeres, suas obrigações. Uma estrutura tem de ser criada, tanto para gerencia do projeto, um bom ambiente de integração continua, rodando testes, controle de lançamentos, enfim, coisas que todos nós estamos cansados de saber… porem tudo fica travado na falta de definição e continuidade atualmente… (em minha opinião)

Bom pessoal, esse é um pouco meu “desabafo”, posso estar errado em varios pontos, mas estou aberto para discutir e quem sabe ajudar não somente na definição e na discussão atual, mas também em dar essa continuidade que tanto reclamei da falta dela.

#14

Boa tarde à todos,

deveriamos pensar que o ADempiereLBR é uma empresa, e todo mundo que utiliza dele, passa a ser filial.

Deveria aprofundar mais em cursos, como vi hoje mesmo da RMS, aonde o curso vai ensinar os alunos a utilizar o sistema deles.

Neste caso, é diferente, pois é um software proprietário, que não dará a chance de utilizar o sistema na empresa dele, mas sim, de adicionar ao currículo do aluno, que passa a ser um diferencial no mercado.

A visão que tenho para o ADempiere, é que como ele é opensource, todos podem usar, só que para usar, deve ter o conhecimento, este fornecido pela(s) comunidade(s), e depende dela(s) para poder crescer e/ou por empresas de consultoria/implantação.

O dinheiro ganho com o ADempiere é através de Consultoria/Implantações, aonde vejo que tem empresas que contratam o serviço destas empresas e que durante a prestação de serviço, fazem contratações de pessoas para aprenderem a usar e desenvolver coisas internas, e assim está sendo difundido o conhecimento do ADempiere, e ficando dentro destas empresas, aonde o fato de pessoas aprenderem a utilizar é somente desta forma, e vejo que isso que desestimula as pessoas a quererem utilizar o sistema.

Seria necessário reunião anual, para que possa ser feita troca de idéias, melhorias, tudo que possa acrescentar para a comunidade. Desta vez quero participar desta reunião, pois sinto que necessito ganhar ainda mais conhecimento, em termos de desenvolvimento do software, regras a serem utilizadas neste desenvolvimento.

Espero que todos possam expressar as suas idéias e que possam contribuir para que este software opensource possa crescer para todos, e não para poucos.

Grato pela atenção.

Abraço.

#15

Vou mudar um pouco o que eu disse para o que realmente eu quiz dizer:

Acho interessante que estas empresas declarem qual é o seu compromisso com o projeto.

O desenvolvimento aberto é o centro da minha opinião, para os que querem contribuir eu sugiro que comecem de forma aberta.

Mais uma vez fazendo referência à Eric Raymond, de acordo com o conteúdo da Wikipedia na página doAdempiere ele é desenvolvido usando o método Bazaar, onde todo o desenvolvimento é feito de forma aberta, em contraste ao Cathedral, onde o desenvolvimento é restrito entre um release e outro.

Pelo que percebi, no Adempiere LBR tem desenvolvedores seguindo o método Bazaar e colocando pequenas modificações a disposição, mesmo que não sejam 100% ideais, e outros seguindo o metodo Cathedral, segurando código que eles pretendem liberar um dia. Eu até acredito que se todo o projeto fosse feito desta forma, daria certo, e eu iria querer estar no lado de dentro dele! Mas se um contribuidor manter código para ser liberado um dia, enquanto isso os outros estarão trabalhando para fazer a mesma coisa e temos duplicação de esforços, sem contar em implementações incompatíveis e uma necessidade de se trabalhar com um monstro de várias cabeças!

Nos últimos dias dei uma estudada sobre o Mercurial e gostei de algumas coisas, e sei que o projeto principal do Adempiere utiliza ele. Na minha opinião o Adempiere LBR tem condições de ocupar um branch dentro do próprio projeto Adempiere… sei que pode ser um pouco difícil a migração… mas também pode ser interessante fazer isso enquanto tem pouca gente mexendo no código.

Acredito que tem pessoas e empresas com muita vontade de contribuir, inclusive gente que ainda nem sabe muito bem do projeto. Estive no FISL nos últimos 3 anos, sempre atento para obter informações referente a ERP… em nenhum dos anos teve apresentações sobre o Adempiere, eu fui assistir a uma sobre o ERP5, que inclusive foi “adotado” pelo Portal do Software Público Brasileiro, o palestrante falou diversas vantagens deste ERP mas quando indagado por um espectador sobre a capacidade do ERP5BR em atender as especificidades brasileiras, como SPED, NFe, SINTEGRA, GIA, etc… o palestrante falou que não havia nada a esse respeito, e não soube informar se estava tendo atividade sobre este assunto! Na minha opinião, o AdempiereLBR deveria estar ocupando aquele lugar na grade daquele evento, e que com certeza atrairia outros olhos e contribuidores!

Quero deixar aqui um desafio a todos nós (eu inclusive) para que mostremos no próximo FISL o AdempiereLBR e possamos responder com orgulho de que este sistema atende às necessidades brasileiras mais básicas e que estamos trabalhando duro para deixá-lo cada vez melhor!

Bom, acho que sou um dos campeões em posts longos… mas, acho bom manter o debate aberto.

Abraços
Claudemir

#16

Nos últimos dias eu conversei com algumas consultorias para entender a dificuldade para contribuir com o projeto, todas reclamaram da mesma coisa, resumindo: As formas com que as contribuições entram no LBR são desorganizadas. Um exemplo simples, nos últimos 25 commits do LBR apenas 5 tem um tracker relacionado. Isso não permite a contribuição tipo Bazaar, pois se cada um quiser contribuir com o seu código de funciona na sua empresa sem que haja um trabalho para deixar o código minimamente genérico o sistema vira uma zona. Então eu acho que deveríamos definir prioridades. A estrutura para o Adempiere receber a nossa localização está pronta, nós adiamos a migração por que houveram alguns problemas no projeto principal (iDempiere vs Adempiere) no passado e não acho o melhor momento agora, pois definir como as coisas serão feitas daqui pra frente que deve acontecer antes, pois quando essa migração se concretizar nós teremos uma visibilidade maior no projeto principal, então o mínimo é que nós tenhamos uma certa organização entre os desenvolvedores para que isso se torne viável.

#17

Eu sempre tive a ideia de que trunk != stable, e não deveria ser usado em produção, pelo menos não diretamente sem pelo menos uma boa verificação… Não estou defendendo que coisas aleatórias sejam colocadas no trunk, mas acredito que isso pode ser melhorado e mesmo assim permitir que qualquer contribuição possa chegar ao projeto independente de ser perfeita ou compatível com tudo o que os outros estejam fazendo. E após passar por um filtro, discussão e ajustes, eventualmente venha a fazer parte “oficialmente” do projeto.

Por isso eu acredito que o Mercurial poderia ser útil para resolver este problema, poderíamos por exemplo ter uma tag “base” ou “stable” que deveria ser a base para o início de qualquer contribuição, eu contribuo em cima dessa tag, o mário contribui em cima desta tag, ricardo, pablo, etc… todos usam esta como base para sua contribuição. Cada um em seu clone pode vir a importar e testar as contribuições dos outros e melhorá-las aos poucos, e, após algumas interações a tag “base” é atualizada para o código novo, discutido e testado. Não me aprofundei muito no mercurial, mas pelo que percebi é essa a principal contribuição do mercurial contra o SVN. Se fossemos fazer isso no SVN, cada contribuição necessitaria de um branch e o trabalho de importar cada código seria bem mais difícil.

O github e o gitorious (usando git), e mais recentemente o Google Code (usando mercurial) implementaram um método de funcionamento onde qualquer um pode clonar um repositório e começar a contribuir, não sei se o Source Forge tem isso, mas eu gostaria muito… era uma forma de eu publicar as minhas pequenas alterações sem interferir no trabalho de quem está cuidando do projeto.

Não quero parecer intrometido, afinal eu sou o cara que até semana passada estava apenas fazendo perguntas (e provavelmente terei mais na semana que vem) e agora estou dando sugestões sobre a organização do projeto, mas eu realmente me sinto parte disso, eu gosto de open source, e o futuro do meu negócio depende do bom funcionamento do projeto e eu quero ser parte ativa dele.

#18

Bom dia à todos,

realmente as empresas disponibilizarem seus códigos que foram desenvolvidos por elas, usando o investimento delas, é complicado de divulgar, eu mesmo investi do meu bolso, para que o pablo fizesse a implementação do código do cupom fiscal, e olha, o meu investimento com certeza é bem menor com relação ao que essas grandes empresas investem para ter o seu sistema funcionando redondinho…

Seria bom que fosse feito votação, de quem vai tomar conta de quê, como foi feito no ano passado, aonde cada grupo ficaria tomando conta de uma contribuição, pois evitaria estarem desenvolvendo a mesma coisa.

Vamos reunir as opiniões, para discutí-las e encontrar um denominador comum, para que o projeto possa crescer de forma organizada.

Abraço.

#19

Pessoal, concordo que devemos discutir todos esses pontos que estão em debate, mas a questão é, DENOVO?

Muito bem citado pelo Murilo, a um ano atrás tivemos essa mesma conversa, e o que mudou?
Sinceramente pessoal, debate é bonito, saudável, mas parém de perder tempo escrevendo todos esses textos enormes querendo justificar porque não está sendo feito nada.

Eu lembro muito bem da versão que era para sair fim do ano passado, que até agora não teria saido se não fosse pelo Mario. Então eu compreendo o que ele está tentando fazer, que em tese é o único que está fazendo, ou fez algo desde o ano passado, ou pelo menos que compartilhou, por que acredito que tem mais gente que fez mas não contribuiu.

Ricardo, não temos um documento regulamentando como devem ser feitas as contribuições?

Quanto a Wiki, houve uma grande discução se deviamos ou não integrar o LBR ao AD Global, para depois criar a wiki, resumindo, tem-se documentação espalhada por todo lugar, menos nessa wiki que deveriamos ter e ainda esperamos a definição, mesma coisa ocorre com os repositórios.

O Silvino está fazendo um fantástico trabalho ao escrever um livro sobre o Adempiere/LBR. Quantas pessoas leram o tópico que pedi que contribuissem com ele? Até agora eu posso contar nos dedos as pessoas que contribuiram.

Tudo que estamos falando parece aquela história da conversa de loucos:
Louco 1: - Você vai pescar?
Louco 2: - Não, vou pescar sim…
Louco 1: - Ahhhh bom, achei que você iria pescar…
Estamos mais ou menos assim, falamos, falamos e nunca nos entendemos.

AGORA TERMINANDO A PARTE POLÊMICA A QUAL TODO MUNDO ACHA QUE TEM RAZÃO E NINGUÉM FAZ NADA, VAMOS AO QUE INTERESSA.

Vamos fazer assim, esquecemos do passado e vamos definir o que importa para a comunidade, PODE SER?

  • COMO CONTRIBUIR?
  • COMO REPORTAR UM BUG?
  • COMO SUGERIR UMA NOVA FUNCIONALIDADE?
  • COMO AJUDAR NA DOCUMENTAÇÃO?
  • COMO ENTRAR PARA COMUNIDADE?

Quais os objetivos até fim do ano?

Obs.: Não gostaria de ler nenhuma resposta que não fosse algo que viesse a acrescentar.

Pablo

#20

Na época da discussão nós fizemos um documento, e enviamos um e-mail para os desenvolvedores pedindo que respondessem com um “De Acordo”, o que não ocorreu até hoje. Vamos tentar novamente, aproveitando que temos mais pessoas envolvidas neste tópico. Gostariamos de sugestões para o documento: REGRAS

A idéia não é polemizar, você leu o tópico desde o inicio? Estamos tentando encontrar soluções para os problemas existentes, pois da forma que está sendo feito não é factível. A idéia de expor os problemas atuais é para que seja proposto uma solução, como por exemplo o que já foi sugerido com relação ao uso do Trunk, Branches, Mercurial, etc. Se todo começar a commitar ou documentar sem rumo, não adianta nada.

A opinião de todos é importante para o crescimento do projeto, inclusive das pessoas que estão envolvidas recentemente com o projeto. Assim conseguimos identificar eventuais dificuldades que para os mais experientes já não incomodam mais. Um exemplo de algo que não acrescenta em nada: