OCE vs OCCT

«Но предположим, я выбриваю на голове число зверя — 666 — и говорю: "Поклоняйтесь мне, ибо иначе истреблю вас!" Все просто рассмеются мне в лицо и скажут: "Тогда мы займемся этим ядром сами"» (Линус Торвальдс, Just For Fun).

Геометрическое ядро — штука сложная. Поэтому ядер так мало. Из бесплатных же компонент, доступных простому смертному, я знаю всего одну — Open CASCADE Technology (OCCT). Или две? Ведь, оказывается, есть еще Open CASCADE Community Edition (OCE Google group), т.е., если по-русски, «самиздат» библиотеки OCCT, сделанный сообществом ее пользователей. Сообществом? Минуточку...

Известно, что библиотека OCCT — это «честный» open source проект, предлагающий лицензирование на основе LGPL (одна из самых либеральных лицензий). Чтобы не вдаваться в скучные подробности, отметим лишь, что LGPL (GNU Lesser General Public License) — это хорошо, по той простой причине, что она не ограничивает коммерческое использование продукта, зависящего от LGPL-библиотеки. Проще говоря, вы можете писать коммерческое ПО, базируясь на Open CASCADE Technology, не раскрывая своего кода, не уплачивая никаких роялти и лицензируя свой продукт как вам угодно. Помимо «правильной» лицензии официальная библиотека OCCT снабжена и всей необходимой экосистемой, включающей:

• Багтрекер
• Репозиторий (Git)
• Форум службы поддержки
• Онлайн-документацию

Новые версии OCCT публикуются в среднем два раза в год, причем из документации по каждому релизу нетрудно видеть, какие изменения и в каком количестве были сделаны. Баг-фиксы и новая функциональность появляется едва ли не в каждом компоненте библиотеки, начиная с фундаментального пакета math (базовая математика и численные методы), и заканчивая пакетами визуализации. Казалось бы, чего не хватает? Зачем существует еще одна версия библиотеки, называемая OCE (Open CASCADE Community Edition)? Попробуем в этом разобраться.

Замороженный кусок глобуса

Идиллия, описанная выше, была не всегда. Еще несколько лет назад не было ни открытого багтрекера, ни общедоступной системы контроля версий, которыми сегодня может похвастаться официальный OCC (Open CASCADE SAS). Однако «испокон веков» существовал официальный форум библиотеки, который и являлся (как, впрочем, и сегодня) точкой консолидации сообщества (community) Open CASCADE Technology. На этом форуме каждый желающий мог задавать вопросы по использованию библиотеки, рапортовать найденные ошибки (баги), общаться и помогать ближнему. Официальным «визирем Египетским» со стороны компании-разработчика выступал пользователь с ником Forum Supervisor, один за всех разработчиков OCCT. Новые релизы библиотеки публиковались нечасто, жизнь текла размеренно, и ничто не предвещало беды. Пока, однажды, не грянул гром... Т.е. новый релиз OCCT 6.5.0. Спустя несколько дней после выхода этой версии на форуме появилось следующее сообщение от одного из членов сообщества (орфография и пунктуация сохранены):

Dear all,

The latest 6.5.0 version was release a few days ago. This new release was expected for a long time by the community. By 'community', I mean people who are not customers of OCC, who didn't pay any fee to the OCC company but just use the product for free or commercial products/projects.

There have been, and there still is, a kind of misunderstanding between the OCC company and the 'community' as previously defined. The community just expects OCC to deliver a good and reliable library, with updates, bugfixes, issue tracking and so on, that is to say provide a XXIth century open source product/project management. On the other side, the OCC first consider their customers request, because the licensing fees from the customers create income. This business model can easily be understood (it's not that original in FOS world), however the community deserves a better consideration from OCC. In my opinion, the OCC company didn't understand yet that the community can create value to the product/project, and that this added value can be converted back to money. This lack of consideration explicitely appears in the 6.5.0 announcement (read http://www.opencascade.org/org/forum/thread_20025/): not even any thank to the community, it's just incredible!

Anyway, the result of this strategy from the OCC company is that the community only benefits today from this poor forum interface to report issues, ask questions, send patches etc. Project plans, roadmaps, issue tracking, source code repository, unit test suite etc. are not publicly available. We (the community) only see the tip of this huge iceberg. Where does this iceberg sail?

After 30 months of work since the 6.3.0 release, the 6.5.0 is out. Expectations were great. Results are, in my opninion, a bit disappointing. Reading the annoucement, I see that "this release introduces about 230 modifications and bug fixes, over previous public minor release 6.3.". 'Minor' release means minor improvements. Well, this is an average of 7.66 bug fixes/minor improvements per month. For your information, from Firefox 4.0 beta 12 to Firefox RC1, 227 bugs were fixed (http://www.mozilla.com/en-US/firefox/4.0/releasenotes/buglist.html) in about two weeks, that is to say an average of 450 bug fixes/month. My conclusion? Although a version was recently released, OCC is not such an active project anymore: fixing 7.66 bugs/month can be achieved by one employee (playing freecell half of his time). Additionnaly, 6.5.0 release seems to introduce regressions, many obvious issues have not been fixed etc. It looks like OCCT is slowly dying, no?

Regarding the latest release, a few fixes are currently being contributed back by the community through this forum (search for OCC650PATCH in this forum). We cannot wait 3 more years (or more?) for the 6.6.0 to be released, and I'm not even sure that any other version will ever be released. Community fixes should be made available to community as soon as possible. Patches are not an easy way to trace modifications to the source code. Some projects were registered on sf.net (http://sourceforge.net/projects/opencascade/, http://sourceforge.net/projects/qtocc/), mostly to share patches, but we should have the complete code somewhere to be able to easily say up to date.

As a consequence, I registered the oce project on github : https://github.com/tpaviot/oce/. oce stands for *o*pencascade *c*ommunity *e*dition. The complete 6.5.0 source code was uploaded (the /ros folder actually). This repository is intended to gather modifs from the community (I'm bored with searching for OCCPATH or OCC650PATCH on this forum), merge OCC services packs from the Salome project etc. Git is a perfect tool to manage such a huge library as OCC.

This project is not a fork. The goal is rather to make the library living between two official releases, ensure a continuity, and setup a tool the OCC team does not want to provide us. There is a risk that this concurrent version diverge from the original one, or that the code is not enough tested and introduce regressions/bugs? Well, no risk, no fun, right?

I strongly encourage Denis Barbier, Pete Dolbey, Roman Lygin and others, who often report issues/bugfixes, to register a github account; then email me to get a write access to the repository.

All the best,

Thomas

Это письмо — своеобразная «нота недоверия» официальному разработчику — послужило отправной точкой для проекта OCE, который изначально должен был адресовать следующие проблемы, связанные с библиотекой:

1. Полная закрытость официальных средств разработки (репозитория, багтрекера и т.д.) пугает сообщество. Есть ли гарантия, что фирма-производитель все еще жива и новый релиз когда-либо выйдет? Не следует ли взять инициативу в свои руки и снабдить сообщество всем недостающим?
2. Багов исправляют мало, по сравнению, например, с проектом Mozilla. Оставим на совести сообщества жонглирование такими цифрами, как «количество фиксов в месяц», ведь сложность указанных проектов едва ли сравнима. Впрочем, сегодня количество фиксов не в пример больше, нежели раньше, так что критика сообщества в какой-то мере была обоснованной.

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

Tom, I understand your point that you are not suggesting forking it. But I suggest to the contrary - fork it. I was going back and forth on this one. 3 years waiting for these people to come out of the stone age is foolish IMO. I keep on asking why in the world do we get stuck with a sinking ship. They are in some frozen corner of the globe (если кто-то не в курсе, существенная часть Open CASCADE Technology разрабатывается у нас, в России, — прим. Quaoar) and probably have a client that totally depended on them...

Возможно я излишне негативен, но давайте посмотрим на тупые «медицинские факты». Что такое OCCT? Это уникальное явление в мире САПР. Такие сложные технологические компоненты, как геометрические ядра, представляют собой весьма лакомый кусочек для производителей инженерного ПО. Писать библиотеки подобные OCCT и обладающие индустриальным качеством (т.е. без floating-point exceptions и прочих злых духов на каждом темном повороте) было бы слишком дорого для САПР-производителя. Поэтому чаще всего эти ребята лицензируют проверенные ядра у таких компаний как Dassault Systemes, Siemens, АСКОН и проч. Если же финансы компании ограничены, то единственной альтернативой промышленным ядрам будет OCCT. Да, пусть оно менее функционально и где-то работает не совсем как надо. Но его могло и не быть, а значит рынок свободного инженерного ПО лишился бы целого пласта, связанного с геометрическим моделированием. И это было бы так, если бы компания Open CASCADE SAS не исповедовала модель open source. Так же, как не было бы Qt без компании Trolltech.

Среди разработчиков открытого ПО наплевательское отношение к копирайту — часть мировоззрения. Все владеют всем. Поэтому, казалось бы, ну что такого. Мало ли, например, существует версий того же Linux? Но чтобы что-то понять и проанализировать, нам следует расстаться с романтическими иллюзиями. Наукоемкий софт индустриального качества НЕ пишется в «базарном» стиле, не взирая ни на какие копилефты. Почему так — понять несложно. Дело в том, что для создания такого продукта как OpenCascade требуется наличие команды разработчиков, смахивающее на инженерно-прикладное подобие исследовательской школы. Со стратегическим целеполаганием, семинарами, научным поиском, конференциями и публикациями. Неспроста лидеры этого рынка имеют академические корни. Комьюнити open source объективно устроено совершенно иначе. Впрочем, хватит теоретизировать. Ниже мы увидим, что если OCE и было зачем-то нужно, то только чтобы подтвердить эту озвученную выше мысль: наукоемкий софт индустриального качества НЕ пишется в «базарном» стиле.

Шаги навстречу

Спустя некоторое время было опубликовано сообщение о намерении компании-разработчика сделать первые шаги навстречу сообществу. С этого сообщения начинается систематическая работа по улучшению прозрачности экосистемы OCCT для стороннего разработчика. Результатом этой работы стало создание сайта разработчиков Open CASCADE Technology и ликвидация практически всех пробелов, указанных активистами OCE в самом начале их деятельности. Кроме того, OCCT «переехала» на лицензию LGPL, была внедрена процедура сборки при помощи CMake, открыта нерегрессионная тестовая база, предложена «дорожная карта» (roadmap) развития и новый форум. Осталась ли надобность в OCE?

По плодам их узнаете их

Чтобы окончательно разобраться с вопросом OCE, можно просмотреть список тех изменений, которые были сделаны сообществом за 3 с лишним года их существования. Метод прост как мычание: идем в багтрекер OCE (на GitHub) и аккуратно просматриваем каждую запись. На момент начала анализа, было обнаружено порядка 500 багов. Выглядит многообещающе. Или не совсем?

Сейчас нам интересно понять, какие реально проблемы решались сообществом OCE. Для этого можно классифицировать каждый баг относительно той функциональности, к которой он относится. Известно, что OCCT — библиотека весьма многогранная. Помимо компонент, напрямую связанных с геометрическим моделированием (B-сплайны, алгоритмы пересечения геометрических примитивов, булевы операции и т.д.), в ней нашлось место подсистеме визуализации, обмена данными, триангуляции и множеству самых разнообразных вспомогательных модулей. Табличка ниже иллюстрирует функциональные классы, к которым может относиться тот или иной баг. Эти классы реально используются в официальном багтрекере OCCT.

Посмотрим для начала на вклад официального разработчика в приведенную копилку, начиная с версии OCCT 6.5.1 (первая после casus belli 6.5.0). Всего на момент написания этой заметки были доступны следующие официальные релизы: 6.5.1, 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.6.0, 6.7.0 и 6.7.1. Каждый релиз по всем правилам хорошего тона сопровождается release notes документом. Эти документы, в свою очередь, содержат полную раскладку по исправленным багам и новой функциональности применительно к каждому конкретному модулю OCCT. Важно заметить, что часть фиксов приходит, безусловно, от сообщества сторонних пользователей OCCT. Мы не станем разбираться «кто исправляет баги», а посмотрим лишь на основные метрики процесса: самые часто обновляемые модули и количество изменений в каждом.

Понятно, что с точки зрения инженерной ценности библиотеки, далеко не все категории являются равнозначными. Так, система сборки OCCT не может быть поставлена в один ряд с ее геометрическими и топологическими алгоритмами в силу очевидных причин — именно последние составляют know-how, присущий Open CASCADE Technology. Утилиты для сборки, тестирования и документирования являются по своей природе лишь своего рода «стапелями» вокруг полезного ядра библиотеки, в котором заключена вся его ценность. Давайте оставим только те категории записей из багтрекера, которые и формируют ядро:

Официальная библиотека OCCT в ее текущем состоянии имеет вполне жизнеспособную процедуру для сборки, снабжена юнит-тестами и хорошо документирована. Качество кода постоянно улучшается, о чем свидетельствует непрерывно сокращающееся количество «ругани» со стороны компиляторов. Поэтому в инфраструктурной части официальные релизы OCCT едва ли могут проигрывать OCE. Но, подчеркну, даже если это и так, то эти факторы по сути своей глубоко вторичны. Мы же сфокусируемся на функциях ядра и посмотрим с этого ракурса на изменения, происходившие в рамках OCE.

Увы, бОльшая часть работы, проделанной в рамках OCE касается инфраструктурных вещей. Те фиксы, которые могут быть формально отнесены к геометрическому ядру или смежным модулям (Data Exchange, Visualization, OCAF) не составляют и 5 (!) процентов от объема работ, проделанных официальным разработчиком библиотеки за 3 года. Те же патчи и обновления, которые как-то касаются собственно полезной функциональности ядра, в большинстве случаев незначительны и очень локальны.

Приходится констатировать, что OCE не может претендовать на замещение оригинальных версий OCCT. Отсутствие стратегического курса развития, ограниченность ресурсов, недостаточность экспертизы и незрелость установленных практик управления проектом делают OCE весьма похожей на китайскую подделку OCCT. Глубокое недоумение вызывает сам факт существования OCE, которая уже сыграла свою позитивную роль для придания нужного импульса официальному разработчику. Официальная версия OCCT теперь стала близка к сообществу пользователей как никогда ранее. В то время, как OCE занимается возведением все новых «строительных стапелей» вокруг полезного кода, OCCT обрастает живым мясом в виде новых численных методов, алгоритмов геометрического моделирования, алгоритмов визуализации и проч. Не имея достаточного ресурса для разработки новых подходов и моделизационных алгоритмов, OCE обречена на подбирание крошек со стола старшего брата, который занимается развитием библиотеки всерьез.

Даже если допустить, что в 2011 году у OCE была какая-то идеалистическая идея о недопущении гибели библиотеки OCCT, то какова эта идея теперь?

Аппендикс или "как мы фиксим баги"

Дюже много бриллиантов там я находил... Кто сказал, что OCE не «лечит» каскейд от багов в моделировании? Ведь есть же и такой безусловно заслуживающий внимания вклад, как, например. https://github.com/tpaviot/oce/pull/338. Читаем внимательно комментарий:

BOP_WireEdgeSet::IsClosed() is bogus, it always return false, but sometimes after lots of unused computations. So let it return false immediately

Это настолько трогательно, что так и просится в эпиграф...

Обновление от 07.11.2016

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

Regarding further development: it's pretty clear now that the original maintainers don't really have much time for this project anymore... I don't really have much time for this anymore but I don't want to see this project die either...

И еще:

It is unfortunate. I finally gave up on oce and installed occt 7 just a little while ago.

Что ж, это была поучительная история, не так ли?