Open source: differenze tra le versioni

Versione delle 13:38, 29 gen 2023

Versione delle 10:41, 3 feb 2023

Riga 76:

# '''servizio di supporto a pagamento''': il programma è gratuito, ma si paga per avere il supporto dello sviluppatore; se il supporto prevede donazioni, si può ritenere simile al punto precedente;

# '''sponsorizzazione''': il programma o il sito che lo ospita può contenere il nome o altro tipo di pubblicità ad un'azienda che supporta economicamente lo sviluppatore; può anche accadere che un'azienda si occupi dello sviluppo di un programma gratuito e conti sulla pubblicità che riscuoterà da esso per farsi conoscere;

# guadagni grazie alla '''didattica''': se il prodotto creato è particolarmente complesso, ad esempio nel caso di un nuovo linguaggio di programmazione o di una particolare [[Libreria (software)|libreria]] (o [[framework]], ecc.), lo sviluppatore può guadagnare grazie all'organizzazione di corsi di apprendimento del prodotto stesso, la vendita di manuali e libri a supporto ecc. Questo tipo di guadagno può risentire della concorrenza dei manuali che sono o saranno pubblicate gratuitamente in rete da parte di utenti, e può dar vita ad una strategia di mercato piuttosto complessa. Nei casi di librerie (o framework) che vogliono fare concorrenza a prodotti esistenti, si deve convincere gli utilizzatori che essi siano validi al confronto degli altri prodotti disponibili. Il produttore può anche rendere disponibile in rete delle introduzioni all'apprendimento del proprio prodotto, che però non coprono tutte le potenzialità dello stesso, cercando allo stesso tempo di creare una comunità di supporto ed un gergo che l'accomuni. Il gergo può far uso di termini nuovi che rimpiazzano quelli già in uso, giustificati con motivazioni diverse (ad esempio, le "[[Funzione (informatica)|funzioni]]" in [[Java (linguaggio di programmazione)|Java]] sono chiamate "[[Metodo (programmazione)|metodi]]", nonostante compiano azioni o restituiscano un risultato di un'elaborazione). Talvolta può dar vita ad una serie di acronimi che rendono quasi criptico il linguaggio (si veda il framework [[Spring Framework|Spring]]). In tal modo si riesce a far diminuire il numero degli autodidatti che imparano in rete, spingendo chi vuole apprendere a comprare libri per l'apprendimento e le pratiche ottimali da seguire e/o seguire corsi e contemporaneamente si crea una comunità di sviluppatori fedele nel tempo, spesso unita anche da una "filosofia" di programmazione. Dunque, la caratteristica di questo modello può spingere i manutentori del progetto ad aumentare artificiosamente la complessità del software e diminuire la leggibilità del codice, contrastando almeno in parte i principi della semplicità di condivisione della conoscenza che animano invece altri tipi di progetti, sempre open-source.

Questi modelli di business tipici non sono al momento distinti da una [[tassonomia]] condivisa. È anche possibile, dunque, che un certo progetto Open Source venga iniziato sotto un certo modello di business, ma poi prosegua sotto un altro.