В этом году доклад Роберта был не таким техническим как ранее, т.к. за прошедшие полгода произошло не так уж и много. Этот доклад он посвятил проблемам сотрудничества в рамках Haxe-сообщества, и Kha в частности.

Видео-версию доклада можно найти на официальном сайте Haxe.

Прежде всего Роберт отметил, что Haxe-сообщество слишком разделено - для всего есть несколько решений, которые конкурируют между собой: Kha vs OpenFL, VSCode vs HaxeDevelop, try.haxe vs KodeGarden...

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

В первом случае была попытка разработки общего формата для С/С++ библиотек, который позволил бы использовать такие библиотеки компонентов в разных фреймворках (Kha, OpenFL, NME). Было долгое обсуждение проблемы, разработан общий план действий, однако никто не стал продолжать работу по этому плану. Даже сам Роберт забыл об этом плане и вспомнил о нем только когда готовил слайды своей презентации.
Другой случай касался обобщенной системы сборки для C/C++ проектов. Кроме очень интересной дискуссии из этого также ничего не вышло.

Далее Роберт поделился мнением о том, каким в идеале должно быть Haxe-сообщество, и чем должен стать Haxe, а именно - он должен доминировать в мире IT :) 

Он сравнил популярность Haxe с Ruby и Go, ставших гораздо успешнее. При этом ясно, что Go стал популярен благодаря компании Google, в которой этот язык был создан и используется. А вот популярности Ruby по его мнению способствовал случай.
К сожалению запланировать такую случайность для Haxe невозможно и нужно действовать иначе.

В качестве положительного фактора Роберт указал существование Haxe Foundation, действующего с целью развития языка, компилятора и средств разработки. Это выгодно отличает Haxe на фоне многих других open-source проектов, которые далеки от такого уровня.

Однако кроме Haxe Foundation в мире Haxe существуют отдельные от него проекты (OpenFL, Kha, множество маленьких библиотек), но они не так организованы, большинство из них работают над своими проектами в свободное время или данные проекты являются побочным продуктом профессиональной деятельности отдельных лиц. То есть напрямую им никто не платит за развитие своих проектов (а денежная составляющая является одним из самых сильных мотиваторов к продолжению работы, в том числе и совместной).

Далее Роберт спросил, почему мы продолжаем заниматься чем-либо. И ответом на этот вопрос по его мнению является - возврат инвестиций (результат деятельности, который не всегда выражается в деньгах) - Return of Investment (RoI).
С целью определить, почему присутствующие в зале занимаются open-source проектами, он провел небольшое голосование со следующими вариантами ответа:

• просто убить время (так никто не ответил);
• ради денег (около половины подняли руки);
• ради славы (кто-то в зале поднял руку);
• просто, чтобы быть хорошим человеком (несколько человек так ответили);
• из любопытства и личной заинтересованности (Роберт признался, что занимается open-source’ом именно по этой причине).

Все перечисленные варианты могут служить RoI.

И если вы хотите заниматься чем-то совместно продолжительное время, то вам нужно найти такой взаимный интерес (RoI), иначе со временем все заглохнет.
Людям хочется заниматься собственными проектами - такова их природа.
Как уже упоминалось, Роберт занимается Kha из любопытства и личной заинтересованности - он хочет решить проблему мультиплатформенной разработки и считает странным, что вся IT-индустрия не может достигнуть этого.

Желаемым результатом сотрудничества с пользователями Kha для него являются пулл-реквесты, исправляющие баги или привносящие новые интересные фичи.

Говоря о пользователях, Роберт поделился примером неудачного опыта пользователя, который он увидел в Twitter: один очень опытный Unity-программист, выпустивший несколько успешных игр, решил попробовать Unreal engine, но ему не повезло и Unreal попросту упал при попытке импортировать 3d-модель. Такое невезение сразу же оттолкнуло этого человека и оставило негативное впечатление об Unreal. Здесь случайное падение решило, будет ли у Unreal новый пользователь или нет.
Тоже самое можно сказать и о пользователях Kha - часто пользователи могут столкнуться с тем, что что-то не работает или работает не так, как они ожидают, и это отталкивает их от этого фреймворка.
Таким образом, время встречи с ошибкой или неожиданным поведением является критическим для привлечения новых пользователей.
Но есть и обратные примеры пользователей, которым нравится Kha и которые не бросят его при первом встретившемся баге, а попробуют разобраться в чем проблема и решить ее. 
И Роберт, говоря о том, что хочет набрать пользовательскую базу, имеет в виду именно таких пользователей, которые могут принести Kha выгоду (например, исправляя баги).
В качестве наиболее выразительных примеров таких пользователей Роберт привел следующие примеры:

Самый очевидный пример - это Lubos и его Armory - высокоуровневый 3d-движок интегрированный в Blender. Lubos занимается им теперь на постоянной основе и довольно успешен на Patreon (он успешнее LibGDX - Java-фреймворка, который гораздо популярнее и имеет намного большую пользовательскую базу). Кстати, благодаря тому, что на Patreon удалось собрать достаточно денег, очень скоро Armory станет бесплатным.

Другой пример удачного сотрудничества - это HaxeUI от Ian Harrigan. В прошлом году Роберт анонсировал и выпустил KodeGarden - онлайн-песочницу для Kha. Изначально интерфейс KodeGarden выглядел ужасно, и Ian просто послал свой пулл-реквест с новым UI - идеальный случай сотрудничества для Роберта :)

Еще одним удачным примером сотрудничества с сообществом программистов является krafix - кросс-компилятор шейдеров, который используется в Kha.
Изначально Роберт написал свою прослойку, которая конвертировала шейдеры из формата SPIR-V во все остальные (HLSL, GLSL, MSL). Однако позже он нашел проект SPIRV-Cross, который делает то же самое, но лучше оттестирован, более стабилен и поддерживается не одним программистом. Роберт решил использовать его и выбросить свой код, что было непростым для него решением. И теперь он помогает поддерживать SPIRV-Cross, а именно - добавил поддержку HLSL-шейдеров.
Далее Роберт привел примеры сотрудничества, которые из его опыта не работают.
Обычно кто-то просит добавить какую-нибудь новую фичу, которая ему (Роберту) не интересна. В таких случаях он отвечают, что это ему не интересно, но обещает помочь с реализацией, если возникнут проблемы. Дальше этого дело не заходит.

Однако о добавлении одной и той же фичи, изначально не интересной Роберту, могут одновременно просить множество пользователей. В таком случае он может попробовать набросать первоначальный вариант реализации данной фичи. Что из этого выйдет, будет ли удачным эта кооперация, он еще не знает.

И тут мы приходим к примерам такой кооперации, которые только начинаются:
Kha и OpenFL - множество пользователей просят добавить фичи из OpenFL, так как они привычны им. 
Результатом такого взаимодействия станет, как он надеется, увеличение числа пользователей, которые будут помогать в разработке.
Но в то же время, Роберт отмечает, что лично ему фичи из OpenFL не очень интересны, т.к. сам Flash ему не интересен и он использовал его только в одном проекте, поэтому ему сложно оставаться мотивированным, работая над поддержкой OpenFL в Kha. Также он надеется на помощь со стороны пользователей с тестированием кода, т.к. сам может не знать всех особенностей поведения Flash.

С целью прощупать интерес к этой задаче среди пользователей он провел краудфандинговую кампанию по сбору средств на Super Nintendo, которая прошла успешно. 

“И с тех пор он только и делает, что играет в нее. На этом все. Спасибо!”

На данный момент нереализованной остается поддержка Graphics API - поначалу Роберту показалось, что графика в OpenFL отрисовывается с помощью OpenGL (т.к. в OpenFL есть класс GraphicsGL), однако это не так и графика рисуется с помощью софтварного Cairo-рендера. Ему не хочется использовать это решение, поэтому в настоящее время он работает над библиотекой для векторной графики, которая бы полностью работала на OpenGL API.
Вы можете посмотреть на код здесь https://github.com/Kode/openfl/
Не ждите чудесного прироста в производительности, т.к. Роберт портировал код один в один, не изменяя его архитектуры (пока что). Но работая поверх Kha, OpenFL теперь можно дебажить в Kode Studio.
Также Роберт еще раз попросил помочь ему с тестированием этого кода, т.к. он не знает как точно он должен работать.

В качестве примера работоспособности его порта OpenFL на Kha Роберт показал традиционный BunnyMark тест.

Kha и Heaps - работать над этим проектом оказалось проще, т.к. в Heaps есть абстракция над 3d API (благодаря этому Heaps может работать как с OpenGL, так и с DirectX).
Но Роберт столкнулся с одной серьезной проблемой - работа с шейдерами.
В Heaps шейдеры компилируются во время исполнения программы, а в Kha используются предкомпилированные шейдеры (компилируются во время компиляции C++ проекта).

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

Так что Nicolas может ожидать скорого пулл-реквеста в Heaps.

Далее Роберт остановился на том, почему он создал Kode Studio - IDE для Kha.
И что множество пользователей жаловались на то, что хотят вместо нее использовать другие IDE.
Причиной для создания Kode Studio была ограниченность механизма расширений в VS Code, который разделяет процессы расширений. 
Однако теперь он работает над переносом функций Kode Studio в отдельные расширения. Они не будут иметь все те же возможности, что Kode Studio, но все же позволят работать в чистой VS Code.

Роберт завершает работу на расширением для VS Code для отладки приложений с помощью electron.

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

При этом Роберт не собирается забрасывать разработку Kode Studio.
На днях он выпустил Kode Studio в Steam - https://store.steampowered.com/app/779260/Kode_Studio/ 
Также в скором времени возможен релиз в Windows Store (нужно дождаться ответа со стороны Microsoft).
Релиз в Mac AppStore также возможен, но для этого необходимы доработки. 

Далее Роберт перечислил направления, по которым он хотел бы поработать совместно с разработчиками других фреймворков.
Во-первых, это уже упоминавшаяся обобщенная система сборки проектов.
В Kha в качестве такого инструмента выступают khamake / koremake. Их сильной стороной по мнению Роберта является то, что на выходе мы получаем проект для MS Visual Studio или для XCode, а в этих IDE имеются все инструменты для отладки и профилирования приложений.
Недостатками же он считает то, что:

• они написаны с использованием TypeScript (не все захотят работать с таким кодом :)
• пока что они слишком сильно завязаны на Kha / Kore и нужно переработать их, чтобы избавиться от такой специализации.

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

Во-вторых, это адаптация KodeGarden для работы с другими фреймворками, а не только с Kha. У KodeGarden следующие сильные стороны по сравнению с try.haxe:

• возможность писать графические приложения;
• поддержка бинарных ассетов и более крупных проектов;
• интеграция с гитом - для каждого проекта создается отдельный гит-репозиторий, благодаря чему есть поддержка истории (Undo/Redo), а также можно форкать чужие проекты;
• используется редактор Monaco со всеми его фичами.

Недостатками KodeGarden Роберт считает:

• отсутствие поддержки макросов;
• отсутствие нормального автокомплита.

Третьим пунктом возможного сотрудничества Роберт назвал возможность предоставить доступ к модулям, обеспечивающим поддержку консолей (PlayStation 4, Xbox One, Nintendo Switch).
Доступ предоставляется бесплатно, для этого нужно иметь действительный аккаунт разработчика для консолей (необходим по юридическим причинам).

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

• студенты Роберта создали ряд тестов производительности 2d-движков
• сам Роберт обещает провести ряд стримов, в рамках которых он реализует 2d-рендер на базе G5 класса (абстракция над Metal и Vulkan API)

От сообщества Роберт ожидает помощь с улучшением и разработкой новых тестов.

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

В качестве итога, Роберт высказал идею, что т.к. Haxe-сообщество сильно разделено (по разным признакам, таким как используемые фреймворки, области применения, целевые платформы и т.д.), то сотрудничество не всегда будет простым. Но мы всегда должны думать над тем, как нам добиться этого. И это волнует Роберта.