ba-dum-tss
...I see :P. Well, you've definitely got a really nice visual design so far, at the very least. I say keep it; the aesthetic (Excel-ness and all) looks good. (That said, now I know that it's Excel, I do strongly associate the visual style with Excel... so there is that. Could be me though.)
To open or not to open is certainly not a decision that can be made lightly, so careful consideration FTW.
On the one hand, this is a fairly unique, original idea, and not something that's been explored all that much, so there isn't that much competition. It would make for a very special product (if you made it standalone) or component (if you just used it in FF) and put you in a very unique position.
But if you stay closed, development and evolution would be driven soley by the experience level (and available time) of the development team behind FF.
On the other hand, language design is incredibly nuanced because of all the offerings that are available out there, and it takes a lot to make a language succeed, both design-wise and implementation-effort-wise. There's also a lot of technical competition - people will flock to whatever's easier to use, less buggy, more developed - and, lately, what's more active.
On top of that, visual languages are a very special case scenario. Considering there's so little out there in terms of visual languages, in a field where academics and tinkerers are constantly trying every possible combination, it's clear that for systems like this to make it, they must provide just the right amount of flexibility/functionality: too little and they'll be frustrating too use, too much and they'll lose design coherence. I suspect the sweet-spot for this level is less generalized than that of common programming languages.
There are people out there that really know language design, know the pitfalls, have made the mistakes, etc, and it would be ideal to be able to get anchoring design/implementation advice for the core system from this hivemind, especially considering the experimental direction you're trying to go in. (This would logistically be significantly trickier, if not absolutely impossible, in a commercial context.)
A few open-source models I can think of off the top of my head, which I've observed and taken vague mental notes on over the years (I feel like I'm forgetting the important ones):
- Fully open, code released as-is; no support, patches/PRs only - popular among burnt-out developers (possibly with soul-crushing jobs)
- Periodic (weekly to biyearly) code-dumps released as-is; full commercial support - the codebase is open so people can tinker with it, but everyone knows the party's where the private repo's at, and the open code dumps are so badly far behind in the dust, there isn't much activity on the open codebase
- Open-source version as-is but supported; commercial version has added magic unicorn pixie dust - interact and make the open-source version feel like it has a nice big community/hub atmosphere around it and you'll eventually attract contributors. (Proceed to spend 90% of your time breaking up catfights among said contributors.)
- Fully open-source; random company decides it's the perfect thing to base their internal stack on - development track must be well-defined in order to to compartmentalize personal goals while prioritizing contracted feature requests
- All program source and related assets placed into the public domain - developer is insane
I write the above as a more-or-less-non-developer with no real-world practical experience. I'm still collecting ideas and methodologies and working out which ones to use where.
One thing I've seen reiterated various different ways is having clearly defined limits. Without this, I've heard you can can wind up having to deal with types who'll send in the support request equivalent of leaving a 10lb dumbbell on the accelerator and walking away... yes, open source can occasionally look like a perpetual motion machine, but that's largely an optical illusion, there are real people behind the support buttons and algorithmic magic.
Something that will be incredibly useful in my case is cultivating consistency: I'm currently figuring out how much public-facing interaction (commit frequency, reply latency, general visibility) I can handle on a really bad day/week/month, so I can then stick to that level regardless of where I'm at. On a good day keeping up everything will only require very little of me, on a bad day I'll still be able to poke stuff without getting too badly bitten. I expect you've already established this with FF, but this type of thing needs to be more explicitly defined in an open-source context (where there's a lot more interaction).
Another useful thing that I think might be relevant here is the idea of closed betas: the code is technically open source, but everyone agrees to keep the lid on it until some specific point in the future. This is ideal both for solidifying project design and incubating an initial userbase who will not be able to help but share it when it goes open :D (I will mention, however, that I'm aware of projects out there that have been invite-only for years (due to licensing issues, looks like) and it's driven me crazy that I have to commit to signing up to the (free) project's beta in order to take it for a 30sec spin. The ideal solution to this, I think, would be keeping it predominantly private and only doing limited publicity; with good ideas, this won't be damaging.)