Принятие Программного обеспечения с открытым исходным кодом в [закрытой] организации
Порт 3000, 8080 и т.п. обычно используются в целях разработки, поскольку при разработке может быть полезно иметь несколько серверов, работающих одновременно, например, один на порту 3000, один на порту 3001 и т. Д. [ 113]
Однако , в Интернете HTTP подается на порт 80, а HTTPS - на порт 443. Таким образом, в основном, в вашей реализации сервера, вы должны установить порт динамически: он не должен совпадать работаете ли вы в производстве и в разработке!
Я лично использую тот факт, что в моей производственной среде (т. е. для вас, на машинах развертывания GoDaddy) переменная среды PORT уже установлена в 80, тогда как на моем локальном компьютере я не установил его, поэтому я могу написать это:
const express = require('express');
const port = process.env.PORT || 3000; // 3000 on my machine, 80 on GoDaddy's server
const app = express();
app.listen(port, () => console.log(`App listening on port ${port}`));
И я получаю доступ к серверу по этим URL:
http://localhost:3000/
http://example.com:80/
http://example.com/
Последние два одинаковы потому что, как уже было сказано, HTTP-порт по умолчанию - 80.
5 ответов
Термин "Открытый исходный код" только описывает модель лицензирования. Строго говоря единственными про, которые Вы, как гарантируют, будете иметь, являются свободы, данные лицензией, и нет никаких недостатков, которые Вы, как гарантируют, будете иметь.
Существует много продуктов С открытым исходным кодом, которые являются также коммерческими, создаются, сохраняемые и поддерживаемые компанией для прибыли. Существует также много продуктов С открытым исходным кодом, которые сохраняются волонтерами, но также и поддерживаются коммерчески. Например, при покупке Red Hat Enterprise Linux затем Red Hat будет поддерживать Вас на всех продуктах, которые идут с ним, даже те, которые сохраняются волонтерами.
Что касается того, как быть уверенными, что будет постоянная поддержка, Вы не можете. Не с Открытым исходным кодом, не с собственным программным обеспечением, не с чем-либо. С Открытым исходным кодом, если сообщество является достаточно многочисленным, можно быть довольно уверены, что сообщество продолжит поддерживать его (возможно, под новым именем), даже если текущие специалисты по обслуживанию откажутся от него, и у Вас есть опция поддержания его самих или найма кого-то еще, чтобы сделать это. Поддержание его самостоятельно не может быть привлекательной опцией, но это может быть жизненное средство сохранения в повышении.
С собственным программным обеспечением, если автор решает прекратить поддерживать его, Вам просто не повезло. Рассмотрите, например, тысячи пользователей Visual Basic 6.
Основное, про из Программного обеспечения с открытым исходным кодом, проиллюстрировано Вашим комментарием:
[В] случай собственного программного обеспечения, существует стимул для организации (деньги), и они будут продолжать нанимать людей для хранения этого разрабатываемым, пока программное обеспечение является прибыльным.
Проблема состоит в том, что, если это прекращает быть прибыльным (например, потому что код так стабилен, что люди покупают его и продолжают использовать его, не нуждаясь в обновлениях), затем пользователи того программного обеспечения могут быть скручены с их хорошим стабильным продуктом, работающим на все больше древних машинах до, однажды, катастрофический отказ машин, или должны быть обновлены до новой версии операционной системы так, чтобы они могли выполнить некоторую другую систему, но потому что собственное программное обеспечение больше не сохраняется, необходимо разочароваться в приложении. Действительно, это не неслыханно для компаний, которые продают собственное программное обеспечение, чтобы обанкротиться. И, если Вы не удостоверились, что был счет условного депонирования кода для программного обеспечения для защиты Вас от возможности поставщика, обанкротившегося, затем Вы застреваете.
Если код был Открытым исходным кодом, и Вы были разумны (Вы получили источник при получении продукта) то можно взять старый продукт и портировать его на новую систему. Как трудно, который будет, зависит от природы и качества кода - но это возможно. Если программное обеспечение было собственным, у Вас никогда не может быть опции.
Не имеет значения, какой менеджер противостоящий Открытый исходный код заявляет.
Необходимо знать хорошо продукт С открытым исходным кодом, который Вы собираетесь использовать.
Необходимо быть уверены что это правильное решение для компании. Необходимо быть уверены, что можно найти людей на рынке, которые знают или могут учиться использовать тот продукт. Необходимо знать TCO для того продукта.
Затем можно спорить с менеджером и привести ему серьезные причины, как компания может извлечь выгоду из Открытого исходного кода.
Следует иметь в виду, что самым дешевым решением не является лучшее решение. Компании должны заработать деньги, чтобы не сэкономить деньги.
Зависит от ситуации, но обычно, для a, внутреннего, некритического, никакая потребность к защищенной системе, как большая часть того, что сделано на предприятии, открытый исходный код похож на Хэллоуин, и Вы не должны действительно заботиться, пока Вы следуете за политикой предприятия.
Для другое большое, важное, должны быть защищенные проекты, его действительно простое. У Вас должна быть часть в проектах, Вы используете и имеете внутренний репозиторий, размещающий проект (таким образом, у Вас есть внутреннее ответвление, которое сохранено в синхронизации с внешним ответвлением). Вещь состоит в том, что те приложения - те, которые занимают долгое время дерьма для создания и поддерживаются в течение тысяч лет. Команды склонны изменяться много и существует много вовлеченных людей. Кто-то нуждается и может быть присвоен репозиторию/управлению сборками.
Теперь, если ее единственное о менеджере, то его примерно коммуникация и аргументация. Обычно они боятся о поддержке, потому что это - долгосрочная стоимость. Они склонны любить слышать о лучших практиках, хорошо чтобы сказать им это - то, что крупные компании делают (и примеры) и что они также имеют тенденцию участвовать в проектах и другие времена них даже или ее возможном для нахождения поддержки его.
Кроме того, любой подрядчик будет рад оказать поддержку OSS. Кто сказал бы "нет" деньгам и способности разработать OSS.
Вопрос: что Вы имеете в виду с "принятием программного обеспечения с открытым исходным кодом". при планировании на радикально обменный каждой части программного обеспечения с закрытым исходным кодом (CSS) с Программным обеспечением с открытым исходным кодом (OSS) Вы перестанете работать ужасно.
Я могу гарантировать Вам, из которых Ваша организация уже использует OSS в ключевых ролях, он - инфраструктура ИТ.
В моей точке зрения только необходимо формализовать, как OSS может ввести компанию и если (и в который форма) компания способствует назад OSS. Большинство компаний требует контракта на поддержку для важнейшего программного обеспечения и передает под мандат то OSS, должен быть куплен через поставщиков, которые оказывают поддержку.
Во многих случаях содействие назад в проекты OSS явно запрещается и только позволяется после знаков технического директора/директора по информационным технологиям на определенном вкладе.
Просто удостоверьтесь, что Ваши политики достаточно гибки для разрешения то, что в настоящее время выполняет отдел ИТ.