Введение

В далёком 1951 году был опубликован роман Айзека Азимова «Основание». Он рассказывает о событиях ещё более далёкого 19 997 года: человечество освоило межзвёздные перелёты, превратилось в Галактическую Цивилизацию, изобрело научные методы психоистории для точного предсказания будущего и в итоге пришло к осознанию необходимости создания Галактической Энциклопедии — базы знаний, накопленных человечеством за многие тысячи лет своего существования. Цель энциклопедии — быть не просто справочником по типу Википедии, а практическим руководством, которое позволяет даже изолированной человеческой популяции пройти путь развития от каменного века до межзвёздных перелётов всего за несколько столетий.
По мнению Айзека Азимова, подобная глобальная база знаний является необходимым условием для фактического бессмертия человеческой цивилизации. В этом я с ним полностью согласен. Но я так и не дочитал книгу до конца, потому что довольно быстро основное внимание автора перешло от интересной научно-фантастической идеи к довольно банальным политическим интригам. Меня в первую очередь интересует техническая сторона «Основания» — как может быть устроена информационная система Галактической Энциклопедии сегодня? Исходя из возможностей современных технологий, за 17 972 года до суда над Гэри Селдоном, изгнания Энциклопедистов с Трантора на Терминус и старта полномасштабной работы над глобальной базой знаний человечества во вселенной Айзека Азимова.
Мотивация
Для героев романа «Основание» мотивация создания Энциклопедии была в том, чтобы преодолеть последствия неминуемого распада Галактической Империи — как можно быстрее выйти из хаоса и возродить цивилизацию. Живя в эпоху индустриального общества, Айзек Азимов описал расцвет и упадок информационного общества, в котором мы живём сейчас. Он высказал сомнения в устойчивости информационного общества и предложил переход к обществу знаний как дальнейший путь развития человечества. Также он указал на то, что такой переход не будет простым эволюционным процессом, а наоборот — потребует революций, усилий и жертв.

Как это согласуется с современным пониманием информации и знаний? Я изучил Википедию на эту тему, там сказано, что знание — это высшая форма информации, и оно может быть записано с помощью естественного языка или специализированной знаковой системы. Что касается информационного общества, то сейчас принято считать, что оно включает в себя общество знаний. То есть, если исходить из современных представлений, то за несколько сотен лет развития человечество должно эволюционно перейти от информационного общества к обществу знаний.
По мнению Айзека Азимова, такой переход невозможен даже за 17 000 лет. Фактически в романе «Основание» подвергается сомнению наше фундаментальное понимание природы знания. Автор утверждает, что даже создание разумных роботов, таких как Демерзель, межзвёздные перелёты на сверхсветовых скоростях, холодный термоядерный синтез, колонизация тысяч звёздных систем не приведут человечество к обществу знаний. Азимов предрекает информационному обществу 30 000 лет упадка и хаоса, которые обязательно наступят после 20 000 лет устойчивого развития.
Лично мне сложно судить, какое будущее ждёт человечество. Но я полностью согласен с идеей Азимова, что знание не является разновидностью информации. На мой взгляд, в цифровых системах данные, информация и знания — это три разных квантовых состояния, которые мы до сих пор чётко не определили. Поэтому вместо того чтобы переходить от информационных технологий к технологиям знаний, мы застряли на устаревших методах и концепциях из 1970-х годов. Лично моя мотивация — выйти из застоя и совершить изменения в обществе, сравнимые с бумом персональных компьютеров в 1980-х или распространением Интернета в 2000-х. При этом я не считаю революционным прорывом технологии блокчейна или нейросетей, потому что по сути своей они не выходят за рамки интерпретации информации.

Следуя логике «Основания», можно сказать, что если мы успеем прийти к точному пониманию того, что такое знание, и отделим его от уже привычных нам данных и информации, мы сможем осуществить переход к обществу знаний и тем самым создать фундамент для устойчивого развития цивилизации. Если же мы упустим время, и Галактическая Империя возникнет и утвердится раньше, чем Галактическая Энциклопедия, то получившееся гипертрофированное информационное общество неминуемо придёт в упадок. И ему не помогут ни искусственный интеллект, ни колонизация Марса, ни дешёвая энергия холодного термоядерного синтеза.
Базовые определения
Я думаю, что путь перехода от информационных технологий к технологиям знаний начинается с чётких определений для четырёх базовых понятий: коммуникация, данные, информация, знания.
Коммуникация — это процесс общения людей и цифровых систем, который идёт на трёх основных уровнях: данные, информация и знания.
Данные — это массивы битов, логических нулей и единиц, на которые не наложено никаких дополнительных интерпретаций. Физически цифровых данных как таковых не существует. Реально существуют электромагнитные импульсы, которые далее интерпретируются как логические нули и единицы. Так формируется основа для работы цифровых устройств.
Информация — это результат интерпретации исходных цифровых данных по определённому алгоритму. Соответственно, бывают более и менее сложные интерпретации, которые дают более или менее сложно структурированную информацию. Одной из самых простых интерпретаций является система ASCII-кодов, которая каждый байт (группу из 8 битов) интерпретирует как букву алфавита, цифру или другой стандартный символ. Таким образом, если бит — это единица измерения данных, то байт — это одна из возможных единиц измерения информации.
Знание — это вся полнота информации, необходимая для принятия однозначного и корректного решения по заданному вопросу. При этом знание не должно содержать информацию, не относящуюся к решению вопроса. Таким образом, знание — это необходимая и достаточная информация для принятия решения.
Здесь стоит уточнить, что принятие решения предполагает ответственность за его результат, поэтому перекладывание важных решений с людей на некий ИИ невозможно — он банально не может должным образом отвечать за последствия.

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

На мой взгляд, на данный момент Open Source Software и Open Source Hardware являются яркими примерами воплощения в жизнь идей и духа «Основания» Айзека Азимова. В рамках Open Source инициатив создают полные и чёткие наборы инструкций для создания программно-аппаратных комплексов, решающих актуальные проблемы. Это сохраняет пользователям годы и даже десятилетия жизни, убирая необходимость создавать все необходимые системы с нуля или покупать проприетарные решения с закрытым исходным кодом, гибкость которых существенно ограничена.
Если воспринимать проприетарное решение как чёрный ящик, в который помещают входную информацию, и из которого затем получают выходную информацию, то это классический элемент информационного общества. Пользователи не могут во всей полноте отслеживать и изменять процесс обработки своей информации, то есть не владеют знанием о работе системы, и значит, могут решать с помощью неё лишь ограниченный круг задач.
С другой стороны, если рассмотреть Self-Hosting для Open Source Software на Open Source Hardware, то мы видим, что пользователь имеет полноту информации, необходимую для контроля и модификации любого элемента своей системы. То есть эта система работает на принципах знания. Разработчики Open Source компонентов предоставляют своим пользователям полные инструкции по созданию оборудования, раскрывают в деталях принципы работы алгоритмов, позволяют запускать и отлаживать системы в реальном времени на оборудовании пользователя.
Другими словами, если свериться с определениями информации и знания, то Open Source — это движение от обрывочной информации к полноценному знанию о системе и, как следствие, к эффективному владению, управлению и развитию системы. Технически для реализации соответствия принципам знания нужна не просто какая-то текстовая инструкция, а весь комплекс в сборе — оборудование и запущенное на нём программное обеспечение, открытое для модификации и отладки прямо в процессе работы.
То есть в современном понимании знание — это всё чаще не статическая информация, зафиксированная в текстовом или даже графическом виде, а работающий программно-аппаратный комплекс, отвечающий высоким стандартам прозрачности и открытости для модификации. Если раньше источником знания считались книги, то теперь эта роль переходит к веб-сервисам и облакам, построенным на принципах Open Source.
Итак, нулевое приближение к обществу знаний заключается в том, чтобы ввести точное определение знания и переосмыслить с этой точки зрения уже накопленный человечеством информационный багаж.
Первое приближение
Далее в этой статье я буду рассматривать развитие Open Source Software, потому что именно эта сфера соответствует моим основным компетенциям и интересам. Но подходы и принципы, к которым мы придём на этом примере, можно будет обобщить и использовать во многих других сферах: Hardware, наука, образование, музыка, кино, литература, торговля, производство, решение изобретательских задач и так далее. Очевидно, текущая концепция Open Source Software не является полноценной реализацией «Основания». На данный момент я вижу пять основных направлений, развитие которых приблизит Open Source к универсальной общечеловеческой базе знаний:
Низкий порог входа
Управление силами одного человека
Быстрый поиск знаний
Простая интеграция компонентов
Эффективная экономическая модель
По сути, продвижение по этим направлениям является первым приближением к технологиям знаний. Я считаю, что ни одно из перечисленных направлений нельзя исключить из первого приближения, потому что они сильно взаимосвязаны, поддерживают друг друга и только вместе смогут вывести индустрию на принципиально новый уровень развития, с которого можно будет увидеть перспективы второго приближения. Давайте подробно рассмотрим каждое из направлений развития Open Source.
Порог входа
На данный момент информационные технологии характеризуются высоким порогом входа. Например, для того чтобы овладеть языком программирования средней сложности на уровне решения простых прикладных задач, может потребоваться 1-2 года. Как мне кажется, основная причина этого в том, что современные системы разработки не уделяют достаточно внимания визуализации структур и процессов, поэтому каждому разработчику приходится учиться строить схемы сложных программных комплексов у себя в голове. Подобная схема должна отражать не только исходный код программы, но и структуру базы данных, связи с внешними сервисами, распределение программных модулей по устройствам, динамику работы программы в рантайме и много чего ещё. Если такая схема будет строиться непосредственно в IDE и заменять собой исходный код, схему базы данных, отладчик и логи, то порог входа для новых разработчиков может сократиться до 2-3 месяцев без потери качества.
Управление
Как известно, основные потери времени внутри организаций происходят на коммуникациях между сотрудниками. Соответственно наиболее эффективной является организация, состоящая из одного человека, потому что в ней нет необходимости во внутренних коммуникациях. Редкие примеры инди-хакеров, зарабатывающих на технически несложных проектах от $10 000 до $500 000 в месяц, тому подтверждение.
Хочется спросить — почему таких компаний сейчас очень мало? Потому что объём информации, который необходимо загрузить в голову для ведения всех аспектов даже очень простого бизнеса в сфере ИТ, настолько большой, что среднестатистический человек с этим просто не справляется. В итоге люди идут по пути разделения ответственности, специализации, введения дополнительных должностей для организации деятельности групп специалистов. Но если ваш бизнес или некоммерческий проект представлен в виде связной эффективной базы знаний и позволяет быстро получать ответы на любые вопросы и принимать любые решения, то вам не нужно держать огромный объём информации у себя в голове. Вся информация хранится в базе знаний, а для решения конкретных вопросов собственник компании получает из неё только необходимый компактный контекст, который не превышает его когнитивные возможности.
Идея компании, состоящей из одного человека, не нова, и последнее время энтузиасты развития искусственного интеллекта утверждают, что именно он является ключом к массовому возникновению миллиардных компаний, состоящих из одного человека. Но я думаю, что нет реальных оснований возлагать такие надежды на ИИ.
Во-первых, ИИ работает в сфере повышения эффективности интерпретации информации. Он не выходит на уровень знаний. А для сведения количества сотрудников в компании к одному нужно именно эффективно управлять знаниями, а не быстрее интерпретировать массивы информации. Потому что если раньше человек перегружал своё сознание объёмом информации, то теперь с ИИ он будет перегружать сознание объёмом интерпретаций, и качественно для него ничего не изменится.
Во-вторых, нет никакой реальной необходимости для разработчиков создавать миллиардные компании. Весь этот тренд на непомерное раздувание капитализации и оборотов скорее всего задаётся инвесторами, которые стремятся повысить эффективность своих вложений в стартапы. Среднестатистическому разработчику будет вполне достаточно создать компанию с оборотом в $100 000 - $1 000 000 в год и тем самым оставить место ещё для 1000 разработчиков в этой же сфере. Потому что потребности рынка не безграничны, и нет смысла брать из него больше ресурсов, чем необходимо для жизни.
Поиск

На данный момент самым популярным методом поиска информации является интерпретация обычной текстовой строки, введённой пользователем. Минусов у этого подхода очень много:
Пользователь не управляет процессом интерпретации своего запроса, поэтому машина может неправильно его понять и соответственно выдать некорректный результат именно из-за неточности интерпретации.
Пользователь не управляет процессом подбора и ранжирования результатов поиска. По решению разработчика туда могут быть внедрены нежелательные для пользователя фильтры, нерелевантные результаты, высокие позиции в рейтинге могут занимать рекламные объявления или удачно оптимизированные под поисковый движок сайты, а не реально полезные материалы.
Не все поисковые запросы можно эффективно выразить через текст. Для работы с многообразием информации, которое нам доступно в Интернете, нужен гораздо более выразительный описательный механизм, чем простой набор букв.
Новый способ организации поиска — когда пользователь формулирует задачу на поиск в виде чёткой программы, состоящей из семантических связей и блоков со строго определённым смыслом. Далее эта поисковая программа выполняется поисковым движком с открытым исходным кодом. Пользователь может отладить и даже изменить алгоритм работы этого движка прямо в процессе поиска. Результатом поиска должен быть полный набор сущностей, отвечающих поисковому критерию. Лишние сущности, не подходящие по критерию, в результат попадать не должны. Рекламные объявления и прочие отвлекающие элементы в результат попадать не должны. Также во всей публичной части сети не должно остаться сущностей, которые подходят по критерию поиска, но по какой-то причине не попали в результат. Поиск, устроенный подобным образом, называется органическим семантическим поиском. Он призван предоставлять абсолютно точные и полные результаты на любой поисковый запрос. Запросы для него формируются не на натуральном языке, а на специальном семантическом языке, который придётся освоить пользователю.
Тенденция, когда для каждого инструмента приходится изучать какой-то особый микроязык, очевидно, не является продуктивной. Поэтому для написания поисковых запросов должен использоваться универсальный семантический метаязык. Он же будет использоваться для описания всех компонентов семантической сети, реализующей глобальную базу знаний человечества. Этот язык придётся спроектировать, реализовать, и затем всем пользователям придётся его изучить, как до этого изучали другие языки: XML, JSON, YAML и так далее. Преимущество метаязыка в том, что он более универсален и выразителен, поэтому один раз выучив его, остальные языки учить не потребуется. Уже сейчас можно утверждать, что метаязык не будет просто ещё одним текстовым языком, он будет интерактивным визуальным языком на основе семантического графа, что выведет его на принципиально новый уровень выразительности и эффективности.
Следующей важной особенностью нового поиска является возможность каждого пользователя дополнять специальными поисковыми метками любые семантические сущности, доступные для поиска. Если поисковая метка оценивается остальными пользователями как полезная, её влияние на поисковую выдачу закрепляется в системе. Если же наоборот, поисковая метка оценивается как нерелевантная, вводящая в заблуждение, она деактивируется, и система больше не позволяет прикреплять подобные метки к сущности.
По всем поисковым запросам должна вестись общедоступная статистика, чтобы пользователи могли видеть, какие поисковые запросы запускаются, насколько часто, и какой результат они дают — приводят они своих авторов к искомому результату или нет. Подобную статистику можно использовать следующим образом:
Искать идеи для собственных поисковых запросов.
Определять популярные запросы для поиска и наиболее популярные ответы по ним.
Определять, на какие запросы существенное количество пользователей не может найти удовлетворительных ответов.
Данная аналитика поможет разработчикам создавать решения, в которых есть реальная потребность, или добавлять новые поисковые метки к уже существующим решениям, повышая тем самым их заметность в поисковой системе.
Интеграция
В современной парадигме разработки интеграция отдельных библиотек, приложений и сервисов между собой — весьма сложная задача, которая по мере развития системы может превысить по сложности разработки даже основной функционал продукта. Первая причина этого в том, что каждая информационная система имеет свою собственную модель данных, которая в общем случае не совместима с моделями данных других систем. Наглядный пример этой проблемы — сложности конвертации файлов из одного формата в другой. Перенести более-менее сложную таблицу из Excel в Google Sheets без частичной потери функциональности — практически невыполнимая задача. Это является следствием использования несовместимых моделей данных в разных системах. На уровне информационных технологий их совместить не получится. Вторая причина — наша привычка интегрировать между собой довольно крупные и разнородные сущности. Интерфейс библиотеки, SDK приложения, API сервиса — как правило, это массивные конструкции со сложной внутренней структурой, которые очень сложно стыковать друг с другом.
В рамках нового подхода я предлагаю развивать методику интеграции программных комплексов на более низком уровне семантических единиц. Если каждый программный модуль описан в виде семантического графа, то он состоит из набора однородных семантических единиц. Тогда интеграция семантических модулей происходит путём простого связывания определённых семантических единиц между собой. Это устраняет необходимость в массивных и сложных прослойках между программами. Проблема несовместимости моделей данных решается за счёт того, что в разных программах используются одни и те же стандартизированные на уровне сети семантические блоки, из которых собираются совместимые между собой семантические модели данных.
Экономическая модель
На мой взгляд, на данный момент самым большим препятствием для развития Open Source является отсутствие достаточно эффективной экономической модели для финансирования высокотехнологичных независимых разработок. В теории можно написать очень полезную библиотеку, собрать миллион звёзд на GitHub, сотни тысяч долларов донатов от преданных фанатов и жить счастливо. На практике для продвижения своего проекта нужно становиться маркетологом, для организации сообщества вокруг проекта — коммьюнити-менеджером, для приёма и обработки платежей — бухгалтером. В итоге непосредственно на разработку останется хорошо, если 20% времени и ресурсов мозга. А ведь ещё при всём этом надо оставаться первоклассным разработчиком в своей области, что практически невозможно, если тратить 80% времени на посторонние вещи, не имеющие отношения к разработке. Поэтому зачастую авторы самых полезных Open Source проектов работают в убыток, на чистом энтузиазме или урывками, в перерывах между основной работой, и в итоге не раскрывают полностью свой потенциал. Чтобы решить эту проблему и позволить разработчикам тратить 80% времени и внимания на разработку своего флагманского проекта, я предлагаю спроектировать эффективную экономическую модель для нового Open Source.
Постулат #1 — Всё должно быть платным
Сейчас мы можем бесплатно зайти на сайт, найти там продукт многолетнего труда группы талантливых людей, бесплатно скачать его, внедрить в своё коммерческое приложение и затем бесплатно раздавать его своим пользователям. Это подрывает экономику Open Source. По моему убеждению бесплатность — это враг свободы и открытости. Новое поколение Open Source лицензий должно декларировать необходимость оплаты за каждое скачивание проекта. А инфраструктура нового Open Source должна исключать возможность нарушения лицензии автоматически — на техническом уровне, а не вручную на юридическом уровне, как это практикуется сейчас. Деньги, которые пользователи платят за скачивание Open Source продукта, должны распределяться между хостинг-провайдером, который обеспечивает хранение, поиск и передачу копии проекта пользователю, и всеми контрибьютерами проекта в соответствии с их вкладом.
Если на заре Open Source бытовало мнение, что свободное ПО не обязательно должно быть бесплатным, то сейчас есть все основания полагать, что оно всегда должно быть платным.
Постулат #2 — Все платежи должны быть автоматическими и дешёвыми
Любой, кто имел дело с интеграцией платёжных систем, знает, что проведение платежа — это дорогое удовольствие. Не важно, принимается платёж в фиате или в одной из популярных криптовалют, его проведение не может стоить дешевле, чем $0.5. Как следствие, нет смысла выпускать на рынок товары со стоимостью ниже $1. Чтобы сделать продукт, за который пользователь готов платить $1, на самом деле нужно очень сильно постараться. Особенно учитывая тот факт, что покупатель проводит платёж вручную, и это требует от него дополнительных затрат времени, усилий и концентрации внимания, которые он в итоге может оценить гораздо дороже $1. Сложно перечислить, сколько цифровых товаров я не приобрёл лишь по причине того, что не хотелось отвлекаться и тратить время на прохождение всех формальностей, связанных с платежом.
Теперь давайте рассмотрим модель пика-экономики, в которой типичный платёж составляет 0.1¢, взимается автоматически, а комиссия составляет 0.1% от суммы платежа. С точки зрения пользователя процесс выглядит так:
Захожу в каталог Open Source Software
У меня с баланса автоматически списывается 0.001¢ за отображение поисковой страницы
Инициирую поиск нужного мне модуля, задав его семантическое описание на метаязыке
У меня списывается 0.005¢ за обработку поискового запроса
Выбираю из результатов поисковой выдачи подходящий модуль
Скачиваю модуль
У меня списывается 0.1¢ за получение копии модуля на мой сервер
Встраиваю модуль в свой сервис
Публикую обновление своего сервиса
У меня списывается 0.01¢ за публикацию обновления в глобальной сети
Клиент открывает мой сервис
-
У клиента с баланса автоматически списывается 0.21¢ за использование моего сервиса, сумма распределяется следующим образом:
0.1¢ перечисляется мне как автору основного сервиса
0.1¢ перечисляется автору использованного мной модуля
-
0.01¢ перечисляется хостинг-провайдеру, который разместил мой сервис на своих мощностях и обеспечил выполнение всех транзакций
в некоторых случаях я сам могу быть хостинг-провайдером, если позаботился о запуске и настройке собственных серверов
Можем ли мы себе позволить платежи на уровне 0.01¢ - 0.1¢ за использование сервисов по мере необходимости вместо десятков ежемесячных подписок на необходимые нам сервисы, которые сейчас стоят $10 - $100 каждый? Я думаю, вполне можем. И тогда за условные $20 в месяц можно будет выполнить десятки тысяч запросов к совершенно разнообразным сервисам. Для сравнения: сейчас в Cursor за те же $20 я имею 500 запросов в месяц, из которых реально использую 200 - 300 штук.
С точки зрения разработчика пика-экономика выглядит так:
Имею популярный проект с 10 000 000 скачиваний в неделю
Над проектом работает 2 контрибьютера с примерно равным вкладом в проект
Когда пользователь платит 0.11¢ за скачивание копии продукта, мы получаем 0.1¢ на баланс проекта
В месяц проект генерирует $40 000, то есть по $20 000 на каждого участника команды
Разработчики не тратят время и силы на интеграцию десятков разных платёжных систем, не разрабатывают интерфейсы для ручного проведения платежа, не интегрируются с платформами для продажи рекламы или привлечения платного трафика. Вся экономика работает автоматически на уровне протокола сети.
Может ли разработчик прожить на $20 000 в месяц? В большинстве городов мира — может. И ещё деньги на авиаперелёты останутся.
Если посмотреть с точки зрения предпринимателя и оценить инвестиции в проверку новых продуктовых гипотез, то получаются следующие расклады. В рамках нано-экономики, к которой мы привыкли, на разработку и запуск продаж для продукта с ценой реализации $1 силами одного человека уходит порядка 1 месяца. В рамках новой пика-экономики создать и запустить продажи продукта с ценой реализации $0.001 можно всего за несколько часов. При этом нет необходимости обязательно создавать полнофункциональный сервис. Достаточно сделать просто полезный и качественный модуль, который затем будет интегрирован в чужие сервисы. Это даёт следующие полезные экономические эффекты:
Низкий порог входа для новых участников рынка.
Быстрая проверка гипотез для предпринимателей.
Быстрое получение доступных по цене решений для пользователей, конечно, при условии качественного оформления задач на разработку.
Сложности в понимании семантических абстракций разработчиками программного обеспечения
Подобно науке психоистории в романе «Основание», современная инженерия знаний малопонятна для большинства специалистов по информационным технологиям. Несмотря на это, она весьма эффективна для решения сложных задач, таких как обучение, управление, поиск, интеграция и оптимизация экономики. Поэтому ситуация, в которой вам не до конца понятны абстрактные рассуждения о проектировании решений на базе семантики, — это нормально. Мне понадобилось более 10 лет изучать семантические подходы на практике, в реальных проектах, чтобы начать более-менее свободно ориентироваться в этой теме. Для изучения теории по инженерии знаний я могу порекомендовать учебник Инженерия знаний. Модели и методы.
Более прикладную информацию по применению инженерии знаний в разработке ПО я планирую выкладывать в виде статей и видео здесь, на Хабре, и на канале Knyte Foundation в Telegram.
Практические навыки работы в семантическом окружении можно будет получить, разрабатывая собственные проекты с помощью расширения для IDE VS Code knyte-space-svg. На данный момент оно работает в режиме preview и не имеет всего необходимого функционала для ведения проектов. Полноценный релиз будет доступен начиная с версии 1.0.0.
Архитектура нового Open Source

Технически инфраструктура нового Open Source может представлять себой глобальную семантическую сеть. Это логически следует из выявленной ранее необходимости применять методы инженерии знаний и работать с семантическими сущностями. Функционирование семантической сети должно быть обеспечено следующими типами компонентов:
Нода — это компьютер, на котором работает серверное ПО семантической сети и обеспечиваются хранение, обработка и передача данных, необходимых для функционирования всех остальных компонентов системы.
Агент — это программная сущность, которая действует внутри семантической сети в интересах своего владельца: выполняет команды, производит финансовые расчёты, хранит принадлежащие пользователю ассеты. Данные, принадлежащие агенту, многократно продублированы и распределены для хранения на достаточно большом количестве распределённых нод, что работает как бэкап и CDN для данных аккаунта. По умолчанию данные агента зашифрованы, и доступ к ним можно получить только при наличии мастер-ключа. При желании агент может опубликовать часть своих данных; тогда они станут доступны для чтения всем остальным агентам в глобальной сети.
Пользователь — это человек, взаимодействующий с семантической сетью через набор своих агентов. Одним агентом могут управлять сразу несколько пользователей, если у них есть его мастер-ключ. Агентами могут управлять не только люди, но и другие агенты — как с помощью классических алгоритмов, так и с использованием нейросетей.
Агенты в семантической сети могут выполнять следующие роли:
Потребитель — это агент, действующий в интересах пользователя, который не публикует в сети ничего нового, а использует уже готовые материалы.
-
Создатель — это агент, который создаёт и публикует новые материалы в сети. Он может действовать в соответствии со следующими стратегиями:
Заказчик — когда агент не находит в сети необходимой ему информации, и публикует запрос на создание новых материалов, соответствующих его критерию поиска.
Исполнитель — когда агент ищет запросы от заказчиков, создаёт по ним новые материалы и публикует их.
Инноватор — когда агент создаёт и публикует новые материалы по собственной инициативе, без привязки к существующим запросам от заказчиков. Эта стратегия подходит для некоммерческих инициатив, для творческих пользователей, ориентированных на самовыражение, и для визионеров, которые работают на удовлетворение запросов рынка, которых пока ещё нет, но которые появятся в будущем.
-
Собственник — это агент, который владеет материалами, опубликованными в сети и приносящими доход. Такие материалы называются ассетами, и они приносят доход за счёт того, что скачивание данных в сети для всех потребителей платное. Технически, если агент создаёт и публикует в сети новый материал, он становится собственником соответствующего ассета. Далее ему доступны следующие стратегии поведения:
Продавец — это агент, продающий права собственности на некоторые из своих ассетов другим агентам. Цель продажи ассета — сразу получить крупную сумму денег и избавиться от необходимости управлять непрофильными активами.
Покупатель — это агент, покупающий права собственности на ассеты у других агентов. Цель покупки ассета — начать получать доход от его скачиваний потребителями, при необходимости изменять его и выпускать новые версии, а также добавить ассет в инвестиционный портфель с другими схожими ассетами и получать дополнительную выгоду за счёт синергетического эффекта. Например, я опубликовал сервис, в состав которого входит 5 модулей: 4 модуля принадлежат мне, а 1 модуль — другому пользователю. Я могу выкупить этот модуль у другого пользователя, снизить его цену и в итоге получить более дешёвый сервис для своих клиентов, что в результате повысит продажи, позволит обойти конкурентов и увеличит чистую прибыль сервиса в целом.
Провайдер — это агент, управляющий нодой, предоставляющей вычислительные ресурсы и хранилище данных в пользование другим агентам. Так как любой запрос в сети платный, провайдер получает платежи от агентов за все операции, выполняемые его нодой по запросам внешних агентов.
Для лучшего понимания назначения компонентов семантической сети, можно провести аналогии с классическим GitHub:
Агент — это аналог аккаунта на GitHub.
Нода — это аналог сервера в дата-центре Microsoft, на котором работает ПО GitHub.
Ассет (опубликованные агентом материалы) — это аналог публичного репозитория на GitHub.
Приватные данные (неопубликованные агентом материалы) — это аналог секретов разработчика, содержимого файлов .env, которые не заливаются в общедоступные репозитории.
Потребитель — это аналог пользователя на GitHub, который ищет и скачивает репозитории без регистрации и без какого-либо участия в развитии проектов.
Заказчик — это аналог пользователя на GitHub, который ставит звёздочки, делает форки, пишет issues.
Исполнитель — это аналог мейнтейнера проекта на GitHub, который работает по issues и официальному роадмэпу проекта.
Инноватор — это аналог независимого инициатора проекта на GitHub, который разрабатывает его в соответствии со своим видением.
Провайдер — это аналог компании Microsoft, предоставляющей доступ к ресурсам GitHub.
User stories нового Open Source

В этом разделе я постараюсь рассказать о том, как могла бы функционировать описанная выше архитектура на примере типичных сценариев поведения пользователей системы.
Общее для всех пользователей
У меня в помещении размещён мой собственный сервер.
На сервере установлено серверное ПО с интерфейсом командной строки; он работает для меня как локальная нода семантической сети.
Сервер имеет двустороннюю связь через интернет со всеми остальными нодами сети.
Потребитель
Я являюсь потребителем контента в семантической сети.
Моя нода хранит все необходимые мне данные и управляет их репликацией на другие ноды сети.
Каждые несколько секунд моя нода получает обновлённые данные о содержимом сети от других нод.
Для чтения данных, хранящихся на моей ноде, я подключаюсь к ней как к серверу по стандартному сетевому протоколу со своего клиентского устройства (ноутбук, планшет, телефон), на котором установлено клиентское ПО с графическим интерфейсом.
Если моя нода вышла из строя, я ставлю вместо неё новое устройство, и за несколько минут оно полностью восстанавливает состояние старой ноды путём подкачивания из сети реплицированных данных.
На клиентском устройстве я могу инициировать поиск нужной мне информации в глобальной семантической сети. Для этого я использую детализированный запрос, сформулированный на семантическом метаязыке и выполняющий роль критерия поиска. По этому критерию сеть выдаёт мне полный и точный результат.
Алгоритм, осуществляющий поиск по моему критерию, открытый и контролируемый, не показывает мне рекламу, не скрывает от меня подходящие под критерий результаты и не добавляет к результатам лишние, неподходящие по критерию записи. Сортировка результатов по релевантности также происходит по подконтрольному мне алгоритму.
При необходимости я могу сделать форк алгоритмов поиска и сортировки результатов, внести в них нужные мне изменения и использовать их вместо стандартных.
Когда я получаю результат поиска, я оплачиваю его внутренней валютой сети. Ничего бесплатного в сети нет. При этом все финансовые транзакции проводятся автоматически, и их размер в среднем исчисляется тысячными долями доллара.
Платёж за каждую операцию в сети делится на комиссию провайдера, который выполняет мои запросы на своих нодах, и комиссию собственника контента, который я нашёл и скачал для дальнейшего использования.
Таким образом, мне как потребителю доступны обширные вычислительные ресурсы, хранилища данных и исходники всех программ, опубликованных в сети. Но всё это доступно не бесплатно, а за небольшие платежи напрямую собственникам этих ресурсов и ассетов.
Создатель
Я являюсь создателем контента в семантической сети.
Я могу локально создавать разные типы контента: программный код, тексты, графику, музыку, анимацию и так далее.
Весь локально созданный контент в зашифрованном виде автоматически реплицируется на достаточно большое количество нод по всей сети.
Пользоваться этим контентом может только создавший его агент. Другим агентам сети, не имеющим мастер-ключа, этот контент недоступен для использования.
Я могу создавать свой контент на основе чужих наработок, доступных в сети как публичные материалы. Я могу делать форки от них и вносить любые изменения.
При желании я могу попробовать опубликовать созданный мной контент. Для этого нужно отправить его на автоматическую проверку на уникальность. Как и любой другой запрос к внешней сети, эта проверка является платной.
-
Получив мой запрос на публикацию контента, система проверяет, есть ли уже в сети аналог. По результатам проверки возможны три варианта:
В сети найден полный аналог моего ассета. Тогда система отказывает мне в публикации и рекомендует перейти на использование общедоступного ассета; ссылка на него предоставляется.
В сети найден ассет, частично совпадающий с отправленным мной на публикацию материалом. Тогда мой ассет оформляется как форк более ранней версии, и на публикацию уходит только дифф между моим решением и найденным в сети оригиналом.
В сети не найдено никаких аналогов моего материала; тогда ассет публикуется в исходном виде.
Однажды опубликованный контент в дальнейшем невозможно будет снять с публикации.
В случае успешной публикации полного ассета (вариант 3) за мной закрепляются права собственности на его контент целиком. В будущем все, кто будут использовать его, будут платить мне соответствующие отчисления.
В случае успешной публикации ассета в качестве форка от другого ассета (вариант 2) за моим агентом закрепляются права собственности на дифф. В будущем все, кто будут использовать его, будут платить соответствующие отчисления и мне, и автору оригинальной версии, от которой был сделан форк.
Я могу улучшать видимость своих ассетов в поисковой системе, добавляя к ним дополнительные семантические метки. Основанием для них могут быть как неявные свойства ассета, которые не видны напрямую из его содержимого, так и адаптация под типичные поисковые запросы Потребителей.
Пользователи системы также могут дополнять мои ассеты своими поисковыми метками, которые им кажутся уместными и полезными.
Добавление поисковой метки к публикации также является публикацией.
По всей сети должен работать механизм ранжирования поисковых меток, чтобы полезные метки активно влияли на результаты поисковых запросов и приносили деньги своим авторам (то есть также работали как ассеты), а бесполезные или даже вредные метки игнорировались при поиске и, вероятно, приносили штрафы своим авторам.
Собственник
Я являюсь собственником контента в семантической сети.
Я имею доступ к набору агентов, работающих в семантической сети.
Каждый агент владеет определённым набором ассетов.
Каждый агент имеет собственный счёт во внутренней валюте сети.
Когда Потребитель запрашивает из сети принадлежащий мне ассет, агент Потребителя автоматически переводит платёж моему агенту за использование моей интеллектуальной собственности.
Мой доход складывается из переводов в пользу моих агентов, которые совершают Потребители в процессе покупки прав на использование моих ассетов.
Я могу регулировать размер отчислений за право использования для каждого ассета.
Я могу создавать новые публикации, чтобы расширить набор принадлежащих мне ассетов.
Я могу покупать права собственности на публикации у других Собственников.
Я могу продавать права собственности на свои публикации другим Собственникам.
Предметом операции купли/продажи прав собственности могут быть как 100% (полная передача прав), так и 10% (продажа доли в собственности). Купив 10% собственности чужого ассета, я буду автоматически получать 10% со всех его доходов.
Если мне срочно нужны деньги, я могу продавать права собственности на свои ассеты.
Если я хочу инвестировать в будущее, я могу покупать права собственности на чужие ассеты.
Провайдер
Я являюсь провайдером услуг в семантической сети.
Я предоставляю часть дискового пространства на своих нодах для хранения данных других Пользователей. За каждый день хранения каждого бита данных я получаю платежи от Пользователей.
Я предоставляю часть вычислительных мощностей своих нод для выполнения запросов других Пользователей: поиск, верификация материалов для публикации, транзакции купли/продажи прав собственности на ассеты и так далее.
Я могу регулировать цены за свои услуги.
Благодаря мне каждое обращение к сети является платным, что существенно понижает риски злоупотребления ресурсами сети и нарушения прав собственности Пользователей сети со стороны других Пользователей или вредоносных алгоритмов.
Заказчик
Я являюсь создателем заказов в семантической сети.
Я сформировал запрос на поиск информации в сети.
Я не получил подходящего результата в ответе на свой поисковый запрос.
Я оплатил Провайдеру взнос, который позволяет поместить мой неудовлетворённый поисковый запрос в реестр заказов. По сути это мой голос за реализацию ответа на этот запрос силами других Пользователей сети.
Чем больше денег я заплатил для регистрации своего запроса, тем выше его рейтинг в реестре заказов, и тем дольше он там продержится.
Каждый день рейтинг запроса в реестре снижается на фиксированную величину. Когда рейтинг падает до нуля, он удаляется из реестра заказов. Технически деньги, обеспечивающие рейтинг, каждый день по частям переводятся в счёт провайдера, обеспечивающего платный хостинг заказа в реестре. Когда деньги заканчиваются, заказ удаляется с хостинга.
Чтобы запрос находился в реестре заказов продолжительное время, мне нужно или сразу внести крупный взнос, или периодически пополнять баланс взноса на относительно небольшую сумму.
Я как создатель запроса могу в любой момент убрать его из реестра заказов, при этом все непотраченные деньги с его баланса вернутся на мой счёт.
Остальные Пользователи системы могут найти мой заказ интересным для себя, и пополнить его баланс своими деньгами. Тогда и рейтинг, и время присутствия запроса в реестре заказов увеличится.
Стоимость присутствия запросов в реестре заказов регулируется Провайдером.
Исполнитель
Я являюсь создателем ответов на запросы из реестра заказов в семантической сети.
-
Я имею доступ к статистике всех поисковых запросов, выполнявшихся в семантической сети. По каждому запросу я вижу результат:
Сколько пользователей нашли устраивающий их ответ и скачали его.
Сколько пользователей не нашли ответ и отказались от дальнейшего поиска.
Сколько пользователей не нашли ответ и зарегистрировали свой поисковый запрос в реестре заказов.
Я могу отсортировать запросы из реестра заказов по тематике и востребованности так, чтобы получить список наиболее востребованных запросов, подходящих под мои компетенции.
Я могу создать и опубликовать решение на любой выбранный мной запрос. При этом все Пользователи, вложившиеся в рейтинг данного запроса в реестре заказов, получат уведомление о том, что в сети появился мой вариант решения.
-
Решение может быть создано одним из следующих способов:
Я знаю, что ответ на запрос уже есть в сети, но Заказчики не могут его найти из-за нехватки семантических меток. Я добавляю эти метки соответствующей запросу публикации. Пользователи начинают видеть в результатах поиска новое решение. Я получаю отчисления с каждого удачного поиска как автор полезных поисковых меток.
Я знаю, что ответ можно создать в виде форка на базе уже существующей публикации. Я делаю такой форк, дорабатываю его для полного соответствия запросу, и по необходимости добавляю поисковые метки, чтобы он легко находился. В результате пользователи начинают находить это решение в сети, а я начинаю получать отчисления и за созданный мной дифф, и за добавленные к нему метки.
Я знаю, что ничего подходящего под запрос в сети нет, и знаю как создать решение с нуля. Тогда я создаю решение целиком и получаю 100% отчислений от Пользователей, которые находят его и начинают им пользоваться.
Решение может быть оценено Заказчиками как подходящее или как неподходящее. Это повлияет на то, будут его находить в дальнейшем по аналогичным запросам или нет.
Известные вопросы к функционированию системы
Итак, мы описали в общих чертах принципы работы семантической сети в качестве общечеловеческой базы знаний. Конечно, данное описание не включает в себя всех деталей реализации. В частности, остаются открытыми следующие важные вопросы, от которых напрямую зависит успех системы:
Как будет осуществляться передача по наследству мастер-ключей для управления агентами, принадлежавшими Пользователю?
Как будет осуществляться восстановление доступа к агентам Пользователя в случае утери Пользователем мастер-ключей к ним?
Как сообщество будет возвращать под свой контроль брошенные ассеты и валюту, принадлежащие агентам, которым долгое время не уделяют внимания их владельцы, и которые по факту стали неуправляемыми?
Как предотвратить злоупотребление поисковыми метками, когда Пользователи или автономные боты могут назначать через своих агентов нерелевантные поисковые метки публикациям, ухудшая тем самым качество поисковой выдачи для них?
Как разумно регулировать цены на услуги провайдеров и отчисления собственникам ассетов?
Я уверен, что все эти вопросы решаемы, но для начала нужно создать и запустить макет сети для работы в более простых условиях, и для изучения работы более общих архитектурных принципов. Далее внутри этой модели можно будет моделировать ситуации, связанные с перечисленными выше вопросами, и искать наилучшие решения в контексте семантической сети и с применением возможностей инженерии знаний.
Реализация первого приближения к новому Open Source

Несколько месяцев назад я организовал Knyte Foundation, который вдохновлён идеями «Основания», и в рамках него работаю над Open Source проектом knyte.space для реализации принципов инженерии знаний в разработке программного обеспечения. Публичный бесплатный релиз в рамках данного проекта — это knyte-space-svg, расширение для VS Code на базе SVG-рендера низкой производительности. Оно позволяет работать с небольшими кодовыми базами: компактные утилиты, пет-проекты, учебные материалы по full-stack разработке, фундаментальные исследования по прикладной семантике. Перспективный проект для коммерческого применения в больших кодовых базах — это knyte-space-webgl, также расширение для VS Code, но уже на базе WebGL-рендера, который позволит работать с проектами масштаба linux, postgresql, nodejs. Основная идея расширений для IDE — отработать методику плавного перевода проектов из классической файловой структуры в семантическую графовую структуру.
Для разработки проектов в полностью семантическом окружении планируется создать Knyte Space IDE и Knyte Space Browser, в которых не будет файлового легаси, и, следовательно, интеграция между компонентами системы будет реализовываться гораздо проще.
Последним важным этапом является создание семантической сети, работающей по принципам пика-экономики, на базе собственной операционной системы для нод сети. Тогда разработку можно будет вести без отрыва от маркетинга и монетизации, и все описанные выше роли агентов сети заработают в полную силу.
Планы на второе приближение

Пока что, не имея опыта работы в первом приближении глобальной семантической сети, сложно представить, чего ожидать от второго приближения в техническом плане. Но с точки зрения пользователей это может выглядеть так:
После успешного внедрения нового Open Source в работу отдельных компаний он начнёт распространяться на остальные организации, повышая уровень интеграции и эффективности взаимодействия между ними.
После успешной адаптации нового Open Source для Software проектов он начнёт использоваться в других сферах жизни: Hardware, создание контента, книги, кино, телевидение, музыка, научные исследования, медицина, сельское хозяйство, промышленное производство, добывающая отрасль и так далее.
Общество совершит переоценку ценностей и вместо генерации избыточной информации, которая в основном отвлекает и перегружает внимание, перейдёт к созданию и накоплению знаний, которые помогают решать реальные проблемы с максимальной эффективностью. Люди перестанут прятать знания друг от друга с целью получения конкурентных преимуществ и перейдут к модели открытых и общедоступных знаний как основы стабильного развития человечества. Таким образом, генерация и циркуляция знаний в обществе приблизится к высоким стандартам, заданным «Основанием» Айзека Азимова.
Заключение

Несмотря на то, что за последние пару лет сформировалась мода на сверхмощный ИИ, гигантские датацентры, суперкомпьютеры и мегакорпорации, я думаю что будущее зависит от самосознания простых людей. Как в своё время мы массово научились читать и писать, чем вывели культуру обмена информацией на новый уровень, так в ближайшем будущем сможем научиться методам инженерии знаний, начнём запускать свои ноды, программировать своих агентов, писать на метаязыке и ориентироваться в семантической сети. В итоге это определит культуру и экономику знаний на ближайшие столетия. Мы создадим эффективные инструменты, основанные на симбиозе людей и машин, и начнём совершенно по-новому взаимодействовать с интеллектуальной собственностью, которая отныне сможет создаваться, принадлежать и управляться не только людьми, но и машинами.
Если вы хотите заглянуть в пост-информационную эру человечества, узнать о развитии семантического Open Source'а и принять активное участие в этом движении, присоединяйтесь к Knyte Foundation, вносите свой вклад в «Основание»!
Комментарии (4)
DenSigma
30.06.2025 06:34Сколько псевдофилософских разговоров. В конце пришли к пошлому коллекционированию денежных знаков.
Хотите зарабатывать - создавайте компанию, пишите и продавайте. Не портите open source.
SensDj
30.06.2025 06:34В будущем рано или поздно всё будет бесплатным (вкалывать будут роботы, а не человек).
Сейчас мы можем делать одно из трёх - помогать приближать это будущее, мешать приближению этого будущего, не мешать ...
Open Source - по сути работает по принципу "от каждого по способностям, каждому по потребностям" (каждый вкладывает что может и каждый берёт что ему надо).
garwall
Перечитайте условия GNU GPL
ddinochrome Автор
Спасибо за проявленный интерес к тематике. К сожалению, мне сложно понять вашу мысль из 4 слов. Лично я не использую в коммерческой разработке проекты с лицензией GNU GPL, есть другие, более популярные и менее ограничительные лицензии.
Rank | License | Pageviews (2024)
1 | MIT License | 1.7M
2 | Apache 2.0 | 244.6K
3 | BSD 3-Clause | 247.9K
4 | BSD 2-Clause | 115.8K
Вот для сравнения статистика по GPL:
5 | GPL 2.0 | 83.8K
6 | GPL 3.0 | 72.4K
Почему в текущей ситуации я не хочу открывать исходники своих коммерческих проектов? Потому что это ведёт к возникновению клонов моего проекта и резкому снижению прибыли. В статье я предлагаю вариант организации опен сорса, в котором разработчикам выгодно открывать свои исходники, в том числе с финансовой точки зрения. И при этом для защиты своих прав им не нужно будет нанимать адвокатов и втягиваться в судебные тяжбы. А как в этом может помочь перечитывание лицензии GNU GPL?