Еще по теме:
- Налоговые льготы ИТ компаниям от Минкомсвязи РФ
- Льготы и преференции для ИКТ
- Пониженный размер взносов 20% ИП и ООО на УСН
- Пониженные 14% тарифы страховых взносов
- Пониженная ставка 15,5% по налогу на прибыль
- Льготы по налогообложению доходов от реализации
- Право ускоренной амортизации
- Упрощенный порядок найма иностранцев
- Аккредитация ИТ-компаний
- Вычет по налогу на прибыль на покупку ЭВМ техники (без амортизации) для аккредитованных ИТ-компаний
- Изменения НДС на услуги в электронной форме в 2019 году
- Интеллектуальная собственность и имущественные права
- Интеллектуальная собственность и имущественные права
- Как влияют преференции, льготы ТОСЭР, ОЭЗ ТВТ на экономику ИТ проекта
Информация других разделов:
- Как защитить свои авторские права
- Авторское право «Copyrights» или ©
- Защита материалов сайта и программы управления контентом
- Защита прав на объекты интеллектуальной собственности ОИС в США и ЕС
- Как доказать, что ваши права были нарушены в интернете?
- Как защитить свои авторские права у нотариуса
- Объекты авторского права
- Основные способы защиты авторских прав
- Патентование решений в сфере IT
- Правила оформления заявки на государственную регистрацию программы для электронных вычислительных машин или базы данных
- Правовая защита и охрана программ ЭВМ и баз данных
- Правовая защита программ ЭВМ и баз данных
- Регистрация программы для ЭВМ и базы данных
- Требования к регистрации базы данных
Также может быть полезно:
- Субсидии до 50% затрат на НИОКР и Льготы резидента ТОСЭР
- Субсидирование части затрат на проведение НИОКР
- Возмещение до 50 процентов затрат на НИОКР цифровой трансформации промышленности
- Перечень НИОКР уменьшающих налог на прибыль в размере 1,5 от фактических затрат
- Субсидии российским IT-компаниям "сквозных" цифровых технологий
- Субсидия на возмещение затрат на НИОКР в рамках комплексных инвестпроектов ППРФ 1312
- Понятие УГТ уровень готовности технологии УГП готовности производства УГС готовности системы УГИ готовности интеграции ГОСТ
- УГТ оценка уровня зрелости технологий ГОСТ Р 58048-2017 Трансфер технологий. Методические указания по оценке уровня зрелости
- УГТ оценка уровня зрелости технологий ГОСТ Р 58048-2017 Трансфер технологий. Методические указания по оценке уровня зрелости
- Что такое инновации (примеры)? Что такое инновации (определение)?
- Программы Фонда Бортника
Наша команда может быть полезна Вам в решении следующих задач:
- внедрение систем управления, бизнес-процессов, ИТ систем (автоматизации, цифровизации) ERP/MRP на базе 1С: Предприятие и 1С:ERP, OEBS (Oracle E-Business Suite), Microsoft Navision, для компаний от микро- до крупного масштаба (от 3 до 700 сотрудников),
- внедрение ИТ решений с значительным количеством функциональных ролей и пользователей (до 250 personal ID) системы управления взаимоотношениями с клиентами (CRM), системы инвестиционного планирования (СИП), графика документооборота (ЭДО) и системы электронного документооборота (СЭД);
- консультационное сопровождение и разработка разной документации для УК, резидентов, девелоперских и управляющих компаний (УК), муниципалитетов, Агентств и корпораций развития (АИР, КР) регионов, промышленных площадок, индустриальных парков, технопарков, территорий опережающего развития (ТОР), особых экономических зон (ОЭЗ), свободных экономических зон (СЭЗ), бизнес-инкубаторов и других объектов инфраструктуры,
- разработка концепции развития (стратегии), бизнес-плана, технико-экономического обоснования (ТЭО), меморандума, презентации, паспорта проекта, подготовка пакета документации по проекту, юридической, иной документации любого бизнес-проекта;
- консультации по финансово-экономическим, налоговым, бухгалтерским, маркетинговым вопросам;
- получение целевого финансирования, налоговых льгот, грантов и субсидий, иных видов поддержки, сопровождение проекта заявителя в конкурсах региональных и федеральных органов власти России;
- консультационная и информационная поддержка, сопровождение проекта заявителя в конкурсах ФОИВ и РОИВ любых регионов России, включая Республику Татарстан;
Программное обеспечение с открытым кодом имеет своих почитателей, а в последнее время если речь заходит о разработке каких-то «национальных» продуктов, так в основном open-source и подразумевают. Парадоксально, но интерес к этому виду программного обеспечения породил массу искажений и заблуждений, которые на практике мешают его распространению.
Наша компания участвует в открытых проектах с 2005 года – и благодаря разработке собственных open source решений (проекты OpenVZ, CRIU), участвуя в других открытых проектах (QEMU, OpenStack, libvirt, libcontainer, и т.д.). За 10 лет мы собрали несколько наиболее распространённых мифов об открытом программном обеспечении. Я расскажу про каждое из заблуждений и объясню, почему оно ошибочно. Наверняка, вы вспомните еще столько же, но, на мой взгляд, эти пять самые «адовые».
Заблуждение 1. "Проект с открытым исходным кодом это открытый проект".
Любой программный проект состоит из множества артефактов: исходный код проекта, информация о неисправленных дефектах, исходный код тестов, документация. Исходный код проекта — это только его часть, свободный доступ к которой не даёт права называть весь проект открытым. Помимо исходного кода, свободный доступ должен быть открыт и к другим артефактам разработки, и чем больше артефактов открыто, тем больше проект открыт для контрибьюторов (людей, которые захотят сделать вклад в проект). Помимо этого, необходимы прозрачные процессы между всеми участниками сообщества, открытые коммуникации в проекте и т.д. Все эти меры будут только способствовать развитию проекта и плодотворному сотрудничеству участников сообщества.
Oracle VirtualBox — это пример закрытого проекта с открытым исходным кодом. Код полностью доступен, но процесс разработки закрыт и непрозрачен.
Заблуждение 2. "Продукты на основе открытых проектов содержат только открытый исходный код"
Компании, которые разрабатывают коммерческие решения на базе открытых проектов, могут включать закрытые компоненты в свои продукты. Потому что именно дополнительная закрытая функциональность может дать им конкурентное преимущество среди компаний, которые также строят бизнес на основе этого открытого проекта. Именно закрытые компоненты зачастую формируют продукт, который компания может продавать своим клиентам и зарабатывать на нём деньги.
Например, недавно мы объявили о разработке следующей версии Virtuozzo, дистрибутив которой будет распространяться бесплатно. Пользователь получит возможность использовать виртуальные машины и последнюю версию наших контейнеров свободно и без ограничений, но при желании он сможет установить набор дополнений (распределенное хранилище данных, компонент для увеличения плотности контейнеров на одном физическом сервере и другие), которые помогут ему успешнее решать его задачи. В этом часть свободы открытого ПО. Вы сами выбираете тот вариант, который вам больше подходит: использовать базовую версию или расширенную. В нашей практике есть примеры компаний-клиентов, которые предоставляли услуги на основе технологий OpenVZ, но позднее оценили преимущества коммерческой версии, и с тех пор стали нашими платными клиентами. Это стратегия win-win, в которой выигрывают обе стороны.
Заблуждение 3. "Использование открытого ПО полностью бесплатно"
Существует расхожее мнение о том, что свободный софт является в то же время и полностью бесплатным. Однако цена самого ПО — лишь малая часть расходов, связанных с его использованием. Свободное ПО – не исключение, поэтому перед его использованием необходимо оценивать весь его жизненный цикл. Только так можно сделать вывод о том, будет внедрение открытого ПО выгодным или нет.
Разберём это на примерах:
- Опытный пользователь установил и настроил на своём компьютере свободно распространяемую программу. Он заплатил за неё своим временем, потраченным на установку, освоение, поддержку (обновления и т.п.)
- Неопытный пользователь попросил опытного установить на свой компьютер свободно распространяемую программу, оплатив его услуги.
- Компания, предоставляющая услуги хостинга, начала предоставлять услуги на базе открытых решений. Такая компания будет платить или персоналу из своего ИТ-отдела или компании, которая участвует в разработке этого проекта, за внедрение и техподдержку. Какой вариант выберет компания — зависит от стоимости, но то, что проект по внедрению и использованию открытых решений не будет бесплатным — это факт.
Во всех примерах не было покупки права использования программы (лицензии), что на самом деле происходит во время приобретения коммерческого ПО. Но каждый раз возникала другая стоимость, к примеру, стоимость услуг или стоимость собственного бизнеса плюс экономия средств за счет свободного права использования.
Одно из достоинств Open Source — предельные затраты, по существу, отсутствуют, так как здесь, как правило, не требуется дополнительных лицензий по мере того, как расширяется внедрение.
Заблуждение 4. "Нельзя построить бизнес на открытых решениях из-за отсутствия технической поддержки"
Поддержка — это ключевой момент для пользователей. Рядовой пользователь вполне может обойтись без нее при использовании открытого ПО, как мы это объяснили в примерах выше, но компаниям техническое сопровождение в большинстве случаев необходимо.
Серьёзные открытые проекты либо активно поддерживаются сообществом разработчиков, либо существуют компании, которые на коммерческой основе могут обеспечить поддержку для крупного бизнеса. А при необходимости — и добавить в продукт нужную функциональность.
Именно такой модели мы придерживаемся в проекте OpenVZ. Компоненты проекта распространяются свободно, но если вам нужна поддержка или разработка дополнительной функциональности, то мы можем её обеспечить.
Заблуждение 5. "Качество открытого ПО хуже, потому что код для него может писать любой желающий"
Главный принцип открытого ПО – открытая совместная разработка – сам по себе является залогом того, что некачественный код, костыли и заплатки попросту невозможно будет скрыть от других участников. Человек, участвуя в такого рода проектах, готов к тому, что его работа будет подвергнута и анализу, и критике, а, значит, халтурить не будет. На кону его репутация, а её терять никто не хочет.
Кроме того, в некоторых сообществах (например, сообщество вокруг разработки Linux-ядра) существует и жесткий принцип – в исходное ядро принимается только самый лучший, оттестированный и идеальный код. Попытку добавить некачественные изменения отклонят, вторая попытка чревата потерей репутации для человека или компании-контрибьютора.
То есть открытый проект действительно даёт возможность любому человеку принять участие в написании кода, но в серьёзных проектах из-за высокого порога вхождения код не будет принят от людей с недостаточным уровнем экспертизы.
В большинстве крупных ИТ-компаний (IBM, Google, Canonical, Parallels и т.д.) есть целые департаменты, в которых специалисты получают зарплату за то, что работают над проектами с открытым исходным кодом и таким образом косвенно работают над продуктами компании.
Отдельно стоит упомянуть, что компании, которые разрабатывают продукты на базе открытых проектов, в ходе тестирования заинтересованы в улучшении кода открытых проектов, которые они используют. Поэтому все обнаруженные проблемы необходимо исправлять и добиваться, чтобы это исправление было добавлено в основную ветку проекта, чтобы иметь как можно меньше отличий в своём коде и коде открытого проекта. Наши продукты используют код других открытых проектов, поэтому проблемы, найденные в коде этих проектов, мы исправляем и отправляем в upstream. Так было с уязвимостями в ядре RHEL: Red Hat отметил Владимира Давыдова за обнаружение серьезных уязвимостей CVE-2014-0203 и CVE-2014-4483 в одном из обновлений ядра RHEL6 (вторая проблема, кстати, была найдена с помощью одного из наших автоматических тестов, использующих Linux Test Project). Василий Аверин получил благодарность за обнаружение ошибки CVE-2014-5045, Дмитрий Монахов – за CVE-2012-4508. Факт хорошего тестирования Linux-ядра был даже отмечен Эндрю Мортоном (кто это?): “Мне интересно. За последние несколько месяцев люди из @openvz.org нашли (и исправили) кучу непонятных, но серьезных и довольно древних багов. Как вы обнаружили эти баги?”
Итог
На самом деле все перечисленные мифы возникают по большей части у пользователей, которые либо только начинают работать с OpenSource ПО, либо не пробовали этого делать вообще. Лучший способ избавиться от предубеждений – начать вплотную работать с такими решениями.
Комментарии 77
-
lanseg
+10-
Согласен с Вами, но это не противоречит исходному заявлению. Любой может написать патч, затем долго и муторно его править, и при должном упорстве, его код примут после всех замечаний. Я сужу по процессу коммита в Qt =)
-
Не мудрёный, если хорошо описан и описание на поверхности.
Два проекта: Qt Creator и OpenOCD. Оба используют Gerrit для приёма патчей.
Описание настройки первого — мутное, лежит не на поверхности, все настройки даны для Qt, назначение бранчей для QtC нужно додумывать. Только свой логин. Описание настройки второго — сразу же находится в девелоперской документации (нужно 2-3 клика мышью на сайте), настройка сервера позволяет использовать логин гугла, гитхаба и ещё пары систем, настройка — по сути чеклист, тестирование кода на предмет соответствия стилю — локально.
С другой стороны, в QtC почти сразу же появляются ревьюверы, начинается дискуссия, есть шансы, что патч попадёт в дерево в тот же день, что засабмичен. С OpenOCD ситуация другая. Ревью висит несколько дней (на данный момент, судя по всему, это далекоооооо не максимальный срок), при том, что в список рассылки инфа о новых ревью прилетает автоматом.
Или FFmpeg (хоть и не крупный, но не сказал бы, что не значимый), влёт принимают патчи прямо в списке рассылки, единственное условие: git patch-format.
Если лень проводить процесс: заводится баг-репорт и аттачится патч к нему. Тут уж действительно, только от тяжести бага скорость обработки зависит.
Ну а да, как обстоит дело в каком нибудь OpenOffice не знаю, не пробовал. Но вообще, скорость продвижения патча зависит от упоротости основных разработчиков и от желания самого репортера, а прислать же его может действительно кто угодно. Разный порог вхождения только обуславливает разное число репортующих.
В том же QtC написал патч, исправляющий часть недочётов в поддержке perforce4, завёл ревью, потом интерес пропал, а потом и перфорс исчез. Только спустя почти год другой человек подхватил его, причесал, позвал на ревью и за 2 дня провёл изменения.
-
я к qbs-у патч отправил, год висит) пара замечаний было и после моих правок все зависло, новых ревью нет, мерджить тоже не собираются. как-то так. Не совсем QtC, но туда тоже код попадает так-то. Патч добавления генерации проектов под MSVC.
Надеюсь что к 16 году кто-то обратит на него внимание)
-
-
Начиная с фрагмента «Использование открытого ПО полностью бесплатно. Существует расхожее мнение о том, что свободный софт является в то же время и полностью бесплатным...» вводится новый термин «свободный софт». В контексте вашей статьи это синоним «открытое по»? Если не секрет, зачем одно и то же разными именами называется — чтобы лучше читалось, или какие-то еще причины?
-
«Открытое ПО» (open source) и «свободное ПО» (free software, что в свою очередь очень часто путают с freeware) — разные понятия.
Свободное ПО гарантирует пользователю права его как угодно использовать, изучать, модифицировать и распространять. Не всякое открытое ПО соответствует этим критериям. Подробнее от идеолога нашего Столлмана: www.gnu.org/philosophy/open-source-misses-the-point.html
Ну или см. в вики соответственно статьи «свободное ПО» и «открытое ПО».-
Свободное ПО гарантирует пользователю права его как угодно использовать, изучать, модифицировать и распространять.
Открытое ПО тоже это гарантирует, что следуют из вашей же ссылки :-) Столлман даже красивую картинку (ASCII-ART) нарисовал и подписал, чтобы объяснить что к чему.
Там три графы:
1. «открытое ПО», которое одновременно и «свободное ПО» (такого — подавляющее большинство),
2. «тивоизованные устройства» (но заметим что само-то ПО на этих устройства — тоже вполне «свободное»)
3. «прочее».Но про «прочее» Столлман сам же и говорит: «Несколько таких лицензий было написано около 2000 года, они применялись для выпуска некоторых программ. Мы давно не слышали о том, чтобы такие лицензии применялись на практике, но у нас нет причин думать, что ими никогда не пользуются.», так что это всё-таки экзотика.
-
-
Существует расхожее мнение о том, что свободный софт является в то же время и полностью бесплатным. Однако цена самого ПО — лишь малая часть расходов, связанных с его использованием…
Не нужно путать открытое ПО (ПО с открытым исходным кодом) и бесплатное ПО. Существуют как платное ПО с открытыми исходниками, так и бесплатное ПО с закрытыми.
Это, наверное, главное заблуждение. Много людей, почему-то, считают, что если исходники открыты, то можно делать все что хочешь и платить не нужно. А это не (всегда) так. Исходники исходниками, но еще есть лицензия.
-
Не уподобляйтесь Микрософту! Если лицензия не позволяет менять исходники без платы кому-либо, то это — не «открытое ПО» и не «свободное ПО».
Другое дело, что не всегда самый дешёвый, в конечном итоге, способ — править всё «бесплатно» самому.
-
При чем тут микрософт и возможность менять исходники? Еще раз, открытость/закрытость исходников и платность/бесплатность ПО, в общем случае, никак не связаны. Да, часто ПО с открытыми исходниками бесплатно (в том числе для коммерческого использования), но это отнюдь не всегда так.
-
Еще раз, открытость/закрытость исходников и платность/бесплатность ПО, в общем случае, никак не связаны.
Ещё раз: и определение открытого ПО и определние свободного ПО прямо и недвусмысленно запрещают ограничивать права пользователя оного ПО.
Да, часто ПО с открытыми исходниками бесплатно (в том числе для коммерческого использования), но это отнюдь не всегда так.
Конечно нет! Но вот беда: в статье речь идёт не о «ПО с открытыми исходниками», я об открытом ПО. А для него — это всегда так. ПО, которое нельзя бесплатно использовать в коммерческих целях не является ни открытым ПО (нарушение параграфа 6), ни свободным ПО (отказ от свободы №1).
При чем тут микрософт и возможность менять исходники?
Притом, что именно Майкрософт с помощью смешивания «открытого ПО», «свободного ПО» и «ПО с открытыми исходниками» пытается всех запутать (см. Shared Source Initiative). Но, увы, нет, не получится: ПО, распространяемое, скажем, под Microsoft Reciprocal License лицензией является открытым ПО, а вот под Microsoft Reference Source License — не является не смотря на схожесть аббревиатур Ms-RL и Ms-RSL и наличие исходников…
С практической точки зрения «ПО с открытыми исходниками» и «ПО с закрытыми исходниками» большой разницы не имеют. Что мне толку открытых исходников если ошибку (в случае её обнаружения) я всё равно исправить не могу? Зачем вы в разговор о свободном ПО его за уши тянете?
-
Ещё раз: и определение открытого ПО
Эвон как вы так ловко одно из многих определений за истину в последней инстанции выдали.
Вот общее определение:Открытое программное обеспечение (англ. open-source software) — программное обеспечение с открытым исходным кодом.
И про ваши ссылки там тоже написано:
Термин Open Source не является торговой маркой организации Open Source Initiative.
А поскольку термин автором не определен, руководствуемся наиболее общей формулировкой.
я об открытом ПО
Я тоже об открытом ПО, т.е. о ПО с открытыми исходниками.
Зачем вы в разговор о свободном ПО его за уши тянете?
Перечитайте заголовок статьи: «Пять заблуждений об открытом ПО». Речь изначально шла об открытом ПО. О свободном ПО я речи не веду. Это очень скользкое понятие, с которым сначала нужно определиться. Я, например, ПО под GPL лицензией свободным не считаю.
С практической точки зрения «ПО с открытыми исходниками» и «ПО с закрытыми исходниками» большой разницы не имеют
Да ладно. Криптобиблеотеки с открытыми исходниками и с закрытыми исходниками, это по-вашему, одно и то же?
-
пруф
Ну давайте, что ли, прочитаем ваш «пруф». Вот что там написано:
Термин open source (англ. программное обеспечение с открытыми исходными кодами) был использован в качестве определения в 1998 году Эриком Реймондом и Брюсом Перенсом, которые утверждали, что термин free software (свободное программное обеспечение) в английском языке неоднозначен и смущает многих коммерческих предпринимателей[1].
Ну а дальше — там подробно расписано вся история, критерии и прочее.
И про ваши ссылки там тоже написано:
Термин Open Source не является торговой маркой организации Open Source Initiative.
И действительно: раз слова «белое» и «чёрное» не являются торговыми марками, то их можно использовать как угодно и для чего угодно — у вас такая логика?
Перечитайте заголовок статьи: «Пять заблуждений об открытом ПО». Речь изначально шла об открытом ПО.
И чего? Перечитайте статью, ссылку на которую вы же сами дали, там как бы нет никаких разногласий: да, Open Source не является торговой маркой и для его использования не нужно получать лицензию, но это не значит, что этот термин можно навешивать бог знает на что: у него есть вполне конкретные (причём ещё живые) авторы и никаких разногласий касательного того кто и для и чего этот термин придумал нет. Ну, вернее есть среди людей поддавшихся Микрософтовской пропаганде.
А поскольку термин автором не определен, руководствуемся наиболее общей формулировкой.
Ну если вы хотите обсуждать фиолетовую воду, текущую из крана и зелёные звёзды Московского Кремля — но нам с вами не по пути, извините.
Да ладно. Криптобиблеотеки с открытыми исходниками и с закрытыми исходниками, это по-вашему, одно и то же?
Почти. С точки зрения нахождения в них ошибок, которые можно поиспользовать для взлома? Разницы почти нет. С точки зрения сертификации — тоже (даже если вы сертифицировали криптобиблиотеку с открытыми исходниками вы не можете изменить в ней ничего без потери сертификата). Гораздо важнее, чтобы к криптобиблиотеках использовался публичный алгоритм изученный достатоточным количеством криптоаналитиков, а как там библиотека работает — дело десятое. Брелок использующий закрытую библиотеку будет генерить точно такие же ключи, как и брелок с библиотекой, исходники от которой у вас есть.
-
Ну давайте, что ли, прочитаем ваш «пруф».
Начните с первого предложения.
Гораздо важнее, чтобы к криптобиблиотеках использовался публичный алгоритм изученный достатоточным количеством криптоаналитиков, а как там библиотека работает — дело десятое.
Знаете, нам действительно с вами не по пути после таких откровений.
-
Начните с первого предложения.
А почему бы и нет? Нам даже всё оно не понадобится
Открытое программное обеспечение (англ. open-source software)
а дальше можно уже обратиться к первоисточнику
Open-source software (OSS) is computer software with its source code made available with a license in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose.
Вам «to anyone», «for any purpose» перевести или в словаре сами посмотрите?
P.S. Да, я знаю, что русская википедия часто увлекается формой в ущерб содержанию, но это не повод из-за этого всё ставить с ног на голову.
-
-
-
-
-
-
-
Платное ПО с исходниками не подходит под определение Open Source Initiative, которое первым пунктом включает возможность распространения, а третьим — модификации.
-
Там есть ещё и шестой пункт, который дополнительно уточняется, что запрет на использование в коммерческих целях — тоже недопустим. И седьмой, которые говорит о том, что ПО, который можно использовать и изменять самому, но нельзя распространять — тоже не «открытое ПО». Это для совсем уж непонятливых.
-
Допустим. Но оно от этого не перестает быть открытым и не перестает быть платным.
И, кстати, что мне помешает выпустить по, которое я разрешаю свободно распространять и модифицировать, но использовать его позволю только после оплаты?-
В целом ничего не мешает, но проконтролировать будет трудно. Это популярная модель, ее например использует Atlassian со своими продуктами: коммерческие компании должны купить продукт, а для открытых проектов можно получить бесплатную лицензию
-
Первое правило open source?
Свободное распространение. Это значит, что лицензия не должна налагать ограничений на продажу и распространение ПО.
Нельзя выпустить ПО как open source и одновременно налагать какие-то условия по использованию или расспостранению. Продавать ПО со своими не open source доработками или услугами можно, но любой другой должен иметь право делать тоже самое, иначе это уже не open source.
-
Получилась забавная ситуация. Термин «open source» ввели, потому что «free software» воспринималось неоднозначно (словом «free» часто значит просто бесплатное), однако, получили новую путаницу, т.к. открытость тоже может быть разной. Поэтому если мы хотим определённости, надо смотреть определение OSI, которое начинается с вступления: «Open source doesn't just mean access to the source code.» То есть, для того, чтобы ПО стало «с открытым кодом», просто открыть доступ к коду недостаточно. А дальше идут 10 правил.
В общем-то это стоит считать первым заблуждением о ПО с открытым кодом. Или нулевым.-
Нет тут никакого нулевого заблуждения. У автора смешались в кучу люди, кони… Сначала он пишет про открытое ПО (ПО с открытым исходным кодом) потом в тексте появляется open sourse (ПО, соответствующее принципам OSI), затем, как чертик из табакерки выскакивает свободное ПО и делается вывод, что все вышеперечисленное бесплатно.
Я собственно и начал с того, что не все открытое ПО бесплатно и соответствует принципам OSI. Но, видимо, читать умеют не все :)
-
Мне кажется это у вас смешались в кучу: Открытое программное обеспечение, как нам подсказывает Википедия, это и есть перевод на русский термина open-source software (что в общем-то все и подразумевают), с чего вы решили что «открытое ПО» это синоним «ПО с открытым исходным кодом» вообще не понятно, учитывая что в русском IT и Википедии «открытое ПО» это синоним open-source (и у автора и в метках и в первом же предложении говорится о open-source). Ну, назовите тогда более правильный русский перевод термина open-source?
-
Ну, назовите тогда более правильный русский перевод термина open-source?
«ПО, соответствующее принципам OSI». Назовите русский аналог терминов «scrum» и «agile». И как называть ПО типа TrueCrypt, если терминами «открытое ПО» и «ПО с открытым исходным кодом» мы будем называть только то, что соответствует OSI?
-
Назовите русский аналог терминов «scrum» и «agile»
Agile прекрасно переводиться как гибкая методология разработки, а scrum просто не переводиться, он это и есть скрам, как Java это просто джава.
«ПО, соответствующее принципам OSI»
Слишком долго, если давно есть всем понятный и принятый термин
как называть ПО типа TrueCrypt
Бесплатное ПО с доступными исходными кодами (дословный перевод терминов freeware и source-available). Термин открытое ПО давно имеет один синоним open-source
-
гибкая методология разработки
Бесплатное ПО с доступными исходными кодами
Процитирую вас же: «слишком долго».
Термин открытое ПО давно имеет один синоним open-source
open-source «просто не переводится, он это и есть» опен сорс. А «открытое ПО» и «ПО с открытым исходным кодом» это просто ПО с открытым исходным кодом.
В общем, я утомился. Давайте уже закончим. Чтобы не было путаницы, необходимо определять термины. Это известно любому, кто закончил хотя бы магистратуру и написал хоть одну статью в рецензируемый журнал. Сойдемся на том, что вы правы, а я нет и разойдемся уже.
-
-
-
-
Я, как и многие участники этой дискуссии, посчитал выражение автора «ПО с открытым кодом» переводом термина «open source software». Собственно, кроме Вас, коней с людьми, по-моему, никто не смешивает.
Одна лишь возможность получить исходный код ПО не делает этот код открытым, тем более она не делает открытым само ПО. Можно, конечно, обсуждать степени открытости, но давайте оставим это маркетологам, ограничившись определением от авторов термина.-
По поводу терминологии смотри habrahabr.ru/company/parallels/blog/261609/?reply_to=8485927#comment_8485945
А по поводу OSI мне так никто и не ответил, какой именно из 10 пресловутых пунктов запрещает мне брать деньги?-
Ни один не запрещает продавать, да. Но Вы не можете запретить распространять свой код любому, кто его получил. Поэтому вероятность появления его в свободном доступе довольно высока. Кроме того, компании достаточно купить всего одну копию, независимо от количества компьютеров и пользователей.
open-source «просто не переводится, он это и есть» опен сорс
Есть нормативный документ или это Ваше личное мнение?
-
-
-
-
-
-
-
-
НЛО прилетело и опубликовало эту надпись здесь
-
Тут сложный вопрос: всякие объективные показатели, как правило, у свободного ПО лучше (есть многочисленные исследования), но вот вопрос стиля и удобства пользования… тут получается обычно «у семи нянек дитя без глазу» (английский вариант, кстати, описывает эту проблему точнее: «too many cooks spoil the broth»). Коллективная вычитка кода в вопросах стиля нифига не спасает, увы.
-
-
А чем HeartBleed отличается от подобных же идиотских ошибок в MS SQL сервере? От тех, из-за которые одно время чуть Internet не лёг? Тем, что вокруг них шумихи не было и шесть месяцев после выхода обновления кто-то спокойно воровал данные пока не замечать проблему стало уже нельзя?
-
-
я думаю не многие будут методично покрывать open-source проект unit-тестами чтобы минимизировать возможности ошибок.
есть конечно большие любители ut кто это делает, некоторые в рамках написания своих книг, например Roy Osherove делал вычитку и правку тестов некоторых open-source проектов на youtube, чтобы показать как правильно.
а в компании обычно сидит человек который за зарплату пишет тесты и проверяет все что возможно. и никуда он не денется, пока все не проверит
-
Ну, смотря какого уровня open-source проекты: apache проекты, хибернет и jboss проекты, гугл open-source проекты и т.п. сверх популярные проекты на java покрыты unit-test'aми в десятки слоев. Там собственно все намного более серьезнее чем в обычной компании, ибо имидж и т.п.
а в компании обычно сидит человек который за зарплату пишет тесты и проверяет все что возможно. и никуда он не денется, пока все не проверит
В компании обычно все упирается в бюджет, зачастую внутреннею библиотеку проще выкинуть и заново переписать, чем покрывать тестами.
-
Ещё один миф: Все Open source проекты это сборище индивидуалов, работающих за бесплатно, поэтому там нет никакого порядка, методологии и стиля.
На самом деле, на реально серьезных проектах вроде Hadoop'a работают очень серьезные программисты ведущих IT компаний за отдельную плату и там уровень разработки весьма высок, ибо тяп ляп и в продакт можно позволить на внутренних проектах, а в выложишь такое в общий open source сразу начнут шептаться «Акела промахнулся, Гуг… Акела промахнулся...»
-
и никуда он не денется, пока все не проверит
Святая наивность. Во-первых, покрытие 100% кода тестами — задача, сравнимая по сложности с написанием самого кода, а часто ещё и выше, т.к. обычно тебе в наследство достаётся говнокод, автор которого даже не знает, что такое unit test, и приходится переписывать. Следствие — обычно в проприетарном коде тестов или вообще нет, или их количество исчезающе мало. Во-вторых, не в каждой компании вообще считают нужным что-то тестировать методом, отличным от «потыкать в кнопочки и убедиться, что не падает».
-
-
-
-
Любой программный проект состоит из множества артефактов: исходный код проекта, информация о неисправленных дефектах, исходный код тестов, документация. Исходный код проекта — это только его часть,
Из кода можно собрать проект, из «прочих артефактов» — нет. Безусловно прочие вещи важны, но в центре стоит идея того, что абсолютно любой может взять код, а дальше все зависит от… много чего. В конечном итоге, результатами тестов и информацией о дефектах можно обрасти.
-
-
Почему же? Вы до сих пор верите что открытое ПО держится на энтузиазме отдельных индивидуумов?
Посмотрите отчеты Linux Foundation о развитии Linux ядра, там в основном вносят изменения крупные компании и не просто ради фана, а потому что они строят бизнес на открытом ПО. Путей монетизации окрытого ПО может быть множество: консалтинг, поддержка, платные дополнения и т.д.
Вот платные дополнения стоят денег и для них компании не публикуют исходный код.-
Эти же пути монетизации применимы и к закрытому ПО. Платные дополнения не публикуются, следовательно код открыт не полностью. Так в чем разница? Чем эта модель отличается от модели скажем Микрософт, у которой есть например бесплатный SQL Server (Express) и есть платный? В развитии ядра Linux заинтересованы некоторые крупные компании, в развитии Windows тоже заинтересованы крупные компании во главе с Микрософт. Так в чем же разница? Только в том что я могу посмотреть исходники?
-
Так в чем же разница? Только в том что я могу посмотреть исходники?
В том, что исходники могут посмотреть (и изменить!) ваши конкуренты. Это принципиальная разница: у проприетарного ПО всегда есть некий хозяин — он как хочет, так и вертит, а если он, не дай бог, обанкротится, то все ваши инвестиции в это ПО пойдут прахом. У открытого ПО хозяина, как такового, нет — обычно есть лидер, который движет его разработку (а иногда и его нет), но если с ним что-то случится (или он обанкротится или захочет чего-то «странного»), то те, кто пользуются этим ПО всегда могут решить, что они дальше пойдут без него. Такое случалось в истории много раз (и банкротство владельца проприетарного ПО и «бодания» разработчиков открытого ПО), так что это — не просто теоретические размышления.
Ну вот подумайте сами: если завтра обанкротится Майкрософт — как это отразится на пользователях Windows? А если завтра обанкротится RedHat — то что будет с пользователями RedHat Linux'а?
Конечно эту простую истину вы редко услышите от людей типа топикстартера, которые хотят вам продать какие-то проприетарные дополнения к открытому продукту, так как их использование во многом лишает вас самого главного преимущества открытого ПО… но даже в этом случае ваша судьба не так печальна: всё-таки «ядро» у вас остаётся в любом случае, а дополнения может кто-нибудь другой по вашему заказу разработать…
-
Кстати про «странное». Вот есть у нас воистину странная история с truecrypt.
Но что-то я не слышал о каком-то полноценном развитии «после смерти».
Хотя инициатив аж несколько…-
А это — как раз хороший пример, показывающий почему «открытое ПО» у нормальных людей обозначает именно то, что оно обозначает, а не то, чего хочется некоторым.
TrueCrypt никогда не был свободным ПО: его лицензия запрещает коммерческое распространение и включает в себя довольно-таки опасные требования по индемнификации оригинальных разработчиков TrueCrypt'а (тут немного контекста). Эта комбинация как бы сразу означает что серьёзные компании у которых в штате есть юристы связываться с TrueCrypt'ом (или его клонами) «после его смерти» не будут, что, понятно, ни разу не облегчает жизнь людям, которые хотят что-то полноценно развивать TrueCrypt (а вернее его клоны, так как та же самая лицензия запрещает развивать собственно сам TrueCrypt).
Добавьте к этому, что Linux'оидам TrueCrypt, в общем-то, не нужен (у них есть tc-play) и окажется, что да, таки ой…
-
да, tc-play оптимален, но хочется его и под мастдаем. Впрочем тут хоть половина аудита сохраняется. Что уже неплохо…
А вот с индемнификацией я не совсем понял. Чем это отличается от стандартного AS IS?-
А вот с индемнификацией я не совсем понял. Чем это отличается от стандартного AS IS?
Тем что это фактически полная противоположность.
AS IS говорит о том, что автор и, главное, распространитель, никому ничего не должен. А поскольку лицензию конечный пользователь получает от оригинальных авторов, то если что — все претензии к ним (GPLv3: Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.), дистрибутор отвечает только за то, что он сделал сам.
У TrueCrypt'а — всё строго наоборот. Пункт IV-4 говорит о том, что любой, кто использует или распространяет TrueCrypt (или продукт, основанный на TrueCrypt) как раз именно что должен сам разруливать все и всяческие вопросы, которые в принципе могут у кого-то возникнуть по отношению к любым разработчикам TrueCrypt'а. Кажется по русски это называется «гарантия возмещения ущерба и ограждение от ответственности». В общем-то за само это принято деньги брать неплохие обычно.
Потому что если окажется, скажем, что TrueCrypt содержит ворованный код, то ты не можешь сказать «за что купил — за то продаю» — именно тебе, в соответствии с этой лицензией придётся разбираться в суде с претензиями и платить, в случае чего, за то, что ты создал 100500 копий чьей-то чужой собственности. Сослаться на то, что ты не знал о том что и у кого анонимные авторы TrueCrypt'а спёрли — ты не сможешь. А учитывая хорошо известный факт, что претензий этих — таки есть…
В общем в этом месте ничего с 2008го года принципиально не изменилось и я, честно говоря, не представляю кем нужно быть, чтобы с этим связываться. Ещё если ты конечный пользователь — можешь в суде попробовать «отмазаться» на основании «закона о правах потребителей» (он здорово ограничивает права продавцов и, скорее всего, требования повесить идемнификацию на конечного пользователя не прокатят), но разработчики и распространители… они-то кем должны быть, чтобы на это подписаться?
Вот точный текст:
YOU SHALL INDEMNIFY, DEFEND AND HOLD ALL (CO)AUTHORS OF THIS PRODUCT, AND APPLICABLE INTELLECTUAL-PROPERTY OWNERS, HARMLESS FROM AND AGAINST ANY AND ALL LIABILITY, DAMAGES, LOSSES, SETTLEMENTS, PENALTIES, FINES, COSTS, EXPENSES (INCLUDING REASONABLE ATTORNEYS' FEES), DEMANDS, CAUSES OF ACTION, CLAIMS, ACTIONS, PROCEEDINGS, AND SUITS, DIRECTLY RELATED TO OR ARISING OUT OF YOUR USE, INABILITY TO USE, COPYING, (RE)DISTRIBUTION, IMPORT AND/OR (RE)EXPORT OF THIS PRODUCT (OR PORTIONS THEREOF) AND/OR YOUR BREACH OF ANY TERM OF THIS LICENSE.
P.S. Очень, конечно, радует, обсуждение на LORе: наивные чукотские вьюноши прочитали сообщение, ни черта не поняли и стали обсуждать вещь, которая к делу отношения не имеет вообще никакого. Проблема-то была ни разу не в требованиях переименования всего на свете (тот же LaTeX имеет подобное требование, как и Firefox — и считаются при этом вполне свободными), проблема была в том, что пребования идемнификации — это, как бы, ни в какие ворота вообще. Они, кстати, в 2008го года (и лицензии 2.4) по большому счёту, не изменились, разве что теперь идемнифицировать требуется только (ко)авторов, а за агентов и прочих всё-таки *опу у суде подставлять не стоит — но зато явно прописано, что придётся оплачивать штрафы и затраты на адвокатов. Понятно почему эта перспективка мало у кого вызвала приступ воодушевления?
-
-
А это — как раз хороший пример, показывающий почему «открытое ПО» у нормальных людей обозначает именно то, что оно обозначает, а не то, чего хочется некоторым.
TrueCrypt никогда не был свободным ПО: его лицензия запрещает коммерческое распространение и включает в себя довольно-таки опасные требования...
Вообще-то, если судит по английской вики, TrueCrypt не считается open sourc'ом, только freeware (не требующим оплаты за пользование) и source-available (позволяющий просматривать исходный код, но не дающий полные права на модификацию.
Тут явно проблемы с однозначным переводом открытого ПО с английского, открытый для просмотра исходный код это source-available, собственно по умолчанию любой код на PHP, JavaScript — source-available и даже в Java декомпиляция байткода практически идет один к одному, при наличии javadoc можно практически всегда получить почти оригинальный исходный код. Это совсем не тоже что термин open source, который обязательно включает свободу распространение, модификации и использования.
-
-
-
-
-
-
1. После недавнего бага у MS с RCE на уровне ядра в драйвере (!) tcp, я даже и не знаю, как можно говорить про «проприетарное надёжнее». Руки у всех одинаковые, и уровень коммитмента одинаковый (и не надо сказок про «не спим не едим о качестве думаем» — наёмные сотрудники (которые код пишут) — это наёмные сотрудники и их энтузиазм может различаться так же, как и у опенсорсных).
2. Сопровождение — это правильная мысль. Однако, если сопровождение отдаётся чужому дяде, то это аутсорс компетенции. Когда толковый человек, разбирающийся в софте, в своём штате, это всегда много много много лучше, чем если этот толковый человек у чужого дяди работает и чужого дядю слушает. Не для всех программ и не всегда это возможно экономически, но если от программы зависит бизнес — только inhouse компетенция. Причём, не по inhouse системе, так, чтобы если товарища hh-автобус переедет, то можно было найти замену.
3. С точки зрения общего блага чем ниже библиотека или код, тем больше он должен быть в опенсорсе. Если компания открывает код бизнес-приложения — это подвиг. Если компания открывает код libfoobar которая обрабатывает foo в формате bar — это обязанность перед человечеством.
4. Саппорт и интеграция — самые хорошие ниши для опенсорс компании. Opencore модели всегда попахивают чем-то не тем.
-
Качество открытого ПО хуже, потому что код для него может писать любой желающий
К сожалению, программный продукт состоит не только из кода. А по какой-то причине привлечь на свободных началах кого-то кроме кодеров довольно сложно. В итоге все OpenSource-проекты страдают от дичайшего дефицита: художников, дизайнеров, специалистов по юзабилити, композиторов и т.д.
Как следствие, OpenSource-разработки в той или иной степени имеют проблемы:
— с дизайном (продукт выглядит так, что заставляет плакать кровавыми слезами)
— с юзабилити (продукт выглядит набором разрозненных фич, т.к. никому и в голову не приходило прорабатывать наиболее типичные сценарии его применения)
— с документацией (даже сложно вспомнить, какой из OpenSource-проектов обладает полной и, главное, актуальной документацией. Практически везде она обрывочная, устаревшая на пару лет, а то и вовсе вместо неё отписка, сгенерированная чем-то вроде doxygen)
— с архитектурой (предполагается, что неудачные архитектурные решения будут исправляться глубоким рефакторингом, когда количество костылей в проекте превысит все мыслимые пределы).
Дополнительным бонусом получаем проблемы с совместимостью. В мире OpenSource они принципиально нерешаемы, т.к. нет владельца, который может навязать всем единый стандарт. В итоге получим множество несовместимых форков.-
Вы знаете, но иногда мне кажется, что люди, которые так говорят, слепы к вырвиглазу у проприетарщиков. Например, все ipmi/ilo/drac'и — вырвиглазные тормозные уё… ща. Дали бы доступ шить своё, были бы няшные на html5 уже давно. Я уверен, что если копнуть почти любую проприетарную систему, в которой «look-n-feel» не point of sale (почти весь серверный софт, многий десктопный, котрый продаётся из-за фичи), то там будет всё то же.
В opensource-же есть офигенные интерфейсы. Mypaint — самый крутой графический интерфейс для программы для рисования, который я видел, inkscape — для векторного рисования, FF (сравнили с IE6, да?).
Что же касается стандартов, то тут вы уж просто принципиально не правы. Когда у вас есть конкурирующие проприетарные форматы, то они лучше сдохнут, чем начнут поддерживать совместимость в «неудобную» для себя сторону. Хороший пример MS, которая срала на нужды всех, кроме своей экосистемы, и срать будет (если окончательно не заопенсосрится).
А вот в опенсорс можно просто прийти и послать пул-реквест с поддержкой формата, благо код чтения тоже в опенсорсе. Я сижу на линуксовом десктопе, и за вычетом нескольких отрыжек полупроприетарного софта (типа djvu), все программы открывают и понимают форматы всех (в пределах функций). Более того, opensource автоматически гарантирует open system interconnection (который требует открытых стандартов на межхостовое взаимодействие), а вот про «стихи» у Oracle'а в протоколе взаимодействия с СУБД можно почитать тут: noss.github.io/2009/04/28/reverse-engineering-oracle-protocol.html. Специально сделано, чтобы засудить можно было.
И после этих стихов мне будут пытаться какать на опенсорс? Эм…
-
В вашем представлении опен сорс идеализирован. Есть открытые проекты, в которые просто так пул-реквесты делать нельзя, нужно либо подписать документацию, что твой работодатель не против твоей активности. Плюс комьюнити не всегда позволяет править код. Да сравнивать IE6 с последним FF удобно, но сравните тот же FF с закрытым Chrome. Не стоит доказывать мол Chrome открыт, открыт Хромиум, так что возможно «стихи» есть не только у Оракла. Всё чаще Open Source подменяется псевдоопенсорсом. Одна только история с Android чего стоит. И да MS срала на нужды всех, и открыла .NET и сделала Windows бесплатной. Почаще бы так.
-
сделала Windows бесплатной
Какая именно Windows полностью бесплатна и функционала для всех? Я нашел только пробные версии на 90 дней, это далеко не бесплатно.
открыла .NET
И сделала бесплатной Visual Studio на продаже которой она и зарабатывает деньги? Открытие .Net не более чем конкурентный маневр в борьбе с платформой Java.
-
А разве студия стоит денег? Для личного использования нет. Для коммерческого… Не найду хорошую бесплатную IDE. Уж извините от Eclipse глаза на лоб лезут
-
Idea community edition — полностью бесплатна и для личного и коммерческого использования. Но речь не о бесплатных аналогов студии, а о том что за открытием Net'a стояли вполне коммерческие интересы M*.
-
-
У нее серьезно урезан функционал.
Не так серьезно, если вы не занимаетесь Enterprise'ом, особенно учитывая кучи плагинов. Даже бесплатная IDEA для меня намного полезнее и функциональнее Eclipse.
Во всём что происходит в ИТ есть коммерческий интерес.
Не во всем, но почти, но разве чисто коммерческое открытие Net как-то противоречит фразе «MS срала на нужды всех»?
-
Закрыты исходники — плохо, открыты — плохо, это коммерческий ход. Это притом что в мире ИТ живет только то что можно использовать для зарабатывания денег. И Джава вся это огромный коммерческий продукт, за которой стоит Оракл, ничем не лучший Микрософта. Как говорят «Я так люблю Java и ненавижу Oracle, так люблю C# и ненавижу Microsoft»
-
Закрыты исходники — плохо, открыты — плохо, это коммерческий ход
Я говорил что это плохо или хорошо, надо понимать что это просто маркетинг и реклама, а не благотворительность Microsoft. Распродажа в магазине делается вовсе не с целью помочь покупателям, стратегия Microsoft как была тянуть одеяло на себя, закрывать все что можно с помощью стандартов и выдавливать за этот счет конкурентов — скорее всего так и осталась. Да, естественно когда крупные компании, вроде гугла, вкладываются в open source, они тоже учитывают свои интересны, но во многом и интересы остального сообщества. MS пока не похоже что собираются учитывать кого-то ещё и в этом разница.
И Джава вся это огромный коммерческий продукт, за которой стоит Оракл, ничем не лучший Микрософта. Как говорят «Я так люблю Java и ненавижу Oracle, так люблю C# и ненавижу Microsoft
Открою вам страшную тайну, платформа Java это сборная солянка от сотен разных вендеров и тысяч open-soure и не open-source проектов, сам язык Java это от силы 1% мира Java, более того существуют сотни реализаций виртуальных машин Java (несколько десятков open source'ных), кроме Java есть JRudy, scala, kotlin, есть джава для андроидов от гугла. Поэтому влияние Оракла на мира Java в десятки раз меньше влияния Microsoft на мир Net.
-
-
-
-
-
-
-
При чём тут бесплатность-то виндов? Движение в районе .net — ну, ок, хотя мне оно ни на виндах, ни на линуксах нафиг не сдалось. Но, вполне себе модель опенсорса, допустим.
Хромом пользоваться невозможно, извините. ФФ можно после допиливания, потому что их попытки заточиться под хромовый интерфейс заставляют ставить специальные плагины для интерфейса «как было».
Вообще, речь о другом: аргумент, что проприетарщина приводит к победе одного стандарта, мягко говоря, не правда.
-
-
Когда у вас есть конкурирующие проприетарные форматы, то они лучше сдохнут, чем начнут поддерживать совместимость в «неудобную» для себя сторону.
Когда у вас есть конкурирующие проприетарные форматы, победит та компания, которая первой сделает полную поддержку формата конкурента у себя в продукте. Если продукт А умеет открывать только свой формат, а продукт Б — и свой формат, и формат продукта А, то как вы думаете, что с более высокой долей вероятности выберут клиенты?
-
Я ж написал «в неудобную для себя сторону». Допустим, у компании А есть видеоредактор и фоторедактор. А у компании Б есть фоторедактор.
Компания А делает интеграцию своего видеоредактора и фоторедактора, а фоторедактор Б поддерживать отказывается (ибо не выгодно). Фоторедактор Б пытается подтянуться, но А старательно гадит в формате и поведении так, что Б всё время отстаёт от А. При этом Б более удобен пользователям, но А пытается их перетянуть на свою сторону видеоредактором.
Типовая рыночная картинка. Не верите? Спросите у MS, где ютубное приложение для виндофона.
-
Лучше спросите это у «доброго открытого» гугла, который принципиально отказался поддерживать виндофон, и устроил массу проблем тем, кто попробовал сделать альтернативные приложения. Сейчас есть пара работающих альтернативных приложений, переименовывающихся чуть ли не каждые полгода (из-за угроз со стороны гугла), но никакой надежды на официальное приложение нет.
-
-
-
-
с документацией (даже сложно вспомнить, какой из OpenSource-проектов обладает полной и, главное, актуальной документацией. Практически везде она обрывочная, устаревшая на пару лет, а то и вовсе вместо неё отписка, сгенерированная чем-то вроде doxygen)
Навскидку: Firefox, VLC player, LibreOffice — это из кроссплатформенных и ежедневно используемых. Каждая из полезный консольных утилит имеет man-страницу, на которой есть вся необходимая информация для использования программы — описание ключей запуска, иногда примеры использования.
В итоге все OpenSource-проекты страдают от дичайшего дефицита: художников, дизайнеров, специалистов по юзабилити, композиторов и т.д.
Ядро Linux тоже Open Source проект, но от композиторов с художниками для его разработки мало пользы будет.
-
-
Опытный пользователь установил и настроил на своём компьютере свободно распространяемую программу. Он заплатил за неё своим временем, потраченным на установку, освоение, поддержку (обновления и т.п.)
Неопытный пользователь попросил опытного установить на свой компьютер свободно распространяемую программу, оплатив его услуги.
Знаете, с платным ПО все ровно точно так же (и возможно даже немного дороже по стоимости услуг).
-
Да, тут можно выделить ещё несколько мифов о open source:
1. Установка open source всегда сложнее и неудобнее коммерческих продуктов и требует намного больших технических знаний, — далеко не всегда, иногда происходить ровно наоборот, как минимум, у бесплатных продуктов нет танцев с серийными ключами, токенами и прочими антипиратскими методами,
2. Тех.поддержка коммерческого продукта всегда лучше, быстрее и грамотней ответов на форуме open source — тоже далеко не всегда, иногда сообщество open source отвечает намного быстрее и отвечают именно разработчики, а не девочки с записанными на листочке стандартными ответами,
-
-
Поэтому все обнаруженные проблемы необходимо исправлять и добиваться, чтобы это исправление было добавлено в основную ветку проекта, чтобы иметь как можно меньше отличий в своём коде и коде открытого проекта.
Очень точно. И, по личному опыту работы — в этом огромный плюс и основная сила открытого ПО.
Если ты что-то сделал для данного ПО дополнительно и активно используешь, и то, что ты сделал хорошо, то единственный способ не остаться «на обочине» — это отдать то, что ты сделал сообществу. Иначе кто-то это сделает вместо тебя и твой код, и твою работу придется со временем просто похоронить, а тебе дополнительно переделывать свой проект под чужой код.
lanseg
Вконтакте
Телеграм
YouTube
Whatsapp