Ho rilasciato codice open source utilizzabile da altri programmatori. Come faccio a farglielo sapere? [duplicare]

Ho ricevuto un paio di progetti su github ( link ) che hanno ricevuto alcuni utenti. Quello che faccio è:

Esempi

Gli sviluppatori sono pigri. Se non riescono a capire come utilizzare il codice, continueranno a cercare dopo un'altra libreria. Esempi chiari e concisi sono importanti

Documentazione

Quando hanno iniziato a usare la tua biblioteca, avranno bisogno di una sorta di documentazione per poterla configurare e usare come vogliono. Nessun documento = si arrenderanno.

Cronologia codice sorgente

Gli utenti saranno sempre scettici nei confronti di nuovi progetti. Non molti progetti open source sopravvivono. Basta dare un'occhiata a github / codeplex / sourceforge. ci sono molti progetti abbandonati. Non puoi aspettarti che gli utenti si tuffino fino a quando non avrai dimostrato che il progetto continuerà a vivere.

Articoli

Gli articoli sono un ottimo modo per attirare nuovi utenti. Ho un blog ( link ) e scrivo articoli su codeproject.com e altri siti simili.

In breve: il tuo progetto ha probabilmente bisogno di una spiegazione / introduzione pulita e semplice su quale problema aziendale risolva (biblioteca / progetto). Pertanto, ci dovrebbe essere una buona ragione per cui preferire la tua soluzione rispetto ad altri.

Quindi, con una spiegazione buona, pulita e breve si può ottenere l'interesse della comunità.

Come accennato, devi diffondere la parola sul tuo progetto "baby" in blog social media e programmatori . Consulta i forum correlati in cui viene discusso un problema specifico o il problema non è ancora stato risolto.

Risorse per esaminare i suggerimenti di condivisione e gestione di Github:

• Condividi il tuo progetto open source tramite GitHub
• Come dovrei creare un repository github per gestire un progetto condiviso?

Il mio primo passo sarebbe pubblicarlo su qualsiasi social media che usi.

Twitter, Facebook, Google+, forse anche il tuo profilo LinkedIn (se ne hai uno)

Sarà la via più facile per la diffusione delle parole da parte delle tue mani. Pubblica su Twitter, chiedi a tutti i tuoi amici di retwittare, chiedi ai tuoi amici di condividere e vedere cosa succede!

Qual è il progetto, se non ti dispiace chiederlo?

Dici che è molto utilizzabile per gli altri, per cosa? Se c'è una nicchia particolare che potrebbe trovare uso in essa (computer vision, elaborazione audio, interfaccia utente, analisi statistica, ecc.) È probabile che ci siano probabilmente numerosi forum e comunità online o anche fisiche intorno a questo. Se fai parte di un inizio lì. Crea un post nei forum, fai sapere alle persone cosa fa e dove sta andando il progetto. Se non ne fai parte, unisciti, sii social, parla con altri programmatori. Diavolo, potresti persino trovare un altro progetto a cui vuoi contribuire.

A quanto pare chi ha bisogno del tuo progetto, dei cui problemi intende risolvere, deve essere messo al corrente.

Penso Stack Overflow, come "La Wikipedia di Long Tail Domande di programmazione " è il posto giusto per il tuo pubblico di destinazione:

^{For every person who asks a question and gets an answer on Stack Overflow, hundreds or thousands of people will come read that conversation later. Even if the original asker got a decent answer and moved on, the question lives on and may continue to be useful for decades...}

Le pratiche e i principi di overflow dello stack possono anche guidarti su come presentare la tua soluzione in modo appropriato. Nota che questi si applicano anche al di là dei siti di rete Stack Exchange, è solo che qui, questi sono dichiarati esplicitamente e lucidati dalla vasta pratica di presentare problemi e soluzioni a questi.

In qualità di utente SO con reputazione elevata con esperienza probabilmente ne sei già ben consapevole e in particolare delle indicazioni fornite in sotto risorse:

• Overflow dello stack - > Come rispondere

  ^{Read the question carefully. What, specifically, is the question asking for? Make sure your answer provides that – or a viable alternative. The answer can be “don’t do that”, but it should also include “try this instead”. Any answer that gets the asker going in the right direction is helpful, but do try to mention any limitations, assumptions or simplifications in your answer. Brevity is acceptable, but fuller explanations are better...}

• SO FAQ - Posso promuoverti qui?

  ^{Be careful, because the community frowns on overt self-promotion and tends to vote it down and flag it as spam. Post good, relevant answers, and if some (but not all) happen to be about your product or website, so be it. However, you must disclose your affiliation in your answers...}

Nota che se non hai trovato domande per "abbinare la risposta" che vorresti scrivere, è legittimo (e anche incoraggiato) presentare la tua domanda e rispondere da solo. Se sei interessato ai dettagli, fai riferimento a tag wiki "self-answer" dei tag , ci sono abbastanza riferimenti utili agli articoli del blog SE. Puoi anche controllare alcune domande in quel tag MSO per scoprire cosa può andare storto e come farlo nel modo giusto.

Nel complesso, le tue tattiche possono essere piuttosto semplici. Trova (o scrivi la tua) descrizione del problema e scrivi una risposta spiegando perché e come potrebbe essere risolto dal tuo progetto. La risposta migliore che scrivi, maggiori sono le possibilità di upvotes, maggiori saranno le probabilità che raggiunga il tuo pubblico di destinazione.

Una cosa da evitare è postare link-only-answers - come probabilmente già sapete, sono piuttosto scoraggiati. Pubblicare solo un link al tuo progetto non ti porterà molto, è meglio dare una descrizione facile e comprensibile del progetto che spiega quali problemi risolve e come.

Supponendo che le domande pertinenti possano apparire in qualsiasi momento, potrebbe essere difficile essere sempre pronti a dare rapidamente una risposta di buona qualità. Per il tuo caso, il modo più naturale per essere preparati è avere un file readme proprio lì nel tuo progetto, con un testo che sarebbe facile da citare quando necessario per spiegare lo scopo e i punti di forza del tuo progetto . Tienilo sotto controllo delle versioni, aggiorna e ripulisci il testo e sarai sempre nella migliore forma possibile per inviare un messaggio al tuo pubblico di destinazione.

In un piccolo progetto semplice, il file readme come menzionato sopra può anche servire a fini di guida per sviluppatori, con sezioni per esempi di utilizzo, come iniziare, note di rilascio ecc.

Un'altra cosa per cui è meglio essere preparati è rispondere a domande tipiche sul tuo progetto. Prima di tutto, questi potrebbero essere come come iniziare e come usare - potrebbe essere molto utile avere risposte "in scatola" a questi nelle rispettive sezioni di readme , come menzionato sopra. Nota che se trovi che una sezione diventa troppo grande, nulla ti impedisce di "estrarla" in un file separato e semplicemente di farvi riferimento nel "file principale":

• ^{Come iniziare.
  Fai riferimento al file docs/QuickStart.txt
  Esempi di utilizzo.
  Fai riferimento al file docs/UsageExamples.txt}

Un altro tipo di domande da parte dei potenziali utenti che ci si può aspettare è "cosa succede se scopro un problema / bug nel progetto?" Questo tipo di domande è meglio servito da issue-tracking .

Per un piccolo progetto semplice con problemi minimi o nulli, questo può essere fatto semplicemente aggiungendo semplicemente una sezione "Problemi noti" nel file readme (se il monitoraggio del problema alla fine si eccessiva, probabilmente sarà necessario "migrare") al vero strumento di monitoraggio).

• <sup>: cosa succede se scopro un problema / bug nel progetto?
  - Sezione di aggiornamento "Problemi noti" nel file readme</sup>

Anche se ritieni che per alcuni motivi il tuo progetto sia privo di bug, è più facile indirizzare i richiedenti come sopra invece di dare loro lunghe spiegazioni sul motivo per cui non puoi avere bug (specialmente considerando che è improbabile che qualcuno crederà nel codice senza bug:).