Pillku es una revista digital sobre cultura libre y bienes comunes. Entre 2011 y 2017 ha generado un total de 22 números con temáticas diversas. En el año 2018 se ha materializado en forma de libro impreso la publicación: Pillku: Antología de un proceso colaborativo. En 2019 y 2020 seguimos distribuyendo el libro y compartiendo la experiencia.
Just 7.7% of devs are unpaid.
As its importance has grown, development of Linux has steadily shifted from unpaid volunteers to professional developers. The 25th anniversary version of the Linux Kernel Development Report, released by the Linux Foundation today, notes that «the volume of contributions from unpaid developers has been in slow decline for many years. It was 14.6 percent in the 2012 version of this paper, 13.6 percent in 2013, and 11.8 percent in 2014; over the period covered by this report, it has fallen to 7.7 percent. There are many possible reasons for this decline, but, arguably, the most plausible of those is quite simple: Kernel developers are in short supply, so anybody who demonstrates an ability to get code into the mainline tends not to have trouble finding job offers.»
One of the interesting things about the Linux kernel is that the vast majority of people who contribute to it are employed by companies to do this work; however, most of the academic research on open source software assumes that participants are volunteers, contributing because of some personal need or altruistic motivation. Although this is true for some projects, this assumption just isn’t valid for projects like the Linux kernel.
Many kernel developers also collaborate with their competitors on a regular basis, where they interact with each other as individuals without focusing on the fact that their employers compete with each other.
Contrary to open-source folklore, it is mostly paid developers who are building the Linux kernel.
Kernel development follows a time-based release model with a new release occurring every two to three months. This is designed to help speed the development for all Linux distributions so that each one doesn’t need to make kernel-specific updates or changes. More than 6,100 individual developers from more 600 different companies have contributed to the kernel since 2005, according the report.
This blog post talks about how we can make it easier to scale and sustain Open Source projects, Open Source companies and Open Source ecosystems.
How do you get others to contribute? How do you get funding for Open Source work? But also, how do you protect against others monetizing your Open Source work without contributing back? And what do you think of MongoDB, Cockroach Labs or Elastic changing their license away from Open Source?
Top of mind is the need for Open Source projects to become more diverse and inclusive of underrepresented groups.
The difference between Makers and Takers is not always 100% clear, but as a rule of thumb, Makers directly invest in growing both their business and the Open Source project. Takers are solely focused on growing their business and let others take care of the Open Source project they rely on.
Organizations can be both Takers and Makers at the same time. For example, Acquia, my company, is a Maker of Drupal, but a Taker of Varnish Cache. We use Varnish Cache extensively but we don’t contribute to its development.
I’ve long believed that Open Source projects are public goods: everyone can use Open Source software (non-excludable) and someone using an Open Source project doesn’t prevent someone else from using it (non-rivalrous).
However, through the lens of Open Source companies, Open Source projects are also common goods; everyone can use Open Source software (non-excludable), but when an Open Source end user becomes a customer of Company A, that same end user is unlikely to become a customer of Company B (rivalrous).
Interestingly, all successfully managed commons studied by Ostrom switched at some point from open access to closed access.
the shared resource must be made exclusive (to some degree) in order to incentivize members to manage it. Put differently, Takers will be Takers until they have an incentive to become Makers.
Once access is closed, explicit rules need to be established to determine how resources are shared, who is responsible for maintenance, and how self-serving behaviors are suppressed. In all successfully managed commons, the regulations specify (1) who has access to the resource, (2) how the resource is shared, (3) how maintenance responsibilities are shared, (4) who inspects that rules are followed, (5) what fines are levied against anyone who breaks the rules, (6) how conflicts are resolved and (7) a process for collectively evolving these rules.
Mozilla has the exclusive right to use the Firefox trademark and to set up paid search deals with search engines like Google, Yandex and Baidu. In 2017 alone, Mozilla made $542 million from searches conducted using Firefox. As a result, Mozilla can make continued engineering investments in Firefox. Millions of people and organizations benefit from that every day.
One way to implement this is Drupal’s credit system. Drupal’s non-profit organization, the Drupal Association monitors who contributes what. Each contribution earns you credits and the credits are used to provide visibility to Makers. The more you contribute, the more visibility you get on Drupal.org (visited by 2 million people each month) or at Drupal conferences (called DrupalCons, visited by thousands of people each year).
It can be difficult to understand the consequences of our own actions within Open Source. Open Source communities should help others understand where contribution is needed, what the impact of not contributing is, and why certain behaviors are not fair. Some organizations will resist unfair outcomes and behave more cooperatively if they understand the impact of their behaviors and the fairness of certain outcomes.
look at what MariaDB did with their Business Source License (BSL). The BSL gives users complete access to the source code so users can modify, distribute and enhance it. Only when you use more than x of the software do you have to pay for a license. Furthermore, the BSL guarantees that the software becomes Open Source over time; after y years, the license automatically converts from BSL to General Public License (GPL), for example.
Un commun = des personnes ayant accès à une ressource qui créent collectivement des règles pour produire et préserver des ressources.
Pas seulement la ressource, aussi les relations sociales autour de cette ressource
Faisceau de droits (usage, glanage,…) VS droit exclusif de propriété
Collectif = micro-institution (E. Ostrom dans la lignée de certains économistes institutionnels)
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.
Just a few hours after the 7.0 magnitude earthquake hit Haiti in January 2010, a group of collaborators from the OpenStreetMap community began collecting all sorts of topographical data about the country – roads, towns, hospitals, government buildings. Within forty-eight hours high-resolution satellite imagery taken after the earthquake became available, and within a month over 600 people had added information to OpenStreetMap of Haiti.
This online map quickly became the default basemap for a wide variety of responders – search and rescue teams, the United Nations, the World Bank, and humanitarian mapping organizations such as MapAction.
Why is software created using taxpayers’ money not released as Free Software?
We want legislation requiring that publicly financed software developed for the public sector be made publicly available under a Free and Open Source Software licence. If it is public money, it should be public code as well.
Code paid by the people should be available to the people!
Debemos ser capaces de soñar y pensar en términos que no estén definidos por Silicon Valley. Para mí, en este punto, las empresas de tecnología son como las cadenas de comida rápida, las casas de apuestas o los casinos: crean y manufacturan una adicción que luego tiene unas consecuencias. En el caso de las tecnológicas, la distracción.
yo construiría una alternativa a Facebook con dinero público en vez de aceptar que la única manera de organizar las comunicaciones es a través de esta firma.
Estamos en una era en que los datos son algo en torno a lo que emergen nuevos modelos de negocio y nuevas formas de explotación.
Google quiere ser el nuevo Estado del bienestar y el nuevo partido político.
could the founder step away from the project and the project keep going?
«The package system was not designed to manage software. It was designed to facilitate collaboration.»
Debian as an autonomous community of developers and as a commons.
