¿Ha pensado alguna vez en iniciar su propia distribución de Linux? Tal vez haya detectado una necesidad en el ecosistema de Linux, o tal vez sienta que los años de ajustes y personalizaciones que ha realizado en la instalación de su sistema operativo personal serían ideales para otros.
Cualquiera que sea el motivo, tiene una distribución o una idea para una distribución que le gustaría que la gente conozca y use.
Muchos usuarios de Linux han tenido estos pensamientos. Y mientras muchos dan el paso y lanzan una distribución a la naturaleza, la mayoría fracasa en un mercado tan competitivo. Pero, ¿es mejor fallar que nunca intentarlo? ¿O tiene éxito a riesgo de restar valor a las distribuciones existentes?
He ampliado estas preguntas a través de una sección modificada del El famoso soliloquio de Hamlet:
Distribuir o no distribuir: aspectos a tener en cuenta: Si es más noble en la mente sufrir El retraso y el diseño de escritorios escandalosos, O tomar las armas contra un mar de sistemas, ¿Y al oponerse a acabar con ellos? Bifurcar: crear.
¿Caseoso? Tal vez. Pero lo convierte en un título pegadizo.
Incluso si tiene el corazón puesto en lanzar una distribución al público, hay algunas cosas que debe considerar antes de emprender la aventura.
¿Creará valor?
Estoy escribiendo esta publicación asumiendo que está buscando enviar una distribución para adopción masiva en lugar de ser específica para una determinada organización o instalación.
Con eso en mente, ya existen cientos de distribuciones de Linux mantenidas activamente que atienden cientos de necesidades diferentes. ¿Dónde encajaría tu distribución? ¿Cuál es el posicionamiento de su producto?
¿Quizás la necesidad que está tratando de satisfacer ya está siendo cubierta por otro equipo de desarrolladores? ¿Tal vez tendría más sentido contribuir aguas arriba a un sistema operativo existente en lugar de competir por los mismos usuarios que buscan la misma solución?
Desea pensar detenidamente sobre su propuesta de valor y si se puede lograr o no uniéndose a un equipo ya existente.
¿Tiene el conjunto de habilidades necesario?
La mayoría de los usuarios de Linux pueden tomar una distribución existente y funcional, agregar algunos programas y temas no modificados o algunas modificaciones muy específicas, luego empaquetarlo y comercializarlo usando el adagio genérico, “ Una distribución simple y fácil de usar para todos.”
Si tu distribución realmente trae algo a la mesa, habrá código involucrado.
Si no puede escribir un código del calibre para enviar en un sistema operativo, está bien. Cuando comencé con VeltOS, no habría confiado en que mi código se ejecutaría en una tostadora, y mucho menos en algo que la gente usara a diario.
Entonces, en lugar de enviar un código deficiente o no crear una base de código en absoluto, recluté a un colega que realmente podía escribir sólido C idioma.
Sin embargo, Las habilidades de programación son solo el comienzo (la punta del iceberg, por así decirlo). Si su distribución obtiene incluso un mínimo de reconocimiento y usuarios, entonces deberá tener habilidades en gestión/desarrollo comunitario, marketing y relaciones públicas. Una vez más, si tiene problemas con un conjunto de habilidades, debe traer a otros para que reemplacen lo que le f alta.
¿Tienes el tiempo?
Una de las principales razones por las que las distribuciones fallan es porque el fundador original descubre que ya no tiene tiempo para invertir en lo que a menudo es un proyecto paralelo. El hecho de que tenga tiempo libre ahora no significa que lo tendrá más tarde.
Si eres un estudiante universitario con tiempo para matar durante las vacaciones de verano, eso no significa que debas ejecutar tu idea de distribución de Linux. Cuando comience el próximo semestre, es posible que deba dejar su base de usuarios colgando sin actualizaciones ni soporte.
Si sabe que siempre tendrá tiempo para estar al tanto de las cosas, entonces hágalo. Si no está seguro, tendrá que dejar su idea de distribución en un segundo plano o aceptar la inevitabilidad de tener que delegar la responsabilidad a otro miembro del equipo en el futuro.
Todo esto se reduce a dos preguntas:
- ¿Está creando innovación de código abierto o ruido de código abierto?
- Si se trata de innovación, ¿tiene las habilidades y el tiempo para ejecutar su idea? Si no, ¿pueden otros?