В рубрике полезного чтения про данные, технологии и не только:
- Saloni's guide to data visualization гайд по визуализации данных с акцентом на наглядность научных данных, хорошие примеры, понятные советы
- Useful patterns for building HTML tools обзор HTML инструментов, в том числе созданных с помощью LLM.Немного за пределами моих интересов, но взгляд на эти инструменты который я лично упускал.
- Economics of Orbital vs Terrestrial Data Centers про обоснованность и возможность создания дата центров на орбите Земли. Любопытно, хотя и не кажется практичным в ближайшие годы
- Cloudflare Radar 2025 Year обзор трендов 2025 года от Cloudflare, обзор большой, в том числе страновой и есть что посмотреть по разным странам. Тянет на отдельную заметку, а пока просто закладка на чтение

#readings #data #dataviz

We’ve launched Dateno API v2 -- a major upgrade to our data search platform

We’re excited to announce the release of Dateno API v2, one of the most important components of our dataset search engine. This new version is a significant step forward for everyone who integrates Dateno into analytics platforms, data pipelines, and AI/LLM workflows.

What's new in API v2?

1. A clear and stable contract model: all responses are strictly typed and consistent across endpoints
2. Predictable pagination and metadata, making it easier to build UIs, exports, and analytics
3. A much more powerful search, built on a unified index with full-text search, facets, sorting, and relevance scoring
4. A richer, normalized data model for catalogs, datasets, and resources — ready for automation and analysis, not just display
5. Consistent error handling, with clearly separated client, infrastructure, and internal errors
6. Improved performance and reliability, with an asynchronous architecture and health-check endpoints
7. Designed for future growth without breaking changes, thanks to built-in versioning and extensibility

Important: The new API v2 is available in test mode until the end of January. During this period, we encourage developers and teams to explore it, integrate it, and share feedback before it becomes the default production version.

API v2 makes Dateno easier to integrate, more predictable to work with, and better suited for professional use cases - from data analytics to machine learning and AI-powered applications.

Learn more and start testing: https://api.dateno.io

#Dateno #API #DataEngineering #OpenData #SearchAPI #Analytics

Множество предсказаний о журналистике в 2026 году https://www.niemanlab.org/collection/predictions-2026/ на сайте Nieman Lab

Многое про технологии и ИИ, есть даже про API для новостей. Для дата журналистов может быть полезным.

#thoughts #readings #journalism

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

Но то что кто-то может назвать когнитивным искажением, можно назвать и способом взгляда на те или иные явления. И вот один из таких способов восприятия реальности - это смотреть на все как на список. Список дел, список строк в файле, список записей в БД и так далее. А если по списку можно проходить и что-то делать с тем что в нем находится то он является перебираемым или на английском языке iterable.

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

Изначально она создавалась для того чтобы реализовать для JSON/JSON lines файлов логику перебора содержимого по принципу csv.DictReader, стандартной библиотеки в Python в которой перебираемые объекты возвращаются как словари. Заодно добавив к этому что чаще всего эти файлы с данными сжаты чем-то Gzip, LZMA, Zstandard и тд.

А в этот раз я обновил эту библиотеку для большей универсальности и поддержки десятков новых форматов данных DBF, JSON-LD, KML, GML, CSVW, Annotated CSV, MessagePack и еще много, полный список.

Включая некоторые экзотические форматы такие как WARC для веб-архивации, которые тоже можно рассматривать как объекты со списками для перебора.

А в качестве наглядного примера, преобразование дампа Википедии из сжатого XML в Parquet.

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

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

#opensource #dateno #datatools #dataengineering

Рассеянные мысли про разное:
1. В продолжение когнитивных искажений или искажений восприятия в наблюдениях последнего времени часто встречаю ещё два случая:
- декларативизация всего что возможно, иногда в форме YAML'ификации, когда декларативное описание (в сформе структурированного описания конфигурации) кажется панацеей для всего. Панацеей оно, конечно, не является и даже вызывает раздражение у многих разработчиков, но становится удобным при использовании ИИ агентов которые как раз такое декларативное описание понимают очень неплохо.
- маркдаунизация всего и вся, ловлю себя на том что стало неудобно писать тексты в Word'е, совсем неудобно, все время хочется использовать синтаксис маркдауна. Кроме того для скармливания объектов ИИ также часто преобразование в Markdown кажется более логичным чем во что-то другое.
2. По прежнему жизненно не хватает продвинутых инструментов управления контактами, такое ощущение что они вымирают и ни один из крупнейших сервисов не дает удобного API для их обогащения. Например, для управления контактами в Google нужно оттанцевать много с бубном чтобы добавить/изменить контакт автоматически. Когда у тебя пара сотен контактов - это не проблема, когда несколько тысяч - уже ощутимо.

#thoughts

Полезное чтение про данные, технологии и не только

AI
- Introduction to AI Agents хорошо написанный четко изложенный документ от Google. Полезно для быстрого погружения в тему
- State of Agent Engineering обзор от LangChain состояния разработки ИИ агентов через опрос 1300 специалистов
- 2025 LLM Year in Review обзор 2025 года с точки зрения LLM, с погружением в технологии, от Андрея Карпатого
- AI Scraping and the Open Web о том что владельцы контента перешли к юридической защите от ИИ скрейперов после того как технические меры перестали работать

Облачная инфраструктура
- Let’s talk about GitHub Actions в блоге Github о том как они переделали Github Actions. Важное для всех что Github Actions использует. Важное тем что для многие GA стали заменой собственных ETL/ELT инструментов и многие конвееры работы с данными и другими действиями живут на Github.

Инструменты
- headson инструмент для выполнения команд типа head/tail для JSON и YAML файлов. Бывает полезно, но как-то узковато, больший универсализм был бы полезнее
- AGENTS.md спецификация для управления кодирующими ИИ агентами через специальный Markdown файл
- chandra модель для OCR с обещанием поддержки сложных структур и таблиц. Надо пробовать, правда ли так работает.
- Mistral OCR 3 свежая ИИ модель от Mistral для OCR, тоже обещают работу со сложными таблицами

Разное
- On the Immortality of Microsoft Word о бессмертии MS Word и почему Markdown не может заменить его, например, в работе юристов с документами

#opensource #ai #readings

В продолжение рефлексии про применение ИИ агентов в разработке. Мои личные ощущения от применения для различных задач.

Документирование. Почти на 100% закрывается с помощью ИИ агентов, при условии что сам код ясно написан и в коде документация присутствует (в Python это обязательные docstrings). Как простая документация так и сложная генерируется без излишних сложностей, но как и код её необходимо тестировать промптами в условном стиле "проверь что все примеры упомянутые в документации являются рабочими" (в реальной работе немного сложнее, но и так можно).

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

Исправление ошибок. По ощущениям эффективности уже в районе 50-80% (до 8 из 10 задач выполняются сразу правильно, без необходимости корректироки). Практически все задачи линтинга кода и большая часть задач исправления ошибок по итогам неудачных тестов. Наиболее часто несрабатывающие исправления касаются взаимодействия с другими сервисами, серверами, параллельно разрабатываемыми продуктами.

Генерация кода. Варьируется от 40% до 70% эффективности, чем более комплексная задача тем хуже результат в виде кода. Простые задачи умеют хорошо делать уже почти все ИИ агенты, сложные часто приводят к переусложненному коду. Например, в качестве теста я делал REST API поверх написанного на Python SDK. Cursor при его реализации начал ваять сложный промежуточный код для обработки данных и преобразования типов хотя все то же самое можно было бы сделать значительно проще простыми исправлениями в оригинальном SDK. Вот эта вот контекстность в решении проблем это особенность ИИ агентов. Они пока не предполагают что решения проблем могут быть за пределами рассматриваемой ими кодовой базы.

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

Разработка дата продуктов (декларативное создание баз данных). Это то что я рассказывал ранее про то что справочные данные можно создавать в виде множества YAML файлов которые расширять и собирать в наборы данных с помощью ИИ агентов. Здесь эффективность весьма вариативна. Чем больше гранулярности в задаче, тем она выше, но исправлять результаты и расширять их нужно практически всего. Однако и это снижает трудоемкость создания датасетов в десяток раз, не меньше.

#thoughts #ai

Суверенное импортозамещение по французски La Suite numerique (Цифровой комплект) в виде набора приложений с открытым кодом включающий:
- Tchap - мессенжер
- France Transfer - сервис передачи больших файлов
- Docs - совместная работа над документами
- Grist - управление проектами
- Visio - видеоконференции
- Messagerie - электронная почта
- Fichiers - управление общими файлами.

Все это в варианте, либо локального развертывания, либо на федеральном портале ProConnect

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

#opensource #france #government

В рубрике как это устроено у них (наверное) портал открытых данных ЕАЭС opendata.eaeunion.org

Содержит реестры и ресурсы ЕАЭС в части разрешительной работы и совместной деятельности.

Предоставляет отраслевые данные через REST API и по стандарту API OData.

Плюсы:
- данные общедоступны декларируемые явным образом как открытые
- хорошо документированное стандартизированное API
- много разных отраслевых данных

Минусы:
- свободные лицензии не указаны явным образом
- нет возможности массовой выгрузки (сразу все), у API ограничение по выгрузке до 5000 записей за раз
- данные рассеяны по множеству отраслевых подсайтов что неудоьно при желании скачать все

#opendata #datacatalogs

В рубрике как это устроено у них открытые данные в Австрии собраны на национальном портале data.gv.at где опубликовано 63 тысячи с небольшим наборов данных по самым разным тематикам. Портал работает на базе ПО CKAN, к нему доступно REST API, а данные экспортируются в форматах связанных данных и почти у всех наборов данных есть привязанная свободная лицензия. В целом портал и все инициативы по открытым данным в Австрии напрямую взаимосвязаны и ссылаются на политики Евросоюза и, в частности, сейчас имеют фокус на публикацию данных особой ценности (HVD) и переход к публикации данных необходимых для обучения ИИ.

Некоторые особенности австрийского портала данных в том что, как и во многих других странах, создатели портала используют искусственное дробление наборов данных для демонстрации их количества. так из 63 тысяч наборов данных 52 тысячи наборов данных - это файлы муниципальных бюджетов страны (1692 муниципалитета) разбитые по годам примерно за 20 лет и по нескольким вида бюджетной отчетности с другого официального портала www.offenerhaushalt.at

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

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

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

#opendata #austria #datacatalogs

У меня есть довольно давняя отложенная нерабочая задача - это извлечь с каталога музейного фонда РФ (goskatalog.ru) материалы по армянскому культурному наследию для чего я когда-то выгружал с портала данных Минкультуры РФ битый датасет этого реестра и преобразовывал 88ГБ текстовый файл в 2.7ГБ файл Parquet с 31.7 записями о культурных объектах. А также есть примерно 100 регулярных выражений позволяющих найти записи в которых есть прямое или косвенное упоминание Армении или армянской культуры.

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

А теперь о подходах как такую задачу можно решить.

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

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

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

Экономное хардкорное программирование. Обращаешь внимание что регулярные выражения - это медленно почти всегда и на то что не все поля в оригинальных данных нужны. Оптимизируешь и пересобираешь оригинальный файл с данными так чтобы он содержал только id записи и поля с нужными текстами, переписываешь регулярные выражения на pyparsing или разворачиваешь их в текст для полного мэтчинга и, конечно, тоже разрезаешь файл с данными на 100 (или сколько нужно) и параллельно запускаешь обработку не обязательно на продвинутом железе. Думаешь о том не переписать ли все это на Rust

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

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

Вайб-кодирование. Описываешь эту задачу ИИ агенту и он за тебя генерирует код (скорее всего не самый высокопроизводительный) и дальше уже по аналогии с ленивым программированием

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

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

#thoughts #programming #dataengineering

В рубрике как это устроено у них Fairstack 1.0 комплект продуктов и сервисов от Китайской академии наук (СAS) по организации инфраструктуры работы с данными для исследователей. Включает множество инструментов с открытым кодом и разработанных в компьютерном центре CAS для организации работы исследователей.

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

#opendata #datacatalogs #china

Ещё в рубрике как это устроено у них FranceArchives официальный архивный портал Франции. Включает более 29 миллионов записей из которых более 5 миллионов - это оцифрованные документы, фотографии, карты и иные цифровые артефакты агрегированные из сотен музеев и архивов страны.

Предоставляют открытое API в виде интерфейса SPARQL, у каждой записи есть RDF, JSON-LD и N3 карточки с описанием со всеми метаданными в структурированой форме и есть возможность получить карточку записи в виде CSV файла.

#opendata #data #digitalpreservation

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

Думаю что в ближайшее время Минюст США эти документы начнет снимать и заменять на реально вымаранные, но как же они умудряются в одну и ту же лужу вступать неоднократно. Я помню как много лет назад в США сотрудники Пентагона выкладывали вымаранные документы, тоже через PDF слой, а считывали его через комбинацию: Ctrl+A, Ctrl+C, Ctrl+V.

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

#privacy #usa #documents

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

1. Скрытые, но доступные данные в недокументированном API
Госорган создает общедоступный портал с некоторой информацией и портал построен по уже классической трехзвенной структуре: База данных -> Слой API -> Веб интерфейс. При этом все ограничения в доступе к данным делаются только на уровне веб интерфейса, а через API вполне можно собирать записи имеющие статус "удаленные" или "черновики". Ситуация вообще не редкая и возникает от недостатка квалификации постановщика задачи, разработчиков и недостаточного тестирования

2. Скрытые данные в общедоступных материалах
Многие форматы публикации текстов, таблиц и изображений имеют свои особенности позволяющие как скрывать часть содержания так и "раскрывать" его. Пример с закрашиванием PDF файлов всем хорошо известен, а есть, к примеру, случаи когда публикуются Excel файлы со скрытыми вкладками, частенько когда публикуют статистику ее рассчитывают на более детальных первичных данных в другой вкладке, а потом эту вкладку скрывают, а не удаляют. Так чувствительные данные внутри Excel файлов становятся общедоступными. Есть и другие случаи когда одни файлы MS Office погружают в другие, а когда запускают процесс удаления метаданных он вырезает метаданные из основного контейнера, но не удаляет их из внедренных файлов. И так далее, это только то что совсем на поверхности

3. Доступное API стандартизированного ПО
Организация выбирает стандартизированное ПО для сайта, а у этого стандартизированного ПО (CMS) есть какое-то количество опять же стандартно общедоступных API о которых они могут и не подозревать. Я привожу часто в пример WordPress у которого есть открытые эндпоинты дающие возможность находить документы ссылок на которые может не быть на сайте, но сами файлы остаются. Например, если кто-то загружает документ в WordPress и потом делиться на него с кем-то по прямой ссылке, то даже если на страницах сайта этого документа нет, то в API он доступен. WordPress - это пример, кроме него есть немало других CMS и веб фреймворков имеющих такую особенность
—
Насмотревшись всего этого в больших количествах я совершенно не удивляюсь когда вижу как в очередной раз кто-то попадается на такой лаже как "затереть текст в PDF файле", думаю что еще не раз такое будет.

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

#thoughts #osint #data #privacy

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

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

1. Автоматизация контроля по "красным флажкам"
Это самое очевидное и активно внедряется во многих странах, за последний месяц я читал о внедрениях такой практики в Чили и в Албании, но уверен что делают такое многие и много где. Можно провести быстрое исследование и систематизировать эту практику, однако в её основе вполне понятная система флажков по которым закупки/контракты определяются по степеням риска. ИИ тут малополезен в части классификации закупки потому что ничего сложного в "складывании флажков" и определении баллов риска нет. Но ИИ может помочь в автоматизации идентификации флагов когда признаки риска заложены внутри текстов документов. Собственно этот анализ текстов и есть главная возможность применения резко снижающая стоимость автоматизации контроля. Все органы внутреннего и внешнего аудита уже не могут говорить "мы же не можем проконтролировать всё". Теперь можете, этот аргумент более не релевантен. Едем дальше

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

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

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

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

#thoughts #ai #procurement

В рубрике интересных продуктов с открытым кодом MapLibre набор библиотек и спецификаций для создания настраиваемых онлайн карт с активным использованием GPU для оптимизации обработки и отображения изображений.

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

В частности в ноябре они выпустили первую версию сервера Martin для создания векторных плиток на лету из баз PostGIS и многое другое. Жаль они у них в планах нет выпуска каталога геоданных потому что Geonetwork и Geonode развиваются медленно.

#opensource #geodata #geospatial

Я недавно писал про Fairstack китайский комплект ПО для открытой науки и про их ПО для институциональных репозитриев данных InstDB. Важная характеристика китайской науки - это систематизация и доступность данных, в том числе по разным дисциплинам. Но есть немаловажный нюанс - существенная изолированность от мира.

У меня есть реестр из 72 инсталляций InstDB из которых удалось открыть лишь 12 при попытках открыть их с IP адресов в Армении, России, США и Германии. Причем 12 открылись только с IP адреса в России, а с других открывались только 6. При том что я точно знаю что большая часть этих сайтов работают, но пока не обзавелся сервером/IP адресом в Китае. Но данные из этих порталов эффективно индексируются внутри Китая в базу SciDB и в поисковик findata.cn.

#opendata #openaccess

Mattermost изначально продукт с открытым кодом активно использовавшийся по всему миру как альтернатива Slack которую можно было бы установить локально для своей команды перешли в режим open core и начиная с 11 версии ввели ограничение в максимум 10 000 сообщений, а все что до определенной даты уходят в архив без воможности просмотра. Пользователи у которых это произошло после обновления справедливо негодуют.

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

Как и всегда проблема в дефиците качественных альтернатив.

#opensource #opencore