Projeto ACBr - Planos de Expansão

[Daniel Simoes]

Olá pessoal,

Compartilho com vocês, os Planos de Expansão do Projeto ACBr.

Em anexo, está o PDF da apresentação

 

Apresentação - ACBr - Planos de Expansão.pdf

[bylaardt]

Como eu não tenho acesso às respostas nos ítens ACBr new, posto aqui. Favor reclassificar se prudente.

Em complemento ao  tópico do Daniel Simões :

Eu acredito que o seu foco está muito voltado ao Desenvolvedor, o que eu considero ruim para a expansão dos negócios.
As principais fontes de renda que você pode ter são justamente com o consumidor dos equipamentos compatíveis com o ACBr. Explico:
Quando Daniel Simões colocou o tópico , especificamente Slide "Falta de outras receitas/Solução/Principais produtos/Marketing cooperado com fabricante", percebi que o seu público alvo está errado, o ACBr não é um produto para os desenvolvedores, e sim para os que querem vender outros produtos, como os fabricantes de hardware.

Minhas sugestões para implementar as ideias do Daniel Simões:
- Crie um processo de certificação de equipamentos com a marca registrada do "Compatível com ACBr" ou "Compatível com ACBr/Plus" que poderá ser atestado por modelo/marca de produto no estilo selo holográfico. Motivo: A maior dificuldade de quem compra um equipamento, é saber se o software "vai rodar" para esse equipamento. A escolha é sempre do software para o hardware, raramente o contrário. Detalhe, essa dúvida ocorre por modelo, não por marca.  
- Crie um certificação para desenvolvedores, com o tempo, desenvolvedores com Certificação ACBr poderão ser selecionados como um diferencial na contratação.
- Suporte compartilhado contratado pelo fabricante do equipamento pelo período de garantia do produto. Explico: Você plugou o equipamento, instalou os softwares, bibliotecas, o software distribuído pelo fabricante funcionou mas no seu PDV não, por quê? Seleção
- Suporte para consumidores finais de software houses conveniadas: O ACBr tem consultores que eu acredito resolvam os problemas de diversos tipos. Grande parte do trabalho dos consultores é entender o que o cliente está tentando dizer para só então direcionar uma resposta. Problemas que vão de equipamento plugado na porta errada à falta de serviço dos servidores do fisco não são dependem de soluções do ACBr propriamente dito, mas tenho certeza que o SAC já atendeu inúmeros chamados nesse sentido. Mensagens de erro de falta de DLL também são facilmente resolvidos. Para isso, basta criar um controle de chamadas de clientes terceirizados para que eu possa repassar (acrescido dos impostos,etc... ) o custo do suporte na fatura dos clientes (sim, cobra-se por chamada, não por mensalidade).
- Consultoria fiscal especializada e SPED. Produto raro no Brasil.
- Palestas acadêmicas ou cursos para áreas distintas do TI, como Direito (principalmente fiscal) Contabilidade e Economia. As universidades do país, em sua maioria, exigem carga extra-curricular, por que não explorar esse mercado?
- Firmar convênios com agências (não funcionários) para vender os selos, palestras ou cursos.
-Transformar o ACBr em franquia, para que possa estar presente em todo o país, especialmente em cidades universitárias.

Importante: Isso são apenas ideias que precisam ser avaliadas para fins de viabilidade.

[Daniel Simoes]

Configurei o ACBrNews, para permitir respostas... e uni os tópicos...

[Daniel Simoes]

Olá @bylaardt,

Agradeço muito as suas sugestões, são de altíssimo nível... Confesso que já pensamos ou temos planos semelhantes a algumas de suas sugestões...

23 horas atrás, bylaardt disse:

- Crie um processo de certificação de equipamentos

Temos algo semelhante.. em:

https://www.projetoacbr.com.br/forum/forum/63-equipamentos-testados/

Mas nesse momento, ainda estou "criando a necessidade"... Hoje, em dia, tudo que solicito ao fabricante, para a emissão de um relatório como esse, é um equipamento para testes... Isso já é bom, e nos garante acesso a praticamente todos os equipamentos que lançam... Não cobro pelo tempo do técnico / consultor que demora até 5 dias para escrever um relatório.. mas penso em cobrar no futuro...

23 horas atrás, bylaardt disse:

o ACBr não é um produto para os desenvolvedores, e sim para os que querem vender outros produtos, como os fabricantes de hardware.

Não em sua totalidade... Isso faz sentido para os nossos componentes, que suportam equipamentos como: SAT, ECF, Impressoras, balanças... Mas não faz sentido para o componente ACBrNFe, por exemplo (que deve ser o carro chefe do ACBr)

O fato do ACBr ser focado principalmente em Delphi / Lazarus, também limita o nosso "poder" de barganha com os fabricantes... Com ACBrXXX.dll, conforme está nos nossos planos, isso pode se tornar cada vez mais evidente e real...

23 horas atrás, bylaardt disse:

- Suporte para consumidores finais de software houses conveniadas:

No momento vou abrir mão dessa receita, e tentar formar uma comunidade de consultores autônomos (freelancers), em: https://www.projetoacbr.com.br/forum/companies/

Acho que isso pode fortalecer MUITO o projeto... pois favorece o livre comercio e a competição... o usuário que precisa de consultoria pode mudar de "fornecedor",  se não gostar do atendimento... e o suporte não irá parar, se uma empresa "fechar as portas".... 
O consultor que estiver ganhando dinheiro prestando serviços, terá total interesse em contribuir tecnicamente para o ACBr...

O modelo de consultoria com "freelancers" parece fazer mais sentido para uma comunidade OpenSource

23 horas atrás, bylaardt disse:

- Suporte compartilhado contratado pelo fabricante do equipamento pelo período de garantia do produto.

Fizemos alguns testes assim... veja que temos um sub-forum da Epson e da Bematech... Mas acho que faltou irmos mais a fundo... termos realmente um contrato de prestação de serviços com o Fabricante, e garantir que toda dúvida referente ao equipamento dele, será tratada com o mesmo padrão do SAC... Vou tratar isso como prioridade...

Mais uma vez, muito obrigado...

[bylaardt]

Oi Daniel, vejo que você está trilhando um caminho visando o cliente, o que é muito bom e não perca esse foco.
mas também vejo que você não está focando o Consumidor.
o projeto ACBr pode crescer ainda mais se focar o consumidor.

Por favor, se tiver algum fornecedor ou fabricante de produtos estudem a proposta de colocar um selo com ou sem QRcode estampado no produto:
"Parceiro projeto ACBr"
"Apoiamos o projeto ACBr"
"Compatível com projeto ACBr"
"Testado por ACBr"

O selo é algo que os consumidores já conhecem em brinquedos infantis , produtos orgânicos, o famoso "designed for" da Microsoft, responsabilidade ecológica, emissão de carbono, aferimento, etc...

Tenho certeza que a o Daniel vai olhar com mais carinho os primeiros fornecedores parceiros que fizerem propostas reais nesses sentido.

E claro, os meus clientes não vão mais se constranger em perguntar para os vendedores comissionados de lojas de varejo se o produto vai funcionar e deixar que estes mesmos vendedores "empurrem" produtos diferentes com a intenção de ganhar premiações de vendas de produtos encalhados.

Ah! sim, Não esqueça de divulgar os fornecedores,os produtos, as lojas e as software houses que receberem esses selo, quero indicá-los aos meus clientes.

[Marcos Gerene]

@Daniel Simoes

 

Aos 6:12 o Sr. trata de "Facilidade da agilidade das revisões", acredito que o problema está no uso do SVN.

 

Acredito que ter o projeto deveria estar no GitHub, com PR´s abertas mas com as issues fechadas (o que não prejudicaria todas as regras ja existentes no forum), um exemplo de quem faz isto é o Firebird.

 

A vantagem é de que lá qualquer um pode fazer um Fork, alterar o que precisa para uso próprio e enviar um PR quando quiser contribuir, se o Sr. pensa em "expandir" o projeto, deveria seguir o mesmo exemplo que os grandes fizeram (vide a própria Microsoft que agora controla tudo via Git e liberou o proprio .NetCore no github).

 

PS: Já vi algumas vezes isto ser abordado no forum e o Sr. mesmo sendo contra, mas acredito que esta seja a hora de repensar no assunto, respeito muito o trabalho do Sr., mas acredito que esteja errando neste ponto.

 

Att, Marcos

[Daniel Simoes]

O problema não é SVN ou GIT... o problema é a disponibilidade de um "core developer" para analisar a sugestão... Por favor veja as respostas que estão no vídeo:
https://www.youtube.com/watch?v=s6tJ1JNoWQk&lc=Ugyk9EvL4jk6RgtGnxd4AaABAg

[Marcos Gerene]

1 hora atrás, Daniel Simoes disse:

O problema não é SVN ou GIT... o problema é a disponibilidade de um "core developer" para analisar a sugestão... Por favor veja as respostas que estão no vídeo:
https://www.youtube.com/watch?v=s6tJ1JNoWQk&lc=Ugyk9EvL4jk6RgtGnxd4AaABAg

Eu vi pelo menos 2 vezes seu vídeo e recebi o mesmo com muito entusiasmo, hoje desenvolvo em c# e ter a suíte ACBr a disposição seria incrível.

 

Concordo com seu comentário sobre a falta de "core developer", mas meu comentário foi direcionado do lado do desenvolvedor que não faz parte desse time e quer contribuir. Caso altere algo no fonte é mais facil simplesmenter abrir um PR aonde os moderadores (core team) pode ver o que foi alterado, comentar a alteração apontando para o trecho do fonte e solicitar mudanças dentro do próprio PR.

 

Hoje a contribuição é feita de forma que eu como "apenas um usuario que raramente contribui" devo subir um .pas para cá, se tiver mudanças altero e subo de novo o .pas e se for algo que envolva um trecho de código que gere uma discussão mais acalorada vai ser um tópico com varios posts e as contribuições de outros que vierem nesse sentido ficam perdidas lá, acredito que o Sr. mesmo já tenha visto isto acontecer.

 

Att, Marcos

[Daniel Simoes]

Sim.. concordo que o GIT é muito mais democrático para projeto com um grande volume de contribuições com o ACBr...

Mas mudar a forma de Download do projeto é sempre traumático... e creio que exigir as contribuições apenas pelo GIT, poderia ser um "tiro no pé" pois muitos dos usuários do ACBr não saberiam como usá-lo...

Enfim... por enquanto manteremos o SVN... Mas penso em organizar melhor a forma de contribuição usando um BugTracker 

[Marcos Gerene]

3 minutos atrás, Daniel Simoes disse:

Sim.. concordo que o GIT é muito mais democrático para projeto com um grande volume de contribuições com o ACBr...

Mas mudar a forma de Download do projeto é sempre traumático... e creio que exigir as contribuições apenas pelo GIT, poderia ser um "tiro no pé" pois muitos dos usuários do ACBr não saberiam como usá-lo...

Enfim... por enquanto manteremos o SVN... Mas penso em organizar melhor a forma de contribuição usando um BugTracker 

 

Acredito que seja possível manter um espelho no SVN por um tempo até que a comunidade se "acostume", mas eu concordo com o Sr. no seu ponto de vista, lembro muito bem de como foi abandonar o Delphi 7 com "apenas 10 meses de prazo"... xD

 

Bem, esta é uma opinião olhando de fora, mas é sempre bom saber que o projeto está evoluindo cada vez mais, abraços

[HASA]

Eu, concordo, utilizo o MONITOR PLUS e não aproveito nada dos fontes pois não programo em DELPHI ou LAZARUS, gostaria muito do acbrNFSEMonitor ou algo assim, poderia ser somente para os colaboradores $$$, eu ajudo mas... pouco aproveito, gostei da iniciativa.

HASA

Editado 19 Novembro, 2017 por HASA

[Janio]

Pode ser que eu esteja falando besteira, mas...

Acredito que a graannnnde maioria dos usuário SAC são os que programam em outras linguagens e não tem conhecimento técnico em Lazarus/Delphi para fazer alterações, ainda que pequenas.

Aos que programam em Delphi e, ao meu ver não assinam SAC, recebem tudo prontinho e de uma forma instantânea após os commits. Já os que assinam SAC (programam em outra linguagem) e usam o Monitor tem que ficar pedindo, lembrando e as vezes "implorando" rsrsrs para que as coisas feitas para a comunidade Delphi sejam colocadas tbm no monitor. Claro que sempre colocam. Mas digo que as vezes isso não eh rápido, nem mesmo para aqueles que sabem compilar o monitor. As adaptações necessárias as vezes demoram a acontecer.

O último caso que tenho lembrança foi a Impressão Fortes em apenas uma linha do Extrato SAT que para o pessoal do delphi foi implementado numa data, mas para o monitor somente foi cerca de duas semanas depois, mesmo para o pessoal do SAC.

Estou apenas tentando responder a pergunta feita pelo Daniel: "Pq a taxa de assinatura do SAC eh tao baixa?" Imagino que uma das causas seja esse delay para implementação no monitor que, imagino, seja a maioria dos assinantes SAC.

Agora com a dll torço para que mude!

Antes que alguém jogue pedra rsrsrs, sei que a comunidade Delphi faz suas contribuições ao projeto de outra forma, o que tbm é importante!

Janio

Editado 19 Novembro, 2017 por Janio

[Juliomar Marchetti]

Por favor convido a contribuir mais!!!

se possível todo o dia anexe aqui no fórum criando um tópico com cada alteração e melhoria que fizer!

iremos avaliar com certeza e não precisaremos dispensar tempo implementando e somente avaliando códigos.

6 horas atrás, Janio disse:

Pode ser que eu esteja falando besteira, mas...

Acredito que a graannnnde maioria dos usuário SAC são os que programam em outras linguagens e não tem conhecimento técnico em Lazarus/Delphi para fazer alterações, ainda que pequenas.

Aos que programam em Delphi e, ao meu ver não assinam SAC, recebem tudo prontinho e de uma forma instantânea após os commits. Já os que assinam SAC (programam em outra linguagem) e usam o Monitor tem que ficar pedindo, lembrando e as vezes "implorando" rsrsrs para que as coisas feitas para a comunidade Delphi sejam colocadas tbm no monitor. Claro que sempre colocam. Mas digo que as vezes isso não eh rápido, nem mesmo para aqueles que sabem compilar o monitor. As adaptações necessárias as vezes demoram a acontecer.

O último caso que tenho lembrança foi a Impressão Fortes em apenas uma linha do Extrato SAT que para o pessoal do delphi foi implementado numa data, mas para o monitor somente foi cerca de duas semanas depois, mesmo para o pessoal do SAC.

Estou apenas tentando responder a pergunta feita pelo Daniel: "Pq a taxa de assinatura do SAC eh tao baixa?" Imagino que uma das causas seja esse delay para implementação no monitor que, imagino, seja a maioria dos assinantes SAC.

Agora com a dll torço para que mude!

Antes que alguém jogue pedra rsrsrs, sei que a comunidade Delphi faz suas contribuições ao projeto de outra forma, o que tbm é importante!

Janio

 

[Janio]

kkkkkkkk

Ah meu Deus!

Eu não programo em Delphi. Achei q isso tinha ficado bastante claro

Outra: Achei que haviam pedido opiniões e sugestões sobre o projeto. 

Editado 20 Novembro, 2017 por Janio
Nao duplicar msg

[HASA]

É incrível mas... tentarei deixar CLARO que quem usa o ACBRNFEMONITOR-PLUS não conhece NADA de Delhpi/Lazarus/C# ( Uni...), ou seja, só posso contribuir com $$$ e enchendo o SACO de vocês, compreendem.

HASA

Editado 21 Novembro, 2017 por HASA

[dorivansousa]

Em 20/11/2017 at 08:27, Janio disse:

kkkkkkkk

Ah meu Deus!

Eu não programo em Delphi. Achei q isso tinha ficado bastante claro

Outra: Achei que haviam pedido opiniões e sugestões sobre o projeto. 

Sempre que se fala sobre o que precisa melhorar algo vem uma pedrada, respostas mandando a "gente trabalhar" no projeto... eu entendo que o projeto precisa de mais contribuições mas se alguem se compromete a colaborar nao tem pq fica cobrando o mesmo dos outros ou pelo menos usar uma estrategia pra envolver as pessoas e nao afastar, a pessoa posta algo e a resposta que recebe é vem fazer tambem, pesquisa, etc... melhor não responder pois parece que tem algo util pra solucionar o problema e no fim das contas a pessoa fica na mesma ou pior, até mesmo quem pesquisa no forum acha que tem a solucão pra um topico e a resposta não é util. Eu sempre achei que isso fere as regras do forum pq nao fala sobre o assunto do topico. 

Muitas vezes falta conhecimento ou recursos (pra quem programa em outra linguagem) pra conseguir fazer a correção e recorrem ao forum... se nao for possivel pedir la no forum vai pedir onde?. 

sou grato pelo acbr, tenho muita coisa do ACBr na minha aplicação e certamente teria muito mais trabalho sem a existencia do mesmo.. mas eu desencantei com o SAC no dia que que recebi uma resposta TLDR.

 

 

[Janio]

Boa tarde,

Estão se perguntando pq ha poucas adesões ao SAC? eis aí alguns motivos.

O moderador que me respondeu, no açodamento que lhe é peculiar, não leu (ou não entendeu) o que escrevi e nem percebeu que estamos num tópico que estão justamente pedindo sugestões de melhoria no projeto kkkk.

O mortal aqui ousou dar sua opinião e recebeu logo uma pedrada, um coice.  Ora, se eu não programo em Delphi, e deixei bem claro que uso o monitor, como vou "mandar contribuição todo dia"???? Talvez seja por essas respostas 'gentis' que quase ninguem aqui está comentando.

Não sabe ele q fui assinante do SAC durante muitos meses, não nesse nickname 'janio', mas em outro. Contribuí pq preciso do monitor compilado semanalmente? NÃO. Aprendi a compilar sozinho. Contribuí por contribuir. Por achar que o projeto é muito importante pra mim. Por achar que o trabalho do pessoal do acbr precisa ser remunerado.

Por dias pensei em expor minha opinião... que o monitor precisa de uma atenção mais especial por parte do projeto. Mas como o colega acima, protelei pq achei que iria receber uma resposta daquela. Num deu outra! Batata!

Sendo assim... ficar calidinho mesmo kkkkkk

Boodbye

[douglaswf]

Boa tarde! Gostaria fazer minhas considerações também... 

Gostaria e pretendo assinar o SAC. Não o fiz ainda por achar que ele é um pouco caro pra o que eu uso. Talvez pra quem usa o ACBR na integra, seja um valor baixo (eu diria de graça), mas pra mim, é um pouco fora. Eu uso o ACBR apenar pra ler os XMLs e extrair as informações alem do DistribuicaoDFe. Não gero NFe, não autorizo, não imprimo DANFE nada. Devido a isso não consigo contribuir com muita coisa fora dessas rotinas que eu uso. Nas rotinas que eu uso,  sempre testo e reporto problemas ou dificuldades nesses processos.  

Minha sugestão seria:

• Quem sabe ter uma opção onde o valor mensal seja menor, e seja cobrado um valor pelo tempo de atendimento seja um caminho.

 

Quando ao Fórum, Como sugestão:

• Impedir responder tópicos muito antigos (tipo 3 meses atras). Isso impede que o novato chegue, e pegue carona num assunto morto, e comece uma nova discussão.
• Posts abertos em duplicidade  poderiam ser "aglutinados" ? Não sei se a ferramenta tem esse recurso. (Isso evitaria 50% das rudezas). Notem que num mesmo dia as vezes temos 3 posts falando de problemas com manifestação do destinatário por exemplo.
• Um release semanal ou quinzenal  com as alterações (será que da pra extrair no GitHub?)  com  uma frase que diga o que foi alterado seria um ótimo jeito de motivar os usuários a testar. Assim eu poderia ajudar mais, testando o que foi alterado e não tudo o que eu uso. Se isso existe hoje, me perdoem pois eu não conheço.

Já notei varias pancadas pra lá e pra cá. Algumas delas, eu acho que não são totalmente sem razão. Tem muito post de usuário que criou a conta ontem e fez o primeiro post  pedindo como faz pra fazer o download do XML, exemplo pronto de como gerar nota na versão x, etc.... Esses deveriam ter mais vontade e correr atras de documentação antes de sair querendo tudo pronto. Mas também já vi muitos casos onde o tratamento dado foi desnecessário e exagerado sim.

As demais sugestões que vi no vídeo do @Daniel Simoes (Criar DLL, Webinar, etc...) acho ótimas e seriam de grande valia para todos.

 

 

[Nelson A Sousa]

Olá, pessoal!

Bom eu tenho uma sugestão, que não sei se é possível implementar...mas lá vai...manerem nas pancadas....kkkkk

Uma coisa que sempre perco todo santo mês, por expirarem, são pontos do meu cartão de crédito, alguns chamam de milhas.

Talvez fosse o caso de se consultar nas operadoras de cartão, se há possibilidade de contribuirmos transferindo esses pontos/milhas pro SAC do ACBR.

Posso estar falando a maior bobagem de todos os tempos...rsrsrsrs...mas é um recurso que, tenho certeza, muitos aqui perdem todo mês.

Sei lá, talvez uma forma de transferirmos por exemplo 500 pontos/milhas mensais pro SAC e o pessoal do SAC transformar essas milhas em recursos.

 

[Daniel Simoes]

13 horas atrás, Nelson A Sousa disse:

Talvez fosse o caso de se consultar nas operadoras de cartão, se há possibilidade de contribuirmos transferindo esses pontos/milhas pro SAC do ACBR.

Vou pesquisar sobre isso....

[Marcos Gerene]

 

@Juliomar Marchetti não entenda como uma ofensa, estou criticando a sua postura no forum, não estou lhe ofendendo e nem te criticando como pessoa, afinal não o conheço. 

Posso reportar ao Sr. (de forma privada) alguns tópicos aonde você teve a mesma atitude que agora, da a impressão que não leu o que foi escrito ou não interpretou o contexto, fica uma resposta grosseira que não leva ninguém a nada e só afasta justamente quem tem menos conhecimento.

 

Se o projeto tem planos de expansão, são justamente Srs. como o @HASA, @Janio e @dorivansousa o público alvo, quem vem de outra linguagem ou tem menos conhecimento técnico, ou seja, existe uma falha na estratégia aqui também.
 

Citar

 

6.3 - Mostre respeito pelo modo de escrever. Escreva de modo claro, gramaticalmente e semanticamente correto. Não escreva TUDO EM MAIÚSCULAS. Isso é lido como se estivesse gritando e é considerado rude. Favor leia as regras do fórum.

 

 

[RobertoRP]

Sugestão somente: Uma maneira de atrair contribuintes e usar GitHub, porque? Eu contribuo somente com o objetivo de melhorar o currículo e o github da uma forma muito legal de empresas visualizarem isso. Ex: https://github.com/ZeusAutomacao/DFe.NET Comecei a contribuir ai somente com o objetivo de não depender da comunidade em si, sempre procurei isso mas logicamente visando currículo também afinal sou trabalhador né, hoje to na empresa que estou amanhã não estou mais, quero algo registrado como currículo algo destacado, o processo hoje do ACBR não permite isso. 

Agora se existir alguma maneira sem github porque temos resistência de uso do mesmo pela comunidade do acbr, criar uma maneira de disponibilizar isso, digo uma pagina em algum lugar com medidas quem contribuiu com oque no código fonte? Quem realmente fez algo? enfim.. cada um tem uma maneira de ser eu sou assim, contribuo sempre mas nada e de graça no mundo não adianta dizer que vou fazer algo realmente 0800 isso não existe, no repositório que contribuo ganho um diferencial na hora de achar emprego.

Se pesquisar no forum de ACBRFramework.net já fiz algo para o TEF aqui mas foi uma necessidade minha de apenas aprender como funciona, nunca mais contribui motivo? (logico algo bem simples que fiz.. mas com o objetivo de aprender como funcionava a DLL para outras linguagens somente isso) Registros somente, esse projeto de DLL contribuiria com o maior prazer do mundo desde que eu tenha tudo registrado de alguma forma, se não tiver não tem negocio (tem negocio no seguinte sentido acho um bug preciso pra ontem vou lá e arrumo no ato)

Roberto existe uma maneira de ver quem contribui com o projeto ACBR? Ok não sabia hehe, mas e algo que todas empresas saibam e sempre procuram ver antes? Algo fácil de ver, intuitivo? enfim.. 

Obs: não sou programador delphi também mas linguagem e apenas linguagem, sempre que preciso aprendo e pronto, nunca tive dificuldades enquanto a isso.

[HASA]

Legal, e o que esse tópico rendeu Srs. ADm´s...

HASA

[bylaardt]

Creio que o Tópico foi para uma direção que o  Daniel não esperava, mas vamos à minha visão:

1) Quanto à postura do Sr. Marchetti:
Também sou de Santa Catarina, um estado que trabalha, que produz, de gente orgulhosa e promissora, que não está acostumado a pedir ajuda sem dar nada em troca. e também não está acostumado a dar ajuda para pessoas ingratas. Isso é cultural para nṍs. Se você quer ajuda, nós ajudaremos, mas se quiser criticar nossa ajuda difamando o nosso trabalho ou achando que a ajuda que fornecemos é uma obrigação e não um favor, culturalmente entenderemos que você não é mais merecedor dos nossos esforços.
O que o Sr. Marchetti fez é apenas um reflexo da nossa cultura (e de outros estados, alguns inclusive do norte, como por exemplo Rondônia, que teve muitos imigrantes gaúchos). Somos diretos, objetivos, não usamos pronomes de tratamento, (segunda pessoa e TU ), mas isso não significa que somos agressivos, apenas que possuímos culturas diferentes.
Tenho certeza que muitos vão achar meu texto agressivo ou chamá-lo de "textão" ou achar que também estou dando "patadas" mas não... quero apenas mostrar as diferenças culturais e se você não é programador delphi e acha que por isso não pode contribuir com o projeto, você provavelmente está errado.

2) Quanto ao "que eu uso", citado pelo Sr. douglaswf :
Eu não uso nada por enquanto. Estou na fase de estudar os códigos. Apaixonei-me pelos códigos e pela organização usada pelo ACBr. Não sou programador Delphi, uso Object-pascal. Muito similar, porém diferentes. meus códigos são sempre cheios de helper types que são incompatíveis com a proposta do ACBr de manter a compatibilidade com o Delphi desde a versão 7 em diante, mas isso não me impede de querer entender e aprimorar cada vez mais.
Minhas primeiras metas pessoais são:
2.1) Fazer com que o ACBr se torne compilável por cross-compile (FPC) de linux para windows. Atualmente não é possível porque os os fontes não estão em UTF8 e os caracteres acentuados deverão estar para que funcione o crosscompile no FPC em linux (espero fazer isso colocando constantes do tipo TTranslateString em arquivos .inc com diretivas de compilação {$IFDEF FPC} ou similar)
2.2) Fazer com que os componentes ACBr possam ser traduzido por arquivos .po através dessas constantes dos arquivos UTF8.
Mas para isso acontecer, preciso de estudo e tempo. Já até sugerido pelo Daniel Simoes que fosse feito um fork. Mas ainda estou estudando a possibilidade de fornecer alterações ao projeto ACBr ou fazer um refactoring do que realmente me interessei. segue o link da sugestão do Daniel.

3) Quanto ao tópico original. Vi que algumas opiniões são pontuais e querem resolver seus problemas pessoais. Esperava ver mais contribuições nos sentidos de:
3.1) Manter a longevidade do projeto;
3.2) Criar formas de arrecadação consistentes;
3.3) Viabilizar para o projeto economicamente e intelectualmente ;
3.4) Promover e divulgar o projeto profissionalmente e academicamente;
3.5) Agregar novos recursos.

4) Quanto à outras linguagens:
Apesar de conhecer diversas linguagens, eu possuo preferências de desenvolvimento, exemplo, projetos comerciais que demandam manutenção, precisam de códigos organizados e de fácil manutenção. por isso opto por object pascal, mas para Android, apesar de já ser possível desenvolver por pascal, uso o java. A maior parte do código livre escrito no planeta são de linguagens c like, mas isso não significa que você precisa aprender apenas uma linguagem.
Caso você seja especialista em outra linguagem, provavelmente poderá contribuir construindo cabeçalhos das bibliotecas descritas no vídeo do Daniel Simoes nas linguagens que você esteja familiarizado.

opinião pessoal: Github melhor  que SourceForge que é melhor que Launchpad, Google Code ou CodePlex.

[jt_vb]

Daniel boa tarde,

Bom minhas questões:

Sobre a DLL esta é uma questão super importante para minha empresa pois hoje utilizamos ACBrFramework.Net.dll e a mesma não tem todos os componentes Nfe/Sat etc...,

Cogitamos em um fabricante porem cobram valores muito autos. Você já tem alguma previsão para a DLL?

 

SAC ACBr minha empresa já foi assinante porem como lhe informei apenas utilizamos a ACBrFramework.Net ( excelente dll) porem desatualizada para alguns critérios do tef estamos tendo problemas para

homologação. Sugestão para o pagamento muitos que utilizam é de outra linguagem somente liberar a atualização da dll 1 vez por mês para quem não tem SAC.

Forma de pagamento poderia ter uma opção de pagamento anual obtendo um belo desconto para quem pagar nesta modalidade.

Acredito que o plano de negócio* não são os programadores DELPHI  porque eles conseguem modificar os objetos diretamente e sim os desenvolvedores de outras linguagem esses sim

seria o foco do ACBR SAC, assim como a minha empresa.

 

Remunerar os maiores desenvolvedores DELPHI que contribuem com o projeto*.

Acho que é isso

Abraço.