что значит программа с открытым исходным кодом
Открытый исходный код 101: Что это такое?
Russian (Pусский) translation by Ilya Nikov (you can also view the original English article)
Проекты с открытым исходным кодом доступны везде, в Интернете, на вашем компьютере и на вашем мобильном телефоне. В этой статье мы рассмотрим:
1. Что такое ПО с открытым исходным кодом?
Хотя программное обеспечение с открытым исходным кодом в основном разрабатывается и поддерживается группой людей, каждый может получить доступ к коду и поиграть с ним, если захочет.
Я внес свой вклад в несколько проектов с открытым исходным кодом и это отличный способ стать лучшим разработчиком и приобщиться к сообществу. Вы учитесь на чужом коде и учитесь писать код лучше сами. Знакомство с проектом с открытым исходным кодом, над которым вы работали вместе с другими разработчиками, является одним из самых приятных ощущений, которые я испытывал в качестве разработчика.
Давайте начнем с рассмотрения некоторых популярных примеров ПО с открытым исходным кодом. Вы можете быть удивлены огромным объемом проектов с открытым исходным кодом, а также некоторыми компаниями, стоящими за этими проектами, такими как Google и Automattic.
2. Популярные примеры
Доступны миллионы проектов с открытым исходным кодом. Ниже приведен список некоторых очень популярных и примечательных примеров.
3. Как это работает
Проект с открытым исходным кодом обычно включает три этапа. Давайте быстро рассмотрим каждый этап.
Этап 1. Содействие
Если вы хотите участвовать в проекте с открытым исходным кодом, вы можете начать с обращения в организацию, которая находится за самим программным обеспечением, и спросить, какие возможности у них есть. Этот метод будет хорошо работать для небольших проектов или стартапов, однако вы должны знать, что большинство проектов с открытым исходным кодом не будут платить за вашу работу и что все делается на добровольной основе.
Раньше, когда я работал над проектами с открытым исходным кодом, мне приходилось ждать недели (и в одном случае, два месяца), прежде чем я получил ответ, но вы должны сидеть там и ждать, пока получите все важные электронные письма с подтверждением.
Альтернативно, для крупномасштабных проектов вы можете просто начать кодирование и разветвление собственной версии программного обеспечения. Вам следует с осторожностью относиться к тому, что если многие люди работают над одним и тем же проектом, что и вы, то ваш тяжелый труд не может быть включен в окончательную версию продукта, поэтому будьте готовы к отказу.
Если вы ищете вдохновение в проекте, над которым нужно начать работать, всегда есть много интересных проектов, особенно если вы смотрите на сайтах, таких как GitHub, SourceForge и Google Code.
Прежде чем приступить к фактической работе над проектом, вы должны ознакомиться с тем, как выполняется проект и какова его структура, чтобы вы знали, к кому обратиться, если вам требуется в чем-либо помощь. Кроме того, рекомендуется проверить, правильно ли вы все делаете, прежде чем начинать, поскольку вы же не хотите запутаться в чем-то, либо потратить время на работу над функцией, над которой уже работает кто-то другой.
Этап 2: фиксация
Когда вы внесли необходимые изменения или внедрили функцию, которую вы задумали, вы передаете свои изменения основному проекту и отправите их разработчикам проекта для просмотра.
Это можно сделать с помощью GitHub или на платформе SourceForge. Обычно ваши изменения получают ответ от организации или команды, отвечающей за проект: да или нет, указывая, будут ли ваши изменения включены в проект. Если да, то настало время для стадии распространения. Если нет, то возвращаемся на первую стадию.
Этап 3. Распространение
Возможно, наиболее сложным этапом является распространение проекта с открытым исходным кодом. Здесь окончательная версия передается в репозиторий, где был размещен проект, а обновленные версии для не-разработчиков обновляются. На данный момент организация и разработчики попрощались с их напряженной работой и передали ее общественности для общего пользования, и, конечно, критики.
В итоге
Надеюсь, вы теперь более уверенно себя чувствуете в разработке с открытым исходным кодом и в том, как вы можете сами участвовать в проекте. Открытый исходный код может быть действительно интересным, но иногда и очень неприятным. Главное, что нужно иметь в виду, это продолжать идти и не сдаваться, когда вы попадаете на препятствие.
Открытый исходный код — благо или троянский конь?
Сразу хочется сузить рамки — разговор идет о продаже программного продукта (php+MySQL).
Вопрос — (про)давать ли исходный код?
Аргументы в пользу закрытого кода.
— Подавляющему большинству клиентов нужно чтобы продукт работал и исходный код не нужен.
— При закрытом коде проще осуществлять тех. поддержку — клиент своими руками не залезет куда не надо и не породит новых уникальных ошибок, в которых хрен разберешься.
— Сложнее стырить исходный код. А точнее его можно получить, но вот что-то серьезное переделать в этом «исходнике» сложно — максимум сломать защиту, внести незначительные правки.
— Есть некоторая надежда разработчика, что закрытый код спасет от перепродажи его продукта лихими людьми.
— Есть легкая надежда, что купят продукт, потому как «сломать» не смогут, либо «ломанный» побоятся использовать.
— Народ (наш народ 🙂 ) привык что если код открыт, значит бесплатно!
Аргументы в пользу открытого кода.
— Иногда клиенту просто хочется иметь возможность взглянуть на код. То есть не обязательно даже его иметь, но чтобы возможность такая была. Это могут быть параноики безопасности в хорошем смысле или просто борцы за какие-то права.
— Клиент имеет возможность внести правки, причем весьма серьезные. Вплоть до потери совместимости с последующими версиями продукта (хотя вот это возможно уже в минус).
— Нет проблем с дешифратором закрытого кода. Не секрет, что такие проблемы встречаются (отсутствие Зенда и иже с ним, какие-то локальные глюки т.д.).
— Есть возможность построить сообщество разработчиков купивших скажем девелоперскую лицензию с доступом к открытому коду.
Добавлю немного конкретики.
Вопрос «открытого кода» интересует в связи с «внутрифирменной» дискуссией по поводу развития одного из наших продуктов (CNCat). Мы проходили разные стадии (открытый код, Зенд) и сейчас осуществляем обфрускейтивание (замену названий переменных на бессмысленные) и легкую шифрацию. Когда мы давали продукт в открытом коде и давали его бесплатно — много кто тырил код и на его основе делали свои продукты без всяких ссылок на нас. Что было немного обидно и сейчас не хочется на этом обжечься опять.
Однако правильное позиционирование открытого кода (АПИ, поддержка, контроль и т.д.) может дать нам приток сторонних разработчиков новых фич, мощную обратную связь, отладку — в общем новый импульс.
Дык хочется получить какие-то дополнительные аргументы или мысли по данному вопросу. Как бы Вы повели себя как клиент, как разработчик (конечно желательно чтобы Вы им являлись, чтоб не голословно)? Может есть какие в мире устоявшиеся теории и доказанные практикой подходы (типа фри версия закрыта, купленная открыта)?
Open Source Guides: Запуск проекта с открытым исходником
Предисловие переводчика
Пару месяцев назад на Гитхабе случайно наткнулся на ссылку «Open source guides» и не мог оторваться. Где-то за неделю я внимательно прочитал все 10 разделов. Конечно, я и раньше знал про open source: читал разные статьи (например, «Понять Open Source»), использовал такие проекты в работе, обращался с вопросами к сообществам, сообщал о багах, рыскал в issues и, даже делал неуклюжие попытки что-то улучшать, хотя бы документацию. И само собой, сердцем я был с этими ребятами, которые делятся софтом и знаниями по его использованию. Тем не менее, понятие об open source у меня было скорее смутное и обрывочное. А эта статья добавила ясности.
К тому же, у меня была пара проектов, которые я планировал запустить в этом формате, с надеждой на поддержку сообщества, и со многими сопутствующими страхами и сомнениями, и снова эта статья помогла мне утвердиться в намерении и подсказала практические шаги.
Вне зависимости от вашего отношения к open source, думаю, вы найдёте в этой серии из 10 статей много интересных идей и фактов: организационных, психологических, юридических, этических и технических.
Я дал прочитать этот текст нескольким непрограммистам, они сказали, что всё поняли. А в заголовке статьи я намеренно поставил «исходник» без «кода», потому что данная тема актуальна не только для программистов, а почти для любой интеллектуальной деятельности в формате открытого проекта.
Само это руководство также является open source и уже переведено на 14 языков. Мне выпала честь добавить русскую ветку и перевод первой статьи. Я планирую и дальше переводить по статье в неделю. Если кто хочет подключиться, вот репозиторий: Open Source Guides.
Если вдруг кому-то понадобится заставка из шапки статьи (иллюстрации + русские названия), то она есть в сверстанном виде на codesandbox.io.
Подбор терминов
Я заранее извиняюсь за огрехи в переводе. Некоторые, казалось бы банальные термины, не так легко подобрать на русском. Например, to contribute, pull request, issue, я чаще переводил как «участвовать в проекте, предлагать исправления и вопрос». Open source я пока оставил на английском. Мне уже сделали замечание и выслали ссылку на словарь терминов Гитхаба. Мне не понравилось там обилие транслитерация. Если пустить в статью все эти ишью, пулреквест, пуш, пул, форк, то она станет непонятной для всех, кто не работал с Гитхабом.
Оглавление
Открытый исходный код: что это и зачем?
Итак, вы думаете о запуске своего проекта с открытым исходным кодом (open source)? Поздравляем! Мир ценит ваш участие. Давайте поговорим о том, что такое open source и почему люди это делают.
Что означает «open source»?
Когда код проекта открыт, это означает, что любой может свободно использовать, изучать, изменять и распространять ваш проект для любых целей. Эти разрешения даются через лицензию с открытым исходным кодом.
Преимущество открытого кода в том, что он снижает барьеры для выбора вашей программы и сотрудничества, позволяя людям быстро распространять и улучшать проекты. Кроме того, это дает пользователям возможность контролировать код, в отличии от закрытого. Компания, использующая программное обеспечение (ПО) с открытым исходным кодом, может нанять кого-то для внесения улучшений в ПО, а не полагаться исключительно на решение поставщика с закрытым исходным кодом.
Свободное ПО (Free software) ссылается на те же проекты, что и открытое ПО (open source). Иногда вы можете встретить комбинации этих терминов: «Свободное и открытое ПО» (free and open source software FOSS или free, libre, and open source software FLOSS). Слова free и libre здесь означают «свободное», а не «бесплатное».
Почему люди делают свою работу открытой?
Одно из самых больших вознаграждений, которое я получил от open source — это отношения, установившиеся с другими разработчиками, столкнувшимися с такими же проблемами как и я.
@kentcdodds, «Как мне было здорово войти в Open Source»
Есть много причин почему индивид или организация открывают исходники своего проекта. Вот некоторые из них:
Open source — значит бесплатно?
Бесплатность open source — это одно из его самых больших преимуществ, но не единственное, а скорее — побочный продукт его совокупной ценности.
Поскольку открытая лицензия предполагает, что кто угодно может использовать, модифицировать, и распространять ваш проект почти для любых целей, то в большинстве случаев это подразумевает бесплатность. Потому что, если бы вы просили плату, то люди бы скачивали проект и использовали его бесплатно, абсолютно легально.
Поэтому большинство open source проектов бесплатны, но это не входит в определение open source. Существуют способы взимания платы за проекты с открытым исходным кодом косвенно, через двойное лицензирование или ограниченные функции, но при этом они соответствуют официальному определению open source.
Стоит ли мне запускать свой open source проект?
Краткий ответ — да, потому что независимо от результата, запуск своего проекта — это хороший способ понять, как работает open source.
Если вы никогда прежде не запускали подобных проектов, вы можете переживать: «что скажут люди?», «а вдруг вообще никто его не заметит?». Если вам это знакомо, не беспокойтесь, вы не один такой!
Open source, как и любая творческая работа, будь то писательство или рисование, вызывает волнение прежде чем поделиться ей с миром. Но единственный способ улучшить её — практиковаться, даже если у вас не будет аудитории.
Если вы ещё не решились, найдите время подумать о ваших возможных целях.
Постановка целей
Цели помогут вам определиться, над чем работать, от чего отказаться, и где вам понадобится помощь со стороны. Спросите себя: «зачем я опенсорсю этот проект?».
Единого ответа на этот вопрос не существует. Вы можете иметь много целей для одного проекта, или разные проекты с разными целями.
Если ваша цель просто показать свою работу и нет нужды в сотрудничестве, вы можете так и написать в файле README. С другой стороны, если вы заинтересованы в помощниках, то вам следует вложить своё время в написание понятной документации и проявлять заботу о новичках.
mavris@mavris, «Программисты самоучки: Почему Open Source важен для нас»
По мере роста проекта ваше сообщество будет нуждаться не только в коде. Ответы на вопросы (issues), проверка кода, распространение информации о себе — всё это важные задачи open source проекта.
Хотя количество времени на непрограммистские задачи зависит от размера и масштаба вашего проекта, вы должны быть готовы решать их сами или найти для этого помощника.
Если вы — часть компании, запускающей open source проект,, убедитесь заранее, что вы имеете внутренние ресурсы для его развития. Назначьте ответственного за сопровождение после запуска и определите, как будут распределяться задачи внутри сообщества.
Если вам нужен выделенный бюджет или персонал для продвижения, эксплуатации и поддержки проекта, обговорите это как можно раньше.
@captainsafia, «Чё, хочешь открыть код проекта?»
Участие в чужих проектах
Если ваша цель — понять как взаимодействовать с другими и как работает open source, рассмотрите возможность участия в уже существующем проекте, который вы используете и любите. Вашим участием могут быть такие простые вещи, как исправление опечаток и обновление документации.
Если вы не понимаете, как начать участие в чужом проекте, ознакомьтесь с нашим руководством Как участвовать в open source проекте.
Запуск собственного open source проекта
Нет идеального момента, чтобы открыть исходники своей работы. Вы можете открыть их на стадии идеи, в процессе работы или после нескольких лет закрытости.
В общем случае, открывать исходники можно, когда вы чувствуете себя уверенно настолько, чтобы показать свою работу посторонним людям и получать их отзывы.
Каждый проект вне зависимости от стадии, на которой вы решили открыть исходники, должен иметь следующую документацию:
Если ваш проект на Гитхабе и вы разместите эти файлы в корневой категории с рекомендованными названиями, Гитхаб распознает их и будет автоматически отображать для ваших читателей.
Выбор лицензии
Лицензия для открытого исходного кода гарантирует, что другие могут использовать, копировать, изменять и вносить правки в ваш проект без каких-либо последствий. Она также защищает вас от неприятных юридических ситуаций. Вы должны включить лицензию при запуске проекта с открытым исходным кодом.
Юридическая работа — не из легких. Но есть хорошие новости: вы можете скопировать существующую лицензию и разместить её в своём репозитории, за одну минуту защитив ваш тяжелый труд.
MIT, Apache 2.0, и GPLv3 — это самые популярные лицензии, но есть и другие варианты для выбора.
Когда вы создаёте новый проект на Гитхабе, вам дается на выбор несколько лицензий. Выбрав open source лицензию, вы сделаете свой проект — открытым.
Если у вас есть другие вопросы или беспокойства относительно юридических аспектов open source, мы описали их здесь.
Составление README
Файл README («прочитай меня») не только рассказывает, как использовать ваш проект, но и объясняет, почему он важен, и что пользователи могут с ним делать.
Постарайтесь ответить в README на следующие вопросы:
@tracymakes, «Писать так, чтобы ваши слова читали (видео)»
Иногда люди откладывают написание README, потому что чувствуют, что проект не завершен, или не хотят принимать доработки других людей. Но это как раз хороший повод написать об этом.
Когда вы добавляете файл README в корневую директорию проекта, Гитхаб автоматически отображает его на главной странице репозитория.
Написание руководства для участников
Файл CONTRIBUTING говорит вашей аудитории, как стать участником вашего проекта. Например:
В первую очередь хотим выразить вам благодарность за то, что подумываете об участии в развитии Active Admin. Именно такие люди как вы делают Active Admin прекрасным инструментом.
На ранних стадиях проекта ваш файл CONTRIBUTING может быть простым. Вы всегда должны объяснить как сообщать об ошибках и оформлять вопросы, а так же описать технические требования к правкам участников (например, тесты).
Со временем вы можете дополнить его ответами на часто задаваемые вопросы. Благодаря этому меньше людей будут спрашивать вас об одном и том же снова и снова.
Чтобы вам было проще составить файл CONTRIBUTING, ознакомьтесь с @nayafia’s шаблоном руководства по сотрудничеству или mozilla’s «Как составить файл CONTRIBUTING.md».
Поставьте ссылку на файл CONTRIBUTING внутри README, так больше людей увидят его. Если вы разместите файл CONTRIBUTING.md в корне вашего проекта, то Гитхаб будет автоматически ссылаться на него, когда кто-то открывает новый вопрос (issue) или добавляет правку в проект (pull request).
Разработка кодекса поведения
@mlynch, Делаем open source более счастливым местом
В итоге, кодекс поведения задаёт базовые правила поведения для участников вашего проекта. Это особенно важно, если вы запускаете проект для компании или сообщества. Кодекс поведения способствует установлению здорового, конструктивного поведения в сообществе, что снижает стресс для вас, как для ответственного за проект.
Помимо описания каким вы хотите видеть поведение участников, кодекс поведения также разъясняет, к кому и когда он применяется, и что будет в случае его нарушения.
По аналогии с лицензией, вам не обязательно писать кодекс самим, а можно скопировать один из существующих вариантов. Соглашение участника используется в более 40,000 open source проектах, включая Kubernetes, Rails, и Swift. Какой бы кодекс вы не использовали, вы должны быть готовы применить его при необходимости.
Поместите файл CODE_OF_CONDUCT.md в корень вашего проекта, так его будет проще находить и ссылаться на него, например, из README.
Именование и брендирование вашего проекта
Брендирование — это не только броский логотип и запоминающееся название, но и то, как вы говорите о своём проекте и до кого доходит ваше послание.
Выбор правильного названия
Выберите название, которое легко запомнить и, в идеале, даёт представление о сути проекта. Например:
Выбирайте в пользу понятности. Каламбуры могут быть забавными, но подумайте о людях из других культур или с отличным от вашего опытом, которые могут не понять шутку. Ваши потенциальные пользователи могут быть работниками компаний, которые будут рассказывать о вашем проекте начальству. Не заставляйте их краснеть при этом.
Конфликт имён
Проверьте наличие open source проектов с таким же названием, особенно если вы используете один и тот же язык или экосистему. Если ваше название совпадёт с популярным существующим проектом, вы можете запутать свою аудиторию.
Если вы планируете завести сайт, твиттер или любую площадку для публикаций, убедитесь, что нужное вам название там свободно. И лучше зарезервируйте эти имена сейчас для душевного спокойствия, даже если пока не планируете ими пользоваться.
Убедитесь, что вы не посягаете на торговую марку какой-нибудь компании. В будущем она сможет попросить вас закрыть проект или даже подать в суд. Это неоправданный риск.
Вы можете проверить конфликт брендов по всемирной базе брендов WIPO. Если вы делаете проект от лица компании, то юридический отдел может помочь вам с этим.
Напоследок, сделайте быстрый поиск в Google по названию вашего проекта. Смогут ли люди по нему легко найти ваш проект? А может быть, по этому запросу появляется что-то нежелательное?
То, как вы пишите (и кодите) тоже влияет на ваш бренд!
За всю жизнь проекта вы будете много писать: README, руководства, документы сообщества, ответы на вопросы, возможно даже информационные бюллетени и списки рассылки.
Будь то официальная документация или обычное сообщение, ваш стиль письма — это часть бренда проекта. Подумайте о том, в каком свете вы выглядите перед аудиторией, и правильный ли подобрали тон.
@janl, CouchDB, «Устойчивый Open Source»
Добрый и вежливый язык создаст приятную атмосферу для новых участников. Следите так же за простотой изложения, так как для многих читателей английский может быть не родным.
Не только слова, что вы пишете, но и стиль кода может стать частью бренда вашего проекта. Angular и jQuery два примера проектов со строгими стилями и рекомендациями.
Нет необходимости составлять руководство по стилю, когда вы только начинаете, и в любом случае вы наверняка захотите включать в свой проект разные стили. Но вы должны заранее понимать, что ваш стиль письма и кода будет привлекать одних людей и отталкивать других. Ранние стадии проекта — это возможность создать прецедент, из которого будет расти проект в желаемом для вас виде.
Проверочный лист перед запуском
Вы готовы открыть свой проект? Вот вам проверочный лист в помощь. Когда отметите все пункты, нажмите «опубликовать» и похвалите себя.
Документация
Если вы частное лицо:
История Open Source кратко: от калькулятора до миллиардных сделок
Когда говорят «Open Source», обычно первые ассоциации — это Ричард Столлман и Линус Торвальдс. Но Open Source начался не с них. Когда в 50-х учёные и инженеры писали ПО, например, для IBM 701, они безвозмездно обменивались результатами своего труда и работали над улучшениями программ своих коллег. Тогда ещё не было проприетарного (закрытого) ПО, но Open Source проекты уже были, и это было задолго до Столлмана и Торвальдса. В истории Open Source было много интересного: программы для «Оборонного калькулятора», коммерциализация UNIX, письмо Билла Гейтса, манифест GNU, Linux и миллиардные сделки покупок Open Source компаний. Мы попробовали разобраться в истории и узнать с чего начался Open Source, какие события способствовали его развитию и почему без Open Source IT не был бы таким, какой он есть.
Если вам интересен Open Source, то, возможно, наш взгляд на историю тоже будет занимателен.
Что такое Open Source для тех, кто совсем не слышал
Если говорить обобщённо, то представим, что мы хотим построить себе дачу. Для этого покупаем проект в коммерческой организации, которая проектирует дома. В контракте указано, что мы можем использовать проект, но менять его или поделиться им не можем. Это проприетарный продукт.
Но что, если мы нарисуем проект сами и построим по нему дом? Потом опубликуем проект в интернете в свободном доступе, чтобы кто-то другой мог его использовать. Другие пользователи используют наши наработки, просят нас что-то поменять или меняют сами, например, цвет фасадов и размер комнат, и также публикуют его в свободном доступе. Это Open Source. А если кто-то на основе производных от нашей работы начнет зарабатывать, например, строить по ним дома, то это тоже Open Source.
Примерно так можно представить себе Open Source ПО.
«Open Source это способ взаимодействия с ПО, который исключает такие занозы, как контракты при покупке ПО или адвокатов. Мы просто хотим, чтобы программы работали, а люди могли присылать патчи к ним»
Брюс Перенс, автор набора правил соответствия Open Source, руководитель проекта Debian 1996-1997.
В определении на Open Source Initiative указано, что Open Source Software (OSS) — это ПО, «исходники» которого доступны для просмотра и изменения. На основе исходного кода можно создавать свои модификации ПО, а также свободно распространять и продавать. OSS — это, в первую очередь, про распространение, свободу использования, а не про деньги, потому что OSS может быть и платным, и бесплатным.
Предпосылки свободного ПО: всё началось с калькулятора
Изучение истории начнём с 50-х, пропустив эпоху «ламповых» компьютеров величиной с дом. Когда ЭВМ стали уменьшаться до размеров небольшой комнаты, то уже можно было ими пользоваться не только в оборонке, например, для вычисления траекторий ракет.
С 1952 по 1955 компания IBM стала выпускать IBM 701. Это первая коммерчески доступная ЭВМ, которая производилась серийно. Аппараты сдавали в аренду научным институтам, военным компаниям и государственным предприятиям. Физическим лицам не давали, да и стоило это космических денег — от 12 до 20 тыс долларов в месяц или больше 100 тыс современных.
IBM 701 называли также Defense Calculator
Выпуск этой модели — первая точка отсчета в истории. Всё потому, что в комплекте с компьютером было только железо — никакой ОС и программ. Все программы ученые и инженеры писали сами и делились с коллегами из других компаний, у которых была такая же ЭВМ. Можно сказать, что IBM 701 — это первые компьютеры, к которым начали писать «свободно распространяемое» ПО.
Примечание. Это неудивительно — все научные знания находятся в свободном доступе. Ведь нет никаких законов физики, которые скрывают (гипотезы заговоров мы не рассматриваем, естественно)? В науке всегда поощрялось, когда ученые делятся и открыто обсуждают свои находки и открытия, потому что теории, технические разработки и технологии базируются на предыдущих открытиях.
За несколько лет для 701 и его потомков «семисотой» серии успели наработать достаточно большую базу ПО. Например:
Компиляторы РАСТ, которые использовали методы хеширования (в том числе для 704). Их совместно разработали компания PACT (военный подрядчик) и IBM.
SOS — Share Operating System. Это примитивная ОС, которая основана на разработках General Motors.
Появились языки программирования Interlisp, UCI Lisp и высокоуровневый ЯП Speedcoding для IBM 701, который написал Джон Бэкус для облегчения работы с ассемблером. Для IBM 704 он же разработал FORTRAN и компилятор (1956).
IBM 701 подтолкнул рынок к разработке других коммерческих ЭВМ. Например, появился Bendix G-15 (1956) с массой «всего» 450 кг, Librascope LGP-30 (1956) или первый мини-компьютер PDP-1 (1960) для одного оператора. А когда в 1965 вышел PDP-8, он стал хитом. Это первый коммерчески успешный мини-компьютер, который продавался тысячами единиц предприятиям и научным лабораториям: небольшой, быстрый и стоил «всего» 18 000 долларов.
Рождение, рассвет и коммерциализация UNIX
Моделей коммерческих компьютеров было достаточно, они стали появляться у любителей, рынок рос. Но у всех компьютеров был один недостаток — нет ПО. Под каждую модель ОС писали с нуля. Компании-производители создавали каждый свою операционную систему, например, BESYS, Compatible Time-Sharing System или CP/CMS.
Из всех ОС нас больше интересует BESYS. Её создала Bell Labs для IBM 7090 и IBM 7094. На основе этой ОС с 1965 по 1969 MIT, Bell Labs и General Electrics разрабатывали ОС Multics. Это должна была быть инновационная ОС: централизованная файловая система с иерархическим деревом, разделение памяти процессов, виртуальная память, динамическое связывание и другие фишки. Но что-то пошло не так: работа затянулась, возникли разногласия и компания Bell Labs покинула проект.
Но два сотрудника компании Кен Томпсон и Деннис Ритчи решили «переиспользовать» модульный дизайн Multics и написать на её основе другую ОС.
Кен Томпсон и Деннис Ритчи (справа)
Первую версию ОС Томпсон написал в отпуске на домашнем PDP-7, презентовал руководству и получил команду разработчиков. Проект получил название UNIX.
Примечание. Полное описание системы и историю на русском можно прочитать в учебном пособии «Операционная система UNIX».
Только через 4 года (1973) систему вывели в свет с открытым кодом. Неожиданно она начала захватывать рынок. На это были причины:
Уже существовал рынок программ. Все модели «семисотых» IBM после 701 поставлялись в комплекте с ПО, и продавались физическим лицам. Цена, естественно, была включена в стоимость железа. Но под давлением антимонопольных регуляторов в 1969 году компания начала продавать ПО отдельно. ОС UNIX здесь пришелся как нельзя кстати.
Небольшая цена. За Bell Labs тоже следили регуляторы. Компания принадлежала гигантам телекома AT&T и Western Electric и на них всех распространялось антимонопольное законодательство. Поэтому на UNIX нельзя было завышать цены — ОС продавалась по цене не сильно выше себестоимости физической копии.
Ориентация на массовость. UNIX изначально разрабатывалась именно для персональных машин, например, для PDP-11, которых выпустили 170 тыс. ОС сразу была нацелена на массовый рынок любителей.
Простота и модульность. UNIX состоял из небольших модулей. Каждый модуль отвечал за отдельную функцию и легко менялся.
Переносимость. UNIX было не сложно перенести с одного ПК на другой. Поэтому быстро появлялись рабочие версии UNIX под новые модели компьютеров.
Но UNIX уже не была свободным ПО: пользователи не имели права делиться или менять исходный код. Однако, благодаря тому, что AT&T была монополией, компания была обязана предоставлять исходный код (с некоторыми ограничениями) разным университетам. Один из университет — Калифорнийский университет в Беркли, начал заниматься улучшениями ОС. Так появилась собственная «университетская» ОС BSD — Berkley Software Distribution.
В первой версии BSD содержался доработанный компилятор языка Pascal, текстовый редактор Ex, а «апдейты» из BSD переносили в UNIX. BSD была лучше, постоянно обновлялась, в ней появлялись передовые сетевые технологии. Но когда университет стал продавать коммерческие лицензии BSD от 750 до 1000 долларов, корпорация AT&T поняла, что теряет прибыль, и в 1979 году ограничила распространение исходного кода ОС. Позже, в 1983 году Bell Labs «отделилась» от AT&T, и антимонопольные законы уже не мешали коммерциализировать UNIX. Цена ОС выросла — теперь она стоила тысячи и десятки тысяч долларов.
Немного цен на UNIX
Проприетарное ПО и Гейтс
Превратить UNIX полностью в коммерческую ОС у Bell Labs получилось, потому что примерно в то же время, что родился UNIX, разработчики ПО всё больше начинают защищать авторские права на свои технологии. Когда всё начиналось с IBM 701, за ОС, компиляторы, языки и программы никто не брал деньги и не требовал авторских отчислений. Все ЭВМ содержались в лабораториях, компаниях, научных центрах — в академической среде, где информация распространялась свободно.
На рынке появлялось больше ПК: они уменьшались, дешевели, их покупало всё больше коммерческих компаний и частных лиц. Появлялось всё больше ПО (в основном на высокоуровневых FORTRAN и COBOL), которое писали энтузиасты или сотрудники коммерческих компаний и всё чаще возникал вопрос, нужно ли лицензировать программы. В итоге в 1974 программы приравняли к литературным произведениям. Началась разработка лицензий для программ, появились юридические запреты на изменение продуктов сторонними разработчиками.
«Свободное ПО появилось вместе с компьютерами. Оно тогда всё было свободное — просто давали друг другу. Только, пожалуй, в конце 70-х, начале 80-х, люди начали закрывать своё ПО, стали говорить: «Нет, вы никогда не увидите исходный код, даже если это важно для ваших нужд. Пожалуй, винить в этом нужно Майкрософт — именно они были пионерами проприетарной модели ПО»
Брюс Перенс, автор набора правил соответствия Open Source, руководитель проекта Debian 1996-1997.
В 1975 году Билл Гейтс и Пол Аллен разработали интерпретатор языка Basic для тогда ещё нового персонального компьютера Altair 8800 от компании MITS. Как ни странно, но интерпретатор работал, MITS заключила контракт с Алленом и ещё тогда студентом Гейтсом. По контракту они получали отчисления за проданные копии BASIC: от 30 до 60 долларов. Цена на копию программы начиналась с 500 долларов, тогда как железо могло стоить меньше сотни.
Возможно, покупатели компьютеров не хотели платить в разы больше за ПО, чем за железо, потому что в итоге компьютеры продавались тысячами, а BASIC — сотнями. Тогда в 1976 году Билл опубликовал своё знаменитое «Открытое письмо энтузиастам компьютерного клуба».
В письме было много обвинений в краже ПО (прим: дальше вольный перевод).
«…Microsoft получила много хороших отзывов от сотен людей, которые используют наш BASIC, но очень удивляют две вещи. Большинство этих пользователей BASIC у нас не покупало, а если посчитать деньги, что мы получили от рынка энтузиастов, и время, которое мы потратили на создание, получается, что разработка приносила нам меньше, чем два доллара в час. Оно нам надо?…
Большинство из вас воры, вы платите за железо без вопросов, но почему-то думаете, что софт можно копировать друг у друга бесконечно! Вам плевать, платят ли за его разработку программистам. Своим воровством вы препятствуете появлению хорошего софта, потому что никто не хочет заниматься профессиональным программированием бесплатно…Кто из вас согласен потратить три года на то, чтобы написать программу, отловить все баги, задокументировать проект и раздать всё бесплатно?…При этом среди вас есть те, кто перепродает наш BASIC…Они поганят имя компьютерщиков-энтузиастов и должны быть изгнаны из клуба на первом же собрании, где они появятся!…»
Всё закончилось в 1983. Apple Computer Inc. подала иск к компании Franklin Computer Corp. Вторая просто скопировала Apple II вместе с ОС и продавала. Суд первой инстанции не удовлетворил иск, зато апелляционный подтвердил, что на всё ПО распространяется авторское право. С того момента проприетарный мир победил. Но он же и породил мир Open Source.
Движение свободного ПО, Ричард Столлман и GNU
В 1971 году Ричард Столлман учился в Гарварде и присоединился к лаборатории искусственного интеллекта (AI Lab) при MIT. В процессе разработки ПО всё ещё чувствовался дух товарищества, а до письма Гейтса было целых 5 лет. Столлман отлично вписался и поучаствовал в работе над свободным ПО, например, над EMACS — текстовым редактором для мини-компьютеров семейства PDP.
«Я присоединился к растущему обществу так называемых хакеров: не взломщиков, а людей, которые любят программировать, и изучать, что ещё можно сделать с компьютером. Они разработали полноценную ОС, написанную полностью в стенах лаборатории. И я стал одним из тех, кто работал над этой системой: улучшал, добавлял новые возможности. Это была моя работа и я её любил. Да мы все её любили, поэтому и занимались ей»
Ричард Столлман, основатель проекта GNU.
Когда «машина проприетарного ПО» начала заводиться (начало 80-х) лаборатория закрылась: появилось NDA, сотрудничества всё меньше, разработчики уходят в частные компании и даже создатель версии EMACS для UNIX в 1983 году продал её коммерческому дистрибьютору. Но Столлман считал, что людям необходима свобода решений и информации, свобода менять и улучшать ПО, возможность делиться.
«Чтобы купить работающий компьютер в ранние 80-е, нужно было купить ОС UNIX. Но разработчики этой системы старались контролировать пользователей и всё им запрещать. Они говорят, что для получения системы, вы должны дать обещание, что ни с кем не поделитесь. Для меня это фактически означает стать плохим человеком — я должен предать и отрезать себя от общества, не взаимодействовать с ним.
Однажды я видел, как в лаборатории уже приняли условие такой лицензии. Это повредило всей лаборатории и мы не смогли сделать множество полезных вещей. Так что я раз и навсегда принял решение, что не буду жить по таким правилам»
Ричард Столлман, основатель проекта GNU.
Примечание. Скорее всего, Ричард имеет ввиду случай, когда Xerox подарила лаборатории лазерный принтер с дефектом. Проблему можно было бы решить, если бы исходники драйвера были открыты. Когда Столлман обратился к коллегам из другого университета, где были исходники, ему отказали, сославшись на соглашение о нераспространении информации.
Получается, что покупая программу, владелец не вправе что-то в ней менять. Например, владелец книги может убрать «лишние» страницы, добавить свои, писать на полях, перепродать или дать почитать другу. С программами так не получится — владелец не вправе что-то менять и дать «попользоваться» программой кому-то другому. Именно это и не нравилось Столлману.
«Давление» проприетарного ПО, убеждения и размышления привели Ричарда к осознанию того, что он мог бы сам создавать открытое ПО и, как автор, разрешить его распространение. Тогда он мог бы пользоваться программами не предавая свои убеждения. Начать решил с ОС, которая станет основой, на которой другие энтузиасты смогут создавать свободное ПО (уже тогда UNIX стала закрытой).
Так, в декабре 1984, появился проект GNU. В январе 1984 Столлман увольняется из MIT и погружается в работу. Увольнение было необходимо, чтобы институт позднее не смог предъявить права на разработки. Столлман решил использовать UNIX в качестве основы, чтобы она была переносима и чтобы пользователи ОС могли легко перейти на новую.
«Само название GNU — это уже хак. Это рекурсивная аббревиатура — «GNU’s Not UNIX»…Это имя означает, что я фактически сделал копию коммерческой системы, но это не была она сама. Свою систему я писал, конечно, с нуля, потому что кодом UNIX нельзя было делиться и он был совершенно бесполезен»
Ричард Столлман, основатель проекта GNU.
Юридические нюансы и лицензии
Кроме системы GNU Ричард и энтузиасты работали над философской и юридической стороной свободного ПО:
Придумали термин «свободное ПО».
Сформулировали четыре критерия свободного ПО: его можно использовать, изучать, делиться и улучшать.
Для финансирования работы, Столлман в 1985 году основал Free Software Foundation (FSF). Это благотворительная организация, которая занимается развитием свободного ПО, за счёт пожертвований. Например, сотрудники FSF написали библиотеку GSL и командный интерпретатора BASH.
Чтобы ПО оставалось свободным, нужна была юридическая защита. Поэтому к 1989 году создали первую версию лицензии GPL — General Public License. Переводится как «Универсальная общественная лицензия GNU». По замыслу, она должна защитить свободу всех пользователей программ, дать права на копирование, модификацию и распространение программ (в том числе коммерческое). Кроме того, Ричард добавил в лицензию «авторское лево», по которому пользователи всех производных программ также получат все оригинальные права, в противовес «авторскому праву».
«GPL – это одна из немногих лицензий, написанных с позиции сообщества, не ставящая во главу угла защиту интересов компаний или правительственных грантов, как в MIT, например. Но это не просто лицензия, а целая философия, которая повлияла на определение Open Source»
Брюс Перенс, автор набора правил соответствия Open Source, руководитель проекта Debian 1996-1997.
Эта первая «каноничная» лицензия на свободное ПО. Но принцип «авторского лева» приняли не все и впоследствии появились другие лицензии, которые позволяют использовать свободное ПО в проприетарном, например, лицензия MIT от Массачусетского технологического института или лицензия BSD от Калифорнийского университета в Беркли (с несколькими вариациями).
В 1991 году появился новый вариант GPL – LGPL (GNU Lesser General Public License). ПО с этой лицензией можно добавлять в проприетарный софт — если это независимый продукт и он отличается от оригинала.
Linux и GNU
Обычно про Ричарда Столлмана принято говорить, что он прежде всего великий философ, а меня воспринимают как инженера, который воплощает его идею»
Линус Торвальдс, создатель ядра Linux
UNIX состоял из разных модулей — подпрограмм. Чтобы создать полный аналог ОС нужно было заменять каждый модуль один за другим: командные оболочки, ассемблеры, компиляторы, интерпретаторы, отладчики, текстовые редакторы, почтовые программы. Это большая работа и Ричард написал анонс с просьбой о помощи.
Часть оригинала сообщения
К 1991 году благодаря совместной работе сообщества энтузиастов были заменены практически все модули, некоторые из которых стали использоваться вне ОС, например, GCC, GNU Debugger или Emacs. Но в системе не хватало ядра ОС, а проект GNU Hurd по его разработке не развивался.
В 1991 Линус Торвальдс выпустил ядро Linux с открытым кодом, а в 1992 — лицензировал ядро по GPL. Linux, также как и GNU, использовал для основы UNIX. Это и привлекло к проекту сначала внимание любителей, а потом и Ричарда.
«Народ в интернете скачивал компоненты GNU и запускал их на ядре Linux. В конце концов у них получалась ОС, которую они называли Linux»
Ричард Столлман, основатель проекта GNU.
Ядра Linux как раз не хватало, чтобы завершить работу над свободной ОС, которую назвали GNU/Linux. В 1992 году появились первые работоспособные версии и это всё изменило — теперь у сообщества появилась полноценная ОС и множество свободных программ.
«Собор и Базар» и Mozilla
В 1997 году уже была готова версия 2.1 ядра Linux на 800 тыс строк кода. Системой пользовалось уже 3,5 млн человек. В это время Эрик Реймонд (программист и хакер) написал эссе «Собор и Базар», которое повлияло на историю. В эссе Эрик демонстрирует два противоположных подхода к разработке.
Собор. Это классический закрытый стиль, где есть точные спецификации и цели, которые поставлены небольшим проектным группам. Группами управляют менеджеры по иерархической модели с длинными циклам релизов.
Базар. Децентрализованная разработка, где каждый участник сообщества может общаться со всеми остальными, а цикл релизов короткий. Здесь есть постоянная и независимая обратная связь от пользователей со всего мира.
«Конгресс Linux в 1997 году был первым местом, где я представил своё эссе публично. Одним из тех, кто его тогда услышал, был Тим О’Райли. Он решил, что мой текст был довольно интригующим и предложил выступить на конференции Perl. А уже на той конференции кто-то из Netscape послушал моё эссе и рассказал о нём в компании. И вот тогда там загорелся огонёк»
Эрик Реймонд, автор «Собор и Базар», сооснователь Open Source Initiative.
Примечание. Тим О’Райли — один из идеологов движения Open Source, основатель издательства O’Reilly и популяризатор термина Open Source Software.
Netscape — первая крупная компания, которая пришла в Open Source. В середине 90-х браузер компании Netscape Navigator был одним из самых популярных в мире. Но когда появился Internet Explorer, он стал вытеснять с рынка Netscape, потому что распространялся бесплатно вместе с ОС Windows. Netscape теряла рынок, приходилось снижать цены, что негативно влияло на компанию.
Своей политикой с браузером компания Microsoft могла получить монополию на стандарты HTTP и HTML, от которых полностью зависит веб. К тому же, в это время Билл Гейтс финансировал разработчиков HTML и все новшества согласовывались с Microsoft. Если бы Microsoft выдавил бы компанию с рынка, это ударило бы и по другому бизнесу компании — разработке серверного ПО.
Примечательно, что Netscape начиналась с того, что основатель компании Джеймс Кларк разослал письма перспективным инженерам из научного мира. Его предложение состояло в том, чтобы совместить научную работу и зарабатывание денег. Первый сотрудник компании — аспирант-программист из университета штата Иллинойс Марк Андрессен, автор первого в мире веб-браузера Mosaic. Это, а также агрессия со стороны Microsoft, возможно, и стали причинами заинтересованности основателя компании произведением «Собор и Базар». В итоге в Netscape приняли решение в 1998 открыть исходный код своего браузера.
«Я написал документ, в котором пытался объяснить, чем компании выгодно открытие исходного кода…Наш исходный код не просто нечто, из чего мы делаем наш продукт, который потом продаём. Это уже наш продукт, в котором заинтересованы наши клиенты. Я пытался объяснить, какая там возможна бизнес-модель, как будем лицензировать, как будем продавать другие продукты…
Я использовал эссе Эрика, чтобы наглядно показать как работает распределённое программирование: как мы сможем использовать рабочие руки сообщества, чтобы разрабатывать нашу программу дальше, их силами. Люди в интернете могли бы помочь нам писать код, поэтому я и сделал отсылку на эссе. Когда моя бумага разошлась, люди, конечно тут же брали и читали работу Эрика»
Фрэнк Хеккер, в то время инженер компании Netscape.
В 1999 компании не стало, а бесплатный Explorer забрал 90% рынка. Но исходный код браузера стал основой для одного из самых популярных браузеров в мире — Mozilla Firefox. Забавно, что браузер Netscape вытеснил с рынка Internet Explorer, а уже его обогнал Mozilla Firefox — потомок Netscape.
Рождение термина «Open Source»
После события с Netscape стало понятно, что коммерческие компании могут и желают участвовать в развитии свободного ПО. Но для этого необходимо придумать замену термину «свободное ПО», чтобы убрать ассоциации с чем-то дешевым, непонятным, бесплатным и никому не нужным. Чтобы поменять эту парадигму в 1998 в офисе компании VA Linux Systems встретились несколько человек:
Эрик Реймонд, автор «Собор и Базар»;
Ларри Августин, доктор наук, со-основатель и генеральный директор VA Linux Systems;
Кристин Питерсон (присутствовала по телефону);
Сэм Окланд (тогда сотрудник VA).
Они и придумали замену термину «свободное ПО» — Open Source, чтобы сменить парадигму бесплатности на доступность.
Чтобы закрепить новую парадигму Эрик Реймонд и Брюс Перенс написали «Определение Open Source», основываясь на политике Debian. В него входят 10 правил, которые и определяют текущее развитие движения.
«Мы приняли решение, что нам нужен некий экзаменационный лист, который бы чётко определял, что такое Open Source. В результате мы пришли к документу, который называется «Определение Open Source». Он вырос из путеводителя по Debian, который написал Брюс Перенс»
Эрик Реймонд, автор «Собор и Базар», сооснователь Open Source Initiative.
В том же 1998 они основали организацию Open Source Initiative (OSI), которая занимается популяризацией Open Source. Можно сказать, что с этого момента и возник Open Source.
Примечание. OSI и FSF пошли разными путями. Во второй больше внимания на «free» — на свободы. Для OSI основной термин — «Open Source Software».
Настоящее «свободного ПО»
«Мне кажется, что коммерциализация важна. Мы хотим чтобы наш софт был мейнстримом»
Брюс Перенс, автор набора правил соответствия Open Source, руководитель проекта Debian 1996-1997.
Проекты GNU и ядро Linux стали основой на которой выросли многие другие продукты и проекты. А поступок компании Netscape привлёк внимание людей и бизнеса к движению свободного ПО и стал одной из причин того, что сейчас IT-гиганты активно вкладываются в Open Source. Всё это вместе привело к тому, что ничто не мешало (и не мешает) развиваться Open Source в коммерческом направлении.
Debian. Этот проект полностью основан на философии GNU и связан с фондом свободного ПО, от которого также получал финансирование.
Apache. Apache сегодня воспринимают как Apache Software Foundation — большую компанию, которая поддерживает много OSS-проектов. Но компания начинала с веб-сервера Apache, очень популярного в свое время. Программа предрешила популярность Linux для веб-серверов. В 1993 году когда появился Apache, рынок интернет-провайдеров стал расти огромными темпами благодаря тому, что Linux и Apache выгоднее для бизнеса, чем проприетарное ПО.
Gnome. Разработка графической среды Gnome привлекла к GNU/Linux пользователей, которые раньше и не задумывались об Open Source ПО. Теперь ОС можно было пользоваться всем, вне зависимости от уровня технических знаний.
Red Hat. Возникла в 1995 году и выпускала ОС Red Hat Linux, продукты на основе свободного ПО, занималась технической поддержкой и обучением системных администраторов и разработчиков. Red Hat — это пример компании, вся деятельность которой основывалась на открытом ПО. Она была очень успешной: на пике «карьеры» в ней работало 3 500 сотрудников и она была включена в S&P500. В 2018 году компанию купила IBM.
Без Linux и открытого ПО не было бы Google. Сейчас корпорация поддерживает 2000 Open Source проектов, среди которых TensorFlow, Go и Kubernetes.
В 2001 Oracle обратила внимание на Linux, как важную платформу для баз данных, опубликовала под лицензией GPL OOCFS2 для Linux и перевела часть внутренних систем на GNU/Linux. Это помогло закрепить успех Open Source в сфере баз данных. Сейчас Oracle активно участвует в проектах Java, Linux, Kubernetes.
Конечно, так происходит не из желания корпораций заняться благотворительностью.
Участие в Open Source проектах привлекает внимание к другим своим проектам, привлекает энтузиастов, что помогает развивать экосистему вокруг продуктов компании.
Это помогает проще нанимать разработчиков, которые уже знакомы с технологиями и продуктами компании.
Банально, но скупка Open Source компаний позволяет удерживать создателей проектов и обеспечивать поддержку, а значит работоспособность ПО.
Это помогает мотивировать разработчиков открытого ПО: когда его замечают крупные компании, это привлекает внимание, продукт становится востребованнее и появляется больше желания над ним работать.
На этом можно закончить «экскурс» по истории Open Source. Конечно, мы не рассмотрели много других событий, но они глобально не влияют на развитие движения.
Из всей истории наша главная мысль в том, что Open Source — важная часть современного интернета и IT. Без Open Source или свободного ПО, как предшественника, не существовало бы интернета, веба и IT, как он есть.
Если захотите обсудить статью — добро пожаловать в наш Телеграм-чат. Там же можно обсудить и Open Source проекты.