OpenSource, и мой путь в него.

Опубликовал
programmeritc

 Мало кто из близких к IT людей может признаться в незнании понятий OpenSource (рус. Открытое ПО). Но далеко не все озадачивались мыслью, чем движима эта сила, почему многие компании успешно строят свою бизнес-модель вокруг, казалось бы,  по определению бесприбыльной деятельности. Бери, кто хочешь, используй, как хочешь (ну, в рамках лицензии, разумеется). Но, тем не менее, движение есть. И не на голом альтруизме оно построено, отнюдь.

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

1. Just for fun/lulz. Профита обычно не приносят, часто нет даже возможности отправить donation автору/авторам. Примеров приводить не буду — тысячи их.

2. Портфолио автора. Лучший пример, ИМХО, POP3/IMAP4 сервер dovecot. Долгое время автор Тимо Сирайнен, разрабатывал его на добровольных основах, но, текущей весной принял приглашение от одной североамериканской организации делать это полезное фултайм и за зарплату. При этом изменений, с точки зрения конечного пользователя, не произошло. Все также функионирует список рассылки, принимаются и интегрируются патчи, etc.

Курс-професія "Junior Data Analyst" від robot_dreams.
Комплексний курc для всіх, хто хоче опанувати нову професію з нуля.На прикладі реальних датасетів ви розберете кожен етап аналізу даних.
Програма курсу і реєстрація

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

 

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

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

В своей работе я достаточно часто останавливаю выбор на СПО, при этом стараюсь выбрирать, руководствуясь критериями функциональность/документированность/активность коммюнити. Внимательный читатель на данном моменте может задаться вопросом "а где же в этих рассуждениях путь автора в СПО?". Отвечу на этот вопрос: просто использование любого ПО я не считаю вовлеченностью в общее дело, так как каждая инсталляция — не более чем составляющая статистики. Не даром я отдельно отметил активность сообщества в критериях выбора — мертвое коммюнити с большей долей вероятности не заметит окончания поддержки продукта, пропустит ошибки и(или) уязвимости, не даст ответа на банальный вопрос, не заметит активности нового прользователя. Активным членом сообщества я стал в результате осознания самой модели, идеологии СПО. По мере возможностей дописывал и дописываю документацию, рапортую о ошибках и неправильном функционировании и с радостью обновляю ПО, в котором есть исправления, проделанные благодаря моей работе. Первый мой патч для open source продукта появился как результат некоторого усложнения и добавления функционала системы, поддерживать и дорабатывать которую довелось. После проведения апдейта я понял, что интеграция внесенных изменений, даже еплохо задокументированных, заняла немногим меньше времени чем первоначальная работа (с учетом регрессивного тестирования). Таким образом твердо сформировалась мысль, что проделывать двойную работу не есть очень полезно и производительно. Код был приведен в вид, максимально близко похожий на принятый в проекте (как по форматированию, так и по наименованию переменных/процедур), документирован комментариями, сформирован разностный файл (diff) и отослан разработчику. Дальше стало значительно проще. То время, которое тратилось бы на поддержание в актуальном состоянии самописного кода, спокойно можно потратить на разработку нового и тестирование функциональности. Автор тоже не в накладе, так как функционал и качество растет, потенциальная база клиентов — тоже. А продукт работает, и приносит доход. Более морализовать не буду, до новых встреч в эфире.

Disqus Comments Loading...