Caig 7 febbraio 2012 Nessun commento

Non hai mai avuto il desiderio di contribuire allo sviluppo di quel progetto di Software libero che tanto adori? È un modo per ringraziare la comunità di sviluppatori che ti offre così tanto senza spesso chiederti nulla in cambio. Come si fa a non sentirsi in debito e a non essere felici di esserlo?

Se questa idea ha trovato posto tra i tuoi pensieri almeno una volta, è facile che si sia scontrata con due possibili obiezioni:

“Non sono capace di X (di solito programmare), come potrei essere d’aiuto?”
“Sembra tutto complicato, non so nemmeno da dove cominciare!”

Non sei riuscito a vincere queste obiezioni? Provaci di nuovo, questa volta non da solo, ma salendo sulle solide spalle di un gruppo di persone che sono riuscite a oltrepassare l’apparente ostacolo tra la posizione di fruitore passivo e quella di attivo collaboratore di vari progetti di Software libero.

Ecco dunque Open Advice, un libro frutto di un anno di lavoro di Lydia Pintscher, molto attiva nella comunità KDE, che raccoglie l’esperienza di persone provenienti dal variegato mondo del Software libero.

È una raccolta di 42 brevi saggi in cui i vari autori raccontano la propria esperienza per trarne utili consigli: quello che avrebbero voluto sapere quando iniziarono a contribuire.

Gli argomenti sono particolarmente vari perché varie sono le possibilità di collaborazione: dalla programmazione al supporto agli utenti e alla creazione della documentazione, dalla traduzione alla grafica, dalla creazione dei pacchetti alla promozione, ecc.

Sfogliamo qualche pagina interessante. Riguardo la creazione di patch, un tipico modo di iniziare a collaborare con un progetto se si desidera programmare, Kai Blin (progetto Samba) scrive:

I have found that few general rules hold pretty much all the time,
and that is what this essay is about.
[...]
Patches doing only one thing at a time are easier to review.
[...]
Depending how the project handles patch submissions, a patch might
get lost in the noise. Do not expect to get your patch committed in
the first iteration.
[...]
Respond to comments on your patch promptly.
[...]
Writing good patches is not hard. There are a couple of things to
consider, but after writing a couple of them you should be on top
of those.

Il primo contatto con la comunità potrebbe anche essere scoraggiante. Mairin Duffy Strode (comunità Fedora e comunità GNOME) racconta la sua prima esperienza per poi trarne utili consigli, ecco qualche frase del suo racconto:

The project’s website indicated that they wanted help and that they
had an IRC channel, so I lurked in there for a week or two. One day
after a lull in conversation, I spoke [...]

“Go away” was the response. Furthermore, I was told that my
help was not needed nor wanted.
This set me back a few years in getting involved – just a few harsh
words on IRC made me afraid to try again for almost 5 years. I did
not discover until much later that the person who had essentially
chased me out of that project’s IRC channel was on the fringes of
the project and had a long history of such behavior, and that I really
had not done anything wrong. If I had only kept trying and talked
to other people, I may have been able to get started back then.

If you would like to contribute to Free and Open Source software
I guarantee you there is a project out there that really needs your
help.

Stuart Jarvis (comunità KDE) racconta le peculiarità della collaborazione con un gruppo di promozione e marketing. Dalla sua esperienza come redattore del sito KDE.News trae alcuni interessanti considerazioni:

With guidance from more experienced contributors, I eventually
learned how to propose something and get it published within a few
days if there were no major objections. The approach can be used
by any contributor to a free Software Promotion team, new or old
alike.
[...]
Importantly, do not ask people what they think – you
can wait for days or weeks and not get definite answers. Instead,
state that you will publish or submit your text or execute your plan
by a set date in the future, pending any objections in the meantime.
[...]
If there are big problems with your plan, someone will
tell you. Things actually get done, you do not get frustrated with
a lack of progress and you get a reputation for completing tasks
successfully.
[...]
Free software communities can easily become discussion groups. Ev-
eryone has an opinion. If you are not careful, discussions can become
large, fade away as people lose interest and finish without reaching
any strong conclusions.
[...]
When you are just starting out, it can be very confusing.
If you want your own task to succeed, you may have to make
decisions between competing view points.
[...] just state your conclusions and what you are going to do.
As long as you are reasonable, people are likely to respect you even
if they disagree.

Be proactive – do not wait to be asked.

Il libro è rilasciato con licenza CC-BY-SA, è disponibile in formato PDF o EPUB liberamente scaricabile o acquistabile in versione stampata. Per i più curiosi è disponibile anche il sorgente LaTeX.

open-advice.org

you in fact are already almost part of ours. The
question is whether you’ll choose to participate actively.

There is no limit as to what you can become – it purely depends
on your personal choice.

Fonte : http://blog.lydiapintscher.de/2012/02/04/open-advice/

Articoli correlati:

  1. NASA e Open Source forum
  2. Open Build Service alla prova!