Open source, salute della community e GitHub Sponsors
Un progetto open source vive di persone che possono leggerne il codice, segnalare un problema e proporre una modifica senza chiedere il permesso a nessuno. I benefici che l’esame si aspetta tu sappia riconoscere sono la trasparenza del codice, la revisione da parte di molti occhi, il riuso al posto della riscrittura e la reputazione che chi contribuisce si costruisce in pubblico. GitHub non si limita a ospitare questi progetti: fornisce gli strumenti che li rendono governabili. I community health files — README, LICENSE, CONTRIBUTING, CODE_OF_CONDUCT e SECURITY.md — dichiarano rispettivamente che cosa fa il progetto, che cosa è legalmente permesso farne, come si contribuisce, quali comportamenti sono accettati e come segnalare in privato una vulnerabilità. Lo stato di questi file è verificabile dalla checklist Community Standards, nella scheda Insights del repository. Le labels convenzionali good first issue e help wanted servono ai manutentori per indicare le issue aperte a chi arriva da fuori, mentre le Discussions ospitano le conversazioni che non sono ancora un bug o una richiesta di funzionalità.
GitHub Sponsors aggiunge il pezzo economico: permette di sostenere finanziariamente le persone e le organizzazioni che mantengono i progetti da cui tutti dipendono. Chi vuole essere sostenuto pubblica un sponsored developer profile oppure un sponsored organization profile e definisce dei tiers con i benefici associati; chi sostiene sceglie un contributo one-time o monthly ricorrente. Il collegamento fra repository e finanziamento è il Sponsor button, che si attiva dalle Settings del repository nella sezione Features → Sponsorships e si configura con il file FUNDING.yml collocato nella cartella .github del branch predefinito; può puntare a GitHub Sponsors, a piattaforme di finanziamento esterne o a un URL personalizzato. Confusione tipica da evitare: Sponsors serve a finanziare chi mantiene il codice, non ad acquistare piani, seat o servizi di GitHub.
Seguire persone e organizzazioni, stelle e scoperta dei progetti
Per restare informato sull’attività di qualcuno usi il pulsante Follow, che sul profilo di una persona si trova sotto l’immagine e sulla pagina di una organizzazione in alto a destra. Seguendo una persona ne vedi l’attività pubblica sul tuo personal dashboard; seguendo una organizzazione vedi le nuove discussions, le sponsorships e i nuovi repository. Il pulsante Unfollow, nella stessa posizione, interrompe il flusso.
Le stars sono una cosa diversa e l’esame ci gioca spesso sopra. Mettere una stella a un repository significa salvarlo per ritrovarlo dalla propria pagina delle stelle, ed è al tempo stesso un segnale di apprezzamento verso chi lo mantiene, perché il numero di stelle contribuisce alla popolarità del progetto; le stelle possono essere organizzate in lists. Quello che le stelle non fanno è iscriverti agli aggiornamenti: le notifiche su issue, pull request e release dipendono da Watch, non da Star. Per la scoperta vera e propria hai Explore, che propone repository e topic popolari, la search e i topics, le etichette tematiche impostabili dalla pagina principale del repository che lo rendono raggiungibile da chi cerca un argomento invece di un nome.
GitHub Marketplace: un catalogo di estensioni, non un negozio di piani
Il GitHub Marketplace è il catalogo dove trovi e installi strumenti che estendono il tuo flusso di lavoro: GitHub Actions, GitHub Apps e OAuth apps. Una action pubblicata qui diventa richiamabile dai workflow di chiunque; una app installata riceve dei permessi espliciti sull’account o sull’organizzazione che la installa. Esistono listing gratuiti e listing a pagamento: pubblicare qualcosa di gratuito è alla portata di chiunque, mentre vendere richiede che l’applicazione sia di proprietà di una organization e che il publisher completi la verifica, riconoscibile dal relativo badge sul listing. Errore da non commettere all’esame: il Marketplace non è il posto dove si scelgono i piani di GitHub, non è una bacheca di offerte di lavoro e non è un negozio di corsi. È un catalogo di integrazioni e automazioni, punto.
InnerSource: gli stessi principi dentro l’azienda
InnerSource significa adottare i flussi di lavoro tipici dell’open source all’interno dell’azienda, senza rinunciare alla sicurezza. Lo strumento chiave è la visibilità internal: un repository internal è leggibile da chiunque faccia parte dell’enterprise, anche da altre organization, ma resta invisibile all’esterno e ai collaboratori esterni. Accanto alla visibilità servono base permissions ragionevoli, così che i membri possano almeno leggere, e la discoverability: README curati, topics, wiki e GitHub Pages rendono un progetto trovabile da chi non sapeva che esistesse. Per la standardizzazione si usano i template repositories, che con Use this template generano un nuovo repository con la stessa struttura ma con storia git indipendente, e i repository centrali che raccolgono le action riutilizzabili.
Il punto su cui l’esame chiede una scelta è quale meccanismo usare: il fork è una copia collegata al repository upstream, con cui condivide la storia e verso cui puoi riproporre le modifiche tramite pull request, ed è la strada giusta quando non hai permessi di scrittura; il template serve invece a far partire progetti nuovi e indipendenti, tra i quali non potrai aprire pull request perché le storie non sono correlate. Se lavori nel repository e hai accesso in scrittura, non ti serve né l’uno né l’altro: ti basta un branch.