Мудрость использования открытого исходного кода в коммерческом программном продукте

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

Плюсы кажутся:

• Это делает для меня много вещей, которые в противном случае включали бы либо много стандартного кода, либо рекомендуемое Microsoft, но более медленное решение (Entity Framework).

Минусы:

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

Какой здесь консенсус? Разумно ли использовать в моем проекте открытый исходный код, который я не знаю / не понимаю так же, как и свой собственный код?

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

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

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

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

Как только вы начнете входить в сферу своей деятельности, вам будет сложнее найти OSS, отвечающий вашим потребностям. Но нет необходимости повторно внедрять еще один продукт ORM. Если dapper достаточно сложен, чтобы вы не смогли отладить и исправить его код, как бы вы оправдали тратить все человеческие часы на написание его с нуля? Кроме того, вы можете (должны?) Всегда смотреть нестандартно на решения NoSQL, пока вы на нем.

Даже Линус признался, что пытался найти решение SCM, которое отвечало бы всем его критериям, до разработки Git. По крайней мере, он смог объяснить, почему ни одно из существующих решений не было достаточно хорошим.

В какой-то момент моей жизни я перестал хотеть переписывать все сам и хотел сосредоточиться на решении реальных проблем. Большинство проблем, которые необходимо решить в бизнесе, зависят от конкретной области. Найдите способы писать меньше кода, а не больше.

Примечание: я не сотрудник Microsoft. Мнение полностью личное. В последние 5-7 лет много мыслей об использовании обоих открытых источников в сочетании с крупными поставщиками в качестве разработчика.

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

Города-призраки: проблема с открытым исходным кодом в 2012 году заключается в том, что это уже не 2000 или 2005 год. Количество проектов продолжает расти, когда количество пользователей, усыновителей, участников примерно такое же, как и много лет назад. Аудитория растянута тонкая. Многие интересные проекты стали несвежими, заброшенными. Нет такой вещи как бюджет проекта с открытым исходным кодом. Поэтому, когда интерес заканчивается, нет никого, кто честно объявил бы, что поддержка закончилась и выключил свет. Проекты никогда не умирают, чтобы привлечь внимание общественности к чему-то лучшему и новому. Таким образом, открытый исходный код всегда будет расти и фрагментироваться. Не имея обратной связи в виде денежного вознаграждения или финансовой смерти, они являются бессмертными существами, существующими во славу вечную.

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

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

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

Я работал над несколькими успешными проектами для крупной компании, которая использовала существенное количество программного обеспечения с открытым исходным кодом. В частности, я использовал Curl, SQLite и Webkit для очень крупной компании в успешных проектах, поставляемых конечным пользователям. Как уже говорили другие, это просто вопрос осторожности с лицензиями и в идеале, чтобы юрист посмотрел их.

Существуют сотни лицензий с открытым исходным кодом, но обычно они делятся на две категории: стиль BSD и стиль GPL. Лицензии в стиле BSD не требуют, чтобы вы открывали исходный код, и, как правило, просто содержат какое-то положение об атрибуции. Лицензии в стиле GPL требуют от вас открытого исходного кода. Большинство компаний (включая мою) обычно смотрят на это косо, поэтому вам следует избегать стиля GPL. Dapper использует лицензию Apache в стиле BSD. Всегда выясняйте, каковы общие условия лицензии, прежде чем приступить к написанию кода.

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

По моему опыту, открытый исходный код с большей вероятностью будет содержать ошибки или сбои, чем платные решения или, если уж на то пошло, решения «сами по себе». Если вы посмотрите на некоторые из наиболее известных инструментов с открытым исходным кодом, качество очень высокое.

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

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

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

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

Предполагается, что проблемы с лицензированием здесь не проблема: бегло взглянув на Dapper, я заметил, что в нем всего 2255 строк хорошо документированного и читабельного кода . То есть

• достаточно большой, чтобы вы могли потратить несколько дней или недель на создание кода сопоставимого качества, делая то же самое
• достаточно мал, чтобы вы могли понять, что он делает, и исправить любые ошибки в этом коде, если они появляются в производстве

Если вы собираетесь написать что-то подобное самостоятельно и «заново изобрести колесо», у вас гораздо более высокий риск того, что ваш собственный код покажет ошибки в работе, и вам будет действительно «трудно их исправить».

Однако, что вы должны сделать здесь, если вы внедрите в свой проект такой фрагмент с открытым исходным кодом, то вы должны взять на себя полную ответственность за этот код, как если бы вы написали его самостоятельно. Убедитесь, что код находится в состоянии, при необходимости вы можете поддерживать его. Не вините «авторов» этого кода, если что-то работает не так, как ожидалось.

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

Здесь нужно подумать об одном: в вашем случае вы упоминаете, что существует широко распространенная альтернатива от крупного поставщика (MS Entity Framework, за которую вам не нужно платить никаких дополнительных лицензионных сборов!). Вы не хотите использовать его из соображений производительности. Я настоятельно рекомендую не допускать, чтобы производительность была единственной или основной точкой, которую следует учитывать. Вопросы, которые вы должны задать здесь: имеет ли Dapper всю необходимую вам функциональность и ожидаемый срок службы вашего программного обеспечения? Или вы можете предвидеть, что вы быстро достигнете пределов Dapper и вам придется добавить множество недостающих функций вокруг него, чего вам, вероятно, не понадобилось бы, если бы вы решили использовать EF в первую очередь? Если последнее так, я бы порекомендовал не использовать Dapper. Также спросите себя: действительно ли EF недостаточно быстр для вашего приложения,

На мой взгляд, это уравновешивание.

Если вы ставите себя в зависимость от поставщика, почти наверняка поддержка исчезнет в ближайшее время

• Потому что у них есть программисты, которые платят, поэтому им нужно продолжать делать новые версии и следить за тем, чтобы старые не могли получить и больше не работали (на более новых платформах), чтобы у новых был рынок.

• Если они не могут продать достаточно, чтобы оправдать бизнес-модель, они передают ее от компании A к компании B на C, каждая из которых меняет ее настолько, что снова, вы не можете использовать новую без перепрограммирования, и вы можете ' получить старый, который работает.

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

Поэтому, если вы хотите создать что-то, что не нужно постоянно переписывать каждые несколько лет, open source может стать вашим другом.

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

Спросите руководство, почему это не удалось раньше, была ли проведена достаточная проверка?

У jquery есть возможность использовать лицензию MIT, поэтому многие коммерческие и правительственные сайты также используют jquery. Сайт Microsoft также использует jquery! Таким образом, проблема заключается в лицензировании. Избегайте использования GPL / LGPL достаточно.

«Как долго можно исправить дефект, о котором сообщают?» После сообщения об ошибке она может быть исправлена ​​в течение нескольких минут, часов или дней. В экстренных случаях персонал может просто «git pull» получить исходный код и скомпилировать его сам. Он просто сообщает руководству версию «v1.2.3-101-gd62fdae», которая отслеживается.

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

Вы уверены, что проблемы управления - это технические проблемы?

Я говорю это, поскольку смешение ОС и коммерческой деятельности является законным минным полем, и более чем один менеджер получил «Пожалуйста, объясните» из юридической команды / генерального директора или, что еще хуже, из другой организации. Большинство менеджеров, которых я знаю, даже те, которые активно используют программное обеспечение для ОС, (по праву) очень осторожны, чтобы полностью понять правовые ситуации, с которыми они сталкиваются. Если вы принимаете программное обеспечение ОС и вносите изменения, вы обязаны вернуть эти изменения сообществу. В некоторых случаях это обязательство является законным, в других - моральным. В некоторых лицензиях на ОС все, что вы делаете, становится ОС, просто связываясь с ними.

С технической точки зрения, это действительно просто решение между конкурирующими продуктами - Задайте несколько основных вопросов - Можете ли вы получить поддержку, необходимую для выбранного вами пакета ?, Как долго можно исправить обнаруженный дефект, сколько это будет стоить за разработчик, за год или один раз и т. д. В ОС есть много нулей в столбце $, но в других часто встречаются пробелы - только вы и ваш начальник можете решить, является ли 0 нулем или нет.

И еще один момент, который нужно помнить: «Никто никогда не был уволен, покупая IBM». (т. е. руководство говорит: «Если вы тратите много денег, это должен быть продукт лучше, чем продукт, который является бесплатным»).