abbra | (Reply)

From:

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

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

Я разрабатывал эту тему достаточно давно, но некоторое время назад меня попросили составить примерный план курса для программистов, в процессе написания которого я попытался эту тему изложить. Вот что получилось (тезисно):

Минимальный курс администрирования на практике, покажи Linux, OpenBSD и FreeBSD, как примеры воплощения POSIX. Этого хватит на часов 10-12, пусть Linux идет последним.
Остаемся на нем и продолжаем со скриптовыми языками -- как reusable components позволяют быстро выстроить нужное решение, часов 12 на примере, скажем, Питона и Ruby, обязательно не один язык, а два.
Теория по лицензиям и практикум по решению задач на комбинирование компонент (модулей питона или руби) и библиотек с целью получить приложение, которое имеет заданные лицензионные характеристики, например: "как получить потенциально коммерциализуемый код, имея определенным образом лицензированные модули и опираясь на них". Студенты должны научиться пользоваться sourceforge, freshmeat, etc., смотреть и читать лицензионные соглашения, понимать разницу между лицензиями.
Игровая составляющая: студенты устроят список рассылки, разделятся на core developers, contributors и users и попытаются добиться пропихивания каких-либо изменений в "upstream". С аргументированием добавления и отказа, с учетом web of trust, копирайтов и прочего. Конкретика проекта не важна, нужно дать понять им, что везде все одинаково и человеческое общение крайне важно.