Сложные open-source проекты

[metaclass]

Последний год был как-то богат на копание во внутренностях С и С++ проектов. Надо сказать, что опыта с обоими языками у меня очень мало, хотя синтаксис я знаю, представляю как программировать вообще, страуструпа прочел (до K&R не добрался). Так же мало опыта с make-файлами и прочей инфраструктурой. Посему большинство работы с оными проектами сводилось к "заставить это дело сбилдится, подправить пару мест кода, сделать dll, подключить ее к дельфи и забыть".

При этом я серьезно не понимаю одну вещь. Как для этих проектов (большинство из них open-source) появляются новые разработчики?

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

Т.е. человеку, чтобы въехать в это дело, надо сидеть и заниматься только этим и ничем больше месяцами. Вопрос - откуда сейчас возьмутся люди со знаниями, опытом и свободным временем для этого?
Студенты всяких околокомпьютерных специальностей могли бы - но у них нет опыта, и самое главное - нет цели использовать собственный продукт в промышленных разработках. А без такой цели все переделки будут абстрактными. Если же цель есть - то у них не будет свободного времени. Это же верно для разработчиков всевозможного коммерческого софта. Тупо начальство не поймет, если разработчик вместо реализации непосредственно нужных фич начнет улучшать используемый сервер БД или там займется теорией компиляторов, чтобы сделать в систему пару-тройку DSL.

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

Comments

[kkirsanov.livejournal.com]

А самое весёлое начинается когда несколько опенсорс-прожектов приходиться использовать в 3-м проекте.

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

[thesz.livejournal.com]

Дело привычки.

Пяток таких проектов и начинаешь понимать где, что и как лежит и/или может сломаться.

[jek-hor.livejournal.com]

Ребе, вы таки не поверите, но очень большому количеству разработчиков в таких проектах ещё и деньги за это платят.

[psilogic.livejournal.com]

Иногда интересно сбацать что-то свое - не за бабло, а именно из интереса. А потом другие начинают использовать, ну и пошло...

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

[qehgt.livejournal.com]

Гибкость языка и кроссплатформенные заморочки приводят к тому, что каждый проект содержит свой дичайший набор макросов для кроссплатформенной разработки, свои синонимы типов, кто во что горазд.

Это от непрофессионализма. В нормальных проектах код одинаковый и при этом работает на (к примеру) на linux/windows/dsp с разными размерами базовый типов и зачастую с разным endian.

Без всяких уродливых "#ifdef LINUX" посреди кода.

В коммерческих продуктах понятно - взяли на работу человека ... А в опен-соурсе как? Ну, kernel, firefox и прочий apache с OO пишут люди, получающие за это зарплату. В большинстве своём.

[noop.livejournal.com]

Хмм... Вообще-то не секрет, что очень очень многие опен-сорс проекты пишутся студентами. У них как раз есть время висеть на комьюнити итд. Можно потом писать, что "учавствовал в разработке ядра Linux", например. Ожидать "высшего пилотажа" в программировании от таких товарищей не стоит. Более-менее серьезные вещи пишутся либо за зарплату от спонсоров, либо дядьками-энтузиастами, которые на работе получают достаточно, а работают нечасто.

[(Anonymous)]

Пример, oracle-64 bit например десятка. Таскает за собой шкаф 32х битных скелетов, посему требует сертифицированную ось(пути к библиотекам, свой ld_preload и прочие бубны). С другой стороны свободные постгрес или мускуль собираются даже на самом страшном железе и осях, всё что открыто, довольно быстро(более или менее) переписывается и унифицируется(читайте чточто про мало опыта с make-файлами и прочей инфраструктурой где у open всё в порядке и собирается на автотулзах на всяком дерьмище). Иначе это как я уже выразился шкафы со скелетами старой архитектуры, до которых никому нет дела.

[dottedmag.livejournal.com]

>Во-первых, нужно быть совсем невменяемым человеком, чтобы лезть в дебри исходников всякого немелкого софта

А что там? Исходники как исходники. Садишься и быстро разбираешься что к чему.

>нужно иметь знания, опыт и свободное время

А на что их не нужно?

>нужно убедить главных разработчиков что твои патчи вообще имеют смысл

Гыгы. Т.е. главные разработчики - полные придурки, что не могут прочесть патч и решить, что он полезен, и их нужно долго умасливать?

>получить доступ на коммит в репозиторий, итд итп.

Не нужно.

>Да на одно только чтение списков рассылки на предмет того, не сделали ли уже то, что интересует, полдня должно уходить.

Стоит поставить нормальный почтовый клиент, который не заставляет тратить на одно письмо по десять минут.