| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | esfragam as mãos de contentes com o desenvolvimento do software livre já que quase nunca têm que pagar por estes productos, contribuindo assim 0 para o desenvolvimento do software e da comunidade mas contribuindo muito para o aumento da sua carteira... Por outro lado, para quem vende a retalho o software livre é sempre uma ameaça. Afinal de contas, quem é que consegue competir com um producto a preço 0? Ok, eu sei que o software livre não é free as in beer mas a verdade é que a regra é mesmo essa: o software livre é quase sempre free as in beer. As perguntas que vos deixo são as seguintes: Podemos concluír que o software livre se tornará predominante mais tarde ou mais cedo? Haverá motivação para investir tempo/dinheiro no desenvolvimento, por ex um servidor http quando já existe uma alternativa livre as in beer and as in speech nomeadamente o Apache que é bastante boa. Como irá sobreviver o software tradicional que geralmente não necessita de suporte logo não terá receitas nessa área. Vai viver do q? Venda de t-shirts? Ou apenas será um sinal que afinal o software livre não é uma boa opção em todas as áreas? Qual é a vossa opnião? Estarão os 5% de programadores na área de productos condenados ao desemprego/mudança para a área de serviços como diz o Eric Raymond ou ainda é muito cedo para falar sobre isso? Vamos la fazer disto um debate saudável :)
|
| | | | | | Já os prestadores de serviços... esfragam as mãos de contentes com o desenvolvimento do software livre já que quase nunca têm que pagar por estes productos, contribuindo assim 0 para o desenvolvimento do software e da comunidade mas contribuindo muito para o aumento da sua carteira...
Não percebi muito bem esta afirmação. Os "prestadores de serviços" não cobram os seus serviços? Que diferença faz que o preço do software que está na base do seu serviço ser 0 ou não?
Para mais não ter que pagar não quer dizer obrigatoriamente que não se contribua "para o desenvolvimento do software e da comunidade"
Cumps
|
| | | | Referia-me aos productos por eles utilizados para desenvolverem software para os seus clientes, etc.
|
| | | | simples, se não devolverem os seus desenvolvimentos depois podem ficar facilmente incompatíveis e terem que readaptar tudo...
---
Que Bush vos abençoe. |
| | | | Posso dar um exemplo que conheço de um amigo meu que trabalha numa empresa que fornece soluções a PME's. Atão houve uma pequena empresa local que lá adquiriu a sua netcabo empresarial e queria por lá o seu servidorzito e duas ou 3 workstations. Foi dado o preço com software Microsoft e respectiva manutenção ao que o cliente engelhou o nariz, aquilo era um bocado exagerado. Então esse meu colega faz um telefonema para um tipo que faz manutenção da máquinas Linux e perguntou quando é que ele levava para esta solução. Apresentou então uma contra proposta baseada em linux a custo (quase) zero e uma proposta de manutenção mais elevada, pois esperava-se logo que principalmente nos primeiros meses o número de deslocações o horas gastas seria muito maior. O cliente aceitou logo. O individuo da manutenção passa por lá sempre que há problemas, recebe o dele que nem é assim tão pouco, e a empresa tem uma solução à medida por um preço bem mais barato do que a solução genérica da Microsoft. Claro, os primeiros dias foram passados a dar formação aos trabalhadores, algo que numa empresa deste tamanho é perfeitamente viável, mas após verca de 2 meses o tipo só lá vai fazer actualizações de segurança (por vezes nem isso, faz remotamente) e a empresa está toda satisfeita.
Para a coisa parecer uma história com final feliz só falta o tipo que tá a fazer a assistência fornecer o código das soluções que teve que implementar à comunidade, mas isso já não sei se acontece. Também ainda é cedo para dizer se é um sucesso, mas numa empresa desta dimensão tudo leva a crer que sim.
|
| | | | | Os prestadores de serviços são mais interessados no desenvolvimento do software, pois eles podem prestar esses serviços em relação ao software, mas se o software não interessar aos clientes, não há serviço para prestar. Daí ser comum os prestadores de serviços não só colaborarem directamente no desenvolvimento do software, como contribuirem com modificações mais ou menos esporádicas, ou mesmo reservarem algum dinheiro para o financiamento do desenvolvimento desse software. O Software Livre não é uma ameaça para o retalhista, o Software Livre é uma ameaça para o retalhista que se ficár por ser retalhista, ou que não tivér acordos com prestadores de outros serviços. Os retalhistas não podem é ser passivos. Haverá sempre motivação para desenvolver mais software enquanto houver alguém que pense que consegue fazer melhor e isso aconteçe, se tem ou não sucesso, já é outra coisa. Que raio é software tradicional? Alguém tem de produzir produtos e a comunidade nem sempre tem como prioridade a produção de alguns produtos. Na minha opnião esses produtos vão ser desenvolvidos por empresas com modelos de negocios baseado no serviço de desenvolvimento de software.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | A minha ideia é mesmo a dos prestadores de serviços e desenvolvedores de projectos close source mais epecificos ( programas de facturação, algo mais complexo e de mais responsabilidade ), mas nunca perdendo a manutenção. Digo desde já que uma empresa prefere pagar x por mês, ou trimestre, ou anual e ter as coisas em condições e telefonar ao gajo e o gajo vir arranjar do que comprar coisas caras e dps aquilo só dá chatisses e ninguém aparece para intervir.
penso no entanto, que qualquer prestador de serviços deve contribuir ( mais que não seja monetáriamente ) para o projecto que dá base à sua actividade. De certo modo estamos a estimular o seu desenvolvimento e nos beneficiará, de novo, a baixo custo. Em PME's, penso que é o mais facil de conseguir transpor para soluções open source, pois têm aplicações mais generalistas ( ofimática, etc ), tenho experiência num caso identico em que apenas foram substituidos servidores, em que todos os problemas são resolvidos remotamente, quer em updates de segurança, quer afinações e configurações ao sistema base e o cliente está bastante satisfeito. Porém as aplicações principais apenas correm em ambiente windows ( programa de contabilidade ).
Aqui entra o close source, o retalhista, que tanto quer fazer dinheiro sem fazer nenhum está-se a perder ... a meu ver será um sistema close source com um open source a servir de base. Tou à espera de ver o phc e etc a serem portados para sistemas opensource. Porém, penso que a alma do negócio está no baixo custo de aquisição e um custo fixo de manutenção. Não compro nada de 5000 euros, mas compro de 500, com um contrato de manutenção anual, renovável, que em 5 anos faz mais que os 5000 euros.
trata-se de estratégia de negócio ... o programa que possuímos actualmente nesse escritorio de contabilidade é de qualidade e foi "oferecido" e tem contrato de manutenção. Algum problema .... just call!
Cumps-
Gass |
| | | | | Os modelos tradicionais de negócio estão a perder peso, incluindo-se no grupo emergente modelos como o do MySQL. Faz o seguinte, compara o crescimento do MySQL com o resto da industria (Oracle, Microsoft, Siebel, PeopleSoft, SAP, etc, etc) e depois sim, faz comparacoes. Agora, bitaites assim sem justificacao nenhuma so' te deixam a fazer figuras tristes.
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | | | MySQL AB and SAP AG Partner to Bring New Open Source Database Technologies to the Enterprise
27 May 2003
http://www.mysql.com/press/release_2003_16.html
//vd |
| | | | Em que é que isso representa mudanças no modelo de negócio da SAP? Quanto muito, representa um reforço no modelo tradicional (investir esforços no que é lucrativo no momento e espreme-lo até ao fim). Afinal, a SAP "atravessou-se" com a SAPDB em OpenSource (o tal "modelo novo"), e depois livrou-se dele para cima da MySQL (o teu link)... Um gajo até pensa que lhes correu mal, não?
O bom na história da SAP+MySQL é que a MySQL ganhou uma DB forte para usar com o SQL, e que a SAP foi inteligente o suficiente para não deitar o seu trabalho pela janela. Já usei o mysql-max, e é consideravelmente melhor que o mysql "normal"; mas não te iludas: O principal motivo foi que a SAP queria sair do negócio das DBs para se dedicar aos ERP (e isto foi dito abertamente por ambas as partes)
|
| | | | | Nao parece que percebeste a minha pergunta... de que forma e' que isto prova de uma maneira ou outra que o modelo da Oracle, Sybase, Microsoft ou qualquer outro vendor de bases de dados esta' a desaparecer em beneficio do da MySQL ? Quanto conseguires demonstrar isso diz.
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | NASA switches from Oracle to MySQL
http://www.mysql.com/news/article-51.html
The Associated Press Relies on MySQL for Transaction-Heavy News Delivery System
http://www.mysql.com/press/user_stories/ap.html
Cox Communications Powers Massive Data Warehouse with MySQL
http://www.mysql.com/press/user_stories/Cox%20Communications.html
Year of the Open-Source Database
http://crm-daily.newsfactor.com/perl/story/22685.html
Vendors Make MySQL Deals
This summer, the company signed a deal to ship MySQL 4.0 with Novell Inc.'s NetWare 6.5
According to MySQL President Marteen Mikos, who moved to California this year to handle the increased business in the U.S. and to be closer to investors who poured nearly $20 million into the company this summer, "2003 has been a good year. Next year, I hope, will be better."
http://www.computerworld.com/databasetopics/data/software/story/0,10801,85902,00.html
MySQL Breaks Into the Data Center
http://www.computerworld.com/databasetopics/data/software/story/0,10801,85900,00.html?SKC= software-85900
Para finalizar e segundo a SIIA - Software and Information Industry Association -
Best Open Source Product or Service
Awards the best software product or service developed from source code in either the pubic domain or licensed according to an open source license.
MySQL database server - MySQL AB
De uma maneira ou de outra, uma empresa com um produto opensource, está a dar cabo de grandes empresas de base de dados. Seja, pelo factor portabilidade (MSFT não corre em Unix), seja pelo factor preço (uma licença Oracle é bastante superior à do MySQL), seja mesmo pelo factor suporte (encontrar suporte para MySQL é bem mais simples do que para Sybase).
//vd |
| | | | | De uma maneira ou de outra, uma empresa com um produto opensource, está a dar cabo de grandes empresas de base de dados. Continuas a insistir... esta' a dar cabo aonde ?!?! Sao meia duzia de exemplos que formam a base da tua argumentacao ? Estava mais 'a espera que me pudesses indicar onde e' que a MySQL faz o $$$ e de que forma e' que vai destronar as 3 grandes (Oracle, SQL Server, Sybase) do data-centre.
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | É muito simples (princípio da navalha de Occam):
Se há uma alternativa mais barata, com perspectivas de ser tão ou mais eficaz (em algumas áreas isto já se verifica) e com possibilidade de um bom suporte, porquê ir para algo mais caro e menos interoperável, como são as soluções da MS e Oracle (p.e.) ?
Dominus vobiscum
"I may have invented control-alt-delete, but Bill Gates made it really famous", David Bradley, IBM Engineer |
| | | | giro, mas não é bem assim. para já, todas as dbs acabam por não ser muito interoperáveis.
e depois, o mysql tem umas falhas a nível de SQL que assustam. há uma página dedicada a isso, eles assumem (em caso de erros de introdução) uns valores por defeito muito muito estranhos, e sem avisos.
---
Que Bush vos abençoe. |
| | | | Em que mundo e' um MySQL pode competir com um Oracle , Informix ou DB2 ? Não é no meu... sejamos sinceros, por exemplo um MySQL alguma vez sobreveriria a fazer registos de tarifaçao online de um Operador Movel ? Comparar 'pesos pluma' com 'pesos pesados' e' comparaçao triste.
--
With the lights out, it's less dangerous |
| | | | Reparei que não indicas-te o MSSQL, foi prepositado, ou puro esquecimento?? (É só uma dúvida.)
------------------------------------------------------------
Todas as coisas mudam, e nós mudamos com elas. |
| | | | Bem, um produto MySQL baseado em SAPDB pode... SAPDB possui diversas características enterprise, plus uma extremamente interessante: Tem um modo de compatibilidade Oracle 7.
|
| | | | Ainda bem que o teu mundo é diferente da Nasa, Google, Cox Communications ou até mesmo da Associated Press.
Ainda bem! Fico bem mais descançado!
//vd |
| | | | Essa da NASA é engraçado...
Lá porque na NASA existem coisas que não podem falhar, o uso de mySQL presume que o mySQL não pode falhar? A resposta é óbvia e é não.
O ponto é que o mySQL ainda não suporta coisas que são absolutamente essenciais para certo tipo de aplicações.
O mySQL será bom a fazer SELECTs... Acredito nisso. Mas uma BD tem de oferecer muito mais que isso.
Já agora, alguém falou em crescimento... bem... o crescimento do mySQL tem sido muito maior que o (de)crescimento dos pesos pesados. Aliás é curioso ver que o mySQL já aparece na lista de preocupações dos pesos pesados.
Cumprimentos.
|
| | | | O único bitaite que tenho a acrescentar é este: quem não souber aceitar as mudanças vai DESAPARECER! E como rodapé, lê o artigo que pelos vistos não o fizeste e a figura triste é tua. O modelo de comercialização empregue pelo pelo autor do Compiere é diferente do da MySQL AB. É isso que esperava que tu e os outros atingissem.
"No comments"
|
| | | | | O único bitaite que tenho a acrescentar é este: quem não souber aceitar as mudanças vai DESAPARECER! Queres nos elucidar com quais mudancas sao estas ? Nao estou a perceber...
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | Nos? Só te vejo a ti a desconversar...é que usas sempre o mesmo tipo de afirmação. Se não percebes, o problema é teu.
"No comments"
|
| | | | O modelo de comercializacao do Compiere e' igual ao de muito software proprietario: lucrar com o suporte em vez do software em si. Nada de novo aqui.
Mas se o teu ponto e' o modelo de desenvolvimento (por os teus clientes a implementar aquilo que querem em vez de to pedirem a ti ao abrigo de um contrato de manutencao), tens alguma razao: e' inovador; infelizmente, tambem e' inviavel para a esmagadora maioria das empresas que apenas querem uma solucao chave-na-mao.
|
| | | | "infelizmente, tambem e' inviavel para a esmagadora maioria das empresas que apenas querem uma solucao chave-na-mao."
End-of-story
"The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." - unknown |
| | | | Um caso do tipo "se o fornecedor desaparece ou pára o desenvolvimento, nós não perdemos nada"
Bullshit. Se o fornecedor desaparece ou pára o desenvolvimento, perdes o fornecedor e mais importante que isso perdes um recurso importante na manutenção e desenvolvimento do produto que usas.
É verdade que tens a capacidade de assegurar tu o desenvolvimento, mas é muito mais complicado faze-lo sem o programador/maintainer original, e provavelmente sai-te mais caro manteres uma equipa (mesmo que seja de 1 pessoa) a substitui-lo do que te saía colaborar com ele. Dependendo da complexidade do código e da necessidade de updates, até te pode sair mais caro que uma solução comercial se tiveres que arranjar pessoas dedicadas a mantê-lo.
Como foi referido num artigo há uns tempos atrás, é muito bonito dizer que os projectos open-source atraem grandes multidões de programadores ansiosos por ajudar; mas a realidade é que, embora esse potencial exista, é raro que se concretize.
O bom do desenvolvimento open-source é que tu, cliente, podes dar inputs sobre alguma coisa, podes implementar essa "alguma coisa", podes corrigir situações, aumentar eficiência, e benificias da experiência e contributos (mesmo que esporádicos) de outras pessoas. Sim, são várias pessoas, e várias cabeças pensam melhor que uma, mas essas pessoas na maior parte das vezes aparecem com o seu "input du jour" e depois desaparecem. No fim do dia, continuas a ter 1 pessoa (ou grupo) a manter o software, e a dependência dessas pessoas é consideravelmente elevada.
|
| | | | | | e se tás a usar um produto que mais ninguém usa, não tens razões para mudar. Se mais alguém usa, partilha o desenvolvimento com ele. Ou paga a alguém com os conhecimentos.
Quanto mais não seja, é muito mais fácil que aquilo que queres já esteja noutros projectos OSS similares.
Dizer que um produto de qualidade desaparece de um dia para o outro não faz sentido nenhum.
---
Que Bush vos abençoe. |
| | | | Engraçado, muitas vezes eu vi o fulano (o fornecedor que referes) que inicia um projecto e que por motivos vários deixa de poder dar continuidade ao mesmo. Como houve mostra de valor desse projecto não demorou muito a aparecer outro que se encarregou da liderança. Isto está sempre a acontecer. No caso do Compiere, e se leste o artigo, a diferença ainda é maior. Chegas a ter um exemplo de uma empresa nórdica a investir valores elevados (e colaboradores internos) mas que fica aquém da outra aplicação que utilizam(vam). O cliente chega a influenciar o desenvolvimente de uma forma mais eficaz do que o levantamento de um consultor externo. Para finalizar, onde é que digo, ou melhor, onde é que foco que o projecto atrai grandes multidões? A questão aqui é outra...
"No comments"
|
| | | | Há uns tempos iniciei o desenvolvimento de uma aplicação à medida para um cliente, para substituir uma existente, cujo programador deixou de desenvolver. Tendo em conta os valores em jogo, sugeri-lhes vender-lhes também o código fonte, para uma maior facilidade de manutenção futura. De notar que a licença não era GPL. Até aqui tudo bem. Fiz uma breve análise das BD's existentes no mercado, e optei por usar SapDB, que é GPL. Passados 2 meses a SAP anuncia a "transferência" do projecto para a MySQL, e basicamente descontinuam todo e qualquer desenvolvimento do projecto existente. O mais curioso é que os termos da licença (apesar de ser GPL) são agora os termos clássicos do MySQL, ou seja, a versão free pode ser usada desde que a aplicação que a use seja free também(link). Apesar de fornecer o código ao cliente, a aplicação não é livre, e o código não é gratuito. Acabei por mudar o servidor para Postgres, por questões de licença, porque como é óbvio não tenho o tempo nem os recursos necessários para efectuar a manutenção do source do SAPDB original, e assegurar assim assistência e correcção de eventuais erros. Isto talvez seja um pouco offtopic, mas já vos aconteceu similar?
|
| | | | Os termos de licenciamento do MySQL são um bocado nebulosos, no entanto penso que poderias ter continuado a usar SAPDB. O esquema de duplo licenciamento do MySQL existe para que os utilizadores que assim o desejarem poderem ficar isentos das obrigações da GPL. Se o software em causa não é linkado directamente com o MySQL ou MaxDB então pode ser proprietário e mesmo assim usufruir da base de dados gratuitamente sob os termos da GPL. Se anteriormente usavas SAPDB (que é GPL) então posso assumir que este é o teu caso, logo poderias continuar a usá-lo mesmo após a transição para MaxDB.
Please note that MySQL AB can only give advice on which license is right for you. The final judgment, of course can be made only by a court of law. With that said, we recommend the commercial license to all commercial and government organizations. This frees you from the broad and strict requirements of the GPL license.
-- Carlos Rodrigues
|
| | | | O problema com o SAPDB é o de manutenção. Como o projecto foi de certa forma descontinuado, deixa de haver manutenção do produto, implementação de novas features, etc. Quanto à política de licenciamento do MySQL é realmente bastante confusa. Não é claro se a utilização do produto GPL pressupõe a aceitação dos termos de oferta (o produto que usa o MySQL tem que ser gratuito), e em que é que consiste essa utilização (distribuir a bd integrada no produto, ou utilizá-la através de um api standard). Por outro lado, o MaxDB terá com certeza suporte para migração de instalações de MySQL, mas não me parece que funcione como drop-in replacement duma instalação de SAPDB existente.
|
| | | | Quanto à política de licenciamento do MySQL é realmente bastante confusa. Não é claro se a utilização do produto GPL pressupõe a aceitação dos termos de oferta (o produto que usa o MySQL tem que ser gratuito), e em que é que consiste essa utilização (distribuir a bd integrada no produto, ou utilizá-la através de um api standard).
Pelo que se lê no site deles, o cliente pode escolher a licença que quiser, só que se escolher GPL fica obrigado às condições desta. Disto entende-se que se pode escolher o licenciamento GPL excepto se a aplicação for linkada ao MaxDB/MySQL. Ora isto é facilmente evitado usando uma biblioteca cliente que não seja GPL (por exemplo o unixODBC). O facto da bilioteca do MySQL ter passado a ser GPL reforça esta ideia. Além disto eu lembro-me de ler algures numa faq do MySQL qualquer coisa como "é necessário pagar licença no caso do uso do MySQL ser obrigatório no contexto da aplicação, isto é, quando a aplicação depender do MySQL e não puder usar facilmente outro SGBD".
mas não me parece que funcione como drop-in replacement duma instalação de SAPDB existente.
O MaxDB é apenas a versão mais recente do SAP-DB, com um nome diferente, logo eu estranharia se não fosse um substituto perfeito para este.
-- Carlos Rodrigues
|
| | | | PS: a melhor forma de clarificar isto é mesmo perguntando-lhes.
-- Carlos Rodrigues
|
| | | | Lol ora aí está uma boa ideia!
|
| | | | lol.
porque é q nc nos lembramos disto? :)
---
Que Bush vos abençoe. |
| | |
|
