Главная » Хабрахабр » Дилетант в opensource — lessons learned за 3 года

Дилетант в opensource — lessons learned за 3 года

Она сэкономила мне немало времени и нервов. Давно, в 2014 году я сделал для себя небольшую утилитку, чтобы перегонять C#-вьюмодели в TypeScript-код. Так началось моё дилетантское участие в разработке открытого ПО. И вот, в сентябре 2015 я решил оформить свои "эксперименты на коленке" в некую удобоваримую форму и вылить их на GitHub. И вот, вчера в репозитории с этим проектом, наконец, появился юбилейный, трёхсотый коммит. Время шло. Я изложу некоторые цифры, расскажу несколько прохладных историй, а так же поделюсь впечатлениями каково это — написать и поддерживать opensource-проект без мам, пап и кредитов поддержки компании, оплаты и… и свободного времени. В связи с этим знаменательным событием, я бы хотел поделиться своим дилетантским опытом о том, с чем придётся столкнуться, если вам вдруг взбредёт в голову разработать что-то "на благо развития индустрии". Заходите под кат, присаживайтесь, мы начинаем.

Какие-то из них известны, какие-то не очень, какие-то вообще приватные. Начнём с того, что на GitHub более 90 миллионов репозиториев. Вы только представьте какая же это долбанная бездна кода и проектов! В виду массовой популярности, Github начали использовать студенты для заданий, преподаватели для лекций, авторы книг для туториалов и даже энтузиасты для законодательства. Что же это значит? Однако же, ставлю бутыль коньяку что если к вам прямо сейчас привяжется журналист и попросит назвать известные репозитории, то навскидку вы назовёте… ну где-то 15-30. И, может быть, 5-10 их друзьям. А значит это то, что GitHub — это огроменная вселенная программных продуктов, большинство из которых, я уверен, известны только их авторам.

Стать более-менее заметным в этой толпе довольно сложно, скажу я вам.

Зачем я рассказываю настолько очевидные вещи, спросите вы? Даже если вы украдёте данные банковских карт всех-всех пользователей мира и выложите их на GitHub — то я уверен, что вас забанят и возбудят уголовное дело этого просто никто не заметит. Особенно для автора этих строк 🙂 Особенно 3 года назад. А вот… вот ни черта они не очевидные! Ну серьёзно, раз уж какой-то left-pad, состоящий по существу из 47 строк кода набрал тысячу звёзд, то моей штуковине-то, которая объективно упрощает разработку — ну 300-то наберётся, так ведь? Тогда я наивно считал, что достаточно сделать что-то действительно полезное, указать теги, написать README и люди сами всё найдут, сами всё скачают.

К сожалению, так это не работает. Ммм… нет. Если посмотреть на график распределения звёзд, то можем наблюдать взлёт почти под 90 градусов как раз в то самое злополучное время. left-pad создан в 2014 и был решительно никому неизвестен до известных событий 2016 года. Из этой дивной истории, очевидно, есть несколько печальных выводов:

Без должного маркетинга ваша самая лучшая идея в мире останется незамеченной.
Чёрный пиар — тоже пиар
Не всегда сумасшедшее количество звёзд говорит о том, что проект хорош

Если вы уже приготовились впасть в депрессию по этому поводу, то мой вам совет — отложите носовые платочки и подушку для рыданий. Но не всё так плохо.

Прежде всего — полезное для себя. Лучше делайте что-то полезное.

Вот вам лично, читающим этот пост. Прикиньте без какого программного продукта вам жизнь не в радость. На вашей работе или в вашей повседневной жизни. Какого приложения, фреймворка, сервиса чёрта вам не хватает? Отлично. Прикинули? Заводите репозиторий, открывайте IDE и пишите. Забейте в гугл и если от выдачи по вашему запросу веет тоской и невнятностью — вперёд! Разгадка проста — если конкретно вам ваш же проект приносит пользу, то во всём мире, скорее всего, наберётся тысяча-другая человек, которым это так же поможет и которые будут вам благодарны. Пишите то, о чём мечтали, собирайте и выкладывайте. Далее дело за малым — донести свои наработки до всех этих замечательных людей и не расплескать по дороге. Уверен, на первое время вам такой аудитории более чем хватит.

Если на собеседовании, кандидат упоминает свой opensource-проект, то следующим же пунктом его начинают распинать на тему "а сколько звёзд?", "сколько скачиваний?", "в скольких живых проектах используется?". Слышал я, в некоторых компаниях есть такая практика. Если менеджеру (или кто там вас собеседует) приходит в голову такой вопрос, то с близкой к стопроцентной вероятностью, он с разработкой свободного ПО никогда дела не имел, о маркетинге не слыхал, да и в целом мало придаёт значения звукам, которые сам же издаёт. Так вот, ответственно вам заявляю: таких вопрошающих надо быстрым и решительным движением языка посылать в пень, вставать и уходить с собеседования, навсегда забывая имя этой компании и друзьям о нём рассказывая. Работать с таким не получится.

Печально, но, видимо, факт: по моим наблюдениям, за популярными и крупными проектами так или иначе стоят компании.

Да да, даже если у вас есть "пятница-для-своих-проектов" — что, думаете её нет в бюджете? Например в виде прямого финансирования разработки: если проект делается в рабочее время, то он де-факто оплачивается. Ну или в виде поддержки "персоналом", а-ля "Вася, иди помоги Олегу сделать фичу в его проекте". Или в виде информационной поддержки (статьи, конференции, видео). NET Core, когда есть целые отделы, занимающиеся такими проектами. И это если не говорить о совсем уж откровенных случаях финансирования opensource-разработки вроде EntityFramework или . Или всё и сразу (тут конспирологи могут задать вопрос "кому же это выгодно", но мы и до этого дойдём).

И нет, я не жалуюсь — я сам на этом настоял, чтобы все права и контроль над разработкой остались у меня. Мне же из ресурсов компания предоставила разве что бесплатное тестирование моих наработок на живых людях. Неудобно как-то людей отвлекать. Да и для компании, с которой контракторские отношения связывают меня последние 4 года, IT — это не то чтобы профильный бизнес. Взамен получает приоритетное право на поддержку и багфиксы, а так же консультации, внедрение и обучение персонала. В общем, в сухом остатке сошлись на следующем: компания относится с пониманием, поддерживает морально и предоставляет свою систему для проверки и обкатки проекта на живых пользователях. Божечки, я говорю словами крупного интегратора, хотя в моём проекте всего-то около 5 тысяч строк (без тестов).

Лирическое отступление про помощь компаний

У меня куплена 2015 студия, 2017я Community Edition, но помимо этого я пользуюсь ReSharper-ом от JetBrains. Ой, а был ещё такой интересный случай. Помимо прочего, у меня так же есть аккаунт на Azure, где за символические деньги размещён простенький веб-сайт с информацией обо мне, ссылками на проекты и документацией. И он у меня тоже куплен. У JetBrains есть программа бесплатных лицензий для опенсорс-разработчиков. Так и вот. Копеечку, но сэкономлю. Ну я и думаю — дай, заапплаюсь. Почему бы и нет? Будет у меня подарочный ReSharper. Мол, так и так. Написал, значит, письмо на требуемый адрес. Дайте, мол, лицензию. Делаю такой-то проект, вроде как опенсорс. В ответ приходит такое:

We have checked your Open Source project to see if it meets all the requirements of JetBrains’ Open Source License Program.
We have to inform you that according to the rules of our program, if the project provides any paid services (training, consulting etc), we cannot issue free licenses on general terms.
As I can see on your project’s website it does provide some commercial services (http://www.reinforced-sc.com/Info/Contact), therefore, unfortunately, I won’t be able to provide free open source licenses for your project.

По существу им не понравилось, что на своём сайте (который посещают 3,5 анонимуса) я написал что готов предоставлять коммерческие консультации и индивидуальную коммерческую поддержку по любому своему проекту (из двух, хе-хе). Короче, опуская подробности. Как вы понимаете, предложений, конечно же, не поступало. Ни стоимости услуг, ни каких-то конкретных условий — просто, мол, "если вдруг надо — вы пишите, договоримся". В конечном счёте получил такой ответ: Что я сотруднику JetBrains и попытался объяснить в непродолжительной переписке.

If your project does not provide commercial services then please remove the commercial section from the website and let me know once you do it — i will then issue an open source license for you.

Нет, ребята, это так себе предложение. "Ну ни фига себе" — подумал я — "это значит получается я должен удалить с сайта информацию об открытости к коммерческим предложениям в обмен на 200 долларов (стоимость лицензии на ReSharper) в год?! И не стал продолжать диалог. Спасибо, не надо".

если мой проект используется в компании, в которой я работаю, но разрабатываю я его в свободное время — это считается оказанием коммерческих услуг? Тут, конечно много вопросов: во-первых, сколько маны небесной рекомендуется употреблять во время разработки, чтобы не потолстеть? JetBrains готов финансировать бесполезные проекты? Во-вторых: если мой проект не используется в бизнесе — он получается бесполезен? Так может его ещё и в резюме не указывать? а если я указываю свой opensource-проект в резюме и это повышает мои шансы быть нанятым — это же тоже коммерческое использование? Необходимо уточнить! А вот ещё бывает что компании поддерживают контрибьютора информационно — это же тоже деньги просто в другом виде? Совсем ничего не понимаю.

Первая же идея, которая пришла мне в голову — надо написать как этим всем пользоваться. В общем, как вы понимаете, я встал перед задачей раскрутки и пиара водиночку. Идея была не столько в "я сделяль"-пиаре, сколько в том, чтобы разместить на хабре ну хоть какую-то русскоязычную документацию. Здесь я решил схитрить и совместил полезное с полезным — я написал первую статью об RT на хабр (за которую и был приглашен НЛО). Так и родились первые три статьи, которые были довольно холодно встречены аудиторией. Мои коллеги всё равно из России, поэтому для них нужен был хотя бы небольшой мануал, а объяснять каждому в переписке или голосом одно и то же не хотелось. Это и понятно — вряд ли кому-то из хабра-сообщества они были полезны, так что по этому поводу я не переживаю.

Мысль о том, что неплохо бы дать людям какие-нибудь знания о том, как моим фреймворком пользоваться не давала мне покоя, пока я её окончательно не сформулировал в таком виде:

С документацией вот какая штука: она бесполезна без кода проекта, а код проекта бесполезен без неё.

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

Конечно же через doxygen, что же ещё может прийти в голову программисту? Как дилетант подходит к написанию документации? Я задался целью запилить XMLDOC (это как javadoc, только в C#) таким образом, чтобы сборка в Release не выдавала ворнингов "об отсутствующих комментариях для публично-видимых членов". Сказано — сделано.

В общем всё, что не internal и не private в понимании C#. К публично-видимым членам компилятор C# относит типы, методы и свойства, видимые "снаружи", при использовании вашей сборки другими пользователями. И всё это надо как-то пользователю объяснить. В настоящее время статистика такова: в проекте около 150 публичных типов (всего — около 250), которые содержат суммарно около 700 публичных методов и 260 пропертей. Я приуныл, но сел писать.

Как, скажите мне, в одном предложении сформулировать на что влияет поле класса? Через первые 20 задокументированных пропертей я заметил, что мой писательский потенциал как-то поиссяк, а словарный запас поистощился. Я зауважал технических писателей. Желательно при этом не использовать пассивный залог, причастные обороты и громоздкие описания обстоятельств времени. Меня осенило: можно подсмотреть как решают проблему с пропертями в MSDN! Ребят, правда: берегите технических писателей — у них действительно собачья работа. Это действие подарило мне абсолютно дивную словесную конструкцию.

Попробуйте начать описание свойства класса со слов "Gets or sets whether..." — каким-то магическим образом концовка сама приходит к вам в голову!

Словом, стало легче.

Процесс документирования был прекращён, код был тщательно проанализирован на предмет того, что пользователю действительно нужно, а без чего пользователь обойдётся. Через 30 задокументированных классов я начал понимать, что что-то в моём проекте слишком дофига этих самых "публично видимых членов". Вот как истинные профессионалы решают проблемы с документацией, да! В результате примерно на треть хлама, нуждающегося в документировании, лёг ровным слоем модификатор internal (это как package в Java). Словом, стало легче. Скрывай лишнее.

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

И doxygen не спасёт. Выяснилось, что одних лишь стандартизированных комментариев в коде недостаточно!

А запихивать примеры использования в каждый класс и каждый метод — это утопиться ж можно! Дело в том, что в суровой реальности пользователь смотрит на reference-портянку, заботливо сгенерированную doxygen-ом, и видит 150 классов, интерфейсов и enum-ов, которые чёрт ногу сломит как между собой связаны. Внезапно, стало совсем плохо. К завершению написания XMLDOC-а я подошёл в полной уверенности, что без "человеческой" документации обойтись не получится.

Выбор пал на казавшуюся мне дивной документацию к Autofac, сделанную на платформе ReadTheDocs.ord. Покончив с XMLDOC-ом, я решил посмотреть как устроена документация в уже существующих проектах и остановиться на варианте, который мне больше всего бы понравился. Решение принято, я засел за написание плана документации. Меня впечатлил формат reStructuredText. Получалась полная фигня. И представляете что? Как пользователь будет это читать? В какой последовательности излагать? На что откуда должны быть ссылки? Что сначала, что потом? Тонна вопросов и вот уже черновики планов летят в урну.

Его усилиями мне был выделен студент, желающий познать тайны искусства технического текста. Я решил попросить помощи и обратился к замечательному chebureque, который на ту пору только начинал своё большое дело по оказанию услуг технической документации. Пришло осознание, что проект весьма специфичен и требует знания многих технических деталей. В ходе нескольких недель работы, студент был замучен описаниями и звонками о том, что и как надо писать. А если я буду говорить голосом и контролировать процесс, то на работу, обсуждения, согласования и ревью у нас уйдёт никак не менее полугода. Если я начну их описывать текстом, то… То в итоге это, чёрт побери, и будет документация! Так что последний был вознаграждён за месяц усилий и отправлен с миром, да благословением. Столько времени и свободных денег на оплату работы студента у меня попросту не было.

Сделать её усилиями одного человека за вменяемое время фактически невозможно. Я остался один на один с пониманием, что хорошая документация к проекту — это долго и дорого.

Как только всё, что пришло в голову было записано, я переставил блоки текста в последовательности, которая мне кажется правильной, разделил по страницам и вылил в GitHub. Закончилась же эта история в лучших традициях: автор психанул, взял встроенную в репозиторий github wiki и просто начал чистым markdown-ом писать то, что ему приходит в голову про проект. Так и живём. Хай будет.

image

Но переписывать что-либо, если честно, сил просто нет. Это сейчас я знаю про эту картинку. Печально. Констатирую, что в вопросах документации я-таки сдался.

Я выпустил ещё 9 версий пакета в NuGet, починил баги, добавил функциональности. Прошло время. В то время я находился в Эстонии (потому что почему бы и нет?) и меня осенила гениальная идея! Итак, шёл 2016 год и я снова подумал что неплохо было бы рассказать о своём проекте ещё кому-либо.

А почему бы не сходить на конференцию и не показать там что у меня есть в репозитории?

Нигде не говорили про C# и TypeScript. Выдача гугла по запросу "european it conferences 2016" озадачила меня. Темы максимально абстрактные, формулировки максимально широкие. Везде web, мобильные устройства, роботы, криптовалюты, IoT. Походив по сайтам, почитав анонсы и заголовки, я с удивлением обнаружил, что огромное количество конференций проходят, буквально, "ни о чём". Столько всего, а пойти некуда! Воистину, паранойя и футурология! Описания гласили нечто в духе "вызовы бизнесу в эпоху повсеместного Интернета", "облачные технологии в современной экономике", "эволюция коммерции на рубеже веков". Но да ладно. В названиях прямо читается немая просьба "эй, кто-нибудь, пожалуйста придите и расскажите что же со всеми нами будет!".

Я написал организаторам и спросил — можно ли? Поскитавшись изрядно и почитав всякого, я нашёл неприметную, почти что местячковую конференцию DeveloperDays 2016 в Польше. Только, говорит, у нас правило есть — все, кто регистрируется слушателем выбирают по 10 интересующих их спикеров. Довольно быстро мне ответил один из организаторов, парень с трудно произосимым именем Кржиштов и сказал что можно. Я отправил описание, с меня так же попросили фотографию, и я стал ждать. Пройдёте этот отбор — мы вам и билет подарим, и размещение оплатим. Написал Кржиштову и тот подтвердил мою догадку. Через пару недель молчания в почте, я сделал смелую догадку что меня не выбрали. Говорит, ваша тема, к сожалению, заинтересовала только двоих человек.

Делать мне не фиг в Краков тащиться! — Не расстраивайтесь — говорит мне Кржиштов — всё равно приходите.
— Ага, щаз! Но пишу, конечно же — Ничего, всё в порядке. —… думаю я. Удачи вам с конференцией.

Счётчик скачиваний в NuGet неожиданно пошёл вверх, а в проект добавилось ажно порядка 10 звёзд. Непредвиденные последствия начались после. Я бы даже сказал, с катастрофически польскими, потому что эти люди начали создавать issues! Конечно же, от пользователей с подозрительно польскими именами и удивительно польскими фамилиями. Всё больше просили фич и задавали вопросы, которые не освещались в документации. Что странно: багов почти не находили. В итоге, после третьего же бейджика faq, присвоенного очередному закрытому тикету, ко мне пришла, вероятно, самая лучшая маркетинговая стратегия для своего проекта.

Черт побери, это гениально! StackOverflow!

И о чудо — моим ответам поставили плюсики! Я зарегистрировался и первым же делом пошёл и нашёл целых три вопроса про экспорт C#-классов в TypeScript, на которые незамедлительно и ответил наглым самопиаром. Там было указано что отныне все вопросы принимаются на StackOverflow по определённому хэштегу, о создании которого я попросил одного из пришедших пользователей. В срочном порядке был переписан README на более доходчивый, а чуть позже была добавлена секция Support policy. На хэштег я подписался через RSS и с энтузиазмом приступил к этапу поддержки проекта. Потому что ну реально удобный формат для хранения FAQ.

При том от людей из абсолютно разных мест и компаний! После того, как RT засветился на StackOverflow — в проект начали медленно, но верно течь звёзды. Географически же звёзды приходили из разных уголков мира — США, Дания, Германия, Румыния, Канада, Австралия… И даже Беларусь! В списке stargazers отметились люди из Barclays и Microsoft. По секрету скажу, что одно время в Insights было видно, что за некоторыми страницам документации упорно наблюдают из JIRA какой-то американской компании.

Приятно. На StackOverflow же я получил несколько вопросов, на которые оперативно ответил, за что был вознаграждён плюсиками и репутацией. Неприятно. В issues периодически приходили багрепорты, которые я старался более-менее оперативно чинить. Я естественным путём пришёл к их необходимости, не пытаясь покрыть тестами что-либо заранее. В какой-то момент в проекте появились тесты. Это простенькие, но гордые регрессионные тесты, в которых я воспроизводил присланные баги (к сожалению, не все — по техническим причинам) и чинил, закрывая баг ссылкой на тест.

TDD — удобно, но только с определённого этапа и только для контроля регрессии.

Это ясно из лайков и коротких, но душевных благодарностей вроде И знаете — люди-таки приятно удивляются, когда их баг во фреймворке более-менее оперативно фиксится.

image

Почти все они были смерджены в мастер (пусть и с изменениями), что прибавило проекту контрибьюторов — их уже целых 10, хотя 99% кода по-прежнему остаётся за мной. Было получено несколько небольших, но хороших пулл-реквестов.

Экосистема развивается настолько быстро, что я буквально не успеваю выкатывать обновления! Самые большие проблемы поддержки были с несколькими конфликтующими фич-реквестами, а так же с тем, что как C# так и TypeScript довольно быстро меняются.

NET Standard, пройти 3 релиза . За время существования RT, успел уйти dnx, появится . NET Core, выйти около 20 релизов TypeScript и под всё это добро мне приходилось оперативно выпускать апдейты, чтобы не выпасть из тренда.

NET Core 🙂 А вчера я узнал, что один из фрейморков-конкурентов до сих пор не выпустил поддержку .

Несмотря на все получаемые благодарности, поддерживать такой проект и обратную связь с пользователям довольно сложно (кто бы мог подумать!). Ощущения, как ни странно, тревожные. Да, это опыт: опыт общения с аудиторией, написания документации, несения публичной ответственности, планирования. Да, я делаю полезное дело, но… мне-то это зачем? NET Core, да купила баба порося). Технический опыт в конце концов (сдался мне этот . Если честно, то ничего. Однако что это даёт помимо опыта?

Работодатели? За последние 3 года никто этим проектом не интересовался помимо его непосредственных пользователей. Пха! Рекрутёры? Ссылка на проект торчит во всех профилях, но не упоминается ни в одном письме с предложением о работе. Не смешите мои тапки. А отдельные индивиды даже просили меня приложить к резюме пример кода zip-архивом — вот настолько у ссылок на GitHub развит навык мимикрии и невидимости! Как будто его не существует. В общем, приготовьтесь к тому, что в карьерном плане небольшой, но живой OSS-проект вам не особо-то поможет.

Да на самом деле почти ничего. Что даёт opensource-проект своему автору?

Показателен интерес Microsoft к OSS — через . Зачем же тогда?
Я могу понять зачем OSS нужен компаниям: они таким образом поднимают себе репутацию на ровном месте (opensource как форма публичной благотворительности) и увеличивают доступность своих технологий для потенциальных пользователей (повышают охват). И как по мне — имеют право! NET Core и "Microsoft loves Linux" активно привлекаются пользователи на MS-инфраструктуру, в которой немало интересных коммерческих продуктов — Azure в частности. Цель благородная, средства законные.

Да-да, вот например Percona берёт mysql, собирает кастомные билды, фиксит баги и допиливает фичи "под заказчика". Компании зарабатывают на opensource. Но в основном продаёт свою экспертизу в области использования mysql для ваших тёмных делишек. Иногда, разумеется, и в сам mysql коммитит, и на вопросы отвечает.

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

Так же используют OSS, внезапно, и для политических целей — я слышал историю о том, что, якобы, через разработку Apache Harmony, ныне почивший Sun Microsystems принуждали открыть исходники JRE (могу ошибаться, слухи всё-таки).

Делов-то — убедить босса в том, что занимаешься очень полезным делом, "делаешь мир лучше" — и готово. Я могу понять зачем OSS нужен сотрудникам компаний, если такую деятельность компании готовы оплачивать. Компания же может использовать этот проект для технопиара — показать, мол, "смотрите как удобно работается в нашей компании — сотрудники от безделия ажно свои проекты создают, а мы открыты к идеям" и т.п. Можно получать зарплату и самому себе ставить задачи. И такую версию событий слышал.

Здесь лучший вариант — выбрать какой-нибудь существующий проект и основательно в него покоммитить. Я могу понять зачем OSS нужен молодым разработчикам — получить промышленный международный опыт, показать себя. С таким опытом хорошо идти на собеседование в серьёзные компании — будешь знать что примерно происходит в живой разработке, интереснее отвечать на вопросы на собеседовании. Поучаствовать в обсуждениях, войти в user group, community, поотвечать на вопросы, пооказывать поддержку. Можно гордо повесить на себя бейджик "member of something user group, contributor". Да и английский попрактикуешь в конце-то концов.

Именно поэтому я называю свой опыт дилетантским. Сделать же большой и сколько-нибудь известный OSS-проект самому, с нуля, в современных реалиях практически невозможно, как мне кажется.

Нет, программист вы, скорее всего, честный и хороший. И дело вовсе не в том, что вы — плохой программист. А вот маркетолог, сотрудник техподдержки и технический писатель в одном лице — скорее всего нет.

А чтобы его построить — нужны или деньги, или огромное количество времени и сил, которыми, опять же, у вас нет возможности разбрасываться — иначе у вас станет существенно меньше денег и, как следствие, еды в холодильнике. Для того, чтобы проект всерьёз работал на ваши карьерные и рекламные цели, вам нужно построить вокруг него заметных размеров community.

Особенно дивный мир "настольного" Linux. Мне кажется, что единственное место, где бесплатные продукты, сделанные одиночками с нуля действительно ждёт целевая аудитория — это, пожалуй, linux. Однако уже и туда компании принесли свои ресурсы и деньги. Система не то чтобы сильно популярная, много чего из программного обеспечения нет — вот пользователи и рады любой разработке. Но рынок есть рынок. Вообще как-то даже обидно, что из "творческого порыва", смелого экспериментаторства и возможности самореализации для разработчиков, opensource превратился в один из инструментов ведения бизнеса и маркетинга для компаний. Без такой помощи открытому ПО было бы гораздо хуже, чем есть сейчас. В конце концов деньги потрачены, результаты есть.

Если какая-то коммерческая структура заявляет, что она-де "поддерживает opensource", подразумевая повышенную духовную чистоту и благодетель — это в большинстве случаев наглая ложь и передёргивание. Но давайте просто будем честными.

Компании не делают то, что им не выгодно.

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

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

Я призываю снять розовые очки и не думать, что если компания поддерживает OSS, то это безвозмездная забота об индустрии и делается от большой доброты душевной. Нет, я не призываю, разумеется, к коммунистической революции, "отнять и поделить" и "изгнать всю коммерцию из opensource". Я бы сказал, что компании выгодно вкладывать копеечку при условии, что её уши будут торчать из проекта во все стороны. Вовсе нет. Как только это условие нарушается, компания теряет к проекту всяческий интерес. И в этом нет никакой благотворительности. Но получите ли его вы? А если интерес есть, то будьте уверены — компания свой гешефт получит. Вот в чём вопрос...

Напоследок я приведу некоторые цифры о своём проекте: Ладно, будем прощаться.

  • около 5000 строк кода, 225 классов, 1428 методов, 380 пропертей;
  • 43 релиза выпущено;
  • 84 issues закрыто;
  • 10 контрибьюторов;
  • 107 звёзд;
  • 28 форков;
  • 1100 посетителей за неделю;
  • ~50 000 скачиваний-установок в NuGet (примерно 40 раз в день);

Ссылка на GitHub, ссылка на NuGet.

Успехов!


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Киберпреступники пять месяцев контролировали ASUS Live Update

Злоумышленники разместили на сервере вредоносный файл с бэкдором, подписанный валидным сертификатом ASUS. Как сообщает «Лаборатория Касперского», хакеры из APT-группировки ShadowHammer 5 месяцев контролировали сервис обновлений ASUS Live Update и заразили более полумиллиона компьютеров по всему миру.Исследователи из «Лаборатории Касперского» обнаружили, ...

Kubernetes 1.14: обзор основных новшеств

14. Этой ночью состоится очередной релиз Kubernetes — 1. По сложившейся для нашего блога традиции, рассказываем о ключевых изменениях в новой версии этого замечательного Open Source-продукта. 14 и сооветствующих issues, pull requests, Kubernetes Enhancement Proposals (KEP). Информация, использованная для подготовки ...