Vantagem em desenvolver um framework WEB próprio

A única vantagem é se você estiver desenvolvendo alguma coisa que ninguém desenvolveu ainda, ou se você tiver certeza absoluta que o que voce está fazendo é melhor do que todos os outros que já existem.

pois é…mas ai vai algumas questões?

-Existe por acaso alguma coisa que alguém não desenvolveu ainda?

-Imagine só o custo para a empresa em se desenvolver um framework novo? O número absurdo de horas de desenvolvimento? de treinamento para cada desenvolvedor? A curva de aprendizado?

-Como é possível saber se é o melhor framework se existem centenas por ai?

Acho que no fundo essas empresas que fazem um framework próprio, o fazem apenas para marketing junto ao cliente…apenas para dizer (nós temos nosso próprio framework e ele é fabuloso)

Existem algumas vantagens:

1. O framework fica 100% adaptado as necessidades da empresa;
2. A manutenção pode ser mais fácil (já que o time de desenvolvimento conhece o software a fundo);
3. A empresa não corre o risco do projeto de terceiros ser abandonado (como já aconteceu com o Jython, por exemplo);
4. A própria empresa pode priorizar a ordem de resoluções de bugs e definir políticas de tempo para correção;

A desvantagem disso, acho que você já deduziu, é o custo e o tempo que leva em desenvolvimento.

E claro, o que o colega falou também existe. É uma grande vantagem quando você é o único detentor da tecnologia. Nesse caso, criar um framework para usar efetivamente a tecnologia representa uma redução de custo e ganho de tempo no longo prazo.

É o nosso caso aqui. Criamos uma framework para fazer os testes no nosso telefone, especificamente, para controlar o hardware que estimula a central. Essa hardware é de desenvolvimento interno, e é muito mais completo que as soluções de mercado, já que para nós, as centrais telefônicas não são uma “caixa preta”.

ViniGodoy:

Existem algumas vantagens:

1. O framework fica 100% adaptado as necessidades da empresa;
2. A manutenção pode ser mais fácil (já que o time de desenvolvimento conhece o software a fundo);
3. A empresa não corre o risco do projeto de terceiros ser abandonado (como já aconteceu com o Jython, por exemplo);
4. A própria empresa pode priorizar a ordem de resoluções de bugs e definir políticas de tempo para correção;

A desvantagem disso, acho que você já deduziu, é o custo e o tempo que leva em desenvolvimento.

E claro, o que o colega falou também existe. É uma grande vantagem quando você é o único detentor da tecnologia. Nesse caso, criar um framework para usar efetivamente a tecnologia representa uma redução de custo e ganho de tempo no longo prazo.

É o nosso caso aqui. Criamos uma framework para fazer os testes no nosso telefone, especificamente, para controlar o hardware que estimula a central. Essa hardware é de desenvolvimento externo, e é muito mais completo que as soluções de mercado, já que para nós, as centrais telefônicas não são uma “caixa preta”.

vcs fizeram esse framework baseado em algum outro já existente?

O mundo não se resume a sistemas comerciais rodando na web.

1. Na indústria tem muita coisa sendo desenvolvida com tecnologia realmente nova, que não tem frameworks de terceiros;
2. Na academia existem muitas tecnologias novas, para uso geral. Por exemplo, seria possível fazer um framework RAD para linguagens funcionais?
3. Algumas empresas tem necessidades muito específicas. Poucos frameworks, por exemplo, tem a escalabilidade necessária para rodar numa base de dados bancária (gigantesca), ou com velocidade suficiente para atender um sistema de tempo real.

Não.

Mas, concordo com vc…

Se a empresa não sai do feijão com arroz (e esse feijão com arroz já envolve sistemas enterprise complexos hoje em dia) não só é burrice fazer a framework “no braço” como é impor um custo desnecessário ao cliente.

Esse é um dos casos que é viável a criação de um FrameWork.
Quando se tem uma situação ou desenvolvimento específico. Criar algo que pode ser reutilizado para futuros projetos com características em comum.

Agora é importante analisar se os FrameWorks de mercado já não resolvem o seu problema com eficiencia.

Não.

Então fizeram tudo do zero? como foi isso? aprenderam a montar TLDs?

eduacsp:

Então fizeram tudo do zero? como foi isso? aprenderam a montar TLDs?

nbluis:

eduacsp:

Então fizeram tudo do zero? como foi isso? aprenderam a montar TLDs?

Frameworks vão muito além de controladores MVC.

Não entendi… :S :shock:

Com certeza… nós mesmo usamos diversas frameworks do mercado para outras coisas, como persistência em bancos de dados, integração com janelas, testes unitários, geração de logs.

Por TLD vc está falando de top level domain?
Aqui temos um domínio próprio. Nossos pacotes ficam sendo chamados de com.siemens.com.xxx
Onde xxx é o nome do projeto em questão.

Mas isso foi purismo, até pq nosso framework é interno.

Ele está pensando que para criar um framework é indispensável criar uma tag library e seu respectivo arquivo TLD. Ora, frameworks não precisam ser Web ou Desktop, e não se restringem a tag libraries.

thingol:

Ele está pensando que para criar um framework é indispensável criar uma tag library e seu respectivo arquivo TLD. Ora, frameworks não precisam ser Web ou Desktop, e não se restringem a tag libraries.

mas estou falando de framework web apenas

Bem, então ignore todas as respostas anteriores. A não ser que a idéia seja completamente genial, já existe um framework web que resolve o problema. Desenvolver frameworks em casa sem organização só dá em porcaria, frameworks frakensteins escritos porque quem mal sabe orientação a objetos, com documentação parca, poucos testes e cheios de gambiarras pra solucionar todos os problemas que os desenvolvedores dele não haviam previsto.

É que isso não estava explícito. O ViniGodoy, por exemplo, não estava falando de um framework web (testes em telefones - controle de hardware…).

Se você precisa de um único* framework web para adotar na sua empresa, nem a Microsoft pode lhe forçar a isso na plataforma .NET - eles vão lançar o seu próprio framework MVC um pouco depois do lançamento do Visual Studio 2008, inspirado no Spring.NET. Isso porque eles já têm o ASP.NET clássico.

• Provavelmente você iria querer “o melhor”, mas isso é uma decisão menos técnica e mais relacionada a:

• Pessoal qualificado disponível;
• Suporte (se for um framework pago);
• Não ser um obstáculo, em vez de ajudar o desenvolvimento
• Outras razões extra-técnicas (como ser homologado pelo seu cliente, por exemplo).

E é por isso que muita gente ainda usa o Struts 1.X apesar de os próprios autores do Struts insistirem que ele está obsoleto - ele não é exatamente um obstáculo ao desenvolvimento, e está homologado por vários clientes grandes.

E o que vcs acham de criar um framework web baseado em outro já existente?

Bem, parte disso é verdade. Porem eu sou contra essa generalização toda.
E pra falar a verdade, para empresas realmente grandes eu sou COMPLETAMENTE a favor de ter um framework web proprio, seja reescrevendo um existente, ajustando alguns pontos (ou somando funcionalidades de varios) ou pra suprir uma necessidade propria, que sempre existe.
Agora, se vc se propõe a criar um framework e não tem profissional pra isso, ai é problema de gestão, que gera um problema tecnico!

existe algum guia para se criar um framework?

Sim, eu estava falando de frameworks no geral. Aliás, o título original do seu tópico não falava em web.

Mas as primeiras respostas servem para web também, afinal, a sua apilcação pode não ser uma aplicação web “ortodoxa” (pode ser, por exemplo, um MMORPG, um sistema que tenha que mostrar dados em tempo real, etc).

Se vc está falando mais especificamente de sistemas de cadastro e relatório, aí sim, não tem muito porque reinventar a roda.
No máximo, vale a pena adapta-la.

Um framework próprio (web ou não) também pode ser desenvolvido pelos seguintes motivos:

1. Simplificação da arquitetura: Como todos os componentes são da mesma empresa, não é preciso fazer proxies, classes de conversão ou trabalhar com várias classes que fazem exatamente a mesma coisa. Fora que um framework específico não tem diversas classes de uso geral, ou diversas opções de flexibilização (muitas vezes obrigatórias), que são inúteis no domínio específico do problema.
2. Performance;
3. Compatibilidade: Os componentes de diversas partes do sistema integram-se perfeitamente e de maneira suave. Não há risco de uma versão futura de um dos softwares gerar incompatibilidade com outras partes do sistema.
4. Know how: O interesse em fazer um software próprio pode estar em fortalecer o conhecimento do time e provar para o mercado a capacidade técnica. Há ganhos imediatos, já que após projetar um framework, os profissionais passam a ter um conhecimento muito profundo sobre os seus “rivais”.

ViniGodoy:

Sim, eu estava falando de frameworks no geral. Aliás, o título original do seu tópico não falava em web.

Mas as primeiras respostas servem para web também, afinal, a sua apilcação pode não ser uma aplicação web “ortodoxa” (pode ser, por exemplo, um MMORPG, um sistema que tenha que mostrar dados em tempo real, etc).

Se vc está falando mais especificamente de sistemas de cadastro e relatório, aí sim, não tem muito porque reinventar a roda.
No máximo, vale a pena adapta-la.

Um framework próprio (web ou não) também pode ser desenvolvido pelos seguintes motivos:

1. Simplificação da arquitetura: Como todos os componentes são da mesma empresa, não é preciso fazer proxies, classes de conversão ou trabalhar com várias classes que fazem exatamente a mesma coisa. Fora que um framework específico não tem diversas classes de uso geral, ou diversas opções de flexibilização (muitas vezes obrigatórias), que são inúteis no domínio específico do problema.
2. Performance;
3. Compatibilidade: Os componentes de diversas partes do sistema integram-se perfeitamente e de maneira suave. Não há risco de uma versão futura de um dos softwares gerar incompatibilidade com outras partes do sistema.
4. Know how: O interesse em fazer um software próprio pode estar em fortalecer o conhecimento do time e provar para o mercado a capacidade técnica. Há ganhos imediatos, já que após projetar um framework, os profissionais passam a ter um conhecimento muito profundo sobre os seus “rivais”.

desculpe minha ignorância a respeito, mas para mim um framework web próprio sempre foi uma biblioteca de tags própria e algumas classes de persistência. Então seria mt mais do que isto?

Bom, se você levar em consideração que existem livros inteiros sobre classes de persistencia e sobre padrões de integração (o MVC é um deles), sim, vai ver que há muito mais coisa do que isso.

Vamos pegar um exemplo clássico.

Numa possível arquitetura web,

1. Você pode usar AJAX para apresentação dos dados (digamos o GWT);
2. Classes do Jakarta commons para controlar o controle de conexões, gerar logs, etc;
3. Hibernate para a persistência em si.
4. Struts para fazer o meio de campo (controller).

Só aí, já são 4 arquiteturas. Existe uma forte possibilidade de haver classes duplicadas.
Existe a chance do hibernate logar usando log4j e o struts fazer isso usando o pacote java.util.logging.
Além disso, os formatos de log não serão padronizados.

Existe também a possibilidade de dois componentes dessa arquitetura serem conflitantes.

E, certamente, há DIVERSOS objetos entre as camadas, que não seriam necessários se tudo não precisasse ser tão flexível (lembre-se você pode substituir qualquer um dos frameworks citados, e há código prevendo isso). Isso pode vir a comprometer a performance num sistema crítico e certamente leva a um código mais complexo (no mínimo, com mapeamentos de classes, classes proxy, conversões de tipo, etc).

Bom, se você levar em consideração que existem livros inteiros sobre classes de persistencia e sobre padrões de integração (o MVC é um deles), sim, vai ver que há muito mais coisa do que isso.

Vamos pegar um exemplo clássico.

Numa possível arquitetura web,

1. Você pode usar AJAX para apresentação dos dados (digamos o GWT);
2. Classes do Jakarta commons para controlar o controle de conexões, gerar logs, etc;
3. Hibernate para a persistência em si.
4. Struts para fazer o meio de campo (controller).

Só aí, já são 4 arquiteturas. Existe uma forte possibilidade de haver classes duplicadas.
Existe a chance do hibernate logar usando log4j e o struts fazer isso usando o pacote java.util.logging.
Além disso, os formatos de log não serão padronizados.

Existe também a possibilidade de dois componentes dessa arquitetura serem conflitantes.

E, certamente, há DIVERSOS objetos entre as camadas, que não seriam necessários se tudo não precisasse ser tão flexível (lembre-se você pode substituir qualquer um dos frameworks citados, e há código prevendo isso). Isso pode vir a comprometer a performance num sistema crítico e certamente leva a um código mais complexo (no mínimo, com mapeamentos de classes, classes proxy, conversões de tipo, etc).

Bom…pelo o que vc falou, um framework próprio seria apenas uma junção de outros frameworks (customizada mas não deixaria de ser uma junção), correto?

Esse é um exemplo…

Pense nos requisitos de um framework de persistência bancário, ou da receita federal, por exemplo.
É bem provável que você não vá achar uma solução de persistência satisfatoriamente escalável, segura (e integravel com mainframe?).

Na verdade, tudo depende dos requisitos do sistema, da capacidade técnica da empresa e dos planos dela de curto, médio e longo prazos.

Aqui desenvolvemos um framework para criação dinâmica de interfaces JSF+AJAX através de anotações feitas nos pojos de persistência. A vantagem é que ficou do jeito que precisávamos, e o tempo gasto em relação ao tempo que vamos economizar daqui pra frente é insignificante. Além do que, como o Vinny já havia dito, não vamos correr o risco do fornecedor do framework abandonar o projeto.

Rodrigo.

E oq vc acha de colaborar com algum framework já existente?

Olá

Este é um dos principais motivos por que sou contra desenvolver um framework web próprio. A chance de uma equipe se desfazer é muito maior do que a de um projeto open source com grande número de usuários mixar.

Se vamos falar de documentação, número de pessoas usando e testando, gente blogando ou escrevendo artigos, discussão no GUJ, etc. e tal dificilmente sobrarão argumentos justificando desenvolver mais um framework web.

[]s
Luca

Que tal uma biblioteca e não um framework, Rodrigo?

rdantas:

Aqui desenvolvemos um framework para criação dinâmica de interfaces JSF+AJAX através de anotações feitas nos pojos de persistência. A vantagem é que ficou do jeito que precisávamos, e o tempo gasto em relação ao tempo que vamos economizar daqui pra frente é insignificante. Além do que, como o Vinny já havia dito, não vamos correr o risco do fornecedor do framework abandonar o projeto.

Rodrigo.

Legal, fizemos aqui um, entretanto com o frontend do ZK, com uso de richlets, também anotando os pojos. O que começou por curiosidade acabou se tornando coisa séria…

ViniGodoy:

…
3. A empresa não corre o risco do projeto de terceiros ser abandonado (como já aconteceu com o Jython, por exemplo);
…

Desculpe, mas de onde você tirou que Jython foi abandonado?

http://www.theserverside.com/news/thread.tss?thread_id=48627

ok…mas qts recursos vcs acham q deva ser destinado para se fazer um framework web com persistência, tag libs, controle de transações, ajax, etc?

Nenhum! Essa porra toda ja existe. Se vc tem um problema pra resolver, resolva o problema e ai sim abstraia as generalizacoes. Ou seja, ao inves de reinventar o Spring, melhore o Spring.

Nenhum! Essa porra toda ja existe. Se vc tem um problema pra resolver, resolva o problema e ai sim abstraia as generalizacoes. Ou seja, ao inves de reinventar o Spring, melhore o Spring. ;)

Como nenhum? ele simplesmente vai nascer do nada?

eduacsp:

ok…mas qts recursos vcs acham q deva ser destinado para se fazer um framework web com persistência, tag libs, controle de transações, ajax, etc?

oq vc precisa que nem o vRaptor, Spring, Struts, Richfaces, e mais os outros 5 trilhões não resolvem?

Boa! Que seja…

Luca:

Este é um dos principais motivos por que sou contra desenvolver um framework web próprio. A chance de uma equipe se desfazer é muito maior do que a de um projeto open source com grande número de usuários mixar.

Se vamos falar de documentação, número de pessoas usando e testando, gente blogando ou escrevendo artigos, discussão no GUJ, etc. e tal dificilmente sobrarão argumentos justificando desenvolver mais um framework web.

Não entendi o seu primeiro argumento. O segundo é muito justificável e concordo plenamente.
Mas… se a equipe se desfizer, aí não terá mesmo porque o framework existir, não?

O fato é que as vezes se faz muito alarde em cima de tecnologias open source que não tem nem uma equipe grande, nem uma comunidade disposta a mante-la. O exemplo que eu citei foi bom, o Jython. Foi simplesmente abandonado, paralizou no tempo. Quem apostou também no Visual Editor para editar telas no Eclipse também se ferrou (o mesmo para os amantes da IDE DevCpp, de C++).

O próprio Groovy tem uma equipe de desenvolvimento relativamente pequena e tem sido muito falado. As chances dele ser abandonado ainda existem e não são pequenas.

O fato é que existem poucos usuários dispostos a manter softwares open source. Essa história de “só baixar os fontes e mudar você mesmo” certamente não é verdade. Para um ou outro bug, ok. Mas se for para fazer assim sempre, então não há ganho. É muito difícil entender software de terceiros e, se for para você mesmo dar manutenção, é melhor fazer o seu próprio framework.

Ok, nada disso é válido para frameworks muito consolidados ou mantidos por grandes empresas como o jakarta tomcat, hibernate, glassfish, netbeans, etc…

É só ver quantas pessoas, naquele outro tópico sobre melhorias do GUJ, disseram que vão baixar o JForum e modifica-lo (quase nenhuma)… e quantas vão realmente fazer isso (provavelmente nenhuma).

Mas minha opinião é. Para o caso da web existem sim bons frameworks em todas as camadas que resolvem os problemas, com comunidades grandes e ativas, e grandes empresas dando suporte. Não faz sentido redesenvolve-los. O máximo é fazer como o rdantas: um framework de integração, para tornar mais suave o trabalho do mapeamento das classes de negócio.

É bom lembrar também que o custo de desenvolvimento de um framework próprio é muito alto. Envolve ter profissionais que tenham conhecimento profundo de projeto. Exceto os casos de onde o framework é o negócio da empresa, certamente, é maior do que uma empresa de pequeno (e as vezes até de médio) porte pode pagar.

Olá

Exatamente! Cada integrante novo que entra na equipe para substituir o que saiu terá que aprender do zero a tal da solução caseira. Não há chances de contratar alguém que já conheça o framework open source. E os que saem muitas vezes o fazem pela insatisfação de usar algo que não serve para nada lá fora (já vi isto mais de uma vez).

E as trocas nas equipes acontecem mesmo em empresas com baixo turn over. Basta uma promoção.

[]s
Luca

Tudo bem, até pode ser, mas como queríamos algo customizado à nossa necessidade optamos por desenvolver. Quanto ao desmantelamento da equipe, estamos tomando os devidos cuidados documentando tudo. Além do mais, usando annotations, ficou fácil demais, qq bom analista destrincha o código tranquilamente.

Neste caso, a relação do custo X benefício para a construção do framework foi muito válida.
E pelo que eu entendi ele aproveitou o JSF.
Então ele não crioou nada do zero.
Apenas automatizou a criação das tela.

até agora vcs não disseram qts recursos devo alocar para criar um framework.

Bem, levando-se em consideração um framework de 5000PF, coloque 5000 desenvolvedores seniors, um pra cada ponto de função e vc acabará o framework em 2 dias, um pra desenvolver e outro pra testar… tem grana pra isso?!? Não??? Ah, então contrate quantos vc conseguir e especifique o tempo… mas ainda acho que o tempo irá guiar quantas pessoas vc precisará…

Isso vai depender do escopo do seu framework, da capacidade técnica da sua equipe e de quantas horas você vai alocar cada recurso.

Bem, levando-se em consideração um framework de 5000PF, coloque 5000 desenvolvedores seniors, um pra cada ponto de função e vc acabará o framework em 2 dias, um pra desenvolver e outro pra testar… tem grana pra isso?!? Não??? Ah, então contrate quantos vc conseguir e especifique o tempo… mas ainda acho que o tempo irá guiar quantas pessoas vc precisará…

na verdade…eu estava pensando em fazer eu mesmo nas horas livres.

Cara, antes de sair criando, você precisa definir o escopo do framework, como o ViniGodoy falou. Qual necessidade ele vai resolver? Os recursos que ele conterá serão baseados nessa resposta.

Uma vez definido o problema, pesquise para ver se já não existe algum que o resolva. Caso exista, veja se a sua idéia pode resolver o problema de uma forma mais otimizada ou inovadora. Depois pense seriamente em contribuir para este framework já existente, implementando a idéia. Se após essas questões você ainda tiver decidido a fazer o framework, leve o projeto a sério! Nada de ficar desenvolvendo “sozinho nas horas vagas”, provavelmente assim ele nem chegará à sua primeira versão de produção.

Agora se a finalidade for aprendizado, aí já são outros 500…

Bem, levando-se em consideração um framework de 5000PF, coloque 5000 desenvolvedores seniors, um pra cada ponto de função e vc acabará o framework em 2 dias, um pra desenvolver e outro pra testar… tem grana pra isso?!? Não??? Ah, então contrate quantos vc conseguir e especifique o tempo… mas ainda acho que o tempo irá guiar quantas pessoas vc precisará…

na verdade…eu estava pensando em fazer eu mesmo nas horas livres.
Pelo amor dos ETs amigos, customize um já existe ou melhor ainda, colabore e faça alterações a um framework que se assemelha mais aquilo que precisa.

Voce que nao quis ouvir

Primeiro que nao se aloca ‘recursos’. Recurso eh impressora, telefone e lousa. Voce aloca pessoas. Mas voce nao aloca pessoas pra fazer um framework.

Pra comeco de conversa, vc nao faz um framework. Voce faz um projeto que resolve um problema de negocio, e dai sim extrai um framework dali, baseando-se em generalizacoes da aplicacao desenvolvida. Uma aplicacao real, que resolve um problema de verdade e economiza/faz dinheiro aparecer na conta da sua empresa/cliente no fim do mes.

Se vc fizer um framework so pq acha bonito fazer um framework, faca a todos nos um favor e nao o divulgue, a menos que ele tenha algo realmente inovador a oferecer. Em outras palavras, se eu consigo fazer a mesma coisa que o seu framework faz no Spring, eh bom que o seu framework me ofereca tanta, mas TANTA conveniencia, que eu va querer migrar ou usa-lo na minha proxima app. Nao eh o caso do Mentawai, por exemplo*.

• saoj, finja que vc nao leu esse ultimo paragrafo e nao comece outra discussao sobre o Mentawai onde ela nao eh bem-vinda

Bem, levando-se em consideração um framework de 5000PF, coloque 5000 desenvolvedores seniors, um pra cada ponto de função e vc acabará o framework em 2 dias, um pra desenvolver e outro pra testar… tem grana pra isso?!? Não??? Ah, então contrate quantos vc conseguir e especifique o tempo… mas ainda acho que o tempo irá guiar quantas pessoas vc precisará…

na verdade…eu estava pensando em fazer eu mesmo nas horas livres.
Pelo amor dos ETs amigos, customize um já existe ou melhor ainda, colabore e faça alterações a um framework que se assemelha mais aquilo que precisa.

Lembrei daquela piada dos programadores e dragões:

Existe um possível problema…
frameworks geralmente são GNU/GPL né?
Então não podem ser incluídos em softwares web pagos pq senão o software que a empresa desenvolver tem que se adaptar à licença. É o meu caso aqui, por isso estou na busca de aprender como desenvolver um framework próprio.
Abraços.

bY,
Max

shiroi2003:

Existe um possível problema…
frameworks geralmente são GNU/GPL né?
Então não podem ser incluídos em softwares web pagos pq senão o software que a empresa desenvolver tem que se adaptar à licença. É o meu caso aqui, por isso estou na busca de aprender como desenvolver um framework próprio.
Abraços.

bY,
Max

Mas ai é querer demais neh, vc usar um framework gpl quase que totalmente ou em parte… e ainda querer ganhar dinheiro com isso.

Olá

shiroi2003:

Existe um possível problema…
frameworks geralmente são GNU/GPL né?
Então não podem ser incluídos em softwares web pagos …

Não é bem assim. Primeiro que nem todos tem a mesma licença e mesmo que fosse isto nunca foi impedimento. Nos casos em que é assim você não pode incluir dentro da distribuição do seu produto mas nada impede que o instalador do seu produto instale o que for GPL.

Acho muito bom desenvolver um framework com intuito de aprendizado. Acho péssimo fazer da sua tentativa de aprendizado um padrão dentro da empresa ou a base do seu produto.

[]s
Luca

uma dúvida…os frameworks da powerlogic usam alguma coisa gpl?

citei esse ponto apenas porque trabalho em uma empresa que faz softwares PAGOS, e infelizmente não é um critério que eu tenho que definir, o fato de lucrar com isso ou não… a minha única opção é desenvolver um framework próprio considerando que a empresa não permite o uso dos prontos por causa da licença.

inclusive queria perguntar se alguem tem uma dica legal sobre um “tutorial” de como criar seu próprio framework, tô apanhando que nem criança pequena pra isso…

valeu,

abraço

bY,
Max

eu tb gostaria de um tutorial…

Olá

Comece pelo estudo das licenças e ensine para seu chefe que há muita coisa boa inteiramente livre para ele fazer o que bem quiser, inclusive revender.

E como eu disse antes: mesmo que sua empresa faça questão de usar algo GPL, como o MySQL por exemplo, não há nenhum impedimento legal de que seu sistema funcione com ele e que na hora da instalação um script baixe, instale e configure para sua aplicação.

[]s
Luca

Luca:

Olá

Comece pelo estudo das licenças e ensine para seu chefe que há muita coisa boa inteiramente livre para ele fazer o que bem quiser, inclusive revender.

E como eu disse antes: mesmo que sua empresa faça questão de usar algo GPL, como o MySQL por exemplo, não há nenhum impedimento legal de que seu sistema funcione com ele e que na hora da instalação um script baixe, instale e configure para sua aplicação.

[]s
Luca

Não. O que eu disse foi o seguinte, poder usar? PODE.
no caso da GNU/GPL por exemplo o software tem que ser distribuído além de vendido, sendo que aqui no caso é Marketing Multinível… são softwares muito grandes que usamos POSTGRESQL + PHP + MVC, e não pode constar algo com licença GNU/GPL ex:. phpboleto
etc…

valeu

Olá

Sim, o mundo não é só GPL. Há muitas outras licenças menos impeditivas.

[]s
Luca

Luca:

Olá

Sim, o mundo não é só GPL. Há muitas outras licenças menos impeditivas.

[]s
Luca

independente…
o software tem que agregar à licença né?

licença do framework menos impeditivo, licença do software tb =\

Abraço

bY,
Max

olá

Errado. Há muita coisa absolutamente livre por aí. Acho que a maior parte do que existe open source por aí é assim, principalmente no caso dos frameworks web. Há inclusive coisas que você pode modificar os fontes sem precisar contar para ninguém.

[]s
Luca

Luca:

olá

Errado. Há muita coisa absolutamente livre por aí. Acho que a maior parte do que existe open source por aí é assim, principalmente no caso dos frameworks web. Há inclusive coisas que você pode modificar os fontes sem precisar contar para ninguém.

[]s
Luca

Bom, o que eu quis dizer é que o software tem que agregar à licença do que usa.

Luca:

olá

Errado. Há muita coisa absolutamente livre por aí. Acho que a maior parte do que existe open source por aí é assim, principalmente no caso dos frameworks web. Há inclusive coisas que você pode modificar os fontes sem precisar contar para ninguém.

[]s
Luca

Mas ai vc ta falando de licença BSD q é menos restritiva que a GPL

Olá

Não é assim. Insisto, leia as licenças. Não conheço nenhum framework web que seja assim.

Além de BSD, há outras licenças completamente livres ou pelo menos livres o suficiente para que se possa incluir em softwares comerciais sem precisar se preocupar com nada ou com quase nada (às vezes é apenas necessário incluir uma nota de copyright).

Veja o caso do Hibernate onde na primeira página do site está escrito:

[]s
Luca

Ok… agora só falta lembrar que a absurda maior parte das licenças públicas americanas não tem validade legal no Brasil. Principalmente por tentar isentar o fabricante das responsabilidades sobre o seu produto o que, no nosso código jurídico, seja de graça ou não, é completamente ilegal.

Existem trabalhos numa tentativa de gerar versões tupiniquins dessas licenças… mas creio que tudo ainda demore um bocado… e do jeito que licenças tem se reproduzido que nem coelhos nos EUA, nunca teremos uma cobertura legal satisfatória.

Aqui tem uma otima referencia sobre todas as licencas.

Quase todas, faltou a licenca WTFPL!