Filipe Saraiva's blog

Tecnologia, sociedade e política.

Dicas para quem submeterá projetos ao Google Summer of Code

with 7 comments

Bem galera, o que seguem são algumas dicas para estudantes que submeterão projetos ao Google Summer of Code (GSoC). Elas são produto de conversas com participantes estudantes e mentores de outras edições, de participação em comunidades que já estão com alguns anos sendo mentoras no GSoC, e do envolvimento, que já contabiliza certa experiência, com comunidades de software livre.

Atenção! Estas dicas devem ser encaradas apenas como elas realmente são – dicas. Elas não são uma receita infalível sobre como ter seu projeto aprovado no GSoC, e além disso ela não contém todas as informações possíveis sobre o tema. Mas certamente, ela poderá servir de ponto de partida para a preparação técnica, sua e de seu projeto, ao Google Summer of Code.

Vamos à lista então!

1 – Trabalhe com aquilo que você já tem alguma experiência

É muito importante que você já tenha uma experiência prévia com a tecnologia que irá trabalhar no GSoC e já tenha familiaridade com o software que irá implementar funcionalidades. Por exemplo, se você nunca fez nada com visão computacional e não conhece o OpenCV, certamente não irá ser fácil ter algo aprovado para o projeto ou terminá-lo caso aprovado. Isso vale para a grande maioria dos softwares.

Ter experiência também é um diferencial na seleção com outros candidatos do programa. Cada organização tem um número limitado de estudantes que serão contemplados no GSoC. Se no momento da decisão entre um estudante e outro, algum deles tiver experiência técnica comprovada com o que irá mexer, ele certamente será a opção prioritária. Isso ocorre porque é importante que o aluno termine seu projeto do GSoC no prazo estipulado; caso o estudante abandone o projeto, ele prejudicará a comunidade na próxima seleção para organizações mentoras do programa. E você fica queimado naquela comunidade.

Claro, existem muitos participantes que não tem conhecimento técnico sobre o assunto mas tem seu projeto aprovado. Primeiro, a ideia do conhecimento prévio não deve ser confundida com o “conhecimento total” da tecnologia; ser intermediário nela, já ter feito algo e poder mostrar esse algo é legal. Segundo, participantes sem ter conhecimento existem, mas eles são a minoria no GSoC como um todo e devem ser encarados como exceção, não como regra geral.

2 – Participe da comunidade ao longo do tempo, e não apenas no GSoC

Se você já participa da comunidade a qual enviará um projeto, você terá mais chance de ser aceito do que alguém que chega na semana de submissão de projetos do GSoC.

Isso é evidente, pois uma pessoa que já está na comunidade já está participando dos processos dentro da mesma: já participou de organização de eventos, escreveu para os respectivos Planet’s, participa das listas e já está se familiarizando com o software e seu código-fonte.

Essa pessoa já demonstra algum comprometimento com a comunidade e com o projeto, algo que uma pessoa que acabou de chegar no deadline da submissão de projetos dificilmente conseguirá apresentar-se como tão parte daquilo quanto a pessoa que já está a mais tempo.

Caso você não tenha participação em nenhuma comunidade, não desanime: você ainda poderá ter seu projeto aceito. Caso não, continue a participar da comunidade e vá criando seus laços com a mesma. O GSoC é legal, mas ele não é o ápice de oportunidades que a participação em projetos de software livre poderá lhe proporcionar. Sim, sério mesmo.

3 – Converse sobre suas ideias e pretensões com os membros da comunidade

Durante o prazo entre a divulgação da lista de organizações mentoras e o deadline de submissões do GSoC, é de máxima importância que o estudante discuta com demais membros da comunidade sobre a ideia que ele pretende apresentar como projeto do Google Summer of Code. “Cair de para-quedas” faltando poucos dias para terminar o prazo de submissões, poderá fazer com que você acabe enviando um projeto imaturo e com inconsistências.

Isso é essencial porque é na conversa com os demais participantes que as ideias fluem, evoluem e se tornam mais embasadas, através do feedback de quem participa. Inclusive, é nelas que alguns participantes já se predispõem a serem seu mentor, caso o projeto seja aprovado.

Interessante também que nessa conversa você sabe das necessidades do projeto e das disponibilidades das pessoas. Em projetos que funcionam como “guarda-chuva” de vários projeto, como o KDE, Gnome, GNU, Linux e outros, pode acontecer de você querer trabalhar em algo específico e não ter ninguém com disponibilidade para ele naquele momento. Então, dá tempo de você partir para outro subprojeto ou acertar possíveis co-mentores que serão responsáveis por você.

4 – Demonstre no projeto como você pretende implementar a funcionalidade

No mundo do software livre temos espaço para todos os tipos de entusiastas: tradutores, desenvolvedores, pessoal de marketing e promoção, filósofos, sociólogos, designers e muito mais. Nos envolvemos tanto com o lado técnico quanto o teórico-social, entre outras denominações.

Mas o GSoC trabalha mais com o lado técnico da comunidade. Portanto, seja técnico na escrita do seu projeto. Não faça analogias nem divagações muito aprofundadas sobre comunidades e assuntos relacionados. Se mantenha na questão de implementação da funcionalidade.

Claro, você deverá falar sobre as necessidades que seu projeto irá suprir, e quais as consequências. Mas não se esqueça de escrever como você pretende implementar a funcionalidade que irá trabalhar, faça um esboço de estudos já existentes, qual toolkit será necessário, o projeto já usa algo que você poderia se aproveitar (ou não), algum diagrama de classe, outras implementações de sucesso que seguiram pelo mesmo caminho que você pretende trilhar, e mais assuntos relacionados.

Mas não exagere! Não vá fazer um artigo científico rigoroso nem nada absurdo para a sua comunidade, pois você poderá ser reprovado por “megalomania excessiva”!

5 – Seja prestativo sempre e respeite a comunidade

Se você tem dúvidas se o projeto que irá submeter será concluído satisfatoriamente; se você não tem ideia de como fará para implementar aquilo que você propõe; se você está com o tempo lotado durante o cronograma do GSoC; ou se você estiver com outras pendências que não o farão se dedicar bastante ao programa, é melhor deixar quieto e se preparar para o próximo ano.

Os projetos aprovados para o GSoC devem ser terminados para que a comunidade se aproveite de seus resultados e também não tenha dificuldades para ser eleita como organização mentora no próximo GSoC. Muitos projetos e comunidades de software livre se submetem ao crivo do Google para serem organizações mentoras, e mesmo tendo muitas aprovadas, a grande maioria ainda fica de fora.

E o estudante, por um motivo ou outro, abandona seu projeto, ele acaba prejudicando a comunidade inteira. O GSoC, devido ao seu prêmio financeiro, atrai a atenção de muitos estudantes e potenciais futuros contribuidores à projetos de software livre. Uma comunidade ou projeto que perde a oportunidade de participar desse programa, perde também essa visibilidade e apoio, o que ocasiona em menos investimento e desenvolvimento para a mesma.

Outra colocação importante: é melhor você deixar para se preparar melhor para o próximo ano do que tentar e depois abandonar. Lembre-se, você está lidando com uma comunidade, e em uma comunidade de software livre a meritocracia é importante. Se você falhar e for tentar de novo com a mesma comunidade, eles lembrarão de você. Portanto, é melhor você “não se queimar” de graça, concordam? Só não faça desse tópico um motivo para você nunca tentar. Se prepare e encare, não protele isto até o dia em que deixar de ser um estudante formal, pois aí você não poderá participar do GSoC.

Claro, existem motivos totalmente justificáveis para o abandono do projeto, que normalmente são imprevisíveis e de cunho fatalista para o proponente. Mas não são deles que estamos falando aqui.

———-

E estas foram as dicas que obtive a partir de vários participantes e mentores nos últimos anos do GSoC, e certamente ela não está completa. Espero que ela sirva como ponto de partida para você que está pleiteando um projeto nesse interessante incentivo ao software livre que a Google proporciona.

Mas diga lá, o que você achou destes 5 tópicos? Acha que existem mais alguns que poderiam ser acrescentados a esta lista?

Fique a vontade para se manifestar nos comentários!

Abaixo uma pequena lista com links para maiores informações:

Written by Filipe Saraiva

março 30th, 2011 at 6:53 pm

7 Responses to “Dicas para quem submeterá projetos ao Google Summer of Code”

  1. Rodrigo Sol disse:

    São boas dicas, mas diria que sou exceção a quase todas elas. Quando tive minha proposal aceita eu nunca tinha tido contato com o Mozilla TraceMonkey e nem conhecia ninguém da comunidade.

    A idéia do Sumer of Code é justamente atrair novos desenvolvedores e não apenas dar um grant para gente já ativa da comunidade. Se as comunidade estão exigindo conhecimento prévio elas estão na contra-mão do objetivo do projeto.

    Eu também tenho minha dica: capriche na proposal. Ela será seu cartão de visitas.

    Abraços

    • Filipe Saraiva disse:

      @Rodrigo Sol, Valeu Rodrigo!
      Bem, como eu havia dito nos tópicos, as dicas ajudam bastante mas existem exceções – e falo delas nos respectivos tópicos.

      A ideia aqui era mais para o estudante que não tem ideia por onde começar, entrar em contato com a comunidade e amadurecer sua proposta antes de enviá-la, algo que certamente ajuda o mesmo a ter um bom projeto e consequentemente mais possibilidade de aceitação.

      Abraços,

  2. Rodrigo Sol disse:

    @filipe exato. Achei o propósito do post muito bom. Só quiz confirmar que a exceção existe!

    Abracos

  3. Camila disse:

    Sobre o tentar e falhar, muitas pessoas falham no GSoC por acharem que não precisam dedicar 8 horas por dia para isso, as vezes mantém um emprego no periodo e aí é claro que vão falhar, Mas se você quer participar e TEM TEMPO para se dedicar, então você deveria tentar!
    Todos vão ser sempre bem vindos! Ninguém é newbie demais para tentar, o estudante tem um mentor para ajudar e toda a comunidade.
    (http://blog.lydiapintscher.de/2011/04/02/something-to-keep-in-mind-for-outreach/ e
    http://www.asinen.org/2010/10/fourteen-reasons-to-be-kde/)
    Eu to dizendo isso pois é um tanto desanimador ler algo como “você não pode falhar” e “vai ser sempre lembrado por isso”. Não é bem assim que funciona. Esse “falhar” e “ser lembrado” depende de muitas coisas. Todo mundo é sempre livre para tentar e falhar! Não desista!

    • Filipe Saraiva disse:

      Opa @Camila, bem-vinda!

      Bem, com certeza todos podem tentar, e ocasionalmente pode incorrer em falha, é normal – inclusive falei lá no texto sobre isso. 🙂

      Mas existem diversos tipos de falhas; existem aqueles que tentam verdadeiramente e falham, não conseguiram cumprir o esperado dentro do prazo, acontece e é normal. Mas existem aqueles que não se dedicam e, por assim dizer, trabalham para criar sua própria falha.

      Eu quis me referir a este último. Este sim, a comunidade irá lembrar dele com pesar. Do pessoal que trabalhou sendo mentor de algum novato – seja no GSoC ou fora dele – aqueles que não se dedicaram nos seus trabalhos, que sumiram no meio da execução, não entraram mais em contato, enfim, são lembrados e não recomendados para nada quando alguém pede alguma opinião sobre esta pessoa.

      Então, no texto eu me referi especificamente a estas pessoas, talvez não tenha sido muito claro. 😉

      Abração Camila, volte sempre!

  4. Camila disse:

    agreed 😉
    abração Filipe
    doida pelo akademy-br para encontrar esse povo denovo 😀

Leave a Reply to Camila