Hi everyone,
Thank you so much for your kind words, feedback and investment in seeing OpenFL succeed. From 2010 until 2020, I had a full-time paid position that connected full-time to developing OpenFL. Ironically, I lost the last position due to success: 1.) OpenFL was accomplishing everything the company needed and 2.) the company was more profitable than ever with shelter-in-place revenue.
My personal life was upended soon after, so since then I have been trying to 1.) provide for my family and 2.) learn healthy limits for myself. I am learning (for example) I am capable of performing only one job well at once. This means my source of income will have to become more aligned with OpenFL if I am to continue making worthwhile investments in the project.
I can foresee two diverging paths, and possible steps for each.
Option A – Maintenance
I am not sure how often I said this out loud, however my personal goal for OpenFL was to provide an “ark” to support friends and allies (present company included!) and enable them to be profitable both during and after the death of Flash Player. With this goal in mind, I believe this mission has been accomplished. We are all standing, whether we are profitable with OpenFL or have moved to other fields or other modes of work.
If we take this path, the goal is to keep OpenFL running smoothly. It works, let’s keep it working when Android releases an SDK update, when Apple makes a change, or when we can improve the performance or accuracy of a feature.
I would recommend either more rigorous release testing or limiting features. A regular release schedule could be determined, perhaps even like Ubuntu where releases will occur regularly regardless of the number of changes. With a focus on stability, the goal would be to focus on adding new features in other libraries and allowing OpenFL to continue to work as it has, without architecture changes.
Option B – Growth
First, I think a conversation about a growth stategy must start with honesty about the ecosystem today as a Haxe developer. I have spent over a decade working to promote Haxe, and largely working to build the features I wanted (or needed) without the benefit of a larger ecosystem.
- The Haxe language
I love the Haxe language. I wish it were optional for users of OpenFL (or a technology based on/inspired by OpenFL if we’re taking about continued growth). Cross-platform development 10 years ago was exciting. Windows, macOS, Linux, Android, iOS, BlackBerry, webOS, Tizen, HTML5, Flash, and other untapped possibilities like Windows Phone. Now an increasing number of applications are all written with web technologies in a native shell.
- Haxelib
I love the “official” nature of Haxelib, though it has serious restrictions that hamper its use in production. I have talked about this before (and contributed multiple times to pull requests for Haxelib), however, the lack of a Haxelib “self-update” command and no wildcard versioning are partially responsible for the current OpenFL and Lime monoliths.
- Complexity
OpenFL is needlessly complex. Granted, it accomplishes (and tries to accomplish) things that few (if any) other platforms even attempt. After time away from the project, even I was struggling to wrap my head around certain features.
If the goal is to continue to grow OpenFL in terms of functionality, I would want to continue to hammer it into a simpler form. In essence, I would want to try to reduce things to libraries or packages that do one thing or have one job. I would want to avoid circular dependencies and complex builds. For example, Lime’s build artifacts must be placed within its source directories in order to actually use the Lime library.
A lot of what OpenFL does is magical. I would want the magic to be optional.
- Clearer points of collaboration
For example, “The Lime NDLL” or “OpenFL TextField” as completely isolated teams. Structuring to allow agency and success with domain-specific knowledge.
- Full-time attention
Naturally, I start putting myself in the position of rolling up my sleeves and working on this effort. To a fault, I often rely on myself as a component of the solution.
For this second path to be fully successful, I may need to move to a job title that overlaps with work on OpenFL, or there may need to be a clear pass of the torch.
- Divergence for Porting vs. New Code
When writing new code, there is a benefit of having a smaller, well-tested, well-documented and well-defined library. On the other hand, when porting from Flash it is a greater benefit to provide as broad of support as possible, even if the features are only stubbed out or undocumented.
I believe a plan focused on long-term growth must consider both of these use-cases, and possibly divide out the compatibility features into a separate library, or have separate entrance points into the platform. For example, if OpenFL was built using Pixi.js, the core is there for new users, while the full platform is there for compatibility. I have no desire to make OpenFL use Pixi.js, however I think that helps illustrate the idea.
Which path do we choose?
I would be interested in the desire here for either Option A (Maintenance), or Option B (Growth). My full-time employment probably also plays a significant factor.
What do you guys think?
But right now there is simply no point for it, imho, in terms of “platform features”