Requisitos para trabalhar com ferramentas Open Source

Quando se apresentam as vantagens teóricas e práticas das ferramentas informáticas Open Source é raro falar-se em profundidade dos requisitos que estas apresentam, ao contrário do que acontece na maior parte das vezes que se discutem ferramentas proprietárias. É natural que assim seja: como estas ferramentas são abertas e livres, não existe, de facto, uma lista de “exigências” e (in)compatibilidades, como acontece muitas vezes com as ferramentas proprietárias, que as apresentam, muitas vezes, apenas por interesses comerciais e sem nenhum fundamento técnico. A diversidade de distribuições de algumas destas ferramentas, disponíveis para variadíssimos “sabores” de Linux, mas também para Windows e Mac OS X, com bastante frequência, tornam ainda mais complicado falar de “requisitos” e promovem a ideia de que todas elas funcionam igualmente bem em qualquer ambiente. Numa primeira abordagem e para uma utilização pacata, suspeito que isso corresponda à verdade e essa é mais uma das razões para que não se levante frequentemente este problema dos “requisitos”, mas se nos debruçarmos mais a sério sobre estas ferramentas e se fizermos uma utilização intensiva, comparando-as com as concorrentes comerciais, começamo-nos a deparar com dificuldades estranhas e muitas vezes pouco documentadas. Especialmente se, como eu, adoptarmos várias ferramentas open source, mas não formos rigorosos militantes do modelo FLOSS— ou seja, não só mantenho como sistema operativo o Mac OS X, como preciso de ver a vantagem técnica das soluções open source, já que as morais, que não menosprezo, em momentos de crise podem não ser suficientes para não me impedir de fazer o meu trabalho.

O dia de hoje— como todos os momentos cruciais de finalização e entrega de trabalhos de design de alguma dimensão desde que comecei a usar intensivamente o GIMP, o Inkscape e o Scribus— voltou a fazer-me pensar, dolorosamente, nesta questão. Sendo, teoricamente, ferramentas muitíssimo potentes e perfeitamente capazes de realizar as mesmas tarefas que as mais avançadas soluções comerciais e tendo eu a experiência de assistir à demonstração disso mesmo ou fazer essas demonstrações eu próprio, a verdade é que, em velocidade de cruzeiro, na configuração que eu tenho neste momento, a performance é dolorosa.

Os problemas maiores que me afligem dividem-se em 3 grandes áreas:

  • Gestão de memória: quando trabalho com ficheiros grandes (imagens raster de grandes dimensões no GIMP, ficheiros com muitos objectos ou geometrias complexas no Inkscape, documentos de grande dimensão no Scribus…) operações relativamente simples demoram imenso tempo, recordando os processos de edição digital de há 10 anos atrás. Em determinados períodos isso não é mau; dá-nos tempo para pensar, ajuda a gerir as pausa, etc. Mas numa fase final de produção de elementos para impressão, em contra-relógio, é exasperante. E se fosse para ter a performance de há 10 anos atrás, não se justificava ter máquinas recentes, com processadores recentes e memória adequada.
  • Instabilidade: na altura da verdade, tenho sido presenteado com freezes e crashes como nunca tinha visto (eu nunca usei Windows para trabalho). E, se no GIMP a instabilidade parece estar directamente relacionada com o problema da gestão de memória, já que só se nota com ficheiros de grandes dimensões (apesar de haver um ou outro filtro ou extensão pouco recomendável, também pelos imensos ficheiros que gera, mesmo que temporariamente), quer no Inkscape, quer no Scribus, chego a pensar que a condição necessária e suficiente para ter um freeze ou um crash é estar a trabalhar em algo de que precise durante algum tempo. Bem sei que tem que haver um padrão e já identifiquei algumas operações “sensíveis” nas duas aplicações, como agrupar e desagrupar grandes quantidades de objectos, aplicar máscaras e clipping paths no Inkscape, tentar abrir a janela de impressão no Inkscape, manipular elementos vectoriais importados no Scribus, obrigar o Scribus a muitos redraws, através de zooms e pans… Mas a instabilidade das aplicações, para quem vem dum universo Macintosh, é um pesadelo kafkiano e em momentos críticos, crashes a cada 5 minutos, como tenho tido quando estou a finalizar a composição de MUPIs, por exemplo, faz perder qualquer esperança no benefício kármico de usar software livre.
  • Compatibilidade: este problema não é tão grave como os outros do ponto de vista de performance, uma vez que é algo a que já estamos habituados nas soluções comerciais, mas é estranho que os SVGs do Inkscape, por exemplo, tenham alguma dificuldade de importação no Scribus se usarem algumas funcionalidades, como máscaras, clipping paths ou transparências e que, mesmo que não tenham essas características, percam referências de dimensão e cheguem fora de formato ao Scribus. Via EPS ou PDF damos a volta a esta questão, mas é estranho. Como é estranho que o Scribus importe ficheiros .PSD, formato proprietário do Photoshop, mas não .XCF, formato nativo do GIMP. Ou que seja preciso recorrer ao Scribus para ter uma imagem em quadricromia feita no GIMP. Ou…

O facto destas questões (algumas delas, pelo menos) não serem abordadas como assuntos sérios nas comunidades de utilizadores e dada a diversidade e exigências de uso a que elas têm sido submetidas, levam-me a depreender que, apesar de “funcionarem” em muitos ambientes, não “correm” em todos. Diz-me um colega de profissão que no seu MacBook, nota uma considerável diferença de performance nestas aplicações entre as versões em Mac OS X e versões a correr em Linux (Ubuntu):

É que não há comparação. Eu agora instalei o Ubuntu no meu MacBook Pro e, comparando com o OSX, as apps gráficas livres correm que é um doce. Compensa o incómodo de ter um dual-boot.

Além de que estás sempre com as versões mais actuais — as ports para OSX demoram sempre um pouco a sair. E têm sempre bugs específicos, que é o que te deve estar a afligir (e que eu também testemunhei).

Diz quem sabe.

Eu vou fazer o teste possível, mas fico a pensar até que ponto este é um problema real da comunidade open source:

  • Será que a difusão da ideia de que as ferramentas livres e abertas funcionam em todos os ambientes e o voluntarismo com que alguns programadores “martelam” o código necessário para que tudo funcione em todo o lado não criam experiências negativas (ou menos positivas) em quem está a ponderar a mudança?
  • Não seria útil gerir melhor as expectativas dos utilizadores (especialmente dos utilizadores mais exigentes, que estejam num percurso de migração, vindo de ambientes proprietários / comerciais), clarificando os requisitos técnicos de cada aplicação e dando exemplos de setups testados para performance e estabilidade?
  • Será assim tão perigoso para a difusão do software livre a declaração de exigências mínimas para aplicações específicas e a constatação de que existem diferenças entre “funcionar” e ser útil e produtivo num ambiente real?
  • Que impacto teria no ecossistema fragmentado dos sabores Linux a declaração, por parte dos principais programadores de cada aplicação, das combinações de hardware e sistema operativo ideais e/ou realmente testados?
  • Como se poderia implementar um sistema de testes das diversas distribuições de cada aplicação em cada ambiente que fosse verdadeiramente fiável? A sensação que se tem é que, em muitos casos, as distribuições Mac OS X foram testadas com uma instalação e um par de cliques por parte de quem 1) não usaria a aplicação profissionalmente e/ou 2) não tem grande experiência de utilização de computadores Macintosh.

Vamos lá a alguns testes, então…

Panorâmicas

Não sei porquê, mas sempre tive um “fraquinho” por imagens “panorâmicas”. Parece que sou sempre mais atraído por imagens de realidades que não se conseguem captar com um único olhar. Realidades que exigem um movimento associado ao olhar, seja horizontal, na paisagem, seja vertical, em alguma arquitectura. Como esta vista panorâmica do Rempart de La Charité-sur-Loire:

La Charité-sur-Loire, Panorama do Rempart

Esta imagem corresponde à montagem destas 6 fotografias:

DSC02202DSC02203DSC02204
DSC02205
DSC02206DSC02207

E a ferramenta usada para fazer a operação de “stitching” é open-source, gratuita e multi-plataforma. Chama-se Hugin e, apesar de não ser elementar na utilização, não é preciso ser-se um especialista para criar montagens decentes, com auto-detecção de pontos-chave, várias formas de correcção da perspectiva e projecção e boas capacidades de mistura (blending). A montagem que vêem, aqui, é uma projecção “trans-mercator”, usando auto-detecção dos pontos chave, com o plugin Autopano-SIFT-C (instalação opcional descarregado com o instalador de base em Mac OS, pelo menos) e “blending” normal.
Para utilizadores mais exigentes, o Hugin lê informação EXIF sobre as lentes e o posicionamento e permite introdução manual de dados relativos a cada imagem (posição, rotação, lente, etc.), afinação manual de pontos-chave, criação de imagens HDR, assim como exportação em diversos formatos de imagem e até pode ser usado para apoiar exercícios de levantamento e modelação em arquitectura (ver aqui).

Confesso que no caso desta imagem, depois de criada a montagem panorâmica, passei pelo GIMP para ligeiros ajustes de cor, porque os originais estavam um bocado desmaiados. Clicando nas imagens (panorâmica e fotos originais), podem ver em maiores dimensões, no Flickr. Que tal vos parece a performance do Hugin? Que conselhos ou sugestões me dariam para melhorar este tipo de imagens? Precisam de alguma ajuda para se iniciarem neste processo de criar panorâmicas? A caixa de comentários está aberta para isso mesmo. ;)

Mudar de vida

É frequente pensar na necessidade de mudar de vida. Nas pequenas rotinas e nas direcções globais. Mas é raro sentir que estou de facto a mudar de vida e hoje senti isso em coisas verdadeiramente elementares e simbólicas. Tive duas boas conversa sobre uma (aparentemente) “nova” forma de promover a criação e o contacto entre criadores, assente na transposição de alguns princípios do movimento Open Source para os processos de criação e debate crítico e participei na instalação de dois sistemas operativos Linux (um Debian e um Xubuntu) em dois iMac G3 (PowerPC) que fazem parte dum parque de máquinas obsoletas que poderão vir, desta forma, a integrar um laboratório de formação e criação. Ao fim do dia, assinei o The Public Domain Manifesto e o dia pareceu alinhar-se perfeitamente.

Mais notícias em breve.

[divulgação] Oficina “Design para uma Redacção Livre”, no JUP

O Hacklaviva organiza no JUP uma oficina dedicada às ferramentas informáticas (FLOSS) necessárias para construir uma “redacção livre”, projecto em curso no JUP. É no próximo sábado, dia 23 de Janeiro, numa tarde cheia de actividades à volta do info-activismo (e que coincide com inaugurações nas galerias da Rua Miguel Bombarda), cujo programa completo pode ser consultado aqui.

Mas, do programa, destaco, por me interessar particularmente, esta Oficina de Design para uma Redacção Livre.

23 jan 2010 | 14h30 – 17h30
Oficina de Design para uma Redacção Livre

Uma redacção a funcionar apenas com software livre? É o objectivo de uma colaboração entre o JUP e o Hacklaviva. Nesta oficina, vamos falar sobre o que é o software livre e as suas implicações na prática criativa, associativa e editorial. Depois veremos como hoje é possível tratar fotografia, criar gráficos e tipografia, paginar, editar áudio e montar vídeo com ferramentas livres. Traz o teu portátil e vem passar uma tarde connosco a descobrir novas formas de fazer o teu trabalho.

A informação chegou-me por via do Ricardo Lafuente, que é uma das pessoas que vai orientar esta oficina. As ferramentas-base da oficina serão:

  • Imagem: GIMP, Scribus e Inkscape (3 que fazem parte do meu workflow actual)
  • Áudio: Audacity (ferramenta muito útil)
  • Vídeo: Kaltura, OpenShot e (talvez) PiTiVi (esta é a área que é toda nova para mim e tenho que verificar se se conseguem instalar algumas destas ferramentas num Mac)

Segundo o Ricardo, “a ideia é mais um overview do que tutoriais; podemos tocar em partes específicas de acordo com as vontades colectivas, mas seria mais uma cena de esclarecimento, já que boa parte do pessoal que vai aparecer não tem noção do que existe no mundo do FLOSS…

Até onde pode ir o Software Livre no Estado Português?

É uma óptima pergunta, não é?

O site Software Livre na AP procura ser parte da resposta:

Este local é um repositório de conhecimento em software livre (Open Source Software – OSS) das entidades do Estado Português e destina-se a ser um ponto de encontro e troca de experiências entre todos aqueles que, ao serviço do Estado, o utilizam. Deste contributo resulta uma mais-valia incalculável para quem pretende vir a utilizá-lo.

Associação Ensino LivreMas a navegação pelos incipientes exemplos de boas práticas dá-nos uma visão deprimente, ainda que realista, do panorama. Uma das áreas fulcrais (porque tem grandes impactos a prazo) é a Educação, e é por isso que a recém-criada Associação Ensino Livre pode vir a ter uma grande importância na definição duma dinâmica diferente.

É que a resposta à pergunta que serve de título a este artigo está na educação. É nas escolas, em todos os graus de ensino, que se podem inverter práticas perversas, criar novos hábitos, difundir novas posturas éticas.

Pessoalmente (e localmente), não posso deixar de lamentar o afastamento que a Universidade de Aveiro, que tanto se orgulha do seu papel pioneiro em tantas áreas, mantém, relativamente ao Software Livre. E não posso deixar de me interrogar, por causa do peso que a UA tem na dinâmica “local”, como seriam as coisas na autarquia, por exemplo, se o “contexto” fosse mais favorável à adopção destas soluções.

Mas quais serão os factores que determinam o grau de penetração do Software Livre nas diferentes áreas da Administração Pública portuguesa (nas autarquias, por exemplo)?

  • Opções políticas?
  • Dimensão e complexidade dos sistemas implementados?
  • Grau e antiguidade da informatização dos serviços?
  • Dependências económicas?
  • Competência do apoio técnico disponível?
  • Proximidade de prestadores de serviços/soluções diversificados?

A resposta será sempre multifacetada e há algumas partes da resposta mais defensáveis (e confessáveis) do que outras, como é óbvio. Mas era importante que se reflectisse publicamente sobre isto, porque esta é uma questão pública, por mais que se tente disfarçar.

Para esta reflexão, todas as contribuições são bem vindas.

Toca a facturar: Gardénia foi a escolha acertada

Pedi sugestões para software de facturação e recebi várias. Gostava de ter tido tempo para fazer testes reais a mais do que uma, mas acabei por usar um conjunto de critérios básicos para seriar as soluções e como os testes da primeira escolha correram bem, a partir de amanhã estarei a “facturar” com o Gardénia Desktop Edition, da Gotham.

As soluções “candidatas” à escolha eram inicialmente três— Evaristo / MP-Biz, Gardénia e Projecto Colibri—, mas vi-me forçado a excluireste último, porque ainda não faz exportação para SAFT-PT na versão Mac e isso é um imperativo legal. Em boa verdade, o facto de não ser open-source também não ajudava, mas foi o SAFT o critério decisivo.

Assim, dei por mim a olhar para as duas opções open-source e verdadeiramente multi-plataforma, muito semelhantes entre si e decidi testar o Gardénia Desktop Edition pela razão mais óbvia de todas: preguiça! Enquanto todas as outras ferramentas obrigam a instalação de PostGreSQL, o Gardénia Desktop Edition funciona com um único instalador e isso, considerando o uso que o software vai ter, é uma grande vantagem. Ainda assim, esperava mais dificuldades, uma vez que não há um manual e que a exportação para SAFT-PT, por exemplo, depende de um script autónomo. E, genericamente, estou habituado a que este tipo de ferramentas não seja de instalação ou manuseamento básico em Mac OS. Mas tive uma agradável surpresa: o fórum de suporte tinha a resposta a todas a minhas questões, a instalação decorreu sem problemas de maior, assim como a configuração dos parâmetros fundamentais e do script para exportação SAFT-PT.

Tive apenas que alterar um ou dois parâmetros em ficheiros de configuração, como indicado no fórum (um por causa do UTF-8, outro por causa da configuração do script do SAFT). E criei 2 scripts simplórios, um para lançar a aplicação, outro o SAFT Export Utility, sem ter que ir ao Terminal (e aprendi a executar shells em AppleScript, que é básico mas acho que nunca tinha precisado).

Continuo a olhar para qualquer aplicação de facturação como um boi para um palácio, mas agora o problema é não perceber nada de contabilidade. Mas fiz os testes de que precisava, confirmei com a contabilista que nos vai dar uma ajuda e está tudo nos conformes. Toca a facturar!

Se alguém quiser fazer perguntas acerca do processo de instalação e/ou configuração, eu posso tentar responder (para Mac OS X 10.4.11), mas ficam muito bem servidos no fórum de suporte. E se quiserem saber mais acerca do Gardénia, podem ter interesse em ver esta apresentação em PDF.

E se tiverem observações pertinentes a fazer, agradeço, também. Só dispenso mesmo maldições e votos de infortúnio. ;)

Precisa dum inquérito online? LimeSurvey, sem dúvida!

 

LimeSurvey: uma aplicação open-source para a construção de questionários on-line extraordinária

Não é propriamente uma necessidade quotidiana, mas já por várias vezes fui abordado para dar conselhos ou apoiar a construção de vários tipos de inquéritos ou questionários on-line e, pela quantidade de vezes que sou solicitado para responder a alguns, parece-me que são ferramentas para levar a sério.

Entre outras coisas, porque um questionário online bem construído pode ser uma poderosa ferramenta de análise de mercado, uma boa base para um estudo de opinião ou um simples indicador estatístico, com uma população alvo vasta e custos de implementação substancialmente reduzidos.

Ser bem construído significa, por exemplo, ter possibilidades de gerar convites, validar respostas, permitir interrupções no preenchimento guardando o que já se fez, criar percursos condicionais, ordenar aleatoriamente hipóteses de resposta-múltipla para evitar distorções, exportar os dados em formatos fáceis de analisar em ferramentas específicas de estatística… e muitas coisas mais que vou aprendendo à medida que acompanho o trabalho de quem pensa nestes assuntos.

O meu companheiro nestes contextos é o LimeSurvey que não cansa de me surpreender por ser tão completo, tão bem pensado e implementado, tão equilibrado em termos de facilidade de utilização e flexibilidade. De tal forma parece ter tudo, estar preparado para tudo e permitir tudo que hoje perdemos algum tempo por presumirmos que teria uma função que, de facto, não tem: gerar ou seleccionar perguntas aleatoriamente de um conjunto pré-determinado. Pelo menos, não duma forma que permita guardar simultaneamente a pergunta e a resposta.
Para que tipo de questionário é que isso é útil seria difícil de explicar, neste momento, mas a verdade é que, sendo uma funcionalidade que eles reconhecem que poderá vir a ser implementada no futuro, para já, não existe.
E, provavelmente, não existe out-of-the-box na esmagadora maioria das aplicações do género, mas confiava de tal forma na aplicação que presumi que seriam favas contadas.

Ainda assim, a verdade é que, depois de perceber e aceitar que a solução mais elegante não estava disponível, encontrei um “dispositivo” que serve os propósitos do inquérito, não estraga nada e permite recolher a informação tal e qual se pretendia: um grupo de perguntas de controlo, com elementos aleatórios gerados por JavaScript e condições resultantes dessas respostas a determinar o passo seguinte, acrescenta uns cliques, mas resolve o problema.

Depois de “dobrar este cabo”, não tenho receio nenhum em recomendar vivamente o LimeSurvey a quem quer que precise de criar e/ou manter um questionário on-line para as mais variadas funções. Aliás, era óptimo se muitos questionários que recebo na caixa de correio fossem feitos por recurso a uma ferramenta deste tipo: as vantagens para quem responde são tão grandes como as para quem desenvolve.

Para mim, é um achado!

Desambiguação: Software Livre / Open Source

Presumo que para muitas pessoas que tentaram acompanhar os comentários a este artigo recente sobre Open Source terão ficado baralhadas pela utilização dos termos Software Livre e Open Source. Eu próprio sou parte dessa confusão porque tenho ainda alguma dificuldade em compreender os contextos em que uma e outra designação se aplicam.

Para ajudar à definição de Software Livre / Free Software e a sua relação com o Movimento Open Source, este artigo do Georg C. F. Greve, traduzido pelo Rui Miguel Seabra no site da ANSOL pode ser útil.

Mas para se perceber que a confusão não é só minha e como forma de perguntar ao “vasto auditório” se estão de acordo com esta visão da FSF e da ANSOL de que

O movimento “Open Source” tem por objectivo ser um programa de marketing do Software Livre. Esse objectivo deliberadamente ignora todos os aspectos filosóficos ou políticos; estes aspectos são considerados prejudiciais à comercialização.

Por outro lado, o movimento Software Livre considera o ambiente filosófico/ético e político como uma parte essencial do movimento e um dos seus pilares fundamentais.

pergunto se as possibilidade de extrapolação do conceito e do termo Open Source, para outras áreas disciplinares, não terão algum interesse.

Não podemos falar da aplicação dos princípios defendidos pelo movimento Open Source em várias áreas vitais? Não será possível agrupar vários esforços “libertários” no que à informação e tecnologia diz respeito debaixo destes princípios, depois duma qualquer generalização? Isso fere os princípios do Software Livre? Ou expande-os?

Estou, muito sinceramente, a pensar alto e a tentar esclarecer-me com a vossa ajuda (possivelmente), sobre as implicações de se confundir processos e procedimentos de desenvolvimento e distribuição de código informático, com princípios éticos e filosóficos. Os últimos são a base dos primeiros e são generalizáveis. Mas esses, como os vou encontrando por aí, ora me iludem, ora simplemsente me confundem e baralham.

A desambiguação da responsabilidade da ANSOL vale como esclarecimento para a futura utilização dos termos neste blog, no contexto do software.

Mas, sinceramente, não estou completamente esclarecido.

Aceitam-se sugestões para software de facturação

Por razões que até a mim me ultrapassam, vou precisar de arranjar um software de facturação. Aceitam-se sugestões dentro dos seguintes parâmetros:

  • emissão de facturas de acordo com a legislação em vigor (incluindo suporte de exportação em SAFT-PT)
  • módulos adicionais de apoio contabilístico e financeiro são extras
  • mais barato do que os livros impressos nas tipografias aqui do burgo (à volta de 60 euros para 2 livros de facturas A5 a 1 cor e 4 vias)
  • preferencialmente open source
  • multiplataforma (Mac / Windows / Linux / …)
  • … lembram-se de mais alguma coisa?

Estou a ponderar fazer um test-drive ao Evaristo, que tem um belo nome. Se tiverem experiência com esta solução ou soluções parecidas (aplicação Java com base de dados em PostgreSQL), avisem.

Open Source: ideia ou doutrina?

É-me difícil deixar de pensar na questão do Open Source, principalmente depois de episódios como este, em termos globais ou conceptuais, tentando perceber as diferentes abordagens possíveis ao fenómeno e tentando compreender ou descobrir a minha real relação com o fenómeno. De certa forma, dou por mim  a pensar que os puritanos de que falava, se calhar, têm razão e, na verdade, eu não apoio o Software Livre.

De facto, pensando nisso com algum cuidado e profundidade, do ponto de vista filosófico, quase, não me seria possível apoiar o Software Livre da mesma forma que um programador o faz, porque o significado desse apoio é fundamentalmente diferente. Basicamente, tudo se resume a uma ideia de liberdade e aos processos e ferramentas necessárias ao exercício dessa liberdade. Para um programador, de facto, o acesso ao código é condição de liberdade, mas, por muita retórica que se use, esse acesso não se traduz num exercício de liberdade para os restante utilizadores do código. Para os utilizadores, poderá ser útil e conceptualmente positivo, como eu acho que é, estar dependente duma comunidade activa e eticamente saudável de programadores, em vez de estar nas mãos duma corporação centrada no lucro, mas o acesso ao código não é condição de liberdade desses utilizadores. Esse “exercício de liberdade” é restrito e, no fundo, estabelece uma outra forma de tecnocracia.

É por isso que a mim me parece que defender e apoiar um ideia de Open Source, consiste em compreender quais as fontes de conteúdo que permitem o exercício real de liberdade a todos. E isso, nem sempre resulta da adopção ou na adopção de soluções de Software Livre. A liberdade no acesso e manipulação de conteúdos como música, imagem, vídeo ou texto é um problema igualmente importante quando se fala de liberdade. Mas é um problema que diz respeito a questões de direitos de autor, propriedade intelectual, formatos de distribuição, etc… Filosoficamente falando, as ligações entre o Software Livre e a luta contra os DRM são evidentes não são? Mas haveria música em formatos digitais (com ou sem DRM) se os músicos e os estúdios estivessem dependentes de Software Livre? Não.

Por isso, e para esclarecer eventuais dúvidas, assumo: não sou apoiante do Software Livre como tal, de forma absoluta, já que a liberdade contida no código aberto é, para mim, uma abstracção de liberdade que, na esmagadora maioria dos casos, não posso exercer. Sou favorável à dependência de comunidades de programadores empenhados, em vez de corporações gananciosas, mas não presumo que essas comunidades, por mais bem-intencionadas que sejam percebam todas as minhas necessidades. Não sinto por isso, na adopção de ferramentas com código proprietário, uma  limitação da minha liberdade. A minha liberdade passa por outras lutas, muito mais centradas na forma de distribuição de conteúdos e nos modelos de propriedade intelectual, com protecção dos autores, mas liberdade para a utilização e derivação.

Sinto muito.