Forking di un'applicazione per un cliente "enterprise"

4

Nota: questa è principalmente una domanda tecnica, ma devo prima spiegare lo scenario aziendale.

LA PARTE COMMERCIALE

Ho una situazione davvero interessante nelle mie mani, almeno interessante per me.

Negli ultimi 3,5 anni ho creato un business / applicazione chiamato Snip Salon Software . È un software di pianificazione per i parrucchieri. Significativamente, ho mirato in modo specifico ai saloni di hair rispetto ai saloni di unghia o ai centri di abbronzatura, che hanno esigenze diverse.

L'azienda ha registrato un certo livello di successo ma finora nulla di spettacolare. Ho 6 saloni nella mia zona locale utilizzando il prodotto.

Qualche tempo fa sono stato avvicinato da un paio di imprenditori nell'industria del salone lash , che ha esigenze di programmazione diverse dai parrucchieri. (L'industria della bellezza è uno spazio sorprendentemente complesso!) Questi ragazzi preferirebbero che io etichettassi in bianco il mio prodotto per loro in modo che possano venderlo come parte di un pacchetto di tipo "business in a box" che offrono ai tecnici di avvio delle ciglia .

LA PARTE TECNICA

Quindi la sfida che mi trovo di fronte è:

  • Non voglio avere una sola applicazione che serve sia i parrucchieri che i centri di ciglia. Penso che si trasformerebbe rapidamente in un incubo.
  • Non voglio che le applicazioni eseguano principalmente lo stesso codice. Sarebbe sciocco.

E non sono solo le caratteristiche: tutto il marchio, ecc. sarà quasi certamente diverso per ogni versione.

Quindi quello che penso di voler fare è forgiare il codebase e impostare hosting separato, ecc. per l'applicazione lash salon. Poi, nel tempo, forse voglio calcolare le parti comuni (ad es. Email di promemoria per appuntamenti) in moduli (sto usando Ruby on Rails, quindi sto parlando di motori Rails) e poi permetto a ogni fork della mia applicazione di usare lo stesso copia di ogni modulo. Ovviamente lo posizionerei in modo tale che ogni motore contenesse solo le funzionalità comuni alle due forcelle dell'applicazione.

La mia domanda: dal punto di vista tecnico, come gestiresti questa situazione?

Sentiti libero di entrare anche nel lato business.

    
posta Jason Swett 12.05.2014 - 20:41
fonte

2 risposte

2

Dal punto di vista del business, penso che tu abbia ragione ad andare con il metodo più semplice possibile per dividere il codice base e poi gradualmente lavorare per riunirli. Anche se potrebbe sembrare il migliore, dal punto di vista tecnico, rearchitect e riscrivere la tua applicazione principale, non ha senso mettere tutto quel lavoro in primo piano a meno che tu non sia assolutamente certo che il progetto ciglia sarà un proficuo rapporto commerciale a lungo termine - per quel che ne sai, potrebbero sfaldarti e essere andato in 6 mesi.

    
risposta data 13.05.2014 - 00:33
fonte
6

Sarei andato dall'altra parte - invece di rendere le parti comuni una libreria riutilizzabile, dovresti implementare un'architettura plugin e creare plugin per i diversi tipi di saloon.

Avrai il codice dell'applicazione principale, che include la base di codice comune e un'infrastruttura per i plug-in (ad esempio interfacce da implementare nei plug-in) e i plug-in stessi saranno progetti diversi. Dovresti anche rendere possibile la creazione di pacchetti dell'applicazione + plug-in specifici, in modo che i ragazzi della lash berlina possano disporre di un pacchetto di lash berlina che sarà facile da installare per i propri clienti.

Il principale vantaggio dell'architettura dei plug-in rispetto all'architettura dei moduli condivisi è che l'applicazione principale deve disporre di molto codice per l'orchestrazione dei diversi moduli \ plugins. Nell'architettura dei moduli condivisi dovrai replicare il codice boilerplate in ogni fork, ma con l'architettura plugins ne avrai bisogno solo una volta, nell'applicazione principale.

    
risposta data 12.05.2014 - 21:02
fonte

Leggi altre domande sui tag