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

Содержание

Узнайте подробнее о мире опенсорса и подготовьте к запуску собственный проект.

Опенсорс — что это и зачем?

Итак, вы думаете о запуске своего опенсорс-проекта? Поздравляем! Мир ценит ваше участие. Давайте поговорим о том, что такое опенсорс и почему люди им занимаются.

Что означает “опенсорс”?

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

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

Свободное ПО относится к тем же проектам, что и опенсорс. Иногда вы можете встретить комбинации этих терминов: “Свободное и открытое ПО” (free and open source software FOSS или free, libre, and open source software FLOSS). Слова free и libre здесь означают “свободное”, а не “бесплатное”.

Почему OPENSOURCE — двигатель ПРОГРЕССА? — Научпок

Почему люди делают свою работу открытой?

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

Есть много причин почему человек или организация открывают исходники своего проекта. Вот некоторые из них:

Сотрудничество: В опенсорс-проект может внести изменения любой человек, где бы он ни находился. Например, платформа для упражнений по программированию Exercism насчитывает 350 контрибьюторов.
Адаптация и доработки: Опенсорс-проекты могут использоваться кем угодно практически для любой цели. Люди могут использовать ваш проект для создания чего-то нового. WordPress, например, стартовал как форк (ответвление) уже существовавшего проекта b2.
Прозрачность: Любой может проверить опенсорс-проект на наличие ошибок и несоответствий. Прозрачность важна даже на государственном уровне. Например, правительство Болгарии и США законодательно предписали прозрачность для таких отраслей как банковское дело, здравоохранение, и программ безопасности, вроде Let’s Encrypt.

Опенсорсом может быть не только ПО, но и многое другое: от наборов данных до книг. В разделе GitHub Explore можно ознакомится с идеями проектов, которые можно заопенсорсить.

Опенсорс — значит бесплатно?

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

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

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

Стоит ли мне запускать свой опенсорс-проект?

Краткий ответ — да, потому что независимо от результата, запуск собстенного проекта — это отличный способ узнать, как работает опенсорс.

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

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

Если вы ещё не решились, найдите время подумать о ваших возможных целях.

Постановка целей

Цели помогут вам определиться, над чем работать, от чего отказаться, и где вам понадобится помощь со стороны. Спросите себя: “зачем мне нужен этот опенсорс-проект?”.

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

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

Однажды я сделал кастомный UIAlertView для своих нужд… и решил выложить его в опенсорс. Я сделал его более динамическим и опубликовал на GitHub. Я также написал свою первую документацию, объясняющую другим разработчикам, как они могут использовать мою работу в своих проектах. Возможно, ей так никто и не воспользовался из-за её простоты. Но зато получил удовольствие от всего этого процесса.

По мере роста проекта ваше сообщество будет нуждаться не только в коде. Ответы в ишью, проверка кода и реклама собственного проекта — всё это важные задачи любого опенсорс-проекта.

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

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

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

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

Участие в чужих проектах

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

Если вы не понимаете, как войти в чужой проект, ознакомьтесь с нашим руководством Как участвовать в опенсорс-проекте.

Запуск собственного опенсорс-проекта

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

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

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

Опенсорс-лицензию
README
Руководство для участников
Нормы поведения

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

Если ваш проект на GitHub и вы разместите эти файлы в корневой категории с рекомендованными названиями, GitHub распознает их и автоматически отобразит посетителям репозитория.

Выбор лицензии

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

Написание README

Файл README (“прочитай меня”) не только рассказывает, как использовать ваш проект, но и объясняет, почему он важен, и что пользователи могут с ним делать.

Постарайтесь ответить в README на следующие вопросы:

Что делает этот проект?
Чем этот проект полезен?
Как начать работать с ним?
Где получить помощь, если понадобится?

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

Хорошая документация — это больше пользователей, меньше просьб о помощи, и больше контрибьюторов. (…) Помните, что ваши пользователи — это не вы. Это могут быть люди с опытом, совершенно отличающийся от вашего.

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

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

Написание руководства для участников

Файл CONTRIBUTING говорит вашей аудитории, как стать участником вашего проекта. Например:

Как сообщить об ошибке (попробуйте использовать шаблоны для ишью и пул-реквестов)
Как предложить реализацию новой функциональности
Как настроить среду выполнения и запустить тесты

Помимо технических деталей, в файле CONTRIBUTING только приветствуется изложить свои ожидания относительно участия других людей. Например:

Какого рода участие вы ждёте?
Ваши планы и видение развития проекта
Как участники могут (и не могут) связываться с вами

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

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

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

Со временем вы можете дополнить его ответами на часто задаваемые вопросы. Благодаря этому меньше людей будут спрашивать вас об одном и том же снова и снова.

Поставьте ссылку на файл CONTRIBUTING внутри README, так больше людей увидят его. Если вы разместите файл CONTRIBUTING.md в корне вашего проекта, то GitHub автоматически предложит ознакомиться с ним когда кто-то открывает ишью или отправляет пул-реквест.

Руководство по сотрудничеству

Разработка норм поведения

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

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

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

По аналогии с лицензией, вам не обязательно писать нормы самим, а можно скопировать один из существующих вариантов. Contributor Covenant используется в более 40.000 опенсорс-проектах, включая Kubernetes, Rails, и Swift. Какие бы нормы вы не выбрали, будьте готовы применить их при необходимости.

Вставьте текст в файл CODE_OF_CONDUCT.md в корне проекта, так его будет проще находить и ссылаться на него, например, из README.

Название и брендирование вашего проекта

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

Выбор правильного названия

Придумайте название, которое легко запоминается и, в идеале, даёт представление о сути проекта. Например:

Sentry (с англ. — караул) — сервис для мониторинга приложения
Thin (с англ. — худой) — быстрый и простой веб-сервер на Ruby

Если вы создаете что-то, опираясь на уже существующий проект, то добавьте его название в виде префикса к своему проекту, — это даст больше деталей о нём. Например node-fetch реализует window.fetch в Node.js.

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

Конфликт имён

Проверьте наличие опенсорс-проектов с таким же названием, особенно если вы используете один и тот же язык или экосистему. Если ваше название совпадёт с популярным существующим проектом, вы можете запутать свою аудиторию.

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

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

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

Напоследок, выполнит быстрый поиск в Google по названию вашего проекта. Смогут ли люди по нему легко найти ваш проект? А может быть, по этому запросу появляется что-то нежелательное?

То, как вы пишите (и кодите) тоже влияет на ваш бренд!

За всю жизнь проекта вы будете много писать: README, руководства, документы сообщества, ответы на вопросы, возможно даже информационные бюллетени и списки рассылки.

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

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

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

Не только слова, что вы пишете, но и стиль кода может стать частью бренда вашего проекта. Angular и jQuery — только два примера проектов со строгими стилями написания кода и рекомендациями.

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

Чеклист перед запуском

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

Вы сделали это!

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

Связанные темы

Поиск пользователей для вашего проекта

Помогите своему опенсорс-проекту расти, передав его в руки счастливых пользователей.

Создание дружного сообщества

Создание сообщества, которое побуждает людей использовать, вносить свой вклад и распространять ваш проект.

Содействие

Есть что предложить? Эти материалы открыты для редактирования. Помогите улучшить их.

Источник: opensource.guide

Open source

в опенсорс всегда найдется решение, вот например, если тебя нету в /dev звуковой карты, тогда сам пой песни!

Open source (рус. программное обеспечение с открытым исходным кодом ) — особо драматичная разновидность софта. В зависимости от степени красноглазия и осведомленности автора, а также темы разговора, может означать несколько разные вещи:

Собственно, софт с открытыми исходниками (открытое ПО). В особо специфичных случаях к свободе их использования может не иметь вообще никакого отношения — см. например мелкомягкую лицензию Ms-RSL (можно смотреть на код, но упаси вас Столлман изменять, где-то использовать или даже просто распространять его). Хотя даже сама МС её именно опенсорцом не называет, но упоротые и немного заблуждающиеся встречаются.
Софт, распространяющийся под свободными лицензиями. Он же FOSS — free and open source software, где free «as in free speech, not as in free beer» (свободное, а не бесплатное, другими словами). Свободность или несвободность в данном случае четко определяется требованиями Free Software Foundation, объявляющих четыре свободы бородатого (запускать, изучать, изменять, распространять).
Открытую модель разработки (обычно софта, но не обязательно). Кодинг «всем миром», где коммьюнити принимает непосредственное участие.

История вопроса

Начало

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

Копирастические нравы были свободные, поделия программистов за редкими исключениями ходили из рук в руки и из НИИ в НИИ, все были довольны, никто не жаловался. Ещё Дональд Кнут задолго до всяких Столлманов раздавал свой винрарный TeX направо и налево. Особенно это было распространено в так называемой хакерской культуре, из которой и вышло большинство американских лидеров FOSS и просто великих людей в истории IT. Хакер тогда и там — это не то, что здесь или сейчас, а что-то вроде дотошного изобретательного ботана (в хорошем смысле, а не заучки).

Но в 1976-м появился Билл Гейтс со своим гневным письмом. Суть: БГ, будучи задротом, свято верил, что его увлечение обязательно сделает его великим (да, так и вышло, но сейчас не об этом). Будучи к тому же американцем он считал, что чтобы стать великим, нужно заработать много бабла, поэтому стремился сделать своё увлечение бизнесом (нет, тогда ещё не очень серьёзным).

Как раз тогда зарождался рынок персоналок, поначалу унаследовавший культуру и нравы хакерской среды. Билли, почуяв гешефт, организовал с приятелем мааленькую фирмочку для разработки мелкого софта для микрокомпьютера (персоналками их стали называть только в 80-е с подачи IBM) Altair. Фирмочку так и назвали — Micro-soft.

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

Испытав баттхёрт, Билли написал то самое письмо, а купленные IBM судьи объявили софт объектом авторского права. Хакерам это не понравилось, и группа программистов с хипповским уклоном решила запиливать программки и раздавать их на халяву друг другу для дальнейшего допиливания, посрав на копирайты. Главным идеологом этого безобразия стал Столлман (aka RMS). Собственно он и выделил это сообщество, превратил его в Free Software Movement (Движение Свободного ПО) и создал его идеологию со знаменитыми 4-мя свободами.

GNU

В 83-м был запущен проект GNU, целью которого было создать Свободную Операционную Систему, и в рамках которого до появления Линукса успели написать практически все компоненты рабочей UNIX-подобной системы, кроме собственно ядра. В 85-м был создан Free Sofware Foundation, который фактически является юридическим лицом Free Software Movement и Столлмана лично, поэтому слова FSF и RMS иногда используются как взаимозаменяемые.

В 89-м, была создана первая версия GPL — юридического документа, воплотившего идею copyleft, суть которой в том, что авторские права используются чтобы исключить возможность реализации прав собственности на ПО. GPL — это лицензия, договор между пользователем и распространителем софта. Их бывает много. Microsoft, например, использует всякие EULA (да-да, это тот самый документ, который тебя зачем-то просят прочитать при установке пиратской венды). Но для СПО наиболее распространена GPL.

Эмоционально-драматический аспект абзаца.

Проект GNU двигался хоть и весело, однако решительного влияния на мир, какого бы хотел RMS, не оказывал, да и не особо кому-либо был нужен. А всё потому, что не было у них внучки ядра.

HURD, разрабатываемое в рамках GNU ядро Свободной Операционной Системы и заодно проект по его написанию, весьма скоро превратился в классический долгострой a-la коммунизм, в котором ни финала, ни даже существенного прогресса не видно. Внезапно, в 91-м некий финский швед (или шведский финн. ) по имени Линус Торвальдс (или просто Linus) решил написать свою собственную UNIX-подобную операционную систему (мотивы луркайте сами), причём начал именно с ядра, ибо так интересней, будучи на тот момент нищебродом писал для 80386.

Делать это тихо и в одиночку он не стал, а, пользуясь другой интересной новинкой того времени — интернетом, поделился идеей с другими такими же, как он, энтузиастами. Проект быстро собрал вокруг себя достаточно мозговитого народа для его успешного развития, а Линус оказался удачным лидером нового движения и феномена. Не сразу, но довольно рано в проекте были задействованы наработки GNU и FSF: возможность допиливания ядра кем угодно была узаконена с помощью лицензии GPL, а слияние ядра с уже написанными приложениями и компонентами GNU дало миру первую полноценную свободную операционную систему — GNU/Linux. кхмхмBSDкхм Ну то есть свободную в столлмановском понимании.

Некоторым программистам, среди которых были Линус Торвальдс и Эрик Реймонд, в целом нравился способ разработки свободного софта, но не нравился некий душок коммунизма с хиппи, и они решили назваться по-другому. Алсо, с таким ребрендингом стало легче заинтересовать представителей бизнеса, поскольку free в английском языке, имеет второе значение «бесплатное». Предложение зарабатывать на бесплатном ПО часто вызывало недоумение у тех, кто был не в теме, да и эта ваша юзерская свобода бизнес обычно немного настораживает. Желающие могут посмотреть фильм Revolution OS, там этот момент раскрывается. В результате и появился термин open source — в принципе та же фигня, что не мешает Столлману и Торвальдсу яростно боксировать по переписке.

Драма

Все что касается СПО, обладает повышенной драматичностью и непременно приводит к обилию еды. Опенсорсники клеймят жадных капиталистов за то что их крутое (по сравнению с опенсорным) ПО не раздается на халяву не поддерживает старые железки и шпионит за юзером. Неопенсорсники называют опенсорсников нищебродами и считают, что последним уготована печальная роль Админов — администрировать серверный линукс и жрать межпальцевых насекомых, по канонам папаши Столлмана. Сами опенсорцники срутся между собой, выясняя, какая лицензия истинно свободна — BSD/MIT/Apache, в отличие от GPL, не являются копилефтными (являются менее «принуждающими к свободе»).

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

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

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

Холиворы

Опенсорс vs. Несвободное ПО. Самый канонiчный.
Опенсорс vs. Бесплатное ПО (freeware). Всякие бесплатные программы (Опера например) с закрытыми исходниками настоящими адептами СПО признаются некошерными и негодными к употреблению.
Опенсорс vs. Свободное ПО. По мнению луноликого Ричарда Столлмана, разрекламированность «open source» несколько вредит свободному ПО, так как некоторые разработчики и пользователи открытого ПО совсем не против собственнического ПО, и люди останавливаются на open source, не доходя до понятий о свободе.
Опенсорс vs. Опенсорс. Казалось бы, ан нет.

Война лицензий. Наиболее частый случай — GPL vs BSD. Код под второй можно невозбранно закрыть, под первой нет — в результате имеем споры, какая же лицензия истинно свободна.
Война дистрибутивов.Slackware vs. Ubuntu а-ля Тру vs. Ньюфаг.
Война гуёв.Гномосеки vs. Кедерасты.
Война программ. Тысячи их.
Консоль vs. GUI а-ля Олдфаг vs. Ньюфаг. Большинство пользуется и тем и другим и не понимает в чём суть проблемы.

См. также

Это не баг, а фича

Мета	DRM (SecuROM • StarForce • Аналоговая дыра) • Баг • Бот (Автоответчик) • Варез (Repack) • Глюк • Гуй • Донат • Копирайт (By design) • Лог • Нюк • Рут (Не работай под рутом) • Спортивное программирование • Мегапиксель • Компьютер • Версия 2.0 • Код • Обфускация • Скриншот • Датамайн • Плагин • Текстовый файл • Большие данные • Альфа и бета-тесты • Таймстамп • Кэш • Шаблоны • Hello World
Фичи	12309 • BSOD • Cookies • Embrace, extend and extinguish • FL Studio • Sheep.exe • Winlogon.exe • Бубен • Защита от дурака • Костыль • Машинный перевод • Пасхальные яйца • Свистелки и перделки • См. рис. 1 • Съешь ещё этих мягких французских булок • Termux • GNU Metro • Индусский код • Нескучные обои • Сжатие (За сжатие Джипега • Шакал • Шкала) • Работает — не трогай
Вредоносное	Ботнет • Брутфорс • Винлок • Звонилка • Китайские пингвины • Пиксель смерти • Троян • Червь Морриса • BonziBuddy • MediaGet • Browser hijacking • Tinder
Компании	1С • Apple / Apple (AppleScript) • Google • Microsoft • SAP • Яндекс
Движения	8-bit • Open source (Красноглазики • Линуксоиды) • Вирусная сцена • Даунгрейд • Демосцена • Моддинг
Офис	3DS MAX • GIMP • GNU Emacs • Movie Maker • MS Paint / Paint • OpenOffice • PowerPoint • vi • Word • Блокнот • Фотошоп • Антивирус Касперского • Avast! • TikZ • ShareX • AlternativeTo • Скрепыш
ОС	Android • BSD • DOS • MenuetOS • ReactOS • Windows (Phone 7 • Phone 8 • 7 • 8 • Vista) / Маздай • Линукс • Русская ОС • Фантом ОС
Браузеры	Internet Explorer • Опера / Opera • Тормозилла (Огнелис • Lolifox) • Хром (шпионаж) • Яндекс.Браузер • Уведомления в браузере
Интернет	Adobe Systems (Flash) • I2P • Low Orbit Ion Cannon • Tor • Tunatic • Чат−клиенты (Miranda • QIP • Skype • Аська • Жаббер • Discord • VIPole) • HTTPS • Прокси-сервер (Proxifier) • Торрент (Magnet-ссылка • ΜTorrent) • JavaScript • CSS • HTML • Баннермейкер • Изменение TTL сетевых пакетов • Капча
Разработка	BrainFuck • C • C++ • C# • Java • Haskell • Ассемблер • Chaos Constructions • BAT • MySQL • GitHub • AutoHotKey (AutoHotInterception) • Sublime Text • APK (APKPure • запрет) • BASIC • Perl • Python • PHP
Люди	LovinGOD • Балмер • Гейтс • Генерал Фейлор • Джобс • Митник • Поттеринг • де Раадт • Спольски • Столлман • Торвальдс • Шахиджанян • Ache666
Костыли	Cygwin • PunkBuster • T9 • Wine • Wishmaster • Антивирусы • Хакинтош • Сборки Windows • Denuvo • Чистая установка • Калькулятор Consul War
Команды	^H • ^W • Alt+F4 • Ctrl+Alt+Del • man • /me • /quit • rm -rf

Источник: neolurk.org