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

Tenere 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 pensare a come funziona l'intero processo. E mentre molto intelligente, molti esperti sono ignoranti sul business e spesso accecati dal dogma.

Hai ragione, ovviamente, rendere il software x-platform di tale portata non è una cosa semplice. Soprattutto quando non si è un'azienda che ha decine di sviluppatori e milioni di utenti. E non sono solo limitazioni tecniche. Si tratta di costi e benefici. Sì, potresti passare l'anno prossimo a trasferire l'app su Linux (nonostante tu, come puoi notare, è già eseguibile in WINE). Certamente, quell'anno di tempo di sviluppo non viene gratis. E alla fine, ti netto forse un ulteriore 5-15% di utenti (in base alla tua stima). Oppure puoi prendere lo stesso denaro / impegno e concentrarlo nello sviluppo di Windows come una nuova versione, o metterlo in marketing e aggiungere il 50% alla tua base di utenti. Quale sembra 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 è una mossa intelligente. E se non fai mosse di business intelligente, sei fuori dal mercato. E poi non ci sarà sicuramente una versione per Linux.

Ci sono due cose da considerare qui, penso:

Il primo è che, in un certo senso, hanno ragione. Scrivere cross-platform C ++ non è così difficile se lo pianifichi 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 Linux medio 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. Questo è in parte dovuto al fatto che le persone con un prurito da porting portano il codice da eseguire sui loro sistemi, ma anche perché la convenzione è quella di pianificare la portabilità multipiattaforma.

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

Per quanto riguarda il punto che si fa sulla confezione, come altri hanno già detto, è davvero necessario produrre pacchetti per l'ultima versione delle principali distribuzioni. Realmente creare i pacchetti non è poi così difficile, e la maggior parte delle principali distribuzioni utilizza o pacchetti debian (debian, ubuntu, ecc.) O RPM (fedora, suse, centos, mandrake), quindi è molto minore modificare alcuni script per produrre più pacchetti da un file di base .deb e un file di base .rpm, e per tutti gli altri basta lanciare un tarball con i binari e un readme, la gente capirà come installarlo. In alternativa, puoi saltare tutta la confezione e pubblicare solo un singolo tarball con uno script bash o perl per fare l'installazione.

Per quanto riguarda come indirizzare gli utenti sui forum a lamentarsi, come ha detto Joe Internet, potrebbero essere solo la percentuale di persone che si lamenteranno a prescindere da cosa, ma la prima cosa che farei è provare a spiegare che hai una grande quantità di codice legacy che non è stato progettato pensando al supporto multipiattaforma. In secondo luogo, sinceramente, vedi se sarebbe in grado di fornire un supporto finanziario per realizzare una porta Linux e di essere aperto con i risultati. Infine, se un porto non è finanziariamente fattibile, si prega di fare del lavoro per far funzionare bene il programma con WINE. WINE non dovrebbe essere la prima soluzione, ma potrebbe tranquillamente semplificare le persone che vogliono semplicemente usare la tua app in Linux, ed essere un progetto meno costoso di una porta piena. Infatti, se aggiungi codice alla base di codice WINE come parte del progetto, non solo potresti aprirti ad un nuovo mercato, ma potresti anche ottenere una buona reputazione dalla comunità.

Adobe, sei tu?

Scherzi a parte, metti una sorta di taglia in modo da poter preordinare le versioni di Linux. Se ricevi abbastanza ordini per fare in modo che una porta valga la pena, altrimenti li rimborserai e ora hai la prova che non ci sono abbastanza persone che lo facciano valere.

Se si ottiene un porting, però, basta prendere di mira l'ultima versione di Ubuntu LTS, RHEL, SLED, e magari fornire un tar.gz le persone possono provare a lavorare se vogliono usare qualcos'altro. Questo ti lascia con 3 pacchetti di cui preoccuparti e chiunque altro probabilmente conosce abbastanza per far partire la versione di tar.gz.

writing cross-platform C++ code is not that easy

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

Il problema più comune quando si fa una porta in ritardo nel ciclo di sviluppo è che ci sono parti significative del codice che si basano su API specifiche della piattaforma in parti del programma che non devono necessariamente essere utilizzate direttamente e probabilmente non dovrebbero tutti. (Un buon progetto avrà moduli strongmente disaccoppiati, e gruppi di classi possono essere scambiati con sostituzioni riscritte a piacere.Se questo non è il caso per un dato modulo, è un strong odore di codice.)

La facile via d'uscita è spesso scrivere semplicemente una classe "Utility" e lanciare tutte le cose specifiche per la piattaforma. Non è "facile e indolore", ma sicuramente meno difficile di quanto si possa pensare.

preparing a lot of distribution packages and maintaining them for all widespread versions of Linux takes time

Questo è un malinteso sfortunato. Se è vero che la manutenzione di build per più piattaforme richiede uno sforzo supplementare (nella configurazione di un server dedicato di creazione giornaliera e apprendimento del pacchetto per una particolare distribuzione), non è vero che è necessario mantenerli per "molta distribuzione [s ]." Al contrario. Devi solo mantenere una piccola manciata di pacchetti - ad esempio, Ubuntu, Fedora e un singolo tarball compatibile con LSB - e le varie comunità Linux prenderanno il resto del lavoro. Soprattutto se il tuo software è popolare, gli HOWTO verranno generati per ogni distribuzione, fornendo le istruzioni di configurazione necessarie. Oppure, se il tuo software può essere distribuito liberamente (cosa che puoi fare anche se non è un prodotto gratuito , a condizione che le tue licenze lo consentano), le distribuzioni più popolari avranno una sorta di repository alternativo contenente copie di il tuo software.

Le community sono generalmente molto brave in questo, e gli utenti esperti faranno volentieri un sacco di questi legwork per te, se glielo permetti.

our estimate is that Linux market is something like 5-15% of all users and those users will likely not want to pay for our effort

Un altro malinteso, e molto errato equivoco.

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 la domanda è ampia, gli utenti Linux saranno più disposti a separarsi dai loro soldi rispetto agli utenti Windows. Dai un'occhiata ai Humble Indie Bundles , dove gli utenti Linux, in media, pagavano più di il doppio di per utente rispetto agli utenti Windows.

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

Con atteggiamenti del genere, li ignorerei. Suonano come il segmento di X, dove X può essere qualsiasi cosa , che si lamenterà indipendentemente da ciò che fai. Rilascia una versione Linux o meno, è una tua scelta, non la loro.

Se lavori per Nvidia ...

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

Altrimenti, se stai facendo regolari applicazioni aziendali, indirizza i progetti futuri a 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 distanti tra loro.