Autonomía digital y tecnológica

Código e ideas para una internet distribuida

Linkoteca. comunidades de código abierto


Open Source projects would benefit from this level of transparency and that giving credit directly into the commit message makes it very transferable.

With this level of transparency, we can start to study how our ecosystem actually works; we can see which companies contribute back code and how much, we can see how much of the Drupal project is volunteer driven, we can better identify potential conflicts of interest, and more. But most of all, we can provide credit where credit is due and provide meaningful incentives for organizations to contribute back to Drupal. I believe this could provide a really important step in making Drupal core development more scalable.

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.

En informática, bus Factor o (Factor Autobús) es un término usado en proyectos de desarrollo de software, que alude a una gran cantidad de información vital de un proyecto de software limitada solamente a uno o unos pocos desarrolladores, impidiendo la continuación del proyecto en el hipotético caso de que estos desarrolladores clave sean atropellados por un autobús.

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.