Autonomía digital y tecnológica

Código e ideas para una internet distribuida

Linkoteca. software libre


Pese a tanta recomendación y que sea software libre, cuando pides el código fuente de esta plataforma, la respuesta de red.es argumenta que su liberación podría ocasionar un perjuicio para su poseedores (red.es como reconocen en la resolución) y se acogen a esta cláusula de la ley de transparencia acceso a la información y buen gobierno para denegarlo. (Pese a que dicen que conceden parcialmente, la realidad es que no conceden nada)

El ciberataque al Ayuntamiento de Jerez ha dejado sin prácticamente ningún servicio informático a todo el ayuntamiento, sin embargo, posiblemente el único servidor importante con GNU/Linux en el Ayuntamiento de Jerez sigue funcionando, permitiendo que los distintos departamentos al menos no estén incomunicados.

… para la industria algorítmica, el software libre supone la incorporación de medios de producción a coste cero. Capital gratis. No es de extrañar que empresas como Facebook, Google o Microsoft hayan apostado tan decididamente por desarrollar y compartir código abierto. Todas comparten la misma mesa, ríen en el festín de la ganancia y brindan a la salud del trabajo gratuito. Irónicamente, mediante su implicación en el software libre, esas empresas mejoran su imagen de marca ante un proletariado tecnológico tan bienintencionado como desprovisto de las herramientas necesarias para decodificar las reglas del juego del que forman parte.

El software libre ha acabado siendo funcional al capitalismo. Hay aplicaciones que resultan útiles hasta cierto punto y que, también hasta cierto punto, han logrado introducirse en circuitos no mercantilistas. Son generalmente aplicaciones de uso final; sistemas operativos, navegadores, gestores de correo, editores de texto o reproductores multimedia al alcance de cualquiera que disponga de una conexión a Internet. Pero estas aplicaciones son, en general, poco útiles para transformar las condiciones materiales de la gente por sí mismas, si no es para legitimar los esquemas liberales de facilitar la “igualdad de oportunidades” en la competición global. Gran parte de los estratos más necesitados ni siquiera dispone de los recursos para obtener hardware o de la alfabetización digital suficiente para extraer un beneficio de esas ofrendas.

… el caudal del software libre se bifurca; por una parte, una pequeña corriente de software desarrollado por los estratos acomodados y destinado a sí mismos. Por otra, un río amazónico de grandes meandros que desemboca generosamente en el mar de la reproducción del capital.

Sin menoscabo de los esfuerzos realizados hasta hoy por el activismo del software libre, es hora de pensar en un software privativo de clase; en un software militante.

Historical note: Until 2010 there was only one suite, OpenOffice.org (OOo) developed by Sun. When Oracle bought Sun and threatened the existence of the office suite, a community fork was created called LibreOffice. Most of the existing OOo developers jumped ship to LibreOffice, considering it the true continuation of OOo instead of Oracle OpenOffice, which was later donated to the Apache Foundation, becoming Apache OpenOffice.

LibreOffice can reuse code from OpenOffice, while the opposite can’t happen. This means that all improvements made in OpenOffice are available in LibreOffice but improvements made in LibreOffice are not available in OpenOffice.

LibreOffice has much more contributions than OpenOffice. LibreOffice commit log, OpenOffice commit log. LibreOffice is also developed by developers from a large number of commercial companies, such as Red Hat, Collabora, Canonical etc. (adding security to the project, because if one company stops development, others will continue support). OpenOffice has only a meager number of IBM developers (I’m not sure if they still continue contributing).

…the original author of any FOSS package or application, by publishing it, would have to accept as fact that any misuse of said software would forever be their responsibility, or at least until that responsibility is, diligently and ceremoniously, transferred to someone else, hot potato style.

FOSS was never about trust in software owners.

It was about not needing to trust them to begin with.

You want to download thousands of lines of useful, but random, code from the internet, for free, run it in a production web server, or worse, your user’s machine, trust it with your paying users’ data and reap that sweet dough. We all do. But then you can’t be bothered to check the license, understand the software you are running and still want to blame the people who make your business a possibility when mistakes happen, while giving them nothing for it? This is both incompetence and entitlement.

Plus how is this any different from using proprietary software? If you’re not going to take full advantage of FOSS, maybe you’re better off spending your money on support contracts anyway. At least then, you are entitled to complain until you’re blue in the mouth. Maybe you can even take someone to court!

We must make software simpler. Much much simpler. And companies who base their service offering on open source software must become more involved in keeping this ecosystem alive in whichever capacity they can.

Software must be made understandable. The essence of FOSS for me can be reduced to one fundamental computing right: the right to refuse to run, on my machines, code that I do not have the option to understand. That is it.

I’m not fundamentally opposed to closed source software, so as long as it runs on someone else’s computer.

However, as we’ve seen, having the source code is not enough to guarantee understandability.

It’s easier for a successful volunteer Free Software project to get money than it is to decide how to spend it. While paying developers is easy, it can carry unintended negative consequences. This essay explores problems and benefits of paying developers in volunteer free and open source projects and surveys strategies that projects have used to successfully finance development while maintaining their volunteer nature.

Barcelona city administration has prepared the roadmap to migrate its existing system from Microsoft and proprietary software to Linux and Open Source software.

The City has plans for 70% of its software budget to be invested in open source software in the coming year. The transition period, according to Francesca Bria (Commissioner of Technology and Digital Innovation at the City Council) will be completed before the mandate of the present administrators come to an end in Spring 2019.

For this to be accomplished, the City of Barcelona will start outsourcing IT projects to local small and medium sized enterprises.

The move from Windows to Open Source software according to Bria promotes reuse in the sense that the programs that are developed could be deployed to other municipalities in Spain or elsewhere around the world. Obviously, the migration also aims at avoiding large amounts of money to be spent on proprietary software.

Let’s be clear up front about something: Just being on GitHub in a public repo does not make your code open source. Copyright in nearly all countries attaches automatically when a work is fixed in a medium, without need for any action by the author. For any code that has not been licensed by the author, it is only the author who can exercise the rights associated with copyright ownership. Unlicensed code—no matter how publicly accessible—is a ticking time bomb for anyone who is unwise enough to use it.

Unlicensed code is unsafe code, period.

When you write open source code, you know that it not only has to work, it has to work in situations you never dreamed of and may not have planned for. Maybe you only had one very narrow use case for your code and invoked it in exactly the same way every time.

The true heart of open source isn’t the code at all: it’s the community.

announce that you’re thinking of creating a new project. Talk about your design goals and how you plan to achieve them. Request input, listen to similar (but maybe not identical) use cases, and build that information into your process as you write code.

This process doesn’t end with the initial announcement. If you want your project to be adopted and used by other people, you need to develop it that way too. This isn’t a barrier to entry; it’s just a pattern to use.

Open source work sharpens your skills in ways you never realized were dull—from writing cleaner, more maintainable code to learning how to communicate well and work as a team.