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

13

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

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

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

Минусы:

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

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

Мистер джефферсон
источник
15
ASP.NET и его стек с открытым исходным кодом.
Эндрю Т Финнелл
11
«Разве неразумно использовать в моем проекте открытый исходный код, который я не знаю / не понимаю так же хорошо, как и свой собственный код?» В отличие от закрытых библиотек, которые являются черными ящиками?
user16764
5
@AndrewFinnell: Не по собственному определению движения FLOSS.
tdammers
6
Что касается конкретного проекта ОС, о котором вы думаете, может быть интересно, что Dapper используется StackExchange ...
Marjan Venema
4
Это не технический вопрос, а не о том, что лучше. Какой из них пойдет не так. MFC мертв, XP умрет менее чем через 2 года и т. Д. Бесплатный проект с открытым исходным кодом не умрет, если они будут хорошими, так как вы или кто-то другой можете их взять на себя. Это о том, кто будет обвинен. Если вы выберете Microsoft, если это будет непредвиденным, или Microsoft виноват. Если вы перейдете на бесплатный / с открытым исходным кодом, это будет ваша вина.
Ctrl-Alt-Delor

Ответы:

20

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

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

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

StriplingWarrior
источник
16

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

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

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

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

Эндрю Т Финнелл
источник
2
+1 Я согласен со всем этим, за исключением того, где вы говорите, что он «(должен)» посмотреть на NoSQL; Каждое решение для хранения данных NoSQL - их много - имеет определенный набор компромиссов по сравнению со «стандартной» реляционной базой данных SQL, поэтому трудно сказать «должен» без большого количества информации. Иногда это хорошие компромиссы, а иногда нет, но вы не можете сделать общие заявления по этому поводу. «NoSQL» - это просто брендинг вокруг множества технологий, имеющих мало общего, кроме того, что он не является самой распространенной схемой хранения данных.
Donal Fellows
Но со всем остальным, что ты пишешь, я определенно согласен. Хороший OSS отнимает много усилий у обычного работающего разработчика (и кто захочет использовать плохой OSS?)
Donal Fellows
Dapper сложен, потому что он обобщен. Если бы я написал свое собственное решение, я бы сделал много кода преобразования набора данных в объекты (т.е. MyClass.Property = set.Tables[0].Rows[i]["Property"].ToString()).
г-н Джефферсон
Как только вы начнете входить в сферу своей деятельности, вам будет труднее найти --OSS-- все, что соответствует вашим потребностям. Если бизнес Microsoft не является вашим бизнесом. (но мне нравится то, что ты сказал.)
ctrl-alt-delor
@ Richard Некоторые из моих ответов могут быть неясными. Ваше заявление - то, что я также говорю. Зачем сосредотачиваться на кусочках, которые были решены снова и снова, как ORM. Сосредоточьтесь на бизнес-сфере. ORM не является бизнес-доменом, если вы не продаете продукт ORM.
Эндрю Финнелл
15

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

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

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

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

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

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


источник
3
+1: я не могу сказать, что полностью согласен, но это слишком хорошо доказано, чтобы не .....
mattnz
14
«Нет такой вещи, как бюджет проекта с открытым исходным кодом». не соответствует действительности У Google есть бюджет на проекты с открытым исходным кодом, и, например, Red Hat Inc. не может вести свой бизнес, если они не используют достаточное количество кодеров для своего программного обеспечения. И что по этому поводу? microsoft.com/opensource/directory.aspx
ONOZ
14
Я не согласен с одним словом, которое вы сказали.
Авио
11
Все эти пункты в равной степени применимы к проектам с закрытым исходным кодом. Добавление нишевых библиотек / структур с закрытым исходным кодом добавляет разнообразие. Старые проприетарные технологии заброшены, если они не приносят им денег. Вы все еще можете настроить IIS, чтобы он был его собственной уникальной бабочкой. Комментарий к качеству игнорирует тот факт, что проект с открытым исходным кодом может быть больше, чем (некоторые) поставщики. И деловой мир сильно политизирован, особенно с Microsoft.
Филипп
3
У меня был противоположный опыт. Мы портировали SQLite на устройство и смогли получить поддержку непосредственно от парня, который написал большую часть этого. Нет никакого способа получить такой уровень сервиса от компании с закрытыми исходными кодами. Некоторые проекты с открытым исходным кодом абсолютно более устойчивы и имеют лучшую поддержку, чем некоторые проекты с закрытым исходным кодом. Я мог бы рассказать историю об использовании «стандартного» компилятора Microsoft C ++ для OS / 2 и о том, как пошла его поддержка, когда Microsoft решила взять под залог OS / 2.
Gort the Robot
7

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

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

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

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

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

Горт Робот
источник
7

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

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

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

М. Дадли
источник
6

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

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

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

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

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

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

Док Браун
источник
1
+1 за вопросы лицензирования. Внимательно проверьте, что использование какого-либо компонента с открытым исходным кодом также не заставит вас открывать собственный код. Я не верю, что это будет иметь место в большинстве случаев с открытым исходным кодом, и если вы просто используете его для создания или размещения своего кода, их станет больше, но, тем не менее, стоит проверить.
Лунивор
Даже если производительность менее важна, EF дает мне меньше контроля. Введение кеширования будет немного сложнее, если это станет необходимым в будущем; Dapper будет легче встроить в более нестандартное решение, в дополнение к необходимости в первую очередь кеширования.
г-н Джефферсон
С другой стороны, желание получить индивидуальное решение поверх EF звучит немного похоже на NIHS. Моя схема данных довольно сложна, с множеством взаимосвязей (внешних ключей), и до того момента, когда мое пользовательское решение управляет этими взаимосвязями, а EF из коробки, безусловно, потребуется некоторое время.
г-н Джефферсон
@ Мистер Джефферсон: серьезно, я не могу дать вам хороший совет, что является лучшим решением в вашем случае, это то, что вы должны решить самостоятельно. Я просто пытался дать вам несколько советов, что следует учитывать.
Док Браун
+1. Вы подняли несколько очень хороших моментов с этим постом. @ Mr.Jefferson: Я уже некоторое время пользуюсь Entity Framework и довольно успешно управлял производительностью с помощью специального кэширования в определенных репозиториях после того, как обнаружил узкие места. Кроме того, наш продукт довольно сложный, но мне все еще не приходилось прибегать к написанию одного SQL-запроса. Я чувствую, что EF дал мне много контроля.
StriplingWarrior
2

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

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

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

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

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

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

Майк Данлавей
источник
1

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

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

тюремщик
источник
Я не знаю много о том, что случилось. Это было до того, как я попал сюда.
г-н Джефферсон
0

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

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

linquize
источник
0

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

Неманья Трифунович
источник
-1

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

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

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

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

mattnz
источник
5
Иронично, что IBM, вероятно, является крупнейшим в мире продавцом программного обеспечения с открытым исходным кодом. HTTP-сервер Apache, Eclipse и т. Д. И т. Д.
Джеймс Андерсон,
7
Продажа OSS не является незаконной. С чего бы это?
tdammers
1
IBMS httpServer - это чистый apache, он поставляется с соглашением о поддержке.
Джеймс Андерсон
2
Вещи меняются. Теперь руководство начинает думать, что если вы заставите компанию платить за компонент, который другие компании получили бесплатно, вы тупица.
Авио
2
«Другие столбцы» редко бывают пустыми для открытого исходного кода. Вы всегда можете получить поддержку от консультантов или поставщиков дистрибуции или кого-то еще, и вы также можете поддержать себя. Больше столбцов для коммерческого программного обеспечения часто пустые, потому что вы заранее не знаете, какова их поддержка, и это редко бывает так полезно, как вам нужно.
Ян Худек