Come spiegare che scrivere codice C ++ universalmente multipiattaforma e spedire prodotti per tutti i sistemi operativi non è così facile?

La nostra azienda distribuisce una gamma di prodotti desktop per Windows e molti utenti Linux lamentano nei forum che avremmo dovuto scrivere versioni dei nostri prodotti per Linux anni fa e il motivo per cui non lo facciamo è

• siamo una società avida
• tutti i nostri specialisti tecnici sono idioti sottoqualificati

Il nostro prodotto medio è qualcosa come 3 milioni di righe di codice C ++.

L'analisi mia e dei miei colleghi è la seguente:

• scrivere codice C ++ multipiattaforma non è così semplice
• preparare molti pacchetti di distribuzione e mantenerli per tutte le versioni diffuse di Linux richiede tempo
• la nostra stima è che il mercato Linux è qualcosa come il 5-15% di tutti gli utenti e quegli utenti probabilmente non vorranno pagare per i nostri sforzi

quando questo viene sollevato, la risposta è che siamo avidi idioti poco qualificati e che quando tutto è fatto bene tutto questo è facile e indolore.

Quanto sono ragionevoli le nostre valutazioni sul fatto che scrivere codice multipiattaforma e mantenere numerosi pacchetti di distribuzione richiede molto impegno? Dove possiamo trovare alcune analisi semplici ma dettagliate con storie di vita reale che mostrano oltre l'ombra di un dubbio quale sforzo ci vuole esattamente?

Tieni presente che la maggior parte delle persone sono dipendenti e quindi non vivono in un mondo in cui devono preoccuparsi di realizzare un profitto. Si presentano al lavoro, fanno le loro cose e vanno a casa, senza mai veramente pensare a come funziona l'intero processo. E sebbene molto intelligenti, molti tecnici sono decisamente ignoranti nei confronti degli affari e spesso accecati dal dogma.

Hai ragione, ovviamente, realizzare software per piattaforme x di quella scala non è una cosa semplice. Soprattutto quando non sei un'azienda che ha molte dozzine di sviluppatori e milioni di utenti. E non sono solo limiti tecnici. Si tratta di costi e benefici. Sì, si potrebbe passare poi l'anno prossimo porting l'applicazione per Linux (nonostante, come si nota, è già essendo runable nel vino). Ovviamente, quell'anno di tempo di sviluppo non è gratuito. E alla fine, forse ti farà reteun ulteriore 5-15% di utenti (basato sulla tua stima). Oppure puoi prendere lo stesso denaro / sforzo e concentrarti sullo sviluppo di Windows come una nuova versione, oppure metterlo tutto nel marketing e aggiungere il 50% alla tua base di utenti. Quale suona come la scelta intelligente? (ovviamente i numeri devono essere personalizzati per la tua azienda e il risultato finale può favorire il porting).

Non so se ciò contribuirà a persuadere i "veri credenti", ma è la mossa del business intelligente. E se non fai mosse aziendali intelligenti, sei fuori dal mercato. E poi non ci sarà sicuramente una versione Linux.

Ci sono due cose da considerare qui penso:

Il primo è che, in un certo senso, hanno ragione. Scrivere C ++ multipiattaforma non è così difficile se lo hai pianificato dall'inizio . Questo è quasi sicuramente il problema che stai vedendo. La maggior parte delle applicazioni open source (la maggior parte delle applicazioni che un utente Linux tocca in un giorno medio) sono assurdamente multipiattaforma. Pensa al numero di applicazioni con cui l'utente medio Linux interagisce quotidianamente, scritte in C o C ++ ed eseguite non solo su Windows e Linux, ma anche su MacOS, BSD, Solaris, ecc. Su x86, x86-64, ARM, SPARC, ecc. Ciò è in parte dovuto al fatto che le persone che hanno il prurito di grattare il codice per eseguire il codice sui loro sistemi, ma anche perché la convenzione prevede di pianificare la portabilità multipiattaforma.

La seconda cosa è che il mercato potrebbe essere più redditizio di quanto si pensi. C'è un grosso malinteso sul fatto che le persone su Linux non vogliono pagare per il software. Per alcune persone potrebbe essere vero, ma ci sono molte persone (la maggior parte, penso,) che usano Linux perché funziona meglio per loro e lo preferiscono, non a causa del prezzo. Inoltre, se la tua azienda sta producendo un prodotto che viene utilizzato principalmente in un ambiente professionale, le aziende sono ben abituate a pagare per l'esecuzione del software su sistemi Linux.

Per quanto riguarda il punto che poni sull'imballaggio, come altri hanno già detto, devi solo produrre pacchetti per l'ultima versione delle principali distribuzioni. Realizzare i pacchetti non è poi così difficile, e la maggior parte delle principali distribuzioni utilizza pacchetti debian (debian, ubuntu, ecc.) O RPM (fedora, suse, centos, mandrake), quindi è molto secondario modificare alcuni script per produrre più pacchetti da un .deb di base e da un .rpm di base, e per tutti gli altri basta lanciare un tarball con binari e un file Leggimi, le persone capiranno come installarlo. In alternativa, puoi saltare tutto il packaging e pubblicare un singolo tarball con uno script bash o perl per eseguire l'installazione.

Per quanto riguarda il modo in cui rivolgersi agli utenti dei tuoi forum lamentandosi, come ha detto Joe Internet, potrebbero essere solo la percentuale di persone che si lamenteranno, qualunque cosa accada, ma la prima cosa che farei è cercare di spiegare che hai un una grande quantità di codice legacy che non è stato progettato pensando al supporto multipiattaforma. In secondo luogo, vedi onestamente se fornirebbe un supporto finanziario per creare una porta Linux ed essere aperto con i risultati di ciò. Infine, se una porta non è economicamente fattibile, vedi come fare qualche lavoro per far funzionare bene il programma con WINE. WINE non dovrebbe essere la prima soluzione, ma potrebbe benissimo molestare le persone che vogliono semplicemente usare la tua app in Linux ed essere un progetto meno costoso di una porta completa. Infatti, se aggiungi codice alla base di codice WINE come parte del progetto, non solo potresti aprirti a un nuovo mercato,

Adobe, sei tu?

Scherzi a parte, crea una specie di taglia in modo che possano preordinare le versioni di Linux. Se ricevi abbastanza ordini per rendere un porto degno di essere messo in tempo, altrimenti li rimborsi e ora hai la prova che non abbastanza persone si preoccupano di renderlo utile.

Se hai qualcosa di porting però, scegli come target l'ultima versione di Ubuntu LTS, RHEL, SLED e forse fornisci un tar.gz che le persone possono provare a lavorare se vogliono usare qualcos'altro. Questo ti lascia con 3 pacchetti di cui preoccuparti e chiunque probabilmente ne sa abbastanza per far partire la versione tar.gz.

scrivere codice C ++ multipiattaforma non è così semplice

Al contrario. Quando pianifichi un lavoro multipiattaforma e fornisci astrazioni per le API specifiche della piattaforma che utilizzi, la maggior parte del codice è già multipiattaforma. Se stai già utilizzando una libreria popolare come Boost o Qt o NSPR, sei già molto vicino ad avere una build multipiattaforma funzionante.

Il problema più comunemente riscontrato quando si esegue una porta in ritardo nel ciclo di sviluppo è che ci sono parti significative di codice che si basano su API specifiche della piattaforma in parti del programma che non devono necessariamente usarle direttamente e probabilmente non dovrebbero affatto. (Un buon design avrà moduli fortemente disaccoppiati e gruppi di classi possono essere scambiati con sostituzioni riscritte a piacimento. Se questo non è il caso di un dato modulo, è un forte odore di codice.)

La semplice via d'uscita è spesso scrivere semplicemente una classe "Utility" e lanciare tutte le cose specifiche della piattaforma al suo interno. Non è "facile e indolore", ma sicuramente meno difficile di quanto si pensi.

preparare molti pacchetti di distribuzione e mantenerli per tutte le versioni diffuse di Linux richiede tempo

Questo è uno sfortunato malinteso. Sebbene sia vero che il mantenimento di build per più piattaforme richiede uno sforzo aggiuntivo (nella configurazione di un server di build giornaliero dedicato e nell'imparare come impacchettare per una particolare distribuzione), non è vero che è necessario mantenerle per "molte distribuzioni ]." Al contrario. Devi solo mantenere una manciata di pacchetti - diciamo, forse, Ubuntu, Fedora e un singolo tarball compatibile con LSB - e le varie comunità Linux occuperanno il resto del lavoro. Soprattutto se il tuo software è popolare, gli HOWTO nasceranno per ogni distribuzione, fornendo le necessarie istruzioni di installazione. Oppure, se il tuo software può essere distribuito liberamente (cosa che puoi fare anche se non è un prodotto gratuito, a condizione che le licenze lo consentano), le distribuzioni più popolari avranno una sorta di repository alternativo che trasporta copie del software.

Le comunità sono generalmente molto brave in questo, e gli utenti esperti faranno volentieri molto di queste legwork per te, se le lascerai fare.

la nostra stima è che il mercato Linux è qualcosa come il 5-15% di tutti gli utenti e quegli utenti probabilmente non vorranno pagare per i nostri sforzi

Un'altra idea sbagliata sfortunata e molto sbagliata.

Solo perché gli utenti Linux ottengono il loro sistema operativo gratuitamente non significa che non sono disposti a pagare per il software. Se il software è molto buono e c'è una grande richiesta, gli utenti Linux saranno spesso più disposti a separare i propri soldi di quanto lo saranno gli utenti Windows. Dai un'occhiata agli Humble Indie Bundles , in cui gli utenti Linux, in media, hanno pagato più del doppio per utente rispetto agli utenti Windows.

È anche possibile che il tuo prodotto abbia una domanda maggiore tra gli utenti Linux rispetto ad altre piattaforme (che non possiamo conoscere senza conoscere il tuo prodotto), a seconda del tipo di software esistente in quell'arena. Potresti avere un mercato potenziale più ampio di quanto pensi.

Con atteggiamenti del genere, li ignorerei e basta. Sembrano il segmento di X, dove X può essere qualsiasi cosa , che si lamenterà qualunque cosa tu faccia. Rilascia una versione Linux o no, è una tua scelta, non la loro.

Se lavori per Nvidia ...

Per amore di Dio, succhialo e scrivi già alcuni driver decenti.

Altrimenti, se stai facendo normali applicazioni aziendali, indirizza i progetti futuri da eseguire su C #.

Mono è completamente compatibile fino a .NET 3.5 e può persino utilizzare la GUI di winforms. Gli unici moduli a cui devi prestare attenzione sono quelli specifici del sistema operativo, ma sono pochi e lontani tra loro.