OpenFL Updates and Budget

Hello everyone!

It’s been a year since Lime (7.9.0 (03/10/2021)) and OpenFL (9.1.0 (04/10/2021)) were last updated, at least on haxelib.
At the moment my Lime version is full of little hacks and fixes, that I’ve done myself for it to work.
Thus I wonder what prevents those bugs to be fixed sooner and Lime/OpenFL to be update regularly?

I understand there is covid situation and all the crazy things happening, but nevertheless.
OpenFL has monthly contributions from donors in amount of ~$700.
I don’t mind to donate more, but I have no idea how are these money spent.

So, how are those money spent? :slight_smile:
Does OpenFL needs more donations?
Can more people be paid to close issues and release updates faster?
Can we see OpenFL budget, income/expenses?

My questions is more for @singmajesty and everyone else involved in the development.

Thank you!


These are good questions. I love seeing new updates as well, so any news on the status of things is very welcome.

1 Like

There’s still quite a lot of work being done. In recent times, @joshtynjala, @singmajesty, @Dimensionscape, @player_03 and @MSGhero appear to be offering the bulk of commits (sorry to anyone I missed) and there’s of course active community input on Discord.

These recent commits are only available on the development / GitHub version though, with the last release being a year ago, as you say.


Is the Sun setting on OpenFL: A brief presentation

Any thoughts or considerations?

1 Like

I think that some kind of project management committee where members can vote to do a release, including some having privileges to submit to Haxelib, would be beneficial to both OpenFL and Lime. A year between releases is feeling particularly rough right now because both OpenFL and Lime on Haxelib have serious bugs. The latest Lime on Haxelib can’t build for iOS. The latest OpenFL on Haxelib has text regressions that have been fixed on Github for a while. From a personal perspective, both of these are critical for Feathers UI and its upcoming stable release.

I think that the Lime restructure to remove lime-tools as a strict requirement could have some benefits, but it feels like it might be too drastic a change right now. There are sure to be some growing pains as things stabilize after the restructure, and it may take some time before everything is finally nailed down. I feel strongly that it would benefit the community to have a release before that happens to make it more likely that people can upgrade to a version with the bug fixes they need. I’m sure that some members of the community will delay upgrading if it seems like the changes are too big, or if they worry that it will actually introduce instability, and they’ll lose out on the hard work we’ve put in lately.

Unfortunately, I made what now seems like a bad assumption that the releases of Lime and OpenFL are getting very near. I planned to release the stable Feathers UI 1.0 around June. However, I’m no longer confident that can happen because I believe that a Lime restructure could take much longer. Maybe I’m wrong, but it’s hard to say because the Lime restructure hasn’t had any public progress in nearly a month after the initial flurry of activity.

I agree strongly that a focus on writing documentation (especially for beginners who never used Flash/AIR), fixing bugs, and improving cross-platform consistency should be the biggest priorities for OpenFL’s future. What’s there today is a really solid foundation, which just needs a little love to truly shine. Unfortunately, the places where OpenFL/Lime needs the most love now isn’t the cool/fun architecture stuff. It’s kind of work where you roll up your sleeves, crawl around in tight spaces, and get a little dirty.


I think both @joshtynjala and @Dimensionscape have lots of valid points on OpenFL progress and what needs to be done.
I also understand that not everyone wants to be involved in development, like myself, especially when we talk about “It’s kind of work where you roll up your sleeves, crawl around in tight spaces, and get a little dirty.”
Thus my emphasis on donations, as we can motive willing developers by rewarding them.

“Project management committee” or some kind of back up team would be great, so we will not end up in a situation like with FlashDevelop, where the one of the last contributors can’t make a release build and project is just slowly dying.

But we need a response from @singmajesty!

Also I want to say thank you to @joshtynjala for amazing Feathers UI, even though I’m just using a tiny part of it, it helped to fix one nasty problem in my own games.

Thanks to everyone for sharing your thoughts! :slight_smile:


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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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?


I guess that the best match for me, between those two options, is probably: maintenance. As long as maintenance still includes contributors like me being able to add missing features from Flash/AIR that OpenFL doesn’t include yet, and being able to improve parity for things that currently behave differently across platforms. I’m happy enough with the current architecture. If the sort of major reorganizations in OpenFL 9 (which I think is mostly reverted now) or Lime 8 (still up in the air) keep happening, it doesn’t leave me confident that I am building on a solid foundation. It won’t “enable [me or the users of Feathers UI] to be profitable”.

I’m happy with the Haxe language. It may not be super popular, but I can’t think of another language that works so well for targeting both the web and native on mobile/desktop. It’s easy to learn too. A rebuilt OpenFL with a language that can target only the web (JS/TS, for example) would lead me to consider alternatives (or even forking). I am not interested in something that forces me to use web tech everywhere (such as with Electron/Cordova/Capacitor). I like having those options available, but I’m not often going to choose them over compiling to C++ native, which will run significantly faster (especially on mobile). And Haxelib isn’t perfect, but it feels good enough for me. I think I’ve seen clues that the Haxe folks want to improve things in Haxelib a bit, so I’m looking forward to seeing what might come of that.

It seems to me like you really want to diverge greatly from the current OpenFL, @singmajesty. There’s nothing wrong with that, of course, and that effort might very well end up with something really cool. However, maybe that doesn’t necessarily need to be OpenFL anymore, but a new project. Kind of like how the creator of Node.js later started Deno. Both Node.js and Deno have a lot of similarities, but they can grow and change independently as separate projects without Deno replacing Node.js. I don’t know, man. Just brainstorming a bit.


why cant you just “take over” operating development? I mean, is there an issue to that happening? You are clearly invested, so why not?

… or, a fork? I mean… its a thing.

EDIT: my involvement / interest in this is minimal at best, so ill bow out :slight_smile:

1 Like

Hi Josh,

I appreciate your feedback. “Option A – Maintenance” reflects the current path we’re on.

I agree. I like Haxe and it is the best tool for targeting both web and native technologies without the compromises of “native everywhere” (Web Assembly) or “web everywhere” (Electron et. al)

Maybe we really have a few small asks?

  1. An increased cadence of releases on Haxelib
  2. More communication between contributors around release schedules
  3. Confidence Lime will remain stable

Yeah, that all sounds good to me. I think it makes sense to try to simplify the build process to avoid the circular dependencies. I feel like that’s not a huge change, but you would know better than I do.

1 Like

I guess that sums it up a bit.

Just having this discussion is a pretty big step in the right direction and makes me feel more confident about how things stand, overall.

I have also thought about the possibility of just forking from OpenFL in the past, but a situation where we all go on supporting our own divergent fork can be averted and its probably the most unhealthy thing that could happen right now.

From what I’ve picked up, we each have our individual grievances about the framework and we all have areas that are important to each of us that we would like to see improved, whether its a bug fix, a behavior fix, implementing a missing feature, or finding that bit of elusive documentation that doesn’t seem to exist. Sometimes these interests align with one another and sometimes they’re more personal in nature.

From my honest perspective as a contributor over the past couple of years, it has really just felt like the “Wild West” in terms of focus and collective direction. For my part, I’ve tried to work closely with Josh in order to make TextField more stable, keeping a line of communication flowing and reaching out when our interests align(feathersui is heavily dependent on text, for example). I’ve also communicated very closely with Joshua in order to fix miscellaneous bugs and introduce various missing APIs. They are both super talented developers and awesome people that I have a lot of respect for, but it takes more than a bit of effort for me to keep these kinds of chains of communication going in what should be a more fluid, open-ended, team-like environment with an open exchange of ideas. That’s not to say that there is a hostile environment, because there absolutely is not - it’s just that communication has just been really weak in my opinion. For example, lets have a thoughtful discussion about something big like an architectural change and come to some agreement about what works best and in what release time frame.

With that said, I love OpenFL and I’m indebted to all of the developers that helped get it to this point, directly and indirectly. I’m also in it for the long haul. The topic of my power point was supposed to be a little provocative. In the end, I think OpenFL is too big and complex for any individual and far too big and complex for a wild west approach. Even so, everyone contributing has been doing awesome things and I am grateful for everyone in the community that plays a part to keep moving the needle forward.


I have some practical suggestions, meanwhile, I think it is important to decide where the best place would be to sort out details. Here? Discord? Private, public?

Let’s suppose we adopted a regular release cadence:

  • Patch version releases (no new features or breaking changes) – Monthly + additional releases if there is an urgent demand
  • Minor version releases (new features allowed, no breaking changes) – Every six months
  • Major version releases (breaking changes) – Perhaps never :wink:

I believe that would lead to the adoption of some branch management on

  • A stable branch with fixes and improvements that are neither breaking nor add new features. This is ready to be released at any time for an urgent need or the scheduled release cycle.
  • A minor version branch with completed, ready-to-release new features to be integrated in one place. This can be used for developers who are relying on a new feature before the scheduled minor version release.
  • Branches (as needed) around feature sets and organic contributor teams. A “textfield” branch could be in active development, then periodically integrated into the “future” branch as it is stable, which would be merged finally to the master development branch when a minor version is to be released bi-annually.

Rather than building teams around smaller repositories or specific folders in the repository, we can build teams around the feature branches (like “textfield”) and use them for active feature development without deleting them. These branches stick around for future feature development, and so does the team structure.

My excitement tends to revolve around major restructures. I think it would be wise to recuse myself and put OpenFL on a path of patches and feature improvement rather than remodeling. It sounds like the majority voice here is to create an OpenFL very much like the one we have today, only incrementally more robust. It also sounds like we have people in the room who are willing to be a part of that effort.

Again, let me know what forum you guys think is the best place to hammer out the details, though putting some things on rails (like pre-scheduled release types and dates and some team management around pull requests or branches) would help ensure OpenFL continues to become “a little faster and a little better” every step of the way as we cheer on :smiley:


I’ll vote for the Maintenance option also. The less wide-sweeping changes we have, the better chance we can get on top of the missing documentation, which is the main friction I experience when using OpenFL.


I think OpenFL’s biggest problem is practicality.

All the popular game engines today have some tools for ui design etc.

Moreover, these tools not only create the ui, but also optimize the ui. (like reduce drawcalls)

OpenFL sucks at this, ui is very difficult to build and unnecessarily expensive.

This must be solved because it has become very easy to make games today, one of the reasons why game engines are preferred today is practicality, because the faster companies/users can create games, the more support they provide.

At this point, my suggestion would be to optimize the swf library and fix its issues. (Like merging all swf assets in 1 spritesheet and custom swf renderer)

Moreover, In a game, the ui designer should do the ui work and the software work should be done by the programmer, but I think that the lack of a tool to provide this keeps people away from this platform.

I mean, separating such processes into tools allows more than one employee to work on the project at the same time.

If you ask me, the biggest difference between OpenFL and Flash is practicality.

So I think if we want OpenFL to have a specific community there are a few things we need to do (Sorted by priority)

  • UI Tool and UI Optimization (or may be optimized swf library) (I think the most important!)
  • Fixing bugs
  • Implement missing features
  • New tools for make some works easier

I also vote for maintance. For me, OpenFL(+starling) targets very clear gamedev niche (2D) and it is already has everything needed for the task, literally. The only problem are per-platform quirks and cases when things are not working as advertised… this is perfect fit for maintance mode. And after a 1-3 years of maintenance, in case there is something really new and shiny stuff arise - the mode can be changed again, right? :slight_smile: But right now there is simply no point for it, imho, in terms of “platform features”

1 Like

For sure @ Ilja_Razinkov has a point! OpenFL seems great for me as it is now, very useful. Entering maintanace would be nice!

Thanks everyone, we have heard your feedback! :smiley: