L’esperienza Open Source aiuta a trovare lavoro

Quando contribuisci a progetti Open Source, anche esistenti e radicati da tempo, i primi vantaggi immediati ai quali assisti fanno sicuramente parte del bagaglio culturale, infatti questa attività è primaria per migliorare le proprie competenze e far crescere la propria esperienza sul campo dello sviluppo software.

In linea indiretta questo però assume in molti casi anche un’altra positiva valenza, che può essere la strada per fare carriera e trovare lavoro. Mentre tu programmi per progetti esistenti, ti confronti e ti proponi, non stai facendo altro che far crescere il tuo nome in comunità di persone gigantesche. Questa popolarità un giorno potrebbe essere premiata. In questo articolo voglio evidenziarti 3 casi di successo che ti aiuteranno a capire meglio di cosa sto parlando.

Alexander Yurchenko, sviluppatore su Yandex

Alexander YurchenkoCon il tempo ho trovato il mio primo lavoro a pagamento, come sviluppatore di sistemi integrati, ero già stato uno sviluppatore ufficiale per il kernel OpenBSD per un anno. Con il termine “ufficiale” voglio dire che ho avuto l’accesso in scrittura al repository. Prima di allora, ho passato un anno da spettatore, con l’invio di patch per gli sviluppatori. Partecipare a un progetto del genere produce un’esperienza colossale. Un buon, grande progetto open source ha tutto ciò che viene in genere richiesto da uno sviluppatore durante i colloqui di lavoro: una buona pianificazione, una buona codifica, l’uso di sistemi di versioning e bug tracker, peer review, il lavoro di squadra, e così via. Così, dopo lo sfruttamento di un ambiente del genere per un anno o due, si ha una buona possibilità di crescere a un livello sviluppatore senior.
Che è, infatti, quello che è successo a me. Sono stato assunto come sviluppatore senior senza avere alcuna esperienza di lavoro formale sul mio curriculum. Dopo la prima settimana, il mio periodo di prova è stato ridotto da tre mesi a zero.

Kirill Gorkunov, sviluppatore per OpenVZ

Kirill GorkunovSi potrebbe dire mi sia iscritto a OpenVZ per caso. Dunque ho fatto per lo più programmazione delle applicazioni che aveva poco o nulla in comune con la programmazione del sistema. Ad un certo punto ho avuto il mio primo notebook a 64-bit (un Acer basato su AMD Turion 64), poichè non avevo un Windows a 64 bit, mi sono orientato su Gentoo. Ha funzionato bene più o meno, ma la sua installazione standard mancava di alcuni driver per cui ho dovuto compilare il mio kernel dai sorgenti. Era lì che mi sono imbattuto nel mio primo bug (non nel kernel, ma nel programma di configurazione). La ricerca sul Web non ha prodotto soluzioni, così ho deciso di risolvere il problema io stesso. Per fare questo, ho dovuto risolvere un sacco di attività correlate (come e con quali strumenti compilare il kernel, ecc). Dopo aver fatto una patch, l’ho inviata alla mailing list. La patch è stata davvero terribile (in futuro in fatti la rifarò), ma, con mia grande sorpresa, i manutentori del kernel mainline / vaniglia erano abbastanza contenti e non rifiutarono il mio progetto. Dunque, mi hanno spiegato come fare le patch in modo appropriato. Poi, ho iniziato a guardare in che modo il kernel stesso ha funzionato. Da questo punto di vista, la natura open source del progetto è stata inestimabile, perché mi ha permesso di guardare i problemi reali che vengono risolti. Mi sono chiesto spesso perché le cose sono state fatte in un certo modo, per cui la possibilità di contattare l’autore del codice è tornata utile.

Per alcuni anni, facevo riparazione di codice, inviavo patch, sempre rimproverato per il cattivo codice e elogiato di complimenti per il buon codice. Questa esperienza è stata impagabile. E si può essere certi che non appena si diventa bravi a farlo, le offerte di lavoro arrivano. Questo è, in effetti, come ho incontrato gli sviluppatori del kernel che lavorano su OpenVZ. Insieme, abbiamo deciso di continuare a lavorare sul kernel OpenVZ ed altro materiale correlato, così come il kernel vanilla, naturalmente.

Alexander Polyakov, uno sviluppatore Open source

Alexander Polyakov sviluppatore open sourceNon considero la mia storia originale in alcun modo. Ecco come è stato con DWM (un window manager dinamico per X). Ero davvero infastidito dal dover configurarlo tramite config.h e ricompilare dopo. Così, ho aggiunto la configurazione via xrdb, quindi fare clic su per mettere a fuoco, e così via. Questi cambiamenti sono andati oltre le linee guida del progetto minimalista così ho dovuto fare un fork del progetto. La stessa cosa è successa con DragonFlyBSD. I testi sul loro sito web sembravano interessanti, e mi annoiavo con FreeBSD. Poi si è scoperto che mancava il supporto per lingue diverse dall’inglese, così come il supporto per ACPI. Così, ho scritto le parti richieste di codice per una nuova versione di FreeBSD. Comunità di sviluppatori su IRC sono state di grande aiuto, fornendo spiegazioni e aiutandomi a risolvere i problemi. Lì ho acquisito qualche esperienza nel kernel e nello sviluppo di librerie di sistema. Ho anche fatto un po’ di soldi in questo periodo, un cliente mi ha trovato tramite git log. Voleva usare DragonFlyBSD nella sua produzione e aveva bisogno di un migliore supporto ACPI e alcuni driver RAID o qualcosa del genere.

Un altro progetto collaborativo è stato 9front. Ho migliorato il driver WiFi e la ACPI a me già familiare. Quella comunità ha ricevuto da me probabilmente la più piccola implementazione interprete AML. Il kernel era compatto, quindi è stato anche più facile da capire.

Per concludere

Impara a programmare con le realtà open source già esistenti, sfruttale per analizzare i loro problemi e aiutali a risolverli, in futuro raccoglierai ciò che stai seminando oggi. Puoi iniziare anche solo traducendo nella tua lingua, la documentazione ufficiale, di alcuni progetti grossi nei quali manca.

 

 

Avvia una discussione su questo tema per coinvolgere i lettori con le tue opinioni