Un sitio web de alternativas de código abierto sin bloat

Centros multimedia y complejidad

• La categoría de TV/Media muestra muchas entradas de XBMC/Kodi; algunos lo ven como una consolidación y una pérdida de variedad frente a hace 10–15 años.
• Explicaciones ofrecidas:
  • El soporte de centros multimedia es técnicamente y en términos de UX complejo (formatos, transcodificación, aceleración, metadatos).
  • ffmpeg es potente pero vasto; entenderlo a fondo puede ser una especialización.
  • Varios describen la transcodificación en sí como “la parte fácil”; construir una UX pulida, catálogos y lidiar con los usuarios es la verdadera carga.
• Desacuerdo sobre la dificultad de audio frente a video:
  • Un lado: los servidores de video son mucho más complejos (transcodificación, subtítulos, aceleración por hardware, scraping de metadatos).
  • El otro lado: audio y video comparten los mismos problemas fundamentales (indexación, múltiples formatos, widgets de front-end).

Ebooks y otras herramientas autoalojadas

• Calibre dominó durante mucho tiempo la gestión de ebooks; herramientas más nuevas como Grimmory y Shelfmark se citan como sucesoras o complementos con mejor UX.

Qué cuenta como “bloat”

• Algunos tratan el sitio como “alternativas de código abierto” más que como “sin bloat” en sentido estricto.
• Debate en torno a Tailscale: se considera útil pero afectado por la expansión de funciones; tensión entre el crecimiento impulsado por inversores y el minimalismo.
• La afirmación de que el capitalismo y FOSS son incompatibles es refutada señalando su coexistencia actual.

Debates sobre estilo de código y consistencia

• Las reglas estrictas al estilo suckless (p. ej., sintaxis de comentarios) son ridiculizadas como bikeshedding y de poco valor.
• Punto de vista contrario: cualquier estilo está bien mientras sea consistente; la consistencia ayuda a la comprensión.
• Otra postura rechaza la “consistencia” como métrica significativa, sosteniendo que el foco debería estar en las pruebas y los algoritmos; otros replican que un estilo consistente realmente mejora la legibilidad.

Autenticación y privacidad

• Se critica el inicio de sesión solo con Google/GitHub; algunos quieren un correo sencillo o cuentas locales del sitio.
• Se señala la ironía: un sitio de “debloat” que depende de OAuth de big tech.

Fiabilidad del sitio, UX e implementación

• Muchos reportan errores de TLS/SSL, bloqueos de antivirus o bloqueos por cortafuegos corporativos; algunos sospechan problemas de carga/capacidad, otros mencionan problemas de certificado.
• Otros ven certificados válidos de Let's Encrypt; la causa general no está clara.
• Se elogia el sitio por:
  • Diseño retro tipo eBay de los 90/principios de los 2000.
  • Sin JavaScript, sin cookies, CSS mínimo.
  • Carga rápida y compatibilidad con navegadores solo de texto; todas las páginas son descubribles mediante sitemap.
• Algunos sospechan HTML “vibe-coded” / parecido a IA, pero no está establecido.

Directorios alternativos y menciones de herramientas específicas

• alternativeto.net se menciona como un recurso de larga trayectoria, pero se critica por haberse vuelto más bloat y menos usable tras su rediseño.
• Alternativas sugeridas: SaaSHub, openalternative.co, tinyapps.org.
• Herramientas concretas elogiadas:
  • Nextcloud se describe como potente pero no “sin bloat”; no hay un reemplazo único claramente más ligero.
  • Immich se cita como un fuerte reemplazo de Google Photos.
  • G-Helper para portátiles Asus.
  • Kanboard como alternativa ligera a Trello.
  • Varias herramientas de ebooks y multimedia (Calibre, Grimmory, Shelfmark, Jellyfin, VLC, gstreamer).

Código generado por IA y “slop”

• Algunos quieren marcadores para “slop” generado por IA.
• Otros preguntan cómo se define “slop” y cuestionan si el código de IA bien probado es inherentemente peor que el código humano mediocre.
• Surge la preocupación de que las peticiones de rigor respecto a la IA a menudo se descartan; el problema subyacente se plantea como “¿cómo estás filtrando la calidad?”.

Rendimiento, APIs y control del bloat en proyectos

• Un comentarista sostiene que los mantenedores deberían tratar el rendimiento como una característica de primera clase y rechazar funciones que amplíen la superficie de API a costa del throughput.
• Se sugiere mantener un módulo central minimalista y “estrangular” las funciones adicionales en wrappers separados, con pruebas que protejan invariantes.

“Debloating” más allá del software (coches)

• Se expresa el deseo de un coche eléctrico “sin bloat”.
• Se dan algunos ejemplos de EV relativamente convencionales con interfaces más simples y controles físicos.
• Preocupan los coches siempre conectados, las SIM integradas, el rastreo GPS y la integración con ecosistemas de big tech como Android Auto.
• Se debate si Android Auto es intrínsecamente invasivo para la privacidad; algunos afirman que puede usarse sin conexión con intercambio mínimo de datos, pero siguen existiendo lagunas legislativas y preocupaciones sobre la recopilación de datos.