Суть GSoC

Всё просто: Google платит $5000 за каждый успешный проект. Код проекта обязан быть опубликован на условиях той или иной свободной лицензии. Студент-исполнитель получает $4500 (минус налоги), организация — $500.

Эта программа не единственная в своем роде. Существует, к примеру, более скромный по масштабам финский аналог под названием Kes?koodi, в рамках которого два года назад Нико Киирала реализовал в Inkscape поддержку нескольких фильтров SVG.

Чтобы вы в дальнейшем не путались, разъясню принятую в программе GSoC терминологию:

  • Организация. Группа разработчиков того или иного свободного приложения. Допускается объединение нескольких групп (примеры: GNOME, KDE, hugin/panotools). Направление может быть самым разным: от сетевых приложений и игр до мультимедии. В этой статье я концентрирую внимание на «графических» и «звуковых» приложениях просто потому, что планида у меня такая.
  • Проект. Проект — он и в Африке проект. Как правило реализуется одним человеком, хотя истории известно и объединение двух человек для работы над одним проектом.
  • Студент. Участник программы, исполнитель по утвержденному проекту. На момент официального работы над проектом (обычно это конец мая) обязан быть студентом того или иного высшего или среднего специального учебного заведения.
  • Руководитель. Своего рода научный руководитель студента, который ведет его от начала и до конца. Как правило, один из разработчиков. Английский термин — ментор — шутки ради легко переиначивается в дементора (см. ниже).
  • Администратор. Руководитель организации, отвечающий за нее.
  • Заявка. Текст, содержащий идею проекта, который студент отправляет в Google.
  • Слот. Оплачиваемый Google проект. У каждой организации фиксированное количество слотов. Если один проект на той или иной стадии выбывает, слот теряется, а выделенные на него деньги возвращаются в Google.

Программа начинается с того, что некий проект по разработке свободной программы решает поучаствовать в ней. Определяется администратор организации, запасной администратор, который в случае необходимости (болезнь, отпуск, фатальная влюбленность, похищение инопланетянами) заменит его, группа дементоров, а также, по возможности, группа запасных дементоров. Сообща они пишут заявку на участие, в которой объясняют, кто они, каков у них опыт и как именно они собираются справляться с жизненными невзгодами вроде исчезновения студентов.

Помимо заявки готовится и публикуется список идей. Обычно в него включают «хотелки», на которые у самих разработчиков вечно не хватает времени. Поскольку в Google работают не дураки, написание документации как потенциальный проект заведомо исключается. Но «хотелки» бывают разными: организация Audacity умудрилась в этом году выбить себе проект с кодовым названием "bugfix ninja", чтобы побыстрее выпустить версию 1.4.0.

В дополнение к этому можно заручиться поддержкой группы специалистов, формально не являющихся участниками сообщества вокруг создаваемой организации, но имеющих заметный вес в своей сфере. Два года назад организация hugin/panotools умудрилась создать небольшой комитет из автора SPi-V Альдо Хебена, создателя QTVR Кена Турковского и других людей, хорошо известных в сообществе панорамных фотографов. Понятно, что не у всех такое может получиться, но если возможность есть и попасть в программу очень хочется, то почему бы такой возможностью не воспользоваться?

Затем в Google рассматривают все заявки и решают, какие организации подходят, а каким лучше попробовать еще раз в следующем году. В этом году из-за рецессии было принято урезать количество участвующих организаций. Как Лесли Хоторн (руководитель программы GSoC) мрачно пошутила в списке рассылки для дементоров, в прошлом году при урезании организаций кровищей был заляпан весь пол. О том, что происходило в этом году, можно только догадываться. Но лучше не стоит: здоровый сон важнее. Известно только, что в программе участвует 150 организаций и 1 000 студентов ровно. Для сравнения, в прошлом году было 175 организаций и 1125 студентов. Не так уж сильно и урезали. Участников даже больше, чем в 2007 году.

После официальной публикации списка принятых организаций можно приступать к поискам студентов. Но это в теории. В реальности же стоит заняться этим пораньше. Связано это с тем, что второй подготовительный этап программы во многих странах приходится на экзаменационную пору, и информация о программе до студентов вовремя попросту не доходит. В прошлом году из-за этого даже пришлось на две недели продлить поиск студентов и принятие заявок от них.

Итак, найденных студентов знакомят со списком идей и спрашивают между делом, нет ли у них каких-либо собственных интересных идей. В этом году была настоящая катастрофа: такого количества заявок, написанных под кальку с описаний выдвинутых дементорами идей за предыдущие четыре года еще не было. (У меня лично создалось впечатление, что по всему земному шару неласковое солнышко прицельно выжгло инициативу молодежи через озоновые дыры.) Проработав идеи со своими потенциальными руководителями, студенты оформляют их как заявки и бережно складывают на сайте GSoC.

Здесь я хочу сразу предупредить руководителей проектов: не цепляйтесь за интересную идею только потому, что она необычна, привлекательна или даже кажется очень и очень нужной. Далеко не каждый успешно реализованный проект GSoC идет в дело. Скажем, замечательный прошлогодний проект hugin/panotools по созданию редактора масок, встроенного в диалог предпросмотра панорамы, в результате сочли выбивающимся из существующей технологической цепочки. По-настоящему успешным будет тот реализованный проект, которые целиком и полностью вписывается в концепцию приложения.

Поскольку на все стоящие идеи слотов может не хватить, руководителям приходится, угнетаясь муками совести, голосовать против одних проектов в пользу других. Критерии оценки тут самые разные, и о них я расскажу ниже, в красках. Голосование осуществляется через веб-формуляр прямо под заявкой студента. В этом году Google ввел в строй новый движок под названием Melange, где публичные комментарии оказались неосторожно включенными по умолчанию. Поскольку раньше они по умолчанию были скрытыми, кое-кому это стоило нервов.

Наконец, Google окончательно согласовывает число слотов с каждым проектом, не забывая о том, что финансирование программы имеет свои пределы, и публикует окончательный список утвержденных проектов. Далее студентам дается несколько недель на медитацию, сдачу экзаменов и небольшие радости жизни, после чего начинается собственно Лето кода.

В середине июля производится промежуточная оценка результатов, по итогам которой студентам либо выплачивают половину обещанной суммы, либо на прощание машут ручкой. Бывает и такое.

Во второй половине августа производится окончательная оценка результатов, после чего авторам успешных проектов высылается вторая часть денег, а организациям перечисляют деньги за каждый успешный проект. Поздней осенью Google проводит на территории своего комплекса конференцию для руководителей и участников Summer of Code.

Почему Google делает это

У общественности на этот счет, как обычно, есть свое особое мнение, и даже не одно. Мне попадались четыре наиболее распространенных точки зрения:

  1. У Google есть секретные планы на разрабатываемый код.
  2. Программа является замаскированной кузницей будущих кадров Google.
  3. Google некуда девать деньги, и они таким образом пиарятся.
  4. Компания просто очень любит открытые проекты.

Итого, две теории заговора, одна теория от анонимных аналитиков ЛОР, мир праху их, и одна теория всеобщего гуманизма. Самое интересное, что почти у всех этих теорий есть право на жизнь. Довольно сложно не заметить, как много проектов традиционно получает организация OSGeo при хорошо известном интересе Google к ГИС. Случаи приема бывших студентов на работу в Google тоже есть. Ну а о том, что компания завышает page rank сайтам свободных проектов, не знает только тот, кому акронимы PR и тИЦ не говорят вообще ничего.

По поводу третьей приведенной точки зрения я могу сказать одно: при том, сколько времени и сил сотрудники Google тратят на работу со свободными проектами, всерьез говорить о пиаре у меня лично как-то не получается. Может быть у вас получится.

Критерии отбора и перестраховщики

Несложно сообразить, что чем популярнее организация, тем больше заявок и тем сложнее выбирать между ними в условиях известной стесненности в слотах. Скажем, не очень популярная организация OpenICC, число заявок в которой никогда не превышало четырех штук, а количество подтвержденных проектов — двух, ВНЕЗАПНО, получила в этом году три практически одинаковых заявки на один и тот же проект, предложенный самими руководителями, плюс еще несколько заявок на другие проекты. Популярным организациям в таких случаях приходится идти на крайние меры и вводить жесткие условия отбора студентов. Но у жестких условий есть еще одна предпосылка. О ней и поговорим.

Когда в этом году мы (hugin/panotools) общались с потенциальными студентами, один из них резко возразил против некоторых наших правил. Правила эти таковы:

  1. Студент должен написать один-два патча перед началом программы;
  2. Студент должен разбираться в панорамной фотографии или как минимум интересоваться ею;
  3. Студент по возможности должен быть родом из сообщества.

Наиболее громкие возражения раздавались по поводу первого из них. Этого же правила, кстати, придерживаются еще несколько знакомых мне организаций, и вы сейчас увидите, почему. Казалось бы, с какой стати студент должен вникать в чужой код и писать патч, если никто не гарантирует, что руководители голосованием пропихнут его заявку наверх, а там уже для нее найдется слот? Не маловата ли морковка и не со слишком ли большого расстояния ею машут?

Дело тут вот в чем. Существует совершенной реальный риск полной потери студента или частичного срыва проекта. Причин тому может быть несколько: от потери интереса к проекту или внезапной госпитализации до банальной нечестности. Большинство хорошо известных мне организаций по тем или иным причинам теряли либо студентов, либо массу времени:

  • один из студентов hugin/panotools выбыл потому, что у него помимо завышенной самооценки еще и оказалась не готова среда сборки; к моменту промежуточной оценке результатов он не сделал ничего толкового, и мы были вынуждены завалить его.
  • одна из студенток Inkscape, которая должна была в 2006 году заняться оптимизацией расхода памяти, исчезла сразу после того, как ее приняли в программу; нет-нет, она жива и здорова, но нас обходит за версту;
  • один из студентов OpenICC угробил почти три недели на создание сборочной среды с Qt3 в Windows, на что в Linux у него при наличии быстрого соединения с Интернетом ушло бы минут двадцать от силы (проект он, тем не менее, завершил успешно).

Таким образом патч к исходному коду фактически означает, что а) у студента готова сборочная среда и б) он успел немного изучить исходный код. Ни одна известная мне организация после перехода к перечисленным выше правилам еще не потеряла студента.

Как тут обойтись без страшной истории? В прошлом году перед началом GSoC я поинтересовался у Михаэля Шумахера, администратора организации GIMP, ввели ли они это правило у себя, зная, что в 2006 году они потеряли двух студентов. Михаэль ответил, что не считает это нужным. Результат? Проваленный проект по созданию диалога поиска по фильтрам. Но и в этом году правило на вооружение взято не было. А между тем на кону шесть очень важных проектов. Скрещиваем пальчики, дамы и господа.

Впрочем, разбавлю бочку дёгтя ложкой меда: студент hugin/panotools, которого мы в 2007 году завалили на промежуточной оценке, в прошлом году снова подал заявку на участие уже другой организации и, вы не поверите, успешно завершил свой проект. В связи с этим потенциальным руководителям и администраторам хочу сказать следующее: голосуя за того или иного студента, нужно отдавать себе отчет в том, что вы признаете его готовым к реализации этого проекта и несете за это вполне определенную ответственность. И если вам кажется, что он может не потянуть выбранный проект, провентилируйте эту тему как можно серьезнее.

Перед тем как выбрать, за какие проекты голосовать, стоит поинтересоваться у студентов, что они собираются делать в случае возникновения непредвиденных обстоятельств, таких как, скажем, поломка компьютера, на котором планируется работать над проектом. Казалось бы, совершенно несерьезный вопрос. Тем не менее, в 2006 году студент, работавший над импортировщиком DXF в Inkscape, выбыл из-за фатальной поломки своего единственного ноутбука, не успев как следует сделать свою работу. Его код до сих пор мертвым грузом лежит в исходниках программы. Другой студент Inkscape в прошлом году также из-за поломки своего ноутбука не смог довести до полной готовности уже успешно завершенный проект по созданию инструмента геометрических построений. На это затем наложились еще и семейные обстоятельства. В итоге этот интересный инструмент, первым в полную силу использующий динамические контурные эффекты, в состав версии 0.47 уже не войдет.

Еще одно правило-пожелание — привязанность к сообществу — против которого мне тоже приходилось слышать тихие возражения, прекрасно иллюстрируется примерами, когда бывшие студенты становились постоянными членами сообщества и руководителями проектов GSoC. Сходу могу назвать три таких примера:

  1. Майкл Выброу, создавший инструмент Соединительные линии для Inkscape, в этом году руководит Arcadie Cracan, который берется довести эту работу до конца.
  2. Йохан Энгелен, в 2007 году реализовавший в Inkscape динамические контурные эффекты, в 2008 уже руководивший группой французских студентов, расширивших эту функцию, и в том же году снова успешно завершивший проект GSoC по дальнейшей интеграции в программу библиотеки lib2geom.
  3. Владимир Кузнецов, написавший в 2007 году физический симулятор для пакета образовательных программ KDE, в этом году сам руководит студентом, который должен создать симулятор потоков газа и воды.

Проект Inkscape как организация интересен тем, что четверо студентов за эти пять лет участвовали в программе GSoC дважды.

Заинтересованность в дальнейшей работе над проектом критически важна, поскольку каждый активный участник оставляет после себя код, так или иначе требующий поддержки. Насколько интерес к проекту сильнее простого желания подзаработать, легче всего выяснить по телефону. Юв Леви, снова администрирующий в этом году hugin/panotools, уже второй год проводит интервью по Skype с потенциальными студентами и задает им разные неудобные вопросы, чтобы лучше понять, с кем мы имеем дело. Настоятельно рекомендую администраторам других организаций в будущем делать то же самое.

Кстати, заинтересованность отлично обеспечивается написанием научной работы по мотивам проекта. Так поступил, к примеру, Лукаc Тврдый, студент KDE/Krita: он посвятил свою научную работу моделированию настоящих кистей. Если вы, занявшись графикой, надумаете поступить так же, отметьтесь по результатам в вики CREATE, если вам не сложно.

В общем, идеальный студент GSoC обладает следующими характеристиками:

  • активный участник сообщества;
  • умеет программировать на языке, используемом в проекте;
  • умеет планировать свое время;
  • владеет английским в степени, достаточной для установления взаимопонимания со своим руководителем;
  • проект является частью его научной работы;
  • студент, спортсмен, комсомолец... хммм? :)

Так что, кто мы после всего этого? Мечтатели? Или, скорее, жлобы и эгоисты? Ну, может быть. Это до сих пор не мешало Юву Леви отправлять подробные личные письма каждому из студентов, не прошедших конкурс. Ну и потом, как вы уже поняли, жесткий отбор и перестраховка существенно снижают риск неудачного завершения проекта. Пользователи в конечном счете от этого только выигрывают, получая более функциональное и удобное приложение.

Несколько рекомендаций студентам

Необходимо абсолютно четкое, документально зафиксированное понимание того, что вы должны предоставить в конце. По этому документу будет производиться окончательная оценка успешности проекта. В ходе проекта его запланированный результат, в принципе, может быть пересмотрен, но рассчитывать на это не стоит.

Планируя работу на лето, следует отдавать себе отчет в том, что этот понедельный план, вероятно, придется пересмотреть. Особенно это касается тех случаев, когда проект предполагает не только практическую, но и существенную теоретическую работу (такой проект был в 2007 году у организации OpenICC — управление цветом в HDR). При этом за выполнение плана отвечаете вы. Поэтому если у вас есть какие-либо сомнения касательно плана, смело делитесь ими со своим руководителем. К моменту начала работы над проектом у вас должен быть разумный минимум сомнений по поводу того, что вы успеете закончить его в срок. Вообще, не стесняйтесь советоваться с научным руководителем, даже если вам кажется, что вы слишком третируете его расспросами. Коммуникация — ключ к успешному проекту. К одному из замков успеха. Многих замков.

Если случилось страшное, и вы все-таки осознали, что откусили кусок, который не можете прожевать, немедленно свяжитесь со своим руководителем и выработайте такую стратегию изменения проекта, при которой ваша работа будет полезна проекту и сможет быть засчитана. Лучше всего, если знамение осенит вас до официального начала работы над проектом: в этом случае разрешается полностью изменить суть проекта. А еще лучше, если вам все это лишь на секунду показалось: свои моменты слабости бывают у каждого. Нужно лишь уметь отличать их от реальных затыков.

Вполне возможно, что ввязываясь в GSoC, вы столкнетесь с недостаточно документированным кодом. В этом случае имеет смысл хотя бы часть времени между принятием в программу и официальным началом работы посвятить изучению исходников, делая для себя пометки. Джейсон Майкл Перпетуа, занимающийся в этом году проектом по добавлению поддержки GPU в GEGL, свои заметки по GeglBuffers написал настолько хорошо, что их после небольшой доработки собираются включить в официальную документацию.

Перед началом работы запланируйте себе пару недель отдыха и согласуйте это со своим руководителем по проекту. Лучше всего отдых назначить на время сразу после промежуточной оценки проекта, т.е. на июль. Так вы и не выдохнетесь, и сохраните мотивацию для дальнейшей работы в виде уже наполовину готового проекта. Потому что, чего уж там, проект может оказаться сложнее, чем вы думали, а от работы кони дохнут.

При возникновении каких-то особых обстоятельств, требующих временного выбывания из проекта, лучше всегда отправить короткое уведомление своему руководителю. Никто вас за форсмажорную паузу не укусит. Гораздо хуже, когда вы исчезаете без предупреждения. Один из студентов Audacity, внезапно и без объяснений пропавший на три недели, в прошлом году таким образом провалился на конечной оценке. Следует отдать ему должное: свою ошибку он признал и проект в итоге доделал. Но вторую половину денег не получил.

Эти дементоры такие дементоры

Думаю, вы не сильно удивитесь, если я скажу, что отношения между студентами и их руководителями во время программы складываются очень по-разному. Со студентами, прошедшими отсев вроде описанного выше, проблем как правило исчезающе мало. В отдельных случаях о них можно вообще забыть, в то время как они будут тихо работать, успевая делать всё в срок или даже опережая собственный график. У hugin/panotools в прошлом году было два таких студента, и в этот раз мы с удовольствием снова взяли их.

Тем не менее, контроль все же нужен. Во-первых, всю разработку рекомендуется открыто вести в общем дереве разработки (возможно, в отдельной ветке). Во-вторых, имеет смысл просить студентов присылать еженедельные отчеты руководителю с копией на администратора и запасного администратора. И если успешность того или иного проекта начинает вызывать опасения, вы всегда можете потребовать от студента перейти на ежедневные отчеты.

Кстати, если у вашей организации есть агрегатор блогов, можно предложить студенту вести блог, чтобы о прогрессе узнавали не только руководитель, администратор и группа наиболее бесстрашных пользователей, живущих на CVS/SVN/git, но и сообщество, сложившееся вокруг. Англоязычные блоги студентов, работающих над приложениями по работе с графикой, мы обычно добавляем на graphicsplanet.org. Радостные комментарии пользователей в стиле «Офигенно, пиши дальше!» без усилий раскручивают стрелку барометра мотивации до положения «Ясно». Проверено на практике.

Выше я приводил пример, когда мы были вынуждены завалить одного из студентов. Вам это кажется жестоким? Объясню причины.

  • Нежелание портить отношения с Google. Если бы меня волновала политкорректность, я поставил бы эту причину последней в списке (или не упомянул вовсе). Но я ставлю ее в начало, потому что при теоретически равном весе причин я считаю ее более важной на практике. Если студент вопреки обещаниям откровенно не тянет свой проект и не торопится признавать это, мы не имеем права пропускать его во вторую половину программы, потому что он не заслуживает денег, которые выплачивает ему Google, а мы, соответственно, не заслуживаем денег, которые получаем как организация. Элементарная честность.
  • Желание попасть в GSoC в следующий раз. Следствие предыдущей причины плюс изрядная доля цинизма. Ну а что вы хотите? Есть подозрение, что серьезные провалы снижают возможность попасть в программу в следующий раз (не исключено, что именно по этой причине после двух провалов в 2006 году GIMP пролетел с GSoC в 2007 году). Ваши пользователи не виноваты в том, что студент решил поводить вас за нос, а вы оказались недостаточно сообразительны, чтобы раскусить его. Они хотят, чтобы проект развивался, а ведь GSoC — тот самый катализатор (примеров — бесчисленное количество).
  • Благо самого студента. Именно так, без шуток. Даже когда студент серьезно разочаровывает, при заваливании нужно подробно объяснить причины и вообще держать марку организации, которая «сурова, но справедлива». Звучит до неприличия пафосно, но холодный душ иногда все же действует отрезвляюще. Мы в этом убедились.

Неудачно завершенный проект — провал не только студента, но и самой организации. Если к промежуточной оценке вы внезапно осознаёте, что студент все это время преданно смотрел вам в рот и ждал, когда же вы по пунктам объясните, что и как он должен делать; если у вас возникает конфликт на почве того, что он не понимает, почему он вообще должен проявлять инициативу, это означает что лично вы допустили ошибку, не разъяснив в самом начале правила игры и проголосовав за него в ущерб другому, возможно, более достойному сопернику. Если вы не поняли студента, а студент не понял вас, это ваша общая ошибка. Возможно, вы оба были недостаточно внимательны, но вероятнее всего вы попросту мало общались.

Конечно, нет ничего лучше личных встреч. Благодаря конференциям вроде Libre Graphics Meeting и Linux Audio Conference эта мечта становится реальностью. В этом году на LGM'09 организация hugin/panotools имела удовольствие в течение четырех дней общаться с двумя из пяти студентов: Девом Гошем (мозаичный режим в hugin/panotools) и Юлией Коцерубой (LightTwist) и убедилась в правильности выбора. Конечно, я тороплюсь с оценкой, но ощущения у нас возникли именно такие.

Эта мечта, как вы понимаете, сбыточна не для всех. Зато существует предостаточно способов мгновенного общения в онлайне. Взамен традиционных IRC, Jabber и прочих Google Talk рискну предложить видеоконференции и телефонные звонки по SIP или Skype. По опыту могу сказать, что студенты порой стесняются сообщать в письмах о возникающих затыках, в то время как в разговоре эта стесненность быстро выплывает наружу и может быть оперативно разрешена в вящему удовольствию обеих сторон.

И вот мы подходим к самому главному.

По большому счету, зачем?

Есть опасность удариться в унылое морализаторство или, хуже того, остервенелый пафос, однако... Когда Дон Аллингтон и Саша Ройзман после шести лет упорной работы были вынуждены по очереди на время оставить разработку замечательной программы GRAMPS, они не бросили свой проект на произвол судьбы, а оставили за главного одного активного участника сообщества, который со временем собрал вокруг себя новую команду разработчиков.

Почти на год оставившие разработку Inkscape Тед Гоулд и Брайс Харрингтон, стоявшие у истоков проекта, тоже были уверены в том, что без них проект не загнется. Вы сами убедитесь в их правоте через месяц, когда выйдет новая версия 0.47.

Как несложно догадаться, я говорю о преемственности, которая важна в любой работе. Осознание того, что начатое вами не будет немедленно похоронено после вашего ухода — один из немногих действительно работающих мотивов, когда черная полоска зебры растягивается в бесконечность.

Есть и более прагматический аспект. Успешные проекты с активным сообществом разработчиков — Mozilla Firefox, OpenOffice.org, GIMP — создают вокруг себя целую экосистему, в которой помимо прочего возникают коммерческие отношения: заказные разработки, консультационные услуги, курсы и т.д.

Но всё это касается выгоды для проекта. А какая выгода от него студенту? Подытожу:

  • весомый абзац в резюме;
  • возможность профинансировать свою научную работу;
  • возможность профинансировать работу над любимым проектом;
  • ценный опыт совместной работы над проектом;
  • ценный опыт разгребания чужого кода и написания своего поверх или даже вопреки чужому;
  • бесценный опыт управления личным временем в условиях, приближенных к боевым.

И еще на одном пункте я остановлюсь более обстоятельно, поскольку считаю его важнее прочих. Примерно полгода назад я обратил внимание на знакомую фамилию, периодически мелькающую в списке разработчиков Inkscape. Сверившись с интервью с разработчиками Krita, уточнил в частном порядке: «Ты не тот самый Билл Бакстер, написавший Impasto?». «Ого!» — удивился Билл — «Я и не думал, что об этой работе знает кто-то кроме парочки академиков». Если вы читали интервью, то знаете: за пять лет, прошедших с момента публикации научной работы ни в одном (свободном ли, закрытом ли) известном проекте его замечательная, а главное проверенная идея действительно реалистичной имитации живописи так и не воплотилась.

Посмотрим правде в глаза: если вы послали свою научную работу на SIGGRAPH и в августе выйдете с этой знаменитой ежегодной выставки, сжимая в руке контракт от Pixar, Mitsubishi или Adobe, вы — счастливчик, один на миллионы и миллионы студентов, чьи научные работы будут пылиться без дела или оседать на сетевых сборниках рефератов. GSoC, хоть и не является серебряной пулей для проблемы в целом, но все же дает дополнительную возможность реализовать ваш научный проект в коде и сделать его используемым другими, даже если вы сами не планируете в будущем возвращаться к нему. Причем небезвозмездно.

Надо отметить, что количество участников программы из России и бывших стран СССР за последние два года заметно подросло. В этом году:

Хочется надеяться, что количество по-настоящему интересных работ, связанных с открытым ПО и сделанных в России и соседних государствах, будет только расти. И если с GSoC в этом году вы уже в пролете, всегда можно найти интересные задачки и в одном из любимых проектов.

Автор: Александр Прокудин. Дата статьи: 25.05.2009

Источник и исходной текст статьи:
http://www.linuxgraphics.ru/articles.php?article_id=66
Last modified: Thursday, 14 July 2011, 6:47 PM