Autonomía digital y tecnológica

Código e ideas para una internet distribuida

Linkoteca. software libre


…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.