Convocatoria para desarrolladores - Jellyfin

 (jellyfin.org)
2 puntos por GN⁺ 2023-10-04 | 1 comentarios | Compartir por WhatsApp
  • Jellyfin busca ampliar su base estancada de colaboradores con motivo del 10.º aniversario de Hacktoberfest en octubre de 2023 y acelerar las mejoras del servidor, la Web UI y los clientes
  • El proyecto mantiene un modelo de voluntariado semicomercial, y las donaciones solo se usan para costos de infraestructura y, en raras ocasiones, hardware cliente para desarrollo
  • Los colaboradores principales suman como máximo unas 30 personas entre el servidor, la Web UI y todos los clientes, y casi no han aumentado en los últimos 3 años, por lo que algunas apps son mantenidas por 1 o 2 personas en su tiempo libre
  • Las quejas de los usuarios se concentran en la falta de soporte de clientes y en la falta de pulido, e incluso funciones y clientes con alta demanda, como Chromecast, pasaron un tiempo sin impulso de desarrollo
  • Hace falta de todo: desde pequeñas correcciones de errores, mejoras de documentación, UI/UX y traducción, hasta desarrollo completo de clientes; quienes aporten contribuciones de calidad de forma constante también podrían unirse al equipo oficial

Por qué Jellyfin está buscando colaboradores ahora

  • Jellyfin ha tomado como una tarea importante atraer nuevos colaboradores con motivo del 10.º aniversario de Hacktoberfest de DigitalOcean
  • Cada vez que surge una polémica relacionada con Plex, Jellyfin aparece como alternativa, pero en la comunidad también se repiten las críticas sobre la falta de clientes, la ausencia de ciertas funciones y la falta de pulido
  • Para cerrar esa brecha, hace falta que más personas participen en mejorar el código, desarrollar nuevas funciones y poner al día la documentación

Limitaciones de un proyecto basado en voluntariado

  • Jellyfin se gestiona como un proyecto semicomercial poco común incluso dentro del FLOSS
    • Desarrolladores, traductores, administradores de comunidad y quienes ayudan a resolver problemas son todos voluntarios
    • Nadie recibe pago por trabajar en Jellyfin, y tampoco hay patrocinio de una empresa ni de una organización aparte
    • No hay planes de monetización, y también se evita activamente ofrecer bug bounties
  • Las donaciones solo se usan para costos de infraestructura y para hardware cliente de desarrollo que se compra rara vez cuando hace falta
    • No se usan donaciones para pagar a desarrolladores, y la postura es que tampoco se hará en el futuro
  • Esta decisión busca evitar el camino de otros proyectos de streaming multimedia que comenzaron como FLOSS, pero luego añadieron funciones hostiles para los usuarios por motivos de ingresos y pasaron a código cerrado

La carga de mantener un alcance amplio con un equipo pequeño

  • Actualmente, la base de colaboradores principales es de como máximo unas 30 personas entre el servidor, la Web UI y todos los clientes
    • En los últimos 3 años, el tamaño total casi no ha crecido
    • Algunas áreas, en especial ciertas apps individuales, son trabajadas por 1 o 2 personas gratis en su tiempo libre
  • Incluso funciones o clientes con mucha demanda pueden quedarse sin avances si no hay quien empiece el desarrollo o ayude
    • Chromecast tuvo que dejarse de lado durante un tiempo, pero en las últimas semanas volvió a haber movimiento

Cómo participar y la vía para unirse al equipo oficial

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-10-04
Opiniones en Hacker News

  • No sabía que Jellyfin estaba basado en C#.
    Empecé mi carrera como desarrollador C#, pero ahora solo uso C++, y llevaba tiempo buscando un proyecto para volver a usar C#.
    Tengo una lista de cosas que me incomodaban de Jellyfin, y ahora que sé que está en C#, me dan ganas de arreglarlas yo mismo.

    • Si hace tiempo que no usas C#, es muy probable que lo disfrutes bastante.
      El lenguaje avanzó mucho, y en particular mejoró la comodidad para desarrollar con cosas como pattern matching, la instrucción using y tipos básicos orientados al rendimiento.
      Empecé a usar C# de nuevo a tiempo completo desde principios de este año y estoy muy satisfecho.

  • Estaría bueno que el equipo de Jellyfin también muestre este pedido de participación en los lugares donde los usuarios piden funciones.
    En el caso del soporte para Chromecast, que es el ejemplo del post del blog, había preguntado en este issue cómo podía ayudar a implementar la función: https://github.com/jellyfin/Swiftfin/issues/271#issuecomment...
    Aunque en la práctica no hubiera habido nada en lo que pudiera contribuir productivamente para esa función, si hubiera existido una guía para empezar, sin duda la habría revisado.
    Si enlazan rápidamente el post del blog y los materiales de inicio en los issues donde la gente pregunta cómo ayudar, creo que la conversión podría ser bastante buena.
    Gracias a todos los que contribuyen a Jellyfin, y sé que el onboarding de desarrolladores a menudo termina siendo un trabajo más grande, pero la sugerencia es que ese es un buen lugar para poner un enlace con llamado a la acción.

  • Había intentado agregar una función de lista de permitidos basada en etiquetas, que se había pedido mucho antes y no parecía difícil de implementar, e incluso había identificado dónde ponerla en el código del servidor.
    Pero me di cuenta de que, para entregar la función, tendría que manejar PRs en al menos dos repositorios y moverme entre ambos para las pruebas de integración, así que lo dejé.
    Para código fuertemente acoplado, un solo repositorio es realmente cómodo.
    Quizás vuelva a revisarlo alguna vez.
    De paso, el control parental basado en listas de permitidos es una de las mejores herramientas, pero frustra que casi nadie lo soporte realmente.

    • Al menos estaría bien enviar feedback sobre en qué punto te trabaste y abandonaste.
      Probablemente no seas la única persona a la que le pasó.
      Al proyecto también puede resultarle incómodo, pero quizá ya se acostumbraron a esa incomodidad y la olvidaron.
    • Este es un gran problema de git/GitHub.
      Si se soportaran PRs entre repositorios, se podría simplificar este proceso; llevo casi 10 años queriendo una función así.
    • Como referencia, el control parental de Plex es absurdamente flexible.
      Configuré la cuenta de los niños para que solo puedan ver contenido con ciertas etiquetas, y como las etiquetas de Plex son bastante granulares, es posible permitir una película o serie completa, parte de una serie, o incluso un solo episodio.
      Ahora pueden acceder a bastante contenido, pero el contenido nuevo no se habilita automáticamente.
      Cuando consigo algo como un episodio nuevo de Bluey, mi esposa quiere verlo primero, y aunque casi siempre lo aprobamos porque rara vez hay algo muy problemático en los programas infantiles, nos da tranquilidad.
    • Durante mucho tiempo me frustró lo de las listas de permitidos, hasta que aprendí en Reddit cómo hacer una lista de permitidos en Plex.
      No recuerdo exactamente los términos, pero hay que tener cuidado porque existen tanto tags como labels.
      Antes estaba intentando con el lado equivocado; básicamente hay que crear un label y luego configurar la cuenta infantil para que solo vea contenido con ese label.
    • Plex soporta tanto listas de permitidos como listas de bloqueo.
      Está bueno porque puedes bloquear la mayoría de las películas por clasificación y permitir solo algunas de forma individual.

  • Como desarrollador que trabaja solo en sistemas Linux, me da curiosidad cómo es el entorno de desarrollo de C#.
    Pensaba que Mono todavía existía y que ese era el runtime que usaban los proyectos C# al ejecutarse.
    Siempre sentí que C# era algo incómodo fuera de Windows, aunque quizá estuve equivocado todo este tiempo.
    Como no tuve oportunidad ni necesidad de usarlo en el trabajo, no sé qué tan buenas son las herramientas en Mac o Linux, ni cómo funciona realmente.
    Por otro lado, varias veces leí que es como un Java mejor, y por aquí parece que también gusta bastante F#.

    • En Arch la instalación es un poco complicada, y desde que Mono prácticamente desapareció, se siente como si la única opción de IDE fuera el VS Code cerrado de Microsoft.
      El plugin de C# no funciona en VSCodium.
      Al igual que Java, el diseño del lenguaje C# asume bastante que vas a usar un IDE.
      Aun así, si se trata de una aplicación web, aparte de eso está bien.
    • C# en Linux es apenas un poco más engorroso que en Windows.
      Hay que prestar un poco de atención al instalar el SDK y algunas APIs del sistema se comportan de forma ligeramente distinta, pero en general el nivel de preferencia por Windows es apenas mayor.
      Mono todavía existe, pero desde alrededor de 2015 C# tiene soporte nativo en Linux y, hasta donde sé, casi nadie usa Mono realmente hoy.
      Su uso principal es ejecutar apps de .NET Framework, no .NET Core.
    • Mono todavía existe, pero Jellyfin usa .NET Core, el runtime libre y open source proporcionado por Microsoft.
    • El entorno de desarrollo de C# es excelente y se ejecuta de forma nativa en Linux.
      Mono todavía sigue existiendo y se usa en algunos casos especiales, como WASM e intérpretes.
    • C# se ejecuta de forma nativa en Linux desde hace mucho tiempo.
      Hasta donde sé, incluso en Azure muchas veces prefieren correrlo en máquinas Linux, y donde trabajo también es así.
      Diría que el rendimiento es igual o mejor.
      Hoy muchos desarrolladores C#, quizá incluso la mayoría, trabajan en máquinas que no son Windows, y el soporte para la nueva arquitectura de Mac también se agregó muy rápido.
      En resumen, hoy en día el lenguaje C# en sí es igual o mejor en entornos que no son Windows.

  • Le di un vistazo al repositorio de GitHub, y en el repositorio principal hay más de 90 PR abiertos, y algunos llevan más de 8 meses sin feedback
    Si el equipo actual ni siquiera puede procesar el volumen de PR existente, no sé qué sentido tiene esta convocatoria a participar
    En el estado actual, que haya más PR no ayuda al proyecto

  • No sabía que Jellyfin necesitaba desarrolladores
    Soy usuario intensivo de Plex, pero de profesión soy desarrollador C#, así que cloné el servidor y el proyecto web y me puse a trabajar en mi primer issue

  • Me encanta Jellyfin y lo uso desde hace 3 años
    Definitivamente pienso participar en Hacktoberfest

  • Quiero usar Jellyfin, pero no tiene cliente oficial para Apple TV

    • https://github.com/jellyfin/Swiftfin
      Lo estoy usando y está bien
    • El reproductor multimedia Infuse[0][1] tiene excelentes clientes para Apple TV / iOS / macOS
      También se integra con Jellyfin
      [0] https://firecore.com/infuse
      [1] https://jellyfin.org/posts/client-infuse/
    • Me pregunto si los clientes existentes son tan malos
      Cuando probé uno hace unos años, no tuve mayores problemas con el cliente de Jellyfin
      Dejé de usar Jellyfin porque Locast cerró, y ese era mi uso principal
    • Desde que compré un Apple TV uso Swiftfin, y es más o menos aceptable
      Le faltan muchas opciones de ordenamiento y filtros; se traba, por ejemplo si haces scroll demasiado rápido, las tarjetas de películas se cargan en posiciones equivocadas, y a veces la barra de progreso deja de actualizarse durante el resto de la película después de pausar
      Aun así, es usable
    • ¿No existe Swiftfin?
      El desarrollo es algo intermitente, pero cuando lo necesité antes funcionaba bien

  • Tenía muchas ganas de usar Jellyfin y en su momento migré, pero al enterarme de que tiene muchas API no autenticadas, incluso para streams de video, volví a Plex
    Me pareció demasiado riesgoso exponer Jellyfin a la web
    https://github.com/jellyfin/jellyfin/issues/5415

  • Ojalá por fin se desarrolle la función de Chromecast en Jellyfin para iOS
    Literalmente uso Plex en lugar de Jellyfin solo por esa función
    Sería genial que alguien con experiencia en la API de Chromecast se sumara y ayudara al equipo