Autonomía digital y tecnológica

Código e ideas para una internet distribuida

Linkoteca. comunidades de código abierto


The tricky bit, as a new study called An Empirical Study of C++ Vulnerabilities in Crowd-Sourced Code Examples, is working out which code is OK and which isn’t.

After analysing real code from Stack Overflow, the researchers found a small but still significant number of examples where this happened over a 10-year period to 2018.

The team reviewed 72,483 C++ code snippets for weaknesses defined by the industry Common Weakness Enumeration (CWE) guidelines, finding 69 representing 29 different types of security flaw, most often CWE-150 (‘Improper neutralization of space, meta, or control sequence’).

I’d be fascinated to see a study that compared cutting and pasting code – which carries the small risk of copying and pasting security errors – with coders who don’t copy and paste code and solve unfamiliar problems by always writing their own solution.

Solving the problem yourself carries three possible penalties: #1 it will take longer; #2 there is a good chance that the code (which solves a problem the developer is not well versed in solving) will make it in to the world without ever being reviewed by another person; and #3 if it does go unreviewed, there is a good chance the developer will never learn of their mistake and could well end up repeating it, even cutting and pasting it, into other projects.

Contributing to open source for the first time can be scary and a little overwhelming. Perhaps you’re a Code Newbie or maybe you’ve been coding for a while but haven’t found a project you felt comfortable contributing to.

Kent C. Dodds proposed First Timers Only to get new people to make their first contribution. Scott Hanselman blogged about Bringing Kindness Back to Open Source, so it was obvious that we team up and promote these ideas and get more folks involved in open source.

Decisions not Options

When making decisions, these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option, this ultimately leads to frustration. As developers, we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions, and avoid putting the weight of technical choices on our end users.

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.