Preparazione per il rilascio del codice come open-source [duplicato]

54

Ho sviluppato uno strumento completamente funzionale che vorrei non solo condividere con chiunque sia interessato, ma anche ottenere supporto dalla comunità. Questo strumento è multipiattaforma, scritto in C ++ con Qt, il codice è ben commentato ma manca ancora tutta la documentazione. Ci sono anche alcuni piccoli problemi e miglioramenti da apportare prima che io possa definirlo una versione finale stabile.

Quali sono i primi passi che devo compiere per rilasciare il codice come open-source e attirare le persone interessate a contribuire?

Questo è il mio primo tentativo serio di rilascio del codice open source e non so davvero da dove iniziare. Dovrei solo spingerlo a Github, mettere insieme una piccola wiki e pregare per il meglio?

    
posta Raphael 16.05.2011 - 00:17
fonte

4 risposte

59

Scegli la tua licenza

Se il tuo codice è stato closed source fino ad ora, la prima cosa che dovresti fare è decidere quale licenza open source ( GPL < = 2, GPL 3 , LGPL , BSD , Eclipse ecc.) che vuoi da usare.

Ci sono pro e contro a ciascuno, quindi leggi le restrizioni che inseriscono nel codice e decidi chi vuoi essere in grado di usarlo. Avviso , a seconda di quale sceglierai, qualcuno si lamenterà - questo è guerra santa e oltre lo scopo di questa domanda.

Sanitizza il tuo repository

Se il codice nel tuo repository non ha già applicato la tua licenza scelta, passerò attraverso l'intera cronologia delle revisioni finora e applicandolo retroattivamente (questo potrebbe richiedere una ricollocazione in ogni punto in cui una nuova fonte il file è stato introdotto). Ciò, tuttavia, produrrà un bel repository pulito che, quando viene rilasciato al pubblico, non ha revisioni in cui la licenza scelta non è in vigore.

Un'altra opzione è avviare il tuo repository pubblico nel punto della tua prima versione, con una cronologia minima o nulla fino a quel momento.

Questo ha lo svantaggio che le persone non possono tornare indietro nella cronologia e capire come sei arrivato dove sei oggi, ma ha il vantaggio che le persone non puoi tornare indietro nella tua storia e capire come sei arrivato dove sei oggi. * 8' )

Quando la società per cui lavoro ha realizzato il software su cui lavoro su open source, abbiamo iniziato producendo solo istantanee della directory di lavoro nei punti di rilascio. Quando ci siamo spostati su repository github pubblici, abbiamo iniziato ogni% repo% co_de al punto in cui un plug-in era (o un insieme di plug-in erano) spostato da git , raramente includendo qualsiasi storia.

Considera una doppia licenza

Se ritieni che ci possa essere un interesse commerciale nell'utilizzo del tuo software, ma hai una preferenza ideologica per una licenza di riutilizzo restrittiva come GPL 3, prendi in considerazione l'idea di offrire una doppia licenza. Offrire licenze GPL 3 per il download pubblico e licenze commerciali a pagamento ti offre il meglio di entrambi i mondi.

Fare questo fin dall'inizio potrebbe causare meno attrito rispetto all'avvio di offrire licenze commerciali in seguito. Se la tua comunità diventa popolare, le persone potrebbero accusarti di vendere se non avessi avuto la possibilità di sfruttamento commerciale in seguito.

Considera un accordo di collaborazione

Se hai intenzione di licenzare due volte, o semplicemente vuoi mantenere il tuo codebase tuo, dovrai o reimplementare te stesso le correzioni apportate dai contributi o ottenere contributori per assegnare i diritti sui loro contributi a te. Altrimenti scoprirai che i loro contributi ti impediscono di rilasciare il tuo codebase sotto altre licenze.

La risposta Mason Wheeler alla domanda La licenza open source del mio codice mi limita più tardi? fornisce alcune buone informazioni su questo e come è stato utilizzato il progetto libsdl per risolvere questo problema.

Tieni presente che, proprio come la tua scelta di licenza può limitare le persone e le organizzazioni che useranno e contribuiranno al tuo progetto, così sceglierai se avere un accordo con il contributore. Alcune persone non saranno felici di contribuire a un progetto che richiede loro di firmare un accordo di contributore.

Accordi di Collaboratore a doppia licenza

Il accordo con i fornitori di Oracle (i collegamenti sono difficili da vedere in quella pagina) è un buon modello per un accordo di contributore. È anche concesso in licenza (CC) in modo da poterlo modificare e riutilizzarlo.

    
risposta data 16.05.2011 - 01:01
fonte
27

risposta di Mark Booth è eccellente, ma parla solo di licensing / versioning, quindi vorrei aggiungere alcuni punti su un campo più tecnico che sono i primi (o meno così) per me quando rilasci il codice open source.

  1. Applica stile e leggibilità . Nessuno vuole contribuire a un progetto in cui hanno bisogno di spendere mesi per capire le basi. E nessuno vuole leggere e usare un codice come questo. Se vuoi che altre persone contribuiscano al progetto, sarebbe anche utile specificare quali sono gli standard di stile da utilizzare.

  2. Pulizia . Mark Booth ha spiegato perché potrebbe essere fastidioso consentire a chiunque di accedere a ogni revisione e vedere come il progetto è stato realizzato dall'inizio. Allo stesso modo, devi liberarti di grandi blocchi di codice commentato prima di rilasciarlo (che è una pratica scorretta in tutti i casi), o rimuovere i commenti che dicono su quale era la modifica, quando è stata fatta, ecc. (Che è una pratica ancora peggiore).

  3. Assicurati che il tuo codice sorgente abbia abbastanza test . È particolarmente importante in questo contesto, dal momento che la gente verrà senza sapere in dettaglio come viene eseguita la tua applicazione e quali sono le avvertenze, e proverà a modificarla, eventualmente infrangendo il codice.

  4. Descrivi il tuo progetto . Il codice potrebbe essere fantastico. Se non ho idea di cosa sia l'applicazione, ci sono poche possibilità di contribuire al progetto.

  5. Descrivi cosa possono fare i contributori . Alcuni progetti open source sono molto vicini e accetteranno i contributi solo dopo severi test e revisioni e solo se ritengono di aver bisogno del contributo in questione. In altri progetti, d'altra parte, i contributi sono benvenuti. È sempre bello sapere che cosa è il caso nel tuo progetto prima di iniziare a contribuire ad esso.

  6. Presenta . Vedi, il sito jQuery è ben fatto, con design professionale, contenuti di alta qualità, ecc. Ti fa desiderare di partecipare al progetto. Se invece hai un sito lento, brutto con contenuti che fanno schifo troppo, le persone preferiscono andare e contribuire ad altri progetti open source.

  7. Aggiungi strumenti di supporto . Ad esempio, la tracciabilità dei bug non è un'opzione per un progetto commerciale. Perché dovrebbe essere per uno open source? Può anche aiutare a sapere quali sono i punti che necessitano di un contributo. Se utilizzo il tuo prodotto open source, trovo un bug, vado al sito di tracciamento dei bug e trovo che il bug è il n. 1 nella lista, sarò più motivato non solo a risolverlo, ma anche a impegnarmi nei miei cambiamenti.

risposta data 16.05.2011 - 12:16
fonte
5

Costruisci e verranno.

Se c'è bisogno del tuo strumento, le persone lo troveranno attraverso i motori di ricerca e la parola di forum. Non fa mai male pubblicare alcuni post in forum di interesse speciale relativi al dominio in cui si trova il tuo strumento. Se ce ne sono, salta su un canale IRC con persone con interessi simili per farglielo sapere. Blog a riguardo (se hai un blog personale). In sostanza, più pubblicità fai, meglio è. Detto questo, se non c'è un bisogno, le persone semplicemente non lo useranno.

Quindi, in breve, sì, spingerlo su GitHub. Abilita la funzionalità dei problemi in modo che le persone possano registrare bug e un Wiki se il tuo strumento è abbastanza complesso da giustificarlo. Non scoraggiarti se non ricevi colpi immediati. A volte gli strumenti del SO possono impiegare un po 'di tempo per raccogliere vapore (anche se alcuni di essi sono un successo anche fuori dal cancello).

Buona fortuna:)

    
risposta data 16.05.2011 - 00:44
fonte
0

Prima di esaminare l'Altro consiglio prendi in considerazione:

Governance

Come sarà gestito il tuo progetto dopo averlo concesso alla comunità. Il modello del dittatore benevolo funziona, ma le persone cammineranno e andranno in giro se non ottengono benefici dal codice / progetto.

Proprietà del codice

Chi possiede il codice è molto importante, in quanto solo i proprietari (nella legislazione degli Stati Uniti) possono portare le persone in tribunale per far rispettare il copyright.

Questo è il motivo per cui l'FSF dice ai contributori di concedere loro la proprietà, e a loro volta concedono l'accesso al codice sotto la relativa licenza (GPL, LGPL versione 2.0 o 3.0).

Organizzazioni di governance

Non sono sicuro di cosa sia disponibile nel mondo PHP, ma ci sono un certo numero di plaform ed ecosistemi utili per la governance del codice. Ciascuno con la propria licenza e la propria struttura di governance.

Altre considerazioni sulla licenza

Dove verrà utilizzato il codice, chi lo ridistribuirà, quali sono le licenze correnti in cui vengono distribuiti il codice di piattaforma e simili. Tutti questi problemi forniscono indicazioni su quale licenza dovrebbe essere utilizzata.

Se non esiste già una community di interessi che puoi sfruttare, è molto difficile avere un progetto di successo da solo.

    
risposta data 16.09.2013 - 03:42
fonte

Leggi altre domande sui tag