WhatsApp

Distribuire o non distribuire? Cose da considerare

Anonim

Hai mai pensato di creare una tua distribuzione Linux? Forse hai individuato una necessità nell'ecosistema Linux, o forse pensi che gli anni di modifiche e personalizzazioni che hai inserito nella tua installazione personale del sistema operativo sarebbero stati l'ideale per gli altri.

Qualunque sia la ragione, hai una distribuzione o un'idea per una distribuzione che vorresti che le persone conoscessero e usassero.

Molti utenti Linux hanno avuto questi pensieri. E mentre molti fanno il grande passo e rilasciano una distribuzione allo stato brado, la maggior parte fallisce in un mercato così competitivo. Ma è meglio fallire piuttosto che non provarci mai? O avere successo a rischio di sminuire le distribuzioni esistenti?

Ho ampliato queste domande attraverso una sezione modificata del Il famoso soliloquio di Amleto:

Distribuire o non distribuire: cose da considerare: se sia più nobile nella mente soffrire Il ritardo e il design di desktop oltraggiosi, O prendere le armi contro un mare di sistemi, E opponendosi finirli? Biforcare: creare.

Cheesy? Forse. Ma è un titolo accattivante.

Anche se hai deciso di rilasciare una distribuzione al pubblico, ci sono alcune cose che dovresti considerare prima di intraprendere l'impresa.

Crea valore?

Sto scrivendo questo post partendo dal presupposto che tu stia cercando di spedire una distribuzione per l'adozione di massa piuttosto che specifica per una determinata organizzazione o struttura.

Con questo in mente, esistono già centinaia di distribuzioni Linux mantenute attivamente che servono centinaia di esigenze diverse. Dove si adatterebbe la tua distribuzione? Qual è il posizionamento del tuo prodotto?

Forse il bisogno che stai tentando di soddisfare è già stato soddisfatto da un altro team di sviluppatori? Forse avrebbe più senso contribuire a monte di un sistema operativo esistente piuttosto che competere per gli stessi utenti che cercano la stessa soluzione?

Vuoi pensare attentamente alla tua proposta di valore e se può essere realizzata unendoti a un team già esistente.

Hai le competenze richieste?

La maggior parte degli utenti Linux può assumere una distribuzione esistente e funzionante, aggiungere alcuni programmi e temi non modificati o alcune modifiche molto specifiche, quindi impacchettarla e commercializzarla usando l'adagio generico, " Una distribuzione semplice e facile da usare per tutti.”

Se la tua distribuzione sta davvero portando qualcosa al tavolo, allora ci sarà del codice coinvolto.

Se non riesci a scrivere codice del calibro da spedire su un sistema operativo, va bene. Quando ho iniziato VeltOS non mi sarei fidato che il mio codice venisse eseguito su un tostapane, per non parlare di qualcosa che la gente usava quotidianamente.

Quindi, invece di spedire un codice scadente o non costruire affatto una base di codice, ho assunto un collega che sapesse davvero scrivere bene C linguaggio.

Le capacità di programmazione sono solo l'inizio, però (punta dell'iceberg se puoi). Se la tua distribuzione ottiene anche un minimo di riconoscimento e utenti, allora dovrai avere competenze nella gestione/sviluppo della comunità, nel marketing e nelle pubbliche relazioni. Ancora una volta, se hai difficoltà con un set di competenze, dovresti coinvolgere altri per sostituire ciò che ti manca.

Hai il tempo?

Uno dei principali motivi per cui le distribuzioni falliscono è perché il fondatore originale scopre di non avere più il tempo di investire in quello che spesso è un progetto secondario. Solo perché ora hai del tempo libero non significa che lo avrai più tardi.

Se sei uno studente universitario con tempo da ammazzare durante le vacanze estive, ciò non significa che dovresti realizzare la tua idea di distribuzione Linux. All'inizio del prossimo semestre potresti dover lasciare la tua base di utenti sospesa senza aggiornamenti e supporto.

Se sai che avrai sempre il tempo per stare al passo con le cose, allora fallo. Se non sei sicuro, dovrai mettere da parte la tua idea di distribuzione o accettare l'inevitabilità di dover delegare la responsabilità a un altro membro del team lungo la strada.

Tutto questo si riduce a due domande:

  1. Stai creando innovazione open source o rumore open source?
  2. Se si tratta di innovazione, hai le capacità e il tempo per realizzare la tua idea? Se no, possono farlo gli altri?