Software livre não nasce em árvores: Do colonialismo ao extrativismo digital
Enviado por Eduardo Santos (eduardo·edusantosΘgmail·com):
Fazendo uma breve revisão do que aconteceu nos últimos anos na área de tecnologia no Brasil, vemos que nossa indústria de informática foi praticamente destruída no início dos anos 90, e passamos quase duas décadas sendo meros consumidores de tecnologia da informação, do hardware ao software. É a isso que chamo de colonialismo digital, pois tal como na época do Brasil colônia, acabamos consumindo tudo aquilo que os colonizadores nos empurravam. Vale lembrar aqui, que durante o início do século XIX, o Brasil chegou a “importar” um navio de patins para patinação no gelo da Inglaterra, uma vez que estes produtos estavam entupindo os estoques ingleses e precisavam ser desovados em algum lugar. Os historiadores contam que nesta época, as lâminas dos patins acabaram sendo utilizadas como facas e facões e assim fomos levando a vida: dando o jeitinho brasileiro para cumprir com nosso papel de colônia.
Considero que seja fundamental termos no Brasil uma comunidade tão militante e ativa na publicidade e no suporte às soluções de software livre, mas infelizmente isso não é suficiente, pois deixamos de ser colonizados digitais e somos hoje extrativistas digitais.
Não exagero em dizer que hoje o Brasil tem em números absolutos a maior comunidade de usuários de Software Livre do mundo, e olha que a TI ainda não chegou a tantos lares assim no Brasil, portanto temos ainda muito a crescer. O que me deixa muito chateado é constatar que ao mesmo tempo, temos uma comunidade de desenvolvedores de software livre quase inexistente (eu mesmo conto nos dedos das mãos os desenvolvedores de “código fonte” em projetos de software livre que conheço). A dita “comunidade” é a primeira a se manifestar e apontar defeitos nos muitos projetos que “participam”, mas na hora de enviar contribuições realmente significativas quase ninguém aparece.” [referência: trezentos.blog.br]
@brlinuxblog
Feed RSS
Nem li o post no blog, mas so o que eu li aqui, sinto como se a alma estivesse lavada.
Na hora da *comunidade* reclamar, estão todos ai. Na hora da *comunidade* juntar uns trocados para comprar um dominio que está sendo leiloado, preferem trocar o dominio e hospedar em outro canto
Augusto, só um adendo: fui eu quem enviei, mas o texto no blog é do Jomar Silva.
Se puder adicionar a autoria dele no post, eu agradeço.
Abraços
Olá Eduardo
Esta sua constatação em relação ao Software Livre no Brasil também se estende aos demais campos do conhecimento.
Este comportamento em não participar na produção do conhecimento é próprio dos países dependente ou periférico.
Somente usamos ou nos deliciamos com o que é produzido nos países centrais.
Somos meros produtores de produtos primários. Minérios, Carne, Frutas e até Garotos e Garotas de Programas.
E os nossos dirigentes estão bastante satisfeitos com esta nossa posição juntos aos demais países do mundo.
Abraços
Deusdará
Ótimo artigo! Infelizmente fala muitas verdades. Contribuições brasileiras são raras!
Mas, espero que voce tenha “mais um dedo” ai na mão, pois sou desenvolvedor de software livre! :)
[]‘s
sebastian
Acredito que contribuições de mais alto nível (a nível de código fonte) sejam bastante limitadas devido à limitação técnica da maioria dos membros da “comunidade” brasileira. Quem aqui está apto a contribuir com o código fonte do Linux, por exemplo? Ou mesmo de outros projetos de menor relevância? Poucos.
Nossa “comunidade” é composta, na sua grande maioria, por entusiastas. E muitas vezes arrogantes em relação aos usuários de outros sistemas.
O texto ia muito bem, até começar a desvalorizar os outros profissionais, para dar mais importância aos desenvolvedores.
exato
caraca comentei isso ontem a noite com a minha esposa! Perfeito!
Excelente artigo. Me lembra os discursos onde o Sérgio Amadeu dizia: “O Governo inteiro será migrado em 11 meses e a comunidade irá suportar esta migração…”
Vale a pena ler, porque de certa forma o trecho aqui só critica a comunidade no papel de pessoas físicas e no texto mesmo inclui as empresas sangue-sugas.
E a falta de cooperar é meio que a norma, uma escolha consciente. A manifestação do velho “levar vantagem em tudo”.
O pior é o gerente babar pelo poderio do Google, IBM ou Apple, mas na hora que se menciona ajudar ou devolver um pouco de código, acha ridículo, chama de comunista e coisas assim.
Daí a mente do gênio consegue esquecer que essas empresas cedem e cooperam muito com software livre.
Achei o texto muito bom. Um ponto que gostaria de destacar do post original:
[i]“Universidades poderiam deixar de usar exemplos genéricos e trabalhos “inventados pelos professores” nas disciplinas de desenvolvimento de software e ter como meta a cada semestre otimizar um trecho de código fonte existente ou implementar uma melhoria ou nova funcionalidade em um software livre existente.”[/i]
Excelente. Temos um problema com várias faculdades particulares, cujo objetivo maior é o lucro e não a qualidade de ensino, que simplesmente fingem que ensinam, enquanto muitos alunos caem no “golpe”. Uma sugestão como essa, sozinha é um passo pequeno para ajudar a mudar isso, mas já é um começo.
O texto é muito bonito, mas peca em colocar os desenvolvedores num pedestal. Considero isso bom, porque explica porque, mesmo tendo soluções superiores, o SL não ‘decola’: a supervalorização do papel do desenvolvedor.
Sem gente para testar, o produto do desenvolvedor não ‘arredonda’ e como consequência não pode ser utilizado.
Sem gente para documentar, o produto do desenvolvedor não vai ser entendido como deve e vai ser trocado por outro antes mesmo de ser instalado, ou seja, não vai ser utilizado.
Sem gente para traduzir, o produto não vai ter penetração em nações com outras linguagens, ou seja, não vai ser utilizado nessas nações.
Sem gente para divulgar, o produto não vai ser utilizado por ninguém.
Sem gente para instalar, treinar e manter o produto, este não vai ser utilizado.
Sem gente para reclamar, não existe feedback para o produto evoluir, e o produto deixa de ser utilizado com o tempo.
O papel do desenvolvedor é vital, mas não é nem mais vital nem mais importante do que os outros papéis. Todos são vitais e igualmente importantes. Porque se faltar um o conjunto não funciona. Ou funciona mal e morre.
E esse é o erro na estratégia do SL: normalmente, focam quase tudo em desenvolvimento, muitas vezes em documentação, algumas vezes em divulgação, raramente em treinamento, e quase nunca em feedback. Os projetos de maior sucesso são os que equilibram melhor (ou menos mal) os componentes. E mesmo assim não percebem, ou não admitem, porque.
Se a memória serve, desde quando o Ubuntu apareceu até a alguns meses atrás não faltou gente para ‘atirar pedras’ porque a canonical ‘não contribuía’. O tempo provou que as críticas eram fruto de miopia, não de visão do conjunto. A ‘turminha’ enxergava as árvores mas nem sabia que existia uma floresta. O Shuttleworth viu uma floresta que ninguém estava cuidando e assumiu a tarefa.
E esse texto, glorificando um papel – e menosprezando os demais por omissão – é oportuno apenas para mostrar porque somos apenas 1% do mercado.
Mauro
“O papel do desenvolvedor é vital, mas não é nem mais vital nem mais importante do que os outros papéis. Todos são vitais e igualmente importantes. Porque se faltar um o conjunto não funciona. Ou funciona mal e morre.”
Na minha opinião, esse discurso de igualdade é bom para Gerente falar em palestra para a equipe da empresa, evitando possíveis conflitos.
O desenvolvedor/desenvolvimento é mais importante, de longe. Não que vender, divulgar ou documentar não sejam importantes. São, mas menos.
Não gosto desse discurso de igualdade porque dá margem a injustiça. È questão de complexidade do trabalho e finalidade. Claro que precisa vender e anunciar, mas criar o produto é MUITO mais, principalmente em TI com a multiplicidade de interfaces, especificações, linguagens, plataformas…
E lembrando que… existe uma grande injustiça. Um vendedor ou um publicitário no geral é muito melhor recompensado que um desenvolvedor.
TI é muito mal paga comparando com essas ou outras profissões como médicos, advogados ou engenheiros.
@Weber Jr.,
Acho que o que o Mauro quis colocar foi a interdependência que existe entre os papéis. Sobre TI ser “mal paga”, pra mim isso depende da área e da função executada. Não é uma profissão regulamentada como as que você menciona, mas esse assunto dá o que falar. []s,
Weber, parabéns. Mais um para provar meu ponto. Que na verdade não é meu, nunca foi. É o mercado que diz isso, quase aos gritos e faz muito tempo.
Vamos citar e analisar alguns casos de sucesso:
* As lojas de aplicativos para iPhone, iPod e Android: Foram criadas infra-estruturas completas de divulgação para as apps cadastradas, e se repararmos bem, as mais vendidas de cada área são, além de serem muito boas, as mais bem apresentadas, mais bem documentadas e cujos desenvolvedores estão atentos a feedbacks; vc. já perguntou a alguma empresa que desenvolve apps para essas lojas de aplicativos quantos homem/hora gastam para desenvolver, publicar, analizar feedbacks e alterar tanto as apps quanto as apresentações e documentação ? Vc. vai se surpreender. A não ser que as apps não tenham tanto sucesso quanto vc. imagina.
* A estrutura de marketing, vendas e treinamento da IBM, Oracle e MS: tem até ‘universidades’ e ‘livros-padrão’. Campanha de divulgação encima de campanha de divulgação. Fazem pesquisas de mercado periódicamente. Tem departamentos dedicados a perguntar aos usuários com o que estão satisfeitos ou insatisfeitos, e porque. O percentual de desenvolvedores não chega a 20% em nenhum caso. Normalmente está abaixo de 10%.
* Google: preciso comentar ?
Bem-vindo à realidade de um mercado que se torna mais concorrido a cada dia, aonde o termo sua majestade, o cliente não é eufemismo. É questão de vida ou morte.
O problema é que pensamos de outra forma. E estamos errados. Miseravelmente errados. Ironicamente, nem o fato de o Brasil até ter ficado ‘bonito’ na última pesquisa com seu 1% mostrou que isso foi porque que temos ‘parasitas’ competentes traduzindo e divulgando. E nem isso abre nossos olhos.
Uma coisa é não enxergar. Outra é não querer ver.
@Mauro
Vc está correto e compartilho do seu ponto de vista. E ouso até fazer dois acréscimos:
1- Esta visão “egocêntrica” dos desenvolvedores não é exclusiva da comunidade de SL. No geral, eles têm uma dificuldade enorme em ver que um software é um produto que existe antes e depois de suas contribuições;
2- Os membros brasileiros da comunidade SL (que afirmamos, devido aos comentários dos mesmos, contribuirem muito pouco), possuem grande aversão aos conceitos mercadológicos e à estrutura empresarial que vc expôs, considerando-os coisas do “demo”. São mentes ainda alimentadas nas deficiências dos modelos existentes, porém ainda de olhos fechados às virtudes dos mesmos. Esta, por acaso é minha opinião sobre os 1% do linux em DT nas pesquisas, estrapolando para o resto do mundo.
Mauro
Basicamente tudo que citou pode ser traduzido como “desenvolver com método” ou nas coxas.
Eu não defendo que se desenvolva nas coxas. Mesmo uma equipe pequena pode criar com qualidade.
O caso é, vai dizer que um vendedor de Geladeira é tão importante quanto o engenheiro que a projetou?
Não, nunca. E veja bem, deixando claro a distinção. Uma coisa é gráu de importância, outra é *respeito*. Respeito todo mundo merece. Não importando cargo, classe social, remuneração.
Mas não, a tia do cafezinho da firma não pode ser considerada tão essencial quanto o engenheiro da tal geladeira.
A Brastemp existe porque cria geladeiras. Tudo gira em torno do produto. O Manual, os vendedores, tem sua importância. Mas não é a mesma.
Isso não é demérito, simplesmente é diferente.
Denis (usuário não registrado) em 27/05/2011 às 9:28 pm
“Sobre TI ser “mal paga”, pra mim isso depende da área e da função executada. Não é uma profissão regulamentada como as que você menciona, mas esse assunto dá o que falar. []s,”
A regulamentação não interfere nisso. Essas profissões que citei são altamente influenciadas pelo status que carregam. Um médico, mesmo sendo somente clínico, facilmente ganha mais que alguém de TI, ambos na média.
Mas um exemplo dentro de TI/Telecom. No Brasil, poucas empresas desenvolvem equipamentos de transmissão de dados. Um engenheiro desses, altamente especializado, ganha menos que o vendedor da empresa. MUITO menos.
Por mais formação que o vendedor tenha, ele é substituido mais facilmente que o engenheiro altamente especializado. Mas mesmo assim ganha muito mais.
Aí fica escancarado como em TI já se está muito subvalorizado. Claro que existe desenvolvedor arrogante que acha que o mundo gira em torno dele, mas no geral o cenário é esse que coloco, ou seja, o inverso: Gente ganhando muito mais em uma função auxiliar que alguém que trabalha diretamente no produto foco da empresa.
Já pararam pra pensar que nem todo SL quer ser um “produto”?
Em projetos assim código é o que vale, o autor do texto tem toda razão.
Até o Ballmer concorda: http://www.youtube.com/watch?v=8To-6VIJZRE
Achei o texto interessante, tenho que destacar um trecho do texto original para fazer uma comparação:
“Tamanha foi nossa aceitação do papel de colonizados, que no final da década de 90 não era raro encontrar universidades que ao invés de lecionar “Sistemas Operacionais”, lecionavam “Windows NT”, ou trocavam “Banco de Dados Relacionais” por “Oracle” ou “DB2” e por aí seguia a carruagem.”
Se fosse comparar isto com os carros, seria como aprendermos dirigir apenas fuscas nas Auto Escolas, enquanto teríamos que aprender a dirigir outros automóveis lendo o manual de instruções. Se fosse hoje, a gente não compraria facilmente outro carro senão o Fusca 2011 nas lojas, pois a procura deste veículo seria grande devido ao fato que as pessoas saberiam dirigir apenas este carro (mesmo que os outros fossem bem mais baratos, espaçosos e confortáveis).
Embora esta realidade dos automóveis não exista, a realidade dos softwares é semelhante ao do exemplo que citei, já que aprendemos nas instituições de ensino desde cedo a usar o Windows ao invés de Sistemas Operacionais e usar MS-Office ao invés de Pacotes Office.
Se vc. se refere a graus de remuneração ou de merecimento a remuneração conforme a tarefa, concordo. Também concordo que as distorções de nosso mercado de trabalho existem e são graves. Mas são _outro_ assunto.
A matéria postada tem impregnada nela uma mensagem mais forte do que a que seu autor quiz transmitir. Algo que reflete a mentalidade do autor – e a da quase totalidade dos desenvolvedores e demais membros da comunidade. Mentalidade esta que creio ser a maior causa de o SL não dominar todo o mercado. A causa de o ‘ano do desktop’ nunca acontecer, de ficarmos nesse 1% – do qual fazemos boa parte. A seguir vou tentar explicar o porquê, na minha opinião.
No exemplo da Brastemp essa mentalidade distorce os fatos além de qualquer chance de aproveitamento real:
O objetivo da Brastemp não é fabricar geladeiras, porque isso não paga nem o engenheiro, nem a tia do cafézinho, nem dá lucro. Encher o depósito de geladeiras é pesadelo, não é sonho.
O objetivo da Brastemp é ter lucro (porque sem lucro o empresário fecha as portas e dispensa todo mundo, sem distinções), e para isso precisa vender geladeiras. E para vender geladeiras precisa fabricá-las. E para fabricá-las precisa do engenheiro, da tia do cafézinho e de muitos outros.
Para continuar tendo lucro vendendo geladeiras, precisa superar, ou pelo menos acompanhar a concorrência. Para isso precisa aperfeiçoar os produtos, otimizar a produção, reduzir os custos e, principalmente, agradar seus consumidores. Porque são estes quem decidem quem vai ter lucro.
E para isso precisa do feedback dos clientes e ficar de olho na concorrência. E para ter feedback precisa de profissionais e recursos para isso.
Sabendo que seus consumidores não gostam de ler manuais com mais de duas páginas, e que, se estes não souberem tirar o máximo proveito de seus produtos, não vão ficar tão satisfeitos quanto deveriam, os times de documentação e grafismos são pressionados a fazer milagres.
Sabendo que, se seus consumidores acharem seu produto ‘feio’ ou ‘sem graça’ não vão comprar, o departamento de design industrial é pressionado a deixar o produto mais bonito – na opinião dos consumidores. Designer que não sabe ‘sintonizar’ o gosto dos consumidores não dura no emprego.
Sabendo que o produto tem que durar pelo menos x anos sem pifar, os departamentos de engenharia e produção são pressionados a atingir os níveis de qualidade desejados – sem gastar mais, se possível.
E todos são pressionados a gastar menos, para manter o produto competitivo e lucrativo. E fazem tudo isso porque seus concorrentes também fazem. A Brastemp entende que perde a cada vez que um consumidor escolhe o produto de um concorrente. E os gestores sabem que os empresários e/ou acionistas não aceitam desculpas. Nem número de geladeiras produzidas ou vendidas. Apenas qual foi o lucro do período.
Os engenheiros e demais funcionários envolvidos com projeto e produção acham que o objetivo da Brastemp é fabricar geladeiras. Não vão crescer na empresa enquanto não entenderem e se sintonizarem com o verdadeiro objetivo. Simples assim.
Mas eu prefiro fazer analogia com o teatro: Bons autores e atores entendem que uma boa equipe resulta em boa divulgação, um bom cenário, bom figurino, boa iluminação e bom som – que não são feitos nem por eles, nem para eles, mas para a platéia. Mas são os atores quem brilham. E são os autores e diretores que são enaltecidos. Quando todos os envolvidos são competentes.
Isso, é claro, salvo para os ‘gênios incompreendidos’: estes gostam de atuar em condições lamentáveis para platéias reduzidas, e assim poderem ‘viver’ sua trajédia fútil. Esses não precisam de equipes. Precisam de psicanálise. Ou serem deixados aonde querem, para serem cultuados por pequenas platéias, que pelo reduzido número dão a falsa impressão de serem uma elite.
Vamos agora analisar a comunidade que cerca o SL:
Tudo começa com os desenvolvedores. O Stallman foi um desenvolvedor. A ‘patota’ dele é um grupo de desenvolvedores. O Linus também é um desenvolvedor. E a grande maioria dos usuários é formada por técnicos e geeks, que reconhecem o valor dos desenvolvedores.
A partir dessa mentalidade, (nem sempre) obtemos manuais que podem ser completos, mas não são fáceis de entender; é como se fossem necessários manuais para entender esses manuais. Como testemunho da inadequação dessa documentação, temos as FAQs: explicações que deveriam estar nos manuais, mas não estão. Boa documentação só precisa de um índice.
A seguir temos os fóruns, que são uma forma adequada apenas a usuários experientes, aonde são comuns respostas do tipo ‘pesquise o fórum antes de postar uma pergunta’, normalmente acrescidos de alguma expressão pedante e antipática, quando não grosseira. Os poucos ‘leigos’ que tentam se aventurar nos fóruns de desenvolvedores para pedir alguma feature são via de regra recepcionados com ‘jóias’ de humildade do tipo: ‘o fonte está aí, implemente essa feature vc. mesmo se acha que é tão importante’ – seguido de uma mistura de ‘ares de compaixão’ com ‘ares de superioridade’. E uma pitada de ironia maldosa. Ou uma pá cheia. Dá a impressão de que ficam na espreita, à espera de um usuário para poder descarregar seus recalques e complexos no coitado. Deveria haver alguma forma de banir esse tipo de desenvolvedor da comunidade. Ou amordaçar.
São necessários meios simples, tais como endereços de email, e pessoas dedicadas a ler, analisar e responder os emails que não forem nem spam nem trollagem. E de elencarem as sugestões em listas de votação para que os _usuários_ decidam quais as ‘features’ mais desejadas, para que os desenvolvedores possam saber o que sua magestade, o usuário quer – e não o que o desenvolvedor ‘acha’, que pode não estar errado, mas pode estar fora de sintonia. E para encaminhar as dúvidas para o time de documentação, para ser analisado e assim se descobrir que partes da documentação devem ser modificadas, ou até reescritas. Ao invés de colocar mais um item no FAQ, que é um testemunho e monumento da documentação mal feita.
A divulgação é limitada a posts em mídia especializada, que só é vista por – adivinhem – desenvolvedores e usuários experientes. Precisamos de pessoal de marketing, procurando os fornecedores de hardware e fechando acordos. E identificando mídias frequentadas pelos grupos que são potenciais usuários e postando notícias promocionais do tipo ‘Ei, isso existe e é bom. Experimente !’.
Quem desenvolve para sí não precisa de opiniões. Mas quem desenvolve para outros precisa ouvir e valorizar as opiniões desses outros. Saber ouvir, saber trabalhar em equipe. E ter canais adequados de divulgação e feedback com os potenciais usuários.
Para tudo isso precisamos de bastante gente que não desenvolva. E de desenvolvedores com menos ego e mais inteligência. Capazes de trabalhar com – e valorizar – uma equipe.
@Weber Jr
Não discordo de você. Mas também não vejo solução pra isso. No meu modo de ver, a área de TI tem uma cadeia produtiva, com suas interdependências, que gera certas discrepâncias, o que não ocorre (pelo menos tão aparentemente) com outras profissões. Acho que é isso. Sobre regulamentação, tem certas profissões que não merecem uma regulamentação, não porque isso é algo bom, mas porque provavelmente quebraria o mercado, literalmente.
Sobre o assunto específico do post, conforme o Mauro coloca (extensamente por sinal!), sem querer ser simplista demais, mas já sendo, será que o problema do Linux é que o poder de decisão sempre ficou mais na mão dos desenvolvedores do que nos marqueteiros? Talvez porque o modelo seja diferente do software proprietário – e num ambiente livre, fica mais fácil pra um desenvolvedor agir com autonomia e discordar de uma decisão por vendas…
@Mauro, tenho um irmão que cursa Ciencia da Computação, acabei de imprimir seu comentário pra ele ler.
@Mauro
Parabéns, Está trazendo uma luz aos comentários do blog!
Nunca tinha lido seus comentários por aqui, talvez eu não ligue o avatar a pessoa mas tudo bem, continue elevando o nível do debate
Clap, Clap, Clap
@Mauro,
Como já comentei no blog onde escrevi o artigo: É uma questao física/econômica (sem produto não existe nem comércio, nem mercado) e não filosófica (quem pode mais na cadeia de valor).
Coloque 50 gestores, 50 vendedores e quantos especialistas em documentacao, traducao e processos em uma sala e veja quanto de software eles irao produzir… Nada !
Coloque 1 programador na sala ao lado com tesao no que esta fazendo, e em poucas horas a legiao da sala anterior vai ter algo para trabalhar… Simples assim !
Não me lembro ter escrito em nenhuma parte que o desenvolvedor não é necessário.
Mas também me lembro de ser insistente e categórico em afirmar que um desenvolvedor inteligente sabe trabalhar em equipe e valorizar essa equipe. Mesmo porque não faz sentido querer ser valorizado ao ponto de desvalorizar os outros profissionais. Quem faz isso não consegue se relacionar direito com profissionais de outras áreas, e consequentemente, não consegue trabalhar em equipe.
Todos ganham pouco.
Enquanto um cientista se mata para curar uma doença, um jogador de futebol ganha 10000x mais que ele :P
@Jomar
Então, basta 1 programador pra fazer tudo dar certo? Não é necessária essa legião dos outros? Ah, então por que reclama? 1 programador é com o que conta os seus projetos-exemplo.
Não acho que tudo no seu texto esteja errado, mas você devia rever esse seu ponto de vista. Uma empresa que contribui polindo e produzindo conteúdo para uso com o software agrega o mesmo valor que um programador, ou grupo deles, contribuindo com patches.
@Mauro
Mauro, entendo o que você quer dizer e reflete muito bem o que a maior parte das pessoas pensa em relação a software em geral. Contudo, o que o post quer dizer (e que eu e muitos outros desenvolvedores de Projetos de Software Livre também) é que há um sério problema na cadeia de valor do Software Livre.
Muitas vezes recebemos o tal “feedback” que você citou. O usuário diz: “precisa melhorar isso no software”. E você olha pra quantidade de coisas que tem pra fazer e pensa que realmente precisa melhorar isso, mas que o esforço vai ser enorme. Aí vem a pergunta que todo desenvolvedor de Software Livre deve estar acostumado” e quem vai fazer?
O Jomar ressalta várias vezes no post que a maior parte dos desenvolvedores é VOLUNTÁRIA. Isso mesmo, pode parecer um absurdo, mas tem muita gente por aí que não ganha NADA com isso, e tem a responsabilidade de atender o tal feedback do usuário. Ou melhorar o produto. Ou divulgar…
Dois exemplos para ilustrar:
1 – Mantenho um dos únicos portais do Governo que é totalmente desenvolvido em Software Livre e tem o código-fonte disponível na Internet. Sim, o código em PRODUÇÃO do Portal é aberto. Uma vez recebi o comentário de um famoso designer da comundiade me dizendo que o Portal era feio. E acho até que ele tinha razão, mas o único desenvolvedor era eu e não entendo nada de design. Aliás, nossa comunidade carece desse problema. Disse ao famoso designer que fizesse uma nova proposta de layout que eu implementaria. Afinal o código está na Internet. Será que eu recebi a tal proposta?
2 – Estava uma vez no FISL numa apresentação de um software para reconstrução de imagens 3D chamado InVesalius. Conhecia os desenvolvedores à época, e fomos procurados por um gerente de hospital que estava assistindo à palestra. Ele disse: “poxa, pra eu usar só falta o software buscar a imagem direto no tomógrafo. Era o que eu precisava e o software X proprietário faz”. Perguntamos se era importante e ele disse que sim. Então eu disse a ele que com US$ 10.000,00 faríamos isso. Ele se sentiu ofendido e saiu. Detalhe: a alternativa proprietária custa US$ 30.000,00 a licença…
Esse problema na cadeia de valor que é difícil de as pessoas enxergarem e que o Jomar (e Eu, e outros) queríamos apontar com o post.
P.S.: Sabe o que recebemos quando desenvolvemos algo que os usuários realmente queriam? Um tapinha nas costas. E as contas continuam vencendo no final do mês…
Em relação à contribuição com código-fonte, acho que é uma questão de “porções”:
- de todos os usuários de SL, só uma porção tem condições de contribuir (os que tiveram alguma formação em programação);
- dos que podem contribuir, apenas uma porção quer contribuir;
- dos que podem e querem contribuir, apenas alguns tem tempo para fazê-lo.
Esta porção dos que podem, querem e tem tempo pode ser grande ou pequena, comparando com o total. Será grande em lugares onde o nível médio de qualificação for alto, e pequena onde for baixo.
Conclusão, o Brasil é um “extrativista digital” e continuará sendo por um bom tempo.
@Eduardo: Também não podemos ser simplistas à ponto que um hospital, sozinho, iria bancar o teu desenvolvimento. No lugar do diretor, também não bancaria.
Sabe por quê? Uma coisa é você chegar do topo da sua cabeça e cuspir uma cifra redonda, após uma palestra no FISL, e achar que um diretor de um hospital (que presta contas de tudo que gasta) vai simplesmente dizer “Beleza, toma aqui o dinheiro.”. A vida não é assim.
Da próxima vez, não terceirize os seus problemas, mas as suas soluções. É US$ 10k que vc precisa? Ótimo. Abra a sua empresa, pegue um financiamento, contrate pessoas, desenvolva o programa e venda o programa completo depois para outros hospitais. Bote o *seu* dinheiro em risco, ao invés do dinheiro dos outros.
Tendo isso, podemos abordar o seu primeiro exemplo: O Designer famoso não iria trabalhar pra você de graça, da mesma forma que vc não quis trabalhar de graça para o hospital. Designers são profissionais especializados e que fazem um trabalho sério, tanto quanto programadores. Por quê você achou que ele iria fazer algo que você não fez?
@Spif
Acho que você não entendeu o que eu quis dizer, mas trouxe um outro problema importante que acho devemos discutir também.
O exemplo que você citou de “abrir empresa, desenvolver programa” reflete muito o velho mito da “caixinha mágica” que também foi citado pelo Jomar no Post. Durante muitos anos e por vários motivos nós nos adaptamos aos softwares, e não eles a nossos problemas. Não existe software que atenda 100% às suas necessidades, existe sim aquele que mais se aproxima disso. O que nós fazemos no caso é nos adpatar a ele, alterando nossos processos e modelos mentais e nos tornando “reféns” do software, enquanto o que deveria acontecer é o contrário.
O software em questão está pronto, atende mais necessidades do hospital que a solução proprietária mas não atendia aquela específica. Nós não terceirizamos os problemas, apenas dissemos que para aquele momento essa não era uma prioridade de desenvolvimento do software, mas que sua necessidade poderia ser atendida por um valor.
Se você ainda acha que vai receber em casa aquela caixinha da prateleira que vai atender todos os seus problemas… Bem, aí não há muito o que fazer. Estamos muitos acostumados ao papel de colonizados.
Voltando ao exemplo do designer, muito bem colocado. O problema não é o designer não ter enviado. A questão, como o Jomar colocou no Post, é que a comunidade é cheia de gente que adora reclamar que uma coisa não funciona direito, mesmo quando você NÃO ESTÁ SENDO PAGO pra fazer aquilo. Contudo, na hora de AS PESSOAS GASTAREM SEU TEMPO ajudando ao invés se só eu gastar o meu fazendo o que ele quer, a quantidade de pessoas é sempre menor, pra não dizer inexistente. O tal designer famoso devia achar que o tempo dele era valioso demais pra me ajudar, mas não tão escasso assim pra reclamar. Curioso não?
Ou o tal designer era péssimo em relações interpessoais e essa reclamação era uma oferta para enviar um orçamento.
Ah, mas reclamar todo mundo gosta… inclusive reclamar de quem reclama. Já no meu caso, reclamar de quem reclama dos que estão reclamando.
Mas gostar de software “caixinha” não tem nada a ver com gostar de ser colonizado, mas de ser um cliente. O cara quer comprar, quere receber o que pagou e quer ligar para um suporte técnico, se der poblema. Qual o problema disso?
Outra questão além do que foi falado.. São as escolinhas de informática que ganham ensinado como se ambientar no windows..
Fácil né… de alguma forma essa tendência tem que mudar…
Software Livre tem que ser a porta de entrada!
É uma questão cultural também.
@Eduardo Santos:
Estou preparando um artigo completo, sob o meu ponto de vista, um resumo histórico das infraestrutura e mentalidade da comunidade GNU, a situação em que nos encontramos e suas causas e consequências. Inclusive o porque dos casos que vc. citou. Tudo isso na esperança de ser publicado aqui. Senão, no mínimo vai ser um meio de organizar melhor as idéias. Mas pode demorar um pouco, estou na fase de implantação do engine de um sistema de backup e consulta de emails em banco de dados voltado a pequenas e médias empresas que desenvolví para um cliente e que pretendo publicar sob GPLv3.
Como o tema é polêmico, acredito que é melhor descrever toda a situação, desde como chegamos a ela, e o que creio serem algumas possíveis alternativas para mudar o quadro atual.
@Augusto Campos:
Tem como publicar, daqui a aproximadamente uma semana, este artigo que estou preparando ?