Discusión de Criterios

No existe un conjunto de prácticas que pueda garantizar que el software nunca tendrá defectos o vulnerabilidades. Incluso los métodos formales pueden fallar si las especificaciones o suposiciones son incorrectas. Tampoco existe un conjunto de prácticas que pueda garantizar que un proyecto mantendrá una comunidad de desarrollo saludable y que funcione bien.

Sin embargo, seguir las mejores prácticas puede ayudar a mejorar los resultados de los proyectos. Por ejemplo, algunas prácticas permiten la revisión de múltiples personas antes de la publicación, lo que puede ayudar a encontrar vulnerabilidades técnicas que de otro modo serían difíciles de encontrar y ayudar a construir confianza y un deseo de interacción repetida entre desarrolladores de diferentes organizaciones.

Esta página discute el conjunto de mejores prácticas para proyectos de Software Libre y de Código Abierto (FLOSS) desarrollado para la insignia de Mejores Prácticas de la Open Source Security Foundation (OpenSSF). Los proyectos que sigan estas mejores prácticas podrán autocertificarse voluntariamente y mostrar que han logrado la insignia relevante. Los proyectos pueden hacer esto, sin costo alguno, utilizando una aplicación web (BadgeApp) para explicar cómo cumplen con estas prácticas y sus criterios detallados.

Estas mejores prácticas se han creado para:

animar a los proyectos a seguir las mejores prácticas,
ayudar a nuevos proyectos a descubrir cuáles son esas prácticas, y
ayudar a los usuarios a saber qué proyectos están siguiendo las mejores prácticas (para que los usuarios puedan preferir tales proyectos).

El modismo "mejores prácticas" significa "un procedimiento o conjunto de procedimientos que es preferido o considerado estándar dentro de una organización, industria, etc." (fuente: Dictionary.com). Estos criterios son lo que creemos que son ampliamente "preferidos o considerados estándar" en la comunidad FLOSS más amplia.

Para más información sobre cómo se desarrollaron estos criterios, vea el sitio GitHub de la insignia de Mejores Prácticas de OpenSSF.

También puede ver los criterios completos.

Estructura de los Criterios

Los criterios de mejores prácticas se dividen en tres niveles:

Aprobado se enfoca en las mejores prácticas que los proyectos FLOSS bien ejecutados generalmente ya siguen. Obtener la insignia de aprobado es un logro; en cualquier momento dado, solo alrededor del 10% de los proyectos que buscan una insignia alcanzan el nivel de aprobado.
Plata es un conjunto de criterios más estricto que el de aprobado, pero se espera que sea alcanzable por proyectos pequeños y de una sola organización.
Oro es aún más estricto que plata e incluye criterios que no son alcanzables por proyectos pequeños o de una sola organización.

Cada criterio tiene un nombre corto, mostrado como texto en superíndice dentro de corchetes después del texto de los criterios.

Relación con Otros Proyectos

La Linux Foundation también patrocina el Proyecto OpenChain, que identifica criterios para un "programa de cumplimiento de Software Libre y de Código Abierto (FOSS) de alta calidad". OpenChain se enfoca en cómo las organizaciones pueden utilizar mejor FLOSS y contribuir de vuelta a los proyectos FLOSS, mientras que la insignia de Mejores Prácticas de OpenSSF se enfoca en los proyectos FLOSS en sí mismos. La insignia de Mejores Prácticas de OpenSSF y OpenChain trabajan juntos para ayudar a mejorar FLOSS y cómo se utiliza FLOSS.

Automatización de Criterios

En algunos casos probamos y completamos automáticamente la información si el proyecto sigue las convenciones estándar y está alojado en un sitio (por ejemplo, GitHub) con un soporte de API decente.

Tenemos la intención de mejorar esta automatización en el futuro. ¡Las mejoras a la automatización son bienvenidas!

Sin embargo, hemos priorizado intencionalmente lo "que es importante", incluso si no puede automatizarse de manera asequible. Nos encantan las mediciones automatizadas, pero no todo lo importante es automatizable o puede automatizarse de manera asequible.

Cambios a lo largo del tiempo

Esperamos que estas prácticas y sus criterios detallados se actualicen con el tiempo. Planeamos agregar nuevos criterios pero marcarlos como criterios "futuros", para que los proyectos puedan agregar esa información y mantener su insignia.

Los comentarios son muy bienvenidos a través del sitio de GitHub como issues o pull requests. También hay una lista de correo para discusión general.

Palabras clave

Las palabras clave "DEBE", "NO DEBE", "DEBERÍA", "NO DEBERÍA", y "PUEDE" en este documento deben interpretarse como se describe en RFC 2119. Se añade el término adicional SUGERIDO. En resumen, estas palabras clave tienen los siguientes significados:

El término DEBE es un requisito absoluto, y NO DEBE es una prohibición absoluta.
El término DEBERÍA indica un criterio que normalmente es requerido, pero puede haber razones válidas en circunstancias particulares para ignorarlo. Sin embargo, las implicaciones completas deben entenderse y sopesarse cuidadosamente antes de elegir un curso diferente.
El término SUGERIDO se usa en lugar de DEBERÍA cuando el criterio debe considerarse, pero las razones válidas para no hacerlo son aún más comunes que para DEBERÍA.
El término PUEDE proporciona una forma en que algo puede hacerse, por ejemplo, para dejar claro que la implementación descrita es aceptable.

A menudo un criterio se establece como algo que DEBERÍA hacerse, o es SUGERIDO, porque puede ser difícil de implementar o los costos para hacerlo pueden ser altos.

Obtención de una insignia

Para obtener una insignia, se deben cumplir todos los criterios DEBE y NO DEBE, todos los criterios DEBERÍA deben cumplirse O no cumplirse con justificación, y todos los criterios SUGERIDOS deben considerarse (debe calificarse como cumplido o no cumplido, pero no se requiere justificación a menos que se indique lo contrario). Una respuesta de N/A ("no aplicable"), cuando se permite, se considera lo mismo que estar cumplido. En algunos casos, especialmente en los niveles superiores, puede requerirse justificación y/o una URL.

Algunos criterios tienen marcas especiales que influyen en esto:

{N/A permitido} - Se permite "N/A" ("No aplicable").
{Justificación N/A} - Se permite "N/A" ("No aplicable") y requiere justificación.
{Justificación cumplido} - "Cumplido" requiere justificación.
{URL cumplido} - "Cumplido" requiere justificación con una URL.
{Futuro} - la respuesta a este criterio actualmente no tiene efecto, pero puede ser requerida en el futuro.

Un proyecto debe alcanzar el nivel anterior para alcanzar el siguiente nivel. En algunos casos, los criterios DEBERÍA se convierten en DEBE en insignias de nivel superior, y algunos criterios SUGERIDOS en niveles inferiores se convierten en DEBERÍA o DEBE en insignias de nivel superior. Los niveles superiores también requieren más justificación, porque queremos que otros entiendan cómo se están cumpliendo los criterios.

Los (muchos) criterios criptográficos no siempre se aplican, porque algunos programas no tienen necesidad de usar directamente capacidades criptográficas. En esos casos, responda N/A.

Hay un criterio de aprobación implícito - cada proyecto DEBE tener un sitio web público con una URL estable. Esto es necesario para crear una entrada de insignia en primer lugar.

Terminología

Si no está familiarizado con el desarrollo de software o la ejecución de un proyecto FLOSS, materiales como Producing Open Source Software de Karl Fogel pueden serle útiles.

Aquí hay algunos términos clave:

Un proyecto es una entidad activa que tiene miembro(s) del proyecto y produce resultado(s) del proyecto. Sus miembro(s) usan sitios del proyecto para coordinar y difundir resultado(s). Un proyecto no necesita ser una entidad legal formal.
Los miembros del proyecto son el grupo de una o más personas o compañías que trabajan juntos para intentar producir resultados del proyecto. Algunos proyectos FLOSS pueden tener diferentes tipos de miembros, con diferentes roles, pero eso está fuera de nuestro alcance.
Los resultados del proyecto son lo que los miembros del proyecto trabajan juntos para producir como su objetivo final. Normalmente esto es software, pero los resultados del proyecto pueden incluir otras cosas también. Los criterios que se refieren a "software producido por el proyecto" se refieren a resultados del proyecto.
Los sitios del proyecto son los sitios dedicados a apoyar el desarrollo y la difusión de los resultados del proyecto, e incluyen el sitio web del proyecto, el repositorio y los sitios de descarga cuando corresponda (ver sites_https).
El sitio web del proyecto, también conocido como página de inicio del proyecto, es la página principal en la World Wide Web (WWW) que un nuevo usuario normalmente visitaría para ver información sobre el proyecto; puede ser el mismo que el sitio del repositorio del proyecto (esto es a menudo cierto en GitHub).
El repositorio del proyecto gestiona y almacena los resultados del proyecto y el historial de revisiones de los resultados del proyecto. Esto también se conoce como el repositorio fuente del proyecto, porque solo requerimos gestionar y almacenar las versiones editables, no los resultados generados automáticamente (en muchos casos los resultados generados no se almacenan en un repositorio).
Un mecanismo de seguridad del proyecto es un mecanismo de seguridad proporcionado por el software del proyecto entregado.

No-criterios

Los criterios:

no requieren ninguna tecnología, producto o servicio específico. Por ejemplo, no requieren git, GitHub o GitLab. Los criterios sí proporcionan orientación y ayuda para casos comunes, ya que esa información puede ayudar a las personas a entender y cumplir los criterios. Hay alguna automatización especial para proyectos que usan git o GitHub, para ayudar a los usuarios en esos casos comunes, pero no son requeridos. Por lo tanto, a medida que nuevas herramientas y capacidades estén disponibles, los proyectos pueden cambiar a ellas rápidamente. Como excepciones, los criterios sí requieren una página web del proyecto y TLS.
no requieren ni prohíben ningún lenguaje de programación en particular. Sí requieren que se tomen medidas adicionales para ciertos tipos de lenguajes de programación, pero eso es diferente.
nunca requieren el uso de software propietario, servicio propietario o una tecnología propietaria, ya que muchos desarrolladores de software libre rechazarían tales criterios. Los proyectos pueden usarlos y depender de ellos.
no requieren desarrollo activo o discusión de usuarios dentro de un proyecto. Algunos proyectos altamente maduros rara vez cambian y por lo tanto pueden tener poca actividad. Los criterios sí, sin embargo, requieren que el proyecto sea receptivo si se le reportan vulnerabilidades al proyecto.
no requieren tarifas para obtener una insignia.
no requieren que todos los criterios se implementen a la vez; la mayoría de los proyectos los implementan con el tiempo.

El nivel de aprobación no incluye criterios que serían imprácticos para un proyecto de una sola persona, por ejemplo, algo que requiera una cantidad significativa de dinero. Muchos proyectos FLOSS son pequeños, y no queremos privarlos de sus derechos.

Identificar un proyecto

Nuestra aplicación le da a cada entrada de proyecto un identificador único, pero eso no ayuda a las personas a buscar el proyecto. Para nuestros propósitos, el nombre real de un proyecto es la URL de su repositorio, y donde eso no esté disponible, la URL de la "página principal" del proyecto. Limitamos los cambios a la URL del repositorio para prevenir algunos absurdos. Los proyectos normalmente tienen un nombre legible para humanos, pero estos nombres no son lo suficientemente únicos.

¿Por qué tener criterios?

El documento Open badges for education: what are the implications at the intersection of open systems and badging? identifica tres razones generales para los sistemas de insignias (todas son válidas para esto):

Insignias como motivador de comportamiento. Esperamos que al identificar las mejores prácticas, alentaremos a los proyectos a implementar esas mejores prácticas si aún no las realizan.
Insignias como herramienta pedagógica. Algunos proyectos pueden no estar conscientes de algunas de las mejores prácticas aplicadas por otros, o de cómo pueden aplicarse prácticamente. La insignia les ayudará a conocerlas y las formas de implementarlas.
Insignias como un significador o credencial. Los usuarios potenciales quieren usar proyectos que están aplicando mejores prácticas para producir consistentemente buenos resultados; las insignias hacen que sea fácil para los proyectos indicar que están siguiendo las mejores prácticas, y hacen que sea fácil para los usuarios ver qué proyectos lo están haciendo.

¿Por qué auto-certificación?

Hemos elegido usar la auto-certificación, porque esto hace posible que un gran número de proyectos (incluso los pequeños) participen. Hay millones de proyectos FLOSS, y pagar a terceros para evaluar independientemente cada uno no escala. Existe el riesgo de que los proyectos hagan afirmaciones falsas, pero creemos que el riesgo es pequeño, los usuarios pueden verificar las afirmaciones por sí mismos, y las afirmaciones falsas pueden ser anuladas. También usamos automatización para anular afirmaciones falsas donde podemos estar seguros de los resultados.