Open source программа что это

Содержание

Open source программа что это

Я предлагаю в этой теме выкладывать ссылки на программы, исходные тексты которых можно скачать (либо на офф сайте либо на 4pda).

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

вот что мне удалось нарыть:

Программы для Today: Плагины, Лончеры, Оболочки
1) MiniMonth — MiniMonth — пример реализации плагина для Today
2) Manila Today Page — http://code.google.com/p/manilatodaypage/
3) IphoneToday от tronik
4) eXSkin — великий и ужасный -QwertY- снизошёл до наших молитв и поделился своей мудростью тут .
5) CRetroClock (Пост #5901656) — исходники появились в шапке темы

Офисные программы
1) Klaxon — Klaxon — пример реализации будильника
2) Jot — Исходники текстового редактора (Япония)
3) Pocket Digital Clock

Системные утилиты и Управление

Он вам не Open Source / Тайная империя свободного ПО

1) Pocket downloader исходники или PocketDownloader
2) 7-zip Extracter — 7-Zip архиватор
3) tMan — tMan (доступ через svn)
4) DeltaLock — deltaLock — в качестве примера блокировщика
5) GSFinder — имеет SVN
6) gsGetFile альтернативный диалог открытия файлов, исходники тут gsgetfile-i-src.zip или тут gsgetfile-i-src.zip (спасибо Dynamite ) GSGetFile0.0.5.1_src_VS2008_.zip
7) dciBattery — исходники обитают тут http://cpp.in/dev/
8) Esperanto (Пост #2190690) — алгоритм рукописного ввода (исходники к сожалению не сохранились)
9) LVMTopBat — заместо dciBattery, исходники обитают тут LVMTopBat.zip
10) Euro Keyboard — opensource клавиатурка нашлась, брать тут eurokbd_src.zip (спасибо говорим XroM)
11) ArkSwitch — тут
12) Axim Power Manager — исходники, спасибо говорим Dynamite
13) RemoteTracker — противоугонная программка с управлением смсками, исходники

Программирование для PocketPC
1) Python 2.4 — Python (что не удивительно)
2) Open source My Task — интересно к чему это приведёт?
3) WiiMob WiiMote for PPC — неизвесный зверь 🙂
4) Tesseract — OCR распознавалка текста, надо её срочно с переводчиком скрещивать
5) Программа для тренировки дыхания
6) BeOnline — клиент для вконтакта на С# с исходниками тут https://code.google.com/p/beonline/

Интернет и Коммуникации
1) pRSSreader — pRSSreader (доступ через svn)
2) Bombus, Bombus UFO, Bombus QD (bombus-im.org, ngufo.googlecode.com, bombusng-qd.googlecode.com) SVN
3) Bluetooth On/Off — исходник ищем тут Кое-какие исходники. (Пост #18804) спасибо говорим -QwertY-

Прочие программы
1) DarkRuler — в качестве примера для работы с камерой и работы с изображениями.
2) objdump от dci — находится тут objdump_by_dci_source_vs2008_.zip
3) установка-удаление драйверов winCE — SVN
4) сплиттер порта
5) OBD Gaude — на форуме программа вроде не освещалось (или я поиском не умею пользоваться)

В чем смысл open source?

6) x50mix — исходники раз и исходники два
7) Расширенный GAPI драйвер для Dell Axim X50v — исходники

Игры
1) Palm Heroes — исходники ищем тут и тут
2) Tetris — спасибо говорим holod
3) Bubbles — спасибо говорим holod

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

Причина редактирования: тема померла
20.05.09, 15:35 | #2
●

Разработчики
Реп: ( 726 )

4)Pocket downloader исходники
А еще на сайте уважаемого [email protected] есть программы с исходниками(не все) и куча статей.
B все проги на сайте ppc.palmopensource.com с исходниками ссылка

21.05.09, 16:03 | #3
●

Друзья 4PDA
Реп: ( 46 )

5) 7-zip Extracter — 7-Zip архиватор
6) Python 2.4 — Python (что не удивительно)
7) tMan — tMan (доступ через svn)
8) pRSSreader — pRSSreader (доступ через svn)
9) DeltaLock — deltaLock — в качестве примера блокировщика

Источник: 4pda.to

Почему тебе стоит начать писать Open Source проекты

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

Что такое Open Source

Open Source — это проекты с открытым исходным кодом, которые разрабатываются открыто и каждый может вносить изменения в них. В зависимости от лицензии, такие проекты можно использовать и даже в некоторых случаях распространять абсолютно бесплатно. Благодаря Open Source мы можем наблюдать огромное количество приложений, инструментов и библиотек с помощью которых уже создаётся всё остальное.

Все основные фундаментальные вещи в IT — такие, как языки программирования, компиляторы, фреймворки — практически всегда с открытым исходным кодом. Почти на любое платное приложение существует его аналог с открытыми исходниками. Но зачем же разработчики и компании тратят своё драгоценное время и деньги на написание Open Source-проектов, если он не приносит деньги напрямую? Давайте разберёмся и ответим на этот вопрос.

Что даёт Open Source разработчику

Поможет сделать первый шаг в карьере

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

Работа с проектами и репозиториями позволит вам начать развивать свой Github-профиль. Если в нём будет не только дата регистрации, а реальные кейсы, будет проще заинтересовать специалиста, принимающего решение о принятии вас на работу.

Улучшить навык программирования

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

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

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

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

Получить признание

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

Но стоит заметить, что не только разработчики делятся своими наработками и достижениями. Учёные пишут научные статьи, фотографы заливают свои работы на unsplash и становятся всемирно известными, а behance переполнен работами дизайнеров и часто именно там рождаются новые тренды и дизайн стили. Весь мир развивается и меняется именно из-за того, что кто-то чем-то решил поделиться, а уже как результат он становится известным, его начинают уважать и прислушиваться.

Повысить репутацию

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

Но также важно упомянуть репутацию компаний, которые развивают Open Source проекты. Все мы знаем, что последние годы IT рынок испытывает колоссальную нехватку разработчиков. Компании сражаются за кадры и пытаются всеми способами привлечь разработчиков к себе в команды. Так вот я тут хочу подметить, что те компании которые имеют хорошую репутацию как поддерживающие, а лучше разрабатывающие Open Source проекты, имеют преимущество на рынке найма. Я часто слышал, как ребята шли в Facebook именно потому что они имеют большое влияние на рынок IT, своими Open Source решениями.

И пусть другая компания не обладает такой библиотекой как React, в любом случае если разработчик работая и получая за это деньги, сможет развивать Open Source библиотеки, это будет отличным подспорьем пойти работать именно в эту организацию.

С чего можно начать

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

Следом у новичка может возникнуть вопрос, а как именно я могу помочь проекту? Кажется, что нужно написать какой-то код и пытаться объяснить, что он что-то улучшает, но даже исправление опечаток в документации уже будет хорошей помощью любому Open Source проекту.

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

Следующим по простоте и важности после документации идёт пункт написания тестов. Владелец даже крупной и популярной библиотеки с радостью примет ваш пулл реквест, который покроет его код тестами.

А более продвинутым ребятам смело можно браться за исправления багов, смотря репорты ошибок или просто анализируя код. Хорошо описав PR с исправлением, он точно не затеряется в потоке пулл реквестов и будет влит в кодовую базу проекта как можно быстрее.

Вместо итога

А в конце хочется подметить то, что именно Вы можете дать миру IT. И это на самом деле самый важный пункт из ответа на вопрос зачем тебе стоит начать контрибьютить в Open Source.

Мы ежедневно, не задумываясь, ищем и находим любую информацию в интернете за пару минут. За один вечер веб-разработчик сможет собрать простой сайт подключив пару библиотек. Или со знанием всего лишь одного языка можно написать приложение, которое потом легко запустится на всех существующих платформах и будет отлично работать. Ещё 10 лет назад это не представлялось возможным и для разработки требовалось в разы больше времени и прикладных знаний.

Но благодаря чему (или кому) всё это возможно в наше время? Благодаря усилию тысяч и миллионов людей таких же как и ты. Благодаря возможности делиться информацией, опытом и инструментами наш мир очень бурно развивается и каждый день появляются всё новые и улучшенные приложения и инструменты для разработки. Внося свой вклад, отдавая частичку знаний и своего времени, вы делаете огромный вклад в индустрию, а взамен получаете ещё больше.

Источник: tproger.ru

Ликбез: Open Source ПО для бизнеса

Мы предлагаем клиентам IT-системы на базе открытого программного обеспечения и сами используем такое ПО в повседневной работе. Наши заказчики хотят знать больше о том, что скрывается за понятием Open Source, и почему такие программы становятся отраслевыми стандартами.

Зарождение Open Source

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

После судебного процесса между Franklin Computer и Apple 12 мая 1982 года американский суд постановил, что на компьютерные программы распространяется авторское право. Так появилось понятие лицензионного программного обеспечения. С этого момента за использование чужого кода нужно было платить его создателям.

Однако, к тому времени уже десятки лет существовали некоммерческие объединения PACT (Project For the Advancement Of Coding Techniques) и DECUS (Digital Equipment Computer Users Society). Разработчики из этих групп хотели свободно делиться наработками и притом знать, что никто не присвоит их труды. Свободному распространению программ также требовалась легальная основа.

В октябре 1985 года программист Ричард Мэттью Столлман основал фонд свободного программного обеспечения, а в январе 1989 года представил первую открытую лицензию — General Public License (GPL).

Разновидности открытых лицензий

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

GPL долгое время доминировала среди других открытых лицензий, но постепенно ее вытеснили более мягкие разрешительные лицензии MIT и Apache 2.0. Они позволяют модифицировать и использовать программы как угодно. Главное, сохранить оригинальное название и упомянуть автора исходного кода.

В 2019 году разрешительные лицензии занимали 67% рынка Open Source. На лицензию MIT приходилось 27% рынка, 23% — на Apache 2.0, и только 13% сохранилось за GPL 3.0.

Открытые лицензии и российское законодательство

После легализации открытых лицензий, государственные органы и организации стали отказываться от коммерческого программного обеспечения в пользу программ на основе открытого ПО, разрабатываемых российскими компаниями. Доля отечественного ПО в госзакупках органов власти к концу 2019 года составила 65%.

Преимущества Open Source

Быстрое развитие

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

Нет платы за использование

Открытое программное обеспечение не требует лицензионных отчислений, которые составляют значительную долю расходов компаний, использующих коммерческое ПО. В случае Open Source, компания платит только за разработку и настройку нового решения. Использование таких программ бесплатно.

Нет привязки к платформе и ограничений поставщика

Коммерческое программное обеспечение зачастую спроектировано так, чтобы работать в закрытой экосистеме. Например, база данных может работать только с теми приложениями, которые продает компания-разработчик. Open Source ПО основано на открытых стандартах передачи информации, и поэтому, лишено этого недостатка. С открытыми решениями можно использовать удобные инструменты, а не те, что навязывает поставщик.

Такие решения не привязаны и к операционной системе. Их можно запускать и на Windows, и на базе различных версий Linux. Так можно избежать платы за лицензии на операционную систему.

Настраиваемость и масштабируемость

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

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

Open Source в компаниях

Во многих компаниях Open Source программы рассматривают в качестве бесплатных аналогов коробочных решений. Их используют «как есть», без тонкой настройки. Это не лучшая практика.

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

Чтобы раскрыть потенциал Open Source, необходима помощь профессиональных разработчиков. Иногда их приглашают в штат, но создавать целый отдел ради нескольких проектов нерационально. Особенно, если IT — не основная сфера деятельности компании. Профессиональная внешняя команда позволит получить готовую к работе IT-систему быстрее и с меньшими сопутствующими затратами.

Аутсорс

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

Как мы работаем с Open Source

В качестве базы для наших проектов обычно выступает .NET Core. Эта разработка Microsoft с 27 июня 2016 года опубликована под открытыми лицензиями MIT и Apache2.

Мы работаем с .NET Core с момента релиза. Со временем мы научились преодолевать ограничения этой платформы, поучаствовали в исправлении нескольких ошибок. Мы разработали набор проверенных решений, которые совершенствуем годами и постоянно используем в новых проектах.

При помощи открытого программного обеспечения мы разрабатываем закупочные платформы, маркетплейсы, CRM и ERP-системы, которые работают без сбоев под высочайшей нагрузкой. Мы предлагаем наш опыт, навыки и экспертизу всем, кто нуждается в импортозамещении и цифровизации процессов внутри компании.

Свяжитесь с нами, и мы найдем лучшее Open Source-решение ваших задач.

Источник: stecpoint.ru

Как выбирать компоненты Open Source

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

27.02.2020 Диомидис Спинеллис

Ключевые слова / keywords:
GitHub
GitHub
Open Source
Программная инженерия
Разработка ПО
Управление процессом разработки

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

Если основная часть разрабатываемого продукта состоит из самостоятельно разработанного кода, то, скорее всего, вы впустую тратите силы и средства, изобретая колесо заново. Однако в связи с тем, что на сайтах вроде GitHub доступно огромное количество проектов Open Source, выбрать подходящие может быть трудно. Чтобы убедительно обосновать выбор, можно оценить код кандидата с точки зрения характеристик его функционала и собственно процесса его создания (см. таблицу).

Как выбирать компоненты Open Source

Продукт

Функциональность

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

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

Лицензирование

Для сужения поиска надо выяснить, совместима ли лицензия [1] проекта с бизнес-моделью нового продукта, задачами и уже применяемым программным обеспечением. Если в продукте используются компоненты, распространяемые по лицензии GNU General Public License, то на ее условиях придется распространять весь код проекта.

Это может быть нежелательным, если бизнес-модель продукта требует держать код в секрете. В этом случае лучше выбирать проекты с менее требовательной лицензией — например, Berkeley Software Distribution или Apache. Если ПО будет предлагаться в виде сервиса, то надо воспользоваться проектом, распространяемым по Affero General Public License. Еще пример: ПО, выпущенное по лицензии Mozilla Public License 1.1, нельзя компоновать с кодом, лицензируемым по GNU General Public License.

Нефункциональные характеристики

Далее следует выяснить, совместимы ли системные требования рассматриваемого проекта с продуктом, подходят ли архитектура процессора, операционная система, связующее ПО. Если, скажем, продукт работает в macOS, но планируется его вывод на рынок Windows, то нужны библиотеки с открытым кодом, поддерживаемые в обеих ОС. Затем надо уточнить, соответствует ли производительность открытого проекта ожидаемым требованиям. Это особенно важно при выборе базы данных или инфраструктуры анализа больших данных. Если производительность критична, не стоит полагаться на опубликованные характеристики — надо провести сравнительное тестирование на реальных нагрузках.

Документация

Ответы на большинство вопросов относительно работы ПО можно получить, проанализировав его исходный код, но это весьма трудоемко, поэтому нужно оценить качество документации проекта — как технической (описание процедур инсталляции, сопровождения и др.), так и пользовательской (обучающие материалы, справочные руководства). В отношении большинства крупных проектов претензий обычно нет, но мелкие могут документироваться плохо. Попадаются, например, утилиты командной строки Unix без стандартной страницы руководства. Таких проектов лучше избегать, чтобы не тратить время на «вычисление» опций командной строки, а кроме того, пренебрежение интересами конечного пользователя может быть признаком наличия других проблем.

Исходный код

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

На качество кода нужно обратить внимание, даже если не планируется его менять: ошибки, уязвимости, узкие места производительности и трудности сопровождения могут негативно отразиться на работе. При этом не нужно разбираться во всех подробностях, чтобы получить объективное представление о характеристиках кода. Чтобы отбросить проблематичный проект, достаточно обратить внимание на файлы исходного кода: хорошим тоном считается, если они названы и размещены в каталогах в соответствии со стандартами используемого языка программирования. Должны присутствовать признаки того, что проект подвергается модульному тестированию, а в репозитории не должно быть посторонних вхождений, например объектных и исполняемых файлов. Хорошо, если методы или функции лаконичные и читаемые, идентификаторы имеют мнемонические названия, в коде достаточно комментариев, а его форматирование соответствует стандартам языка — отклонения могут свидетельствовать о скрытых недостатках.

Процедура сборки

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

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

Процесс

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

Разработка

При оценке качества процесса разработки проекта надо, в частности, выяснить, практикуется ли в нем непрерывная интеграция. Это просто определить по наличию соответствующих конфигурационных файлов (.travis.yml, Jenkinsfile) в каталоге проекта. Следует также уточнить, какие компоненты включены в конвейер непрерывной интеграции, предусмотрены ли статический анализ кода и модульное тестирование, выполняются ли сборка и проверка орфографии документации, подсчитывается ли тестовое покрытие, осуществляется ли контроль соблюдения стандартов кодирования, реализуется ли проверка зависимостей на актуальность. Ответы на эти вопросы можно получить, ознакомившись со значками на странице проекта в GitHub, хотя их наличие не всегда показатель качества проекта.

Фиксации кода

Важно обратить внимание на фиксацию кода в репозитории управления ревизиями. Отсутствие свежих фиксаций может означать, что при обнаружении ошибки или появлении новых требований они останутся без внимания. Исключение — стабильные проекты и лишь сохраняющие фиксацию (например, библиотеки функций численного анализа).

Тревожным сигналом может быть присутствие фиксации только от одного или нескольких авторов — в этом случае существует риск, называемый «фактором автобуса» (если ведущий разработчик попадет под автобус, развитие проекта завершится). Надо подробно изучить несколько фиксаций: они должны иметь понятные метки и описания, а также ссылки на задокументированные проблемы, исправленные согласно стандартной процедуре. Должны быть свидетельства того, что изменения кода обсуждались и подвергались ревизиям.

Релизы проекта

Далее следует разобраться, насколько свежими являются последние релизы проекта и как часто они публикуются. Если речь идет о проекте в области современных технологий (скажем, библиотеки глубинного обучения), обновления должны быть регулярными, а в случае стабильных проектов должны присутствовать свежие релизы с исправлениями. В некоторых случаях частая интеграция новых релизов компонента Open Source в кодовую базу нового продукта может быть нежелательной ввиду рисков и дополнительного объема работы. Чтобы избежать проблем такого рода, можно обратиться к специальному каналу релизов, на котором выходят только заплаты и критические исправления. Также, чтобы свести к минимуму проблемы с интеграцией крупных обновлений, надо уточнить, предусмотрены ли в проекте релизы с долгосрочной поддержкой и соответствуют ли их сроки действия графику выпуска вашего продукта.

Каналы поддержки

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

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

Разрешение проблем

Рано или поздно в используемом проекте с открытым кодом могут обнаружиться ошибки, поэтому стоит выяснить, как его участники решают проблемы такого рода. Во многих проектах есть доступ к системе управления проблемами (GitHub Issue, Bugzilla, Jira), где можно в деталях уточнить соответствующие процедуры. Следует выяснить, насколько быстро разрешаются проблемы, много ли из них остаются открытыми в течение длительного срока и сбалансировано ли соотношение открытых и закрытых проблем с учетом количества участников проекта.

Внесение исправлений и улучшений

Со временем может понадобиться внести изменения в исходный код проекта — для исправления ошибки или реализации новой возможности. Здесь можно сохранить изменения только для своего продукта, однако их интеграция в проект Open Source способствует развитию проекта и стимулирует выпуск новых релизов, не говоря уже о соблюдении требований лицензии.

Надо оценить, насколько просты процедуры внесения исправлений и доработки, уточнить наличие инструкции для участников. Если для продукта используются двоичные файлы проекта, то надо выяснить, легко ли будет провести сборку из исходного кода и тестирование. Полезно определить, насколько сложна процедура приемки изменений, и узнать, можно ли предоставить их удобным способом — например, посредством запроса на включение изменений (pull request) GitHub. Затем стоит выяснить, насколько регулярно в рамках проекта принимаются изменения от сторонних участников, поскольку некоторые организации выпускают проекты по лицензии открытого кода, но при этом ограничивают возможность внесения изменений в него третьими сторонами.

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

В частности, критерии с цветовой маркировкой относятся к решающим факторам, влияющим на отсеивание проекта. Если проблемы обнаружились при проверке критериев из столбца с желтой маркировкой, значит, придется формировать собственные ресурсы для поддержки проекта с открытым кодом. А если принимается решение обеспечивать такую поддержку, то нужно уделить повышенное внимание вхождениям, отмеченным зеленым. Выполнение всех перечисленных проверок дает хорошие шансы наладить крепкие, долгосрочные и взаимовыгодные отношения с проектами Open Source, выбираемыми для создания нового продукта.

Литература

1. A. Morin, J. Urban, P. Sliz. A quick guide to software licensing for the scientist-programmer // PLOS Comput. Biol. — 2012. — vol. 8, N. 7. — P. 1–7.

2. A. Trockman, S. Zhou, C. Kastner, B. Vasilescu. Adding sparkle to social coding: An empirical study of repository badges in the npm ecosystem. In Proc. 40th Int. Conf.

Software Engineering, 2018. — P. 511–522.

3. K. Yamashita, S. McIntosh, Y. Kamei, A. E. Hassan, N. Ubayashi. Revisiting the applicability of the Pareto principle to core development teams in open source software projects. In Proc. 14th Int. Workshop Principles of Software Evolution, 2015. — P. 46–55.

Программная инженерия,Разработка ПО,Управление процессом разработки,Open Source,GitHub,Software Engineering, Software Development

Источник: www.osp.ru

Бесплатные аналоги Open source

Scilab

Scilab — мощный математический пакет для построения 2D и 3D графиков, решения задач линейной алгебры, работы с разряженными матрицами; предоставляет возможность использования интерполяции и аппроксимации, дифференциальной и недифференциальной оптимизации. .

Sumatra PDF

Sumatra PDF — бесплатная программа для просмотра файлов следующих форматов: PDF, ePub, MOBI, XPS, DjVu, CHM, CBZ и CBR. Программа легка в использовании; помимо устанавливаемой версии имеется возможность воспользоваться переносной версией (portable), котора.

Manjaro

Manjaro — Linux или Manjaro — дистрибутив GNU/Linux, основанный на Arch Linux, использующий модель обновлений rolling release[3]. Официально доступно несколько версий: с рабочим окружением Xfce, KDE Plasma или GNOME..

Категории бесплатных программ

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

О проекте

Created by: Freeanalogs team.

Нашли ошибку или у вас есть предложение?

Источник: freeanalogs.ru